An idea for integrating third party effect management libs such as redux loop/saga/observables

TLDR: Allow rfr to optionally dispatch ROUTE_CHANGE_BEGIN, ROUTE_CHANGE_RESOLVE, ROUTE_CHANGE_REJECT actions to replace thunk argument for routes.

Why: All 3 libs (loop/saga/observables) relies on listening to store actions to trigger side effects (reducer, saga, epic respectively). So what we can do perhaps:

• add a flag dispatchThunkActions (need better name), rfr will dispatch a ROUTE_CHANGE_BEGIN action.
• loop/saga/observable can listen to this event, do the side effect thing
• when the side effect resolves/rejects, loop/saga/observable will dispatch ROUTE_CHANGE_RESOLVE/REJECT
• Once, rfr receives ROUTE_CHANGE_RESOLVE/REJECT, rfr will continue as usual.

[avionbg]

I like the idea very much, and if had found the redux-saga-first-router before redux-first-router, I would probably go with it or at least try it. (I didn’t go trough their code, but I think they have something like that). Since the project that I’m working on has gone too far at this point, switching is not an option. I’ll probably test it and play with it at some point in the future, who knows. Anyway routing doesn’t have to be complicated like with react router and clones, that’s why I was attracted to rudy, and I must say everything looks and feels waaaaaay better than before (with R.router) Apart of that, I’m convinced that sagas are the future, or at least they are here to stay … which I can’t say for sure for thunk etc.

More about that idea, having full control doesn’t necessary mean that you will use all of it’s power. Someone can still implement simple routing, but having an option to control the flow of the app is a powerful thing, and even if you don’t need it initially there can always come a point where having it would be a great advantage… better than inventing workarounds and hacks.

There are endless possibilities, and our only limit (and enemy) is our imagination.

BTW. I really like the way everything is mapped and can be accessed later … it’s something I was dreaming about earlier with react [redux] router.

[faceyspacey]

@avionbg very nice:

.filter(route => routesMap[route].saga)

For your needs, how did you feel about @gniquil 's idea of giving full control to Sagas? Currently, there is no way to block route changes OR make the route change happen after data fetching (in thunks or sagas). But if RFR could wait on a specific action, then sagas could control the flow.

Ultimately, it’s not the setup i’d go for, but I can see why people might want it, or perhaps want it for some routes. Basically, doing the route change after async data fetching is complete simplifies component rendering logic, as you don’t have to worry about not having data and displaying spinners as much. It makes it very easy to implement a global modal spinner throughout your app for every page, and then let your components never worry about it. They can as a result just assume that if they’re gonna render they have the data.

A caveat to this is on initial load of the app, you want to render something immediately, rather than wait for the async data fetching to complete. So you better design that global spinner to look good there too (a modal one might look stupid). Basically you have to structure your components so you render the layout, and a placeholder for everything else, with a spinner showing until that placeholder is ready. It’s less fine-grained, and shows changes less soon to the user. I’m not in love with that approach as I prefer to show the most relevant changes to the UI immediately (at the expense of perhaps a minor bit more work across components), but I think having the option is valuable.

Anyway, I also thinking seeing the complete flow controlled by sagas (or observables or redux-loop) is also quite valuable. Perhaps more valuable. Power users are in love with these async middlewares, and it’s therefore very important for them to get the power of RFR as a truly first-class setup. Now that said, such power of having RFR listen to Sagas/Observables/Loop is only really needed if you prefer the aforementioned order and control over route changes. But likely even more opportunities/possibilities would open up if RFR had the listening capability.