3 ms·

It's fairly easy to roll your own. An example implementation of groupBy in lodash, for example: https://github.com/lodash/lodash/blob/4.17.15/lodash.js#L9393 ht

by tibbar 3y ago

It's fairly easy to roll your own. An example implementation of groupBy in lodash, for example: https://github.com/lodash/lodash/blob/4.17.15/lodash.js#L9393 https://github.com/lodash/lodash/blob/4.17.15/lodash.js#L939.... More broadly, this is an example of a utility function for organizing data in a data structure, which JavaScript and all other major programming languages are well-equipped to implement in arbitrary ways, so this is just a convenience function. It's not like a hook into underlying environment APIs that can't be independently shimmed.

jauntywundrkind 3y ago
Trying to read lodash can (to put it mildly) be difficult. Lots of code reuse. This is probably missing checking for a bunch of corner cases, but this is the general idea: // quick & dirty Object.groupBy function groupBy(iterable, callbackFn) { const out = {} for(const [key, value] in Object.entries(iterable)) { const name = callbackFn(value, key) (out[name] || (out[name] = [])).push(value) } return out } I literally wrote something very like this yesterday (after checking & finding it only got added to Node 21, and deciding not to pull in a dependency). Edit: had keyBy impl in here, fixed! Thanks commenters!
- tibbar 3y ago
  I think `out` should be typed as a map to an array in this case; each iteration should be appending to the corresponding array instead of overwriting the entire entry.
- quonn 3y ago
  That‘s closer to keyBy than groupBy.
- moritzwarhier 3y ago
  Oh yes, I agree. I remember me running into the problem of internal dependencies when extracting parts of it into a non-ESM/non-build project some years ago... Like, the internal consistency of the library probably benefits, and with tree-shaking it works reasonably well but it is still a poster example of DRY vs KISS... It has its benefits, but its API surface can be annoying, too. When I encounter it, I often have to think for a second and look at the docs, e.g. some cryptic xor or map function with three parameters, one of which being an optional config object. OTOH, it can be great to have a well-tested implementation at hand for all kinds of higher-order functions, like throttle, debounce etc
- explaininjs 3y ago
  Aaannd… now you have a prototype pollution vulnerability :) Object.from(null), always.
ricardobeat 3y ago
It's very funny to point to lodash as an example of simplicity. Here is what happens when you start unraveling the code you linked to: https://gist.github.com/ricardobeat/040af80971273f5abd71c2bfcfdfdd50 https://gist.github.com/ricardobeat/040af80971273f5abd71c2bf... I got tired, but wouldn't be surprised if the whole thing goes beyond 1000 lines. It's basically a black hole. Better hope you really, really trust their test suite, it's impossible to debug and there must only be a handful of people familiar with the whole codebase.

by tibbar 3y ago

jauntywundrkind 3y ago

Trying to read lodash can (to put it mildly) be difficult. Lots of code reuse. This is probably missing checking for a bunch of corner cases, but this is the general idea: // quick & dirty Object.groupBy function groupBy(iterable, callbackFn) { const out = {} for(const [key, value] in Object.entries(iterable)) { const name = callbackFn(value, key) (out[name] || (out[name] = [])).push(value) } return out } I literally wrote something very like this yesterday (after checking & finding it only got added to Node 21, and deciding not to pull in a dependency). Edit: had keyBy impl in here, fixed! Thanks commenters!

tibbar 3y ago
I think `out` should be typed as a map to an array in this case; each iteration should be appending to the corresponding array instead of overwriting the entire entry.
quonn 3y ago
That‘s closer to keyBy than groupBy.
moritzwarhier 3y ago
Oh yes, I agree. I remember me running into the problem of internal dependencies when extracting parts of it into a non-ESM/non-build project some years ago... Like, the internal consistency of the library probably benefits, and with tree-shaking it works reasonably well but it is still a poster example of DRY vs KISS... It has its benefits, but its API surface can be annoying, too. When I encounter it, I often have to think for a second and look at the docs, e.g. some cryptic xor or map function with three parameters, one of which being an optional config object. OTOH, it can be great to have a well-tested implementation at hand for all kinds of higher-order functions, like throttle, debounce etc
explaininjs 3y ago
Aaannd… now you have a prototype pollution vulnerability :) Object.from(null), always.

ricardobeat 3y ago

It's very funny to point to lodash as an example of simplicity. Here is what happens when you start unraveling the code you linked to: https://gist.github.com/ricardobeat/040af80971273f5abd71c2bfcfdfdd50 https://gist.github.com/ricardobeat/040af80971273f5abd71c2bf... I got tired, but wouldn't be surprised if the whole thing goes beyond 1000 lines. It's basically a black hole. Better hope you really, really trust their test suite, it's impossible to debug and there must only be a handful of people familiar with the whole codebase.