71–80 of 97 posts
I've made it a habit to check Mozilla's JS docs once in a while for functions like Flat() and FlatMap(). Sometimes if I find myself reaching for underscore/lodash, I'll check Mozilla docs first to see if there's some new function that can let me omit using lodash. I'm often delighted to find new convenience functions I can just use without adding another dependable.
Is there a Google equivalent to MDN?
Earlier quoted context omitted.
In addition to being essentially a combined "filter" and "map", it's also a "better" filter than filter itself in TypeScript in such that it narrows types much more ergonomically[0]. In TypeScript, you might have an array of multiple types (e.g. `Array `), and use a `filter` call to only keep the `A`s. However, in many situations TypeScript can't figure this out and the resulting array type is still `Array `. However…
I wonder if it is possible to add a feature to Typescript to help with this: You could potentially add a syntax for type guards function types, then add a signature to filter that accepts a type guard and returns an array of the guarded types. Shouldn't be too much of a stretch given that we have type guards. The syntax is a bit annoying... should be something like filter (cb: A => A is B) :/
I don't know why the type isn't narrowed in Array.filter like it is in if statements without this weird workaround.
const array: (number | string)[] = [];
const mixedArray = array.filter(value => typeof value === 'string');
// mixedArray: (number | string)[]
const arrayOfString = array.filter((value): value is string => typeof value === 'string');
// arrayOfString: string[]
[1]: https://www.typescriptlang.org/docs/handbook/advanced-types....
Earlier quoted context omitted.
I often use Lodash’s sumBy, groupBy and orderBy. Love the versatility and one-liner aspect. E.g. sumBy(“orders”, “total.amount”)
Which input method are you using that double quotes are ” (U+201C) instead of " (U+0022)?
Something that people may not see immediately is that flatMap is more general than map and filter. Say, for a contrived example, that you'd like to filter out the even numbers in an array, and then double the odd numbers that remain. Instead of: [1, 2, 3, 4, 5].filter(n => n % 2 === 1).map(n => n * 2) You can do: [1, 2, 3, 4, 5].flatMap(n => n % 2 === 1 ? [n * 2] : []) Again, this is a contrived example, but I think…
If you are looking for really general and powerful, then there is the mighty reduce: [1, 2, 3, 4, 5].reduce((x, y) => y % 2 === 1 ? [...x, y * 2] : x, [])
[1, 2, 3, 4, 5].reduce((x, y) => { if (y % 2 === 1) x.push(y * 2); return x; }, [])
I've always found `flatMap` to be interesting because it feels like a convenience function, combining .map(fn).flat() into one function. It's interesting because JS doesn't really have a lot of convenience functions that are this shallow (ie. that provide just minimal cleanup compared to the functions they're wrapping). Is there some specific reason that `flatMap` made the cut?
probably because flatMap (also called chain) is an important array (or monads in general) function in functional programming. If anything, .flat() is the aberration.
I've always found `flatMap` to be interesting because it feels like a convenience function, combining .map(fn).flat() into one function. It's interesting because JS doesn't really have a lot of convenience functions that are this shallow (ie. that provide just minimal cleanup compared to the functions they're wrapping). Is there some specific reason that `flatMap` made the cut?
probably because flatMap (also called chain) is an important array (or monads in general) function in functional programming. If anything, .flat() is the aberration.
But in a program it usually makes sense to do the flattening in one go, since it avoids the need to do some possibly expensive intermediate calculations.
Earlier quoted context omitted.
I just filed this issue on the MDN page: https://github.com/mdn/content/issues/11763 That note is misleading.
It still creates a temporary [x, 2*x] array for every element though. This is an unavoidable problem with flatMap, while reduce can easily be changed to reuse the same accumulator array, making it twice as fast as flatMap and almost as fast as the simple for-loop approach.
I've made it a habit to check Mozilla's JS docs once in a while for functions like Flat() and FlatMap(). Sometimes if I find myself reaching for underscore/lodash, I'll check Mozilla docs first to see if there's some new function that can let me omit using lodash. I'm often delighted to find new convenience functions I can just use without adding another dependable.
So I still prefer using lodash map, reduce, filter, etc for that added defensiveness.
I've always found `flatMap` to be interesting because it feels like a convenience function, combining .map(fn).flat() into one function. It's interesting because JS doesn't really have a lot of convenience functions that are this shallow (ie. that provide just minimal cleanup compared to the functions they're wrapping). Is there some specific reason that `flatMap` made the cut?
Small mistake, and maybe that's why this function exists, but it's actually combines `.map(fn).flat(1)`. I think conceptually, `flatMap` is a `map` where each iteration can return multiple values (or none). So it feels quite more powerful than just `map` and is a quite common convenience function.
I've been a developer for 15 years and I have rarely found a need for flatMap.