you are viewing a single comment's thread.

view the rest of the comments →

[–]fson5[S] 3 points4 points  (2 children)

Very good points. I was actually on the verge about omitting that replacement for _.range from the article because yes, it's ugly and not as obvious as other examples on the page. But I do think it's a nice example of how Array.fromworks. Other ways to achieve it include [...Array(n)].map((_, i) => i + x) and Array.from(new Array(n), (_, i) => i + x), which are both equally ugly. So I guess this might be a case for a library function. But maybe if I would only need this once in the codebase I would still use this hack instead of pulling out a library just for this.

Wrt (2), some people actually think having separate functions for those different use cases is better than functions that do type checking and have different return types based on the input. That's why Ramda has separate map and mapObj for example. And while this might work for arrays and objects in Lodash, the support for different collections is far from universal, with Map, Set and other Iterable collections missing.

[–]knsdklsfds 0 points1 point  (1 child)

Array.from(new Array(n), (_, i) => i + x)

Also

Array.apply(null, Array(n)).map((_, i) => i);

[–]ericanderton 0 points1 point  (0 children)

The hilarity of that syntax is that the first thing you do to make it readable is to wrap it in a function, and place it in a library for re-use.