5 ms·
Shouldn't it be ".map(([prop, value]) => ...)" ? I like to write it this way, using as much syntax sugar as possible: const mapObject = fn => obj => Object.as
by djfm 9y ago
Shouldn't it be ".map(([prop, value]) => ...)" ?
I like to write it this way, using as much syntax sugar as possible:
const mapObject = fn => obj => Object.assign(
...Object.entries(obj).map(
([key, value]) => ({ [key]: fn(value) })
)
);
- komali2 9y ago>using as much syntax sugar as possible It's not possible to say this on the internet without being rude so, apologies, but, why code like that? It genuinely was a struggle to parse (in my brain) your oneliner of code there. If I found this in our code base it would be a huge waste of time and energy.
- water42 9y agothe trend of style over readability. google recommends avoiding list comprehensions in python yet 99% of stackoverflow python questions have some convoluted list comprehension answer
- djfm 9y agoNo offense taken. I said I like to write it this way, not that I always do it. > why code like that It's a fun exercise. > it would be a huge waste of time and energy I don't fully agree on this: from the name and signature it's pretty clear what the function does, so you don't need to waste time "parsing" the details. And with unit tests it is also very low-risk. But that's speculative, in a real project I'd just use lodash.
- rmrfrmrf 9y agoIn production code, if I ever have clever one-liners, they're usually offset with just as many additional lines of comments to explain what it's doing and why it works. Plus, this function is generic and would probably be extracted into a utility module, anyway. To your point, though, this one is pretty esoteric.
- deleted 9y ago[deleted]
- tracker1 9y agoI really like that... I've tended to use Object.assign in a reducer, but this works too, and is a little cleaner imho
- thomasfoster96 9y agoYep, it should be. Thanks for catching it.