Some developers be making things look difficult

Not really a massive difference ey?

Ah yes, fuck readability

nope. fuck that. we're not playing code golf here.

I would remove condition and person variables for they are unused

Fuck that. Not gonna read your conditions spagethi onbly you use.

I liked the rant because I thought that second is plain unnecessary and that this guy shrugs out of pain while trying to transcribe what's happening anymore.
Althought, I don't get your opinion here: it's behind the layers of the layers of sarcasm, I guess.

@vintprox The explanation is...
When initialising an object that has dynamic attributes, you really don't need another initialisation to add the new attributes... You can just use the "spread" syntax which is very handy for that.

@GiddyNaya that I get. But syntax-wise you initialize another object to do a simple property change on condition met.

which one is supposed to be the more difficult one? (if you want elegant code, don't use JavaScript and no JSX either)

@vintprox There is difference between adding and updating... The code block is adding age and that can be done at the point of initialisation.

@vintprox It would be different case if age was to be updated.

@fraktalisman The first.
The developer could have ended the program at initialisation if only they knew about "spread".

If condition is a const why even write an if statement?

@wackOverflow Lol True talk. The message I see though is different since all values are hard coded.

@GiddyNaya I see (but to me as an old school developer who started coding BASIC in the 1980s, the first one is still MUCH more human readable than second one, but maybe I am just getting old).
Second one looks like generated code written by Babel ... or by someone who uses JSX regularly

I'd argue that this would make sense if you wrap the conditional assignment in a helper function with a descriptive name; if not, just stop trying to look smart.

@fraktalisman because it is more readable.

I would say the first one is way better in this case. Have 15 props like this and I would look to optimise that and I guess it is a possible approach depending on the conditions. Could be looping over data structure is the more sensible thing.

Yes indeed. The second snippet looks way more complex than it actually is - making it less readable.

I've been working with React so much lately this seems normal to me. That being said, the first example is better for readability I agree.

@GiddyNaya JavaScript does not really care about init time fields as it can add new ones on the fly anyway

@iiii Some optimisations work better if you put the initialization tightly together, but it definitely does not matter here.

@iiii I get your point and I can agree with the readability here but the main difference between the two code specifically is that the latter has its initialisation at the point of declaration.

No need to do a
...click down
...click down
...click down
add if block here
Just so you can add an attributes when it can be done at the point of declaration.

Javascript is an ugly mess as always, but the task at hand (optionally defining a field) shouldn't require a (re)assignment. I'm starting to see why pure functional languages are so much better than procedural languages with lambdas and a budget array transformation library.

@GiddyNaya it does matter for languages where construction and assignment are different (like C++)

@iiii Yes you're right

No one is arguing about conditional existence of properties? I suppose that’s completely normal in something like JS...
Good god I’m so glad not to be part of this madness anymore.

@Lensflare this whole snippet is a little bizarre. There are lot better ways to write js.

@wackOverflow I don’t even mind this as much.
I just find it very disturbing to see code that explicitly defines objects/structures/data with a property being sometimes present and sometimes not.
IMO, a property should always be there. If the value of that property is missing, that should be represented as null.
Probably, the value of that missing property will resolve to undefined in JS, but you wouldn’t know that this property exists if you just look at some of the objects at runtime.
How is one supposed to use code if you don’t even know about the properties, let alone the types?

It looks like JS coders purposely design their code to be as dynamic, unpredictable and unsafe as they possibly can.
I mean I’ve seen properties with types that can vary, which I obviously dislike. But in the world of that kind of languages, it’s considered normal. But properties that can exist or not, that is another level if madness!

@Lensflare In TypeScript this is fairly common but also safe because the optional property is indicated in the interface definition. You can think of it as an instance of a type that has a known subtype. It doesn't matter until you want to do something with the subtype's properties or methods.

@homo-lorens yeah if the optional existence is declared explicitly then it’s at least a bit better than nothing.
I know something similar from Objective-C, where protocol (interface) methods can be optional.
It sounds nice in theory but has sometimes problems because it is not clear whether the method returns nil because the return value is nil or because the method doesn’t exist. There is a syntax to check for existence but it’s awkward and boiler-platy.
Also, not a big fan of that. Fortunately they got rid of that in Swift.

@Lensflare in this case because the property is set or not at initialization I would agree the value, not the property should be optional and a ternary should be used like age: condition ? 23 : null. You can also implement nullish coalescing operators and optional chaining when referencing optional properties at runtime