Really cool summary of the power of such libs like redux-saga.
I indeed prefer using sagas than observables, maybe because of the cool 'select', 'put' and 'call' apis that helps me to do smart hook methods. With a good combination with such normalizr lib (https://github.com/paularmstrong/normalizr), you can actually fast implement a light optimist transactions system between frontend and backend.
For instance, you can define a REQUEST_PUT_ENTITIES action, and a saga watching on it.
This saga will do:
- a 'call' for calling the api post method for updating the backend (ie updating all the collections through your backend database apis)
- get back from the api the put data, and into the saga you then 'put' a MERGE_INTO_ENTITIES action, in order to direclty update and normalize your frontend entities app state.
- once your app state is synchronised, your saga can even 'select' again these put entities thanks to their ids and you can 'put' a nice REQUEST_PUT_ENTITIES_SUCCESS action from which you can hook any kind of specific-to-the-app post-synchronized methods.
So, for me redux-saga with a bit of wrapping is like a light solution for doing what we all are searching actually in such heavy libs like Relay or react-appollo (but here I am talking for a quick solution with a 'stupid-like REST approach'...so maybe not optimized for sure)
That's cool to have here a synthetic explanation on how Relay can be more familiar.
I think I would just still be more attracted by Appollo framework which is more a redux-like syntax, so more consistent with all the workflow of the apps I used to develop. But maybe Relay has better benchmarks?
Also, if I want to stay REST but with optimist transactions between the backend and frontend, I prefer lighter lib like
https://github.com/tonyhb/tectonic
or even I just write some fast redux-saga watchers that helps to make my frontend always synchronized when my app calls a mutating db request.
But is Icaro more on listening changes on javascript objects, in a general manner, better than just the DOM ones?
I think that this light lib could be actually a cool toy to use if you need for example to do some simple app state listened manipulations on the node backend side.
Otherwise, that is true, I would maybe still prefer to use frontend side some well-designed frameworks like redux-Rx or redux-react
That article proposes to select and highlight a particular subset of these helpers, notably React and Redux.
But all of these are made in JS... So it is about to empower this language through good sugar syntaxes, and with dom manipulation/app state transactions friendly apis.
