3 ms·

You don't need lodash/underscore, you need ramda[0]! I been using ramda heavily for tasks like merging data from normalized redux stores and it's been really h

You don't need lodash/underscore, you need ramda[0]! I been using ramda heavily for tasks like merging data from normalized redux stores and it's been really handy, but it's also great for simple tasks as well. I find the resulting utilities really easy to test and since Typescript got much better at higher order type inference, it's become much easier to use ramda in a Typescript project. EDIT: The version of typescript that improved higher order type inference was 3.4[1] 0: https://ramdajs.com/ https://ramdajs.com/ 1: https://devblogs.microsoft.com/typescript/announcing-typescript-3-4/ https://devblogs.microsoft.com/typescript/announcing-typescr...

cj 7y ago
We hired a developer for a project and they introduced Ramda into the codebade (in addition to underscore which was already in use). The resulting code was a mix and match of Ramda and Underscore helpers. Flipping between Ramda and Underscore documentation the decipher the dozens of helper / utility methods is quite infuriating. Worse, the Ramda API was previously under heavy development with breaking changes on every upgrade. To stay up to date requires reading through pages and pages of migration guides describing how to migrate off of one deprecated utility method to another. It definitely had short-term value to the person who wrote the original code with it, but that value quickly faded.
- adregan 7y ago
  I wouldn't recommend mixing those two libraries as they often do _very_ different things with the same name (eg. `chain` in ramda is `flatMap`) but also because ramda mostly flips the arguments of most functions. For example, `map` takes the function first and then the collection. That's handy because everything is curried so you can partially apply map: const double = R.map(x => x * 2); and can build up helper functions. Something similar in lodash would be: const double = (collection) => _.map(collection, x => x * 2); which there is nothing wrong with, it's just that the first is more ergonomic with `pipe` (and the potential future feature pipeline operator `|>`). That said, it took a while to adopt at work. It wasn't until we had a critical mass of people who enjoyed functional programming that it really took off. Before that time, we used a few methods lightly (utils like `pathOr` and `propOr` are so nice when you want to safely traverse an object without `o && o.foo && o.foo.bar`) and were very conscious that it might not be everyone's cup of tea.

cj 7y ago

We hired a developer for a project and they introduced Ramda into the codebade (in addition to underscore which was already in use). The resulting code was a mix and match of Ramda and Underscore helpers. Flipping between Ramda and Underscore documentation the decipher the dozens of helper / utility methods is quite infuriating. Worse, the Ramda API was previously under heavy development with breaking changes on every upgrade. To stay up to date requires reading through pages and pages of migration guides describing how to migrate off of one deprecated utility method to another. It definitely had short-term value to the person who wrote the original code with it, but that value quickly faded.

adregan 7y ago
I wouldn't recommend mixing those two libraries as they often do _very_ different things with the same name (eg. `chain` in ramda is `flatMap`) but also because ramda mostly flips the arguments of most functions. For example, `map` takes the function first and then the collection. That's handy because everything is curried so you can partially apply map: const double = R.map(x => x * 2); and can build up helper functions. Something similar in lodash would be: const double = (collection) => _.map(collection, x => x * 2); which there is nothing wrong with, it's just that the first is more ergonomic with `pipe` (and the potential future feature pipeline operator `|>`). That said, it took a while to adopt at work. It wasn't until we had a critical mass of people who enjoyed functional programming that it really took off. Before that time, we used a few methods lightly (utils like `pathOr` and `propOr` are so nice when you want to safely traverse an object without `o && o.foo && o.foo.bar`) and were very conscious that it might not be everyone's cup of tea.