Since Ramda 0.26 can’t be loaded (due to a conflict with thenables), and 0.27 for some reason isn’t showing up on npm after months, I created a notebook that imports 0.25 and makes all of its functions available.
This lets you import via
import {negate, curry, filter} from '@bobkerns/ramda-0-25'
The ramda version is explicitly in the name, to pin this notebook as a source for that version.
which is rather more convenient than require anyway.
I wasn’t familiar with Ramda (it vaguely rang a bell but I have never used it in practice)
How do you feel that its idioms mix with Observable’s approach to coding?
Fairly well, actually, but I’m still working on the best way to integrate with async generators. The problems are more on the async generator side and not specific to use Ramda. I’m working on something I hope will make it easier, that lets you consume generators, get their results, process them, returning a new generator with cancellation propagating back properly.
It’s not hard to do for a single generator, with a combination of Generators.observe and Generators.map.
A common case I hit—nothing to do with Ramda—is something returns an async generator, which I don’t realize because it is automatically resolved @ top level. I then go to stick that somewhere, like interpolated into text, and … nope.
But the functional/monad approach to error handling is a natural fit for Observable’s dependency handling, and I’d like to leverage it.