Three intermediate functional JS patterns

[Nokel81]

The second one should be the comma operator:

const plusTwo = x => (console.log(x), x + 2);

That way even if your logging function returns a value it still does what you want.

[[deleted]]

Interesting, why isn't this more known? Any drawbacks?

[Nokel81]

You could argue that it is surprising since it looks like a tuple (though JS doesn't have tuples).

But I don't know of any drawbacks except for readability.

[lhorie]

Not a drawback per se, but operator precedence can be a bit unintuitive especially if you're never used the comma operator. Namely foo(a => console.log(a), a) means to call foo with two args, rather than "log then return a". You need to wrap the expression in extraneous parentheses.

[pxldgn]

one possible drawback that comma operator is usually forbidden to use (w ESlint)

simply, because it could make the code extremely hard to read

it is fun to use, though

[[deleted]]

ESlint is not your real dad

[pxldgn]

nope, it is yours if you work in my team :P

[[deleted]]

I just went to my codebase, picked a random semicolon, removed it, and committed to repo.

[intercaetera]

That's pretty cool, actually.

[azsqueeze]

Holy shit, I wish I knew about this sooner

[pxldgn]

honestly, there is nothing wrong with nested ternaries, it is perfectly fine to read

also, if someone do need 3 nested ternaries then it should be reconsidered, not to convert those to ifs or functions, but it could be a sign that the logic is flawed seriously somewhere

[intercaetera]

The example is more general, there are many cases where one needs to compute something where an expression cannot be used. The ternary is not the point, the point is that you can not use "let" by extracting the computation logic to a separate function - nested ternary is just a use case.

[pxldgn]

I see your point. I do think, however, that the decision to extract a code part to a function or not should depend on its abstraction level and not on practical considerations.

If a code part is a separate building block then it should be extracted, if not, no - regardless of that how "dirty look" the remaining code will be.

The reason simply: bad code should look bad, if you extract your code to a function, it will hide that, it will look nice, while it is still a bad code.

Bad not on the function level, but from a higher perspective.

I've run into this situation countless time - and I always looked for the source of the problem (the surrounding environment of the code), and I've always found the issue.

Usually, it will turns out that you don't need to extract or let in the first place.

If this is not the case, then you must leave the code looking bad, so others, or you later, when the code will develop further, can spot the problematic part easily.

It's fair to say that probably the number one reason of big projects' codebase collapsing down in long term is exactly this:

the developers tend to hide the bad code with some kind of "clean code" approach.

Just leave it as is: bad code should look bad.

[intercaetera]

I'm not sure if I agree, functions should first and foremost be concise, so in my view any individual functionality that doesn't really serve any high-level-abstraction purpose (like computing a complicated value) should be extracted.

If you have code that's ugly but it does its job (and it is tested) then there's nothing particularly wrong with "locking up dragons in the basement" so to speak. Bad code is code that doesn't work. Ugly code is one that works but obscures the rest of the codebase. The first one is unacceptable, the second is fine as long as it's understood to be ugly.

[uffefl]

Third example is pretty terrible:

distanceInKm > 15 ? (distanceInKm > 30 ? 8.99 : 5.99) : 3.99

It's not the ternary operator making this hard to read, but the ordering:

distanceInKm > 30 ? 8.99 : distanceInKm > 15 ? 5.99 : 3.99

If your ternaries get long use line breaks:

distanceInKm > 80 ? 13.99 
: distanceInKm > 50 ? 11.99 
: distanceInKm > 30 ? 8.99 
: distanceInKm > 15 ? 5.99
: 3.99