ELMo riding a HellCycle down to Inferno
Elmo is my experiment with trying to unify some concepts from two of my favourite Javascript projects: Cycle and Elm. I tend to learn by doing, and this experiment is helping me understand better how both Cycle and Elm are designed and work.
Like Cycle, Elmo uses reactive streams to transform data all the way down, and everything flows by combining those streams using just pure functions.
Elmo has its own Cycle.run function named
HellCycle
used to connect the side-effect-free Elmo Components
(things you write like counter app) with
effect-producing drivers.
Now, being this an experiment, I just wanted to implement my own ten-lines cycle.
In theory, it's possible to use any Cycle Driver with Elmo, as they have the same interface - it's something I'm planning to experiment with these days, and maybe extracting the Elmo Driver, so you could implement Elm-architectured components with Cycle.
Elmo has a tiny stream adaptor around Flyd, but I expect to experiment with other libraries or even use Cycle's own stream adaptor.
Elmo has a driver for the Inferno rendering library. I'll try to implement something like TodoMVC with Elmo and see how that benchmarks. Also, it'd be nice to have a Cycle driver to render with Inferno.
Elmo, as its name implies, tries to follow the Elm Architecture,
so every component exposes init, update, view functions along with their Msg and Model definitions.
I'm planning to implment elmish like Cmd and Subscription to communicate with other existing cyclic drivers.
However, instead of calling the update or view functions everytime, Elmo follows the reactive way: having those
functions receive and return streams for when data needs to be changed.
The view (in the example counter app implemented with Inferno's jsx) for example, returns an stream of Inferno DOM nodes to be updated on the browser by the Inferno Driver
I did try to keep things as pure and functional as possible - Elmo itself uses Ramda extensively to achieve this.
One thing I've found interesting on exploring is having the
Elmo Component's update and view functions not having direct access to the model's object.
Instead, the view has read-only access to lens of the current model.
Even the update function is given lenses for getting, setting and updating while keeping data immutable, the new data returned by update lenses becomes the new model. It is of course possible to get the actual model object inside those functions, but I just didnt want to make that obvious, and trying to hide it to prevent object mutation.
The example counter can be seen here
To be continued...
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent