Build 3rd party plugins that optimize Sagas usage (following this blueprint) [and another for Redux-Observable]

Would like to get some ideas from the community on ways to improve the experience of using redux-first-router with redux-saga.

Some thoughts:

1. Adding a reference to a saga to fire before firing our action dispatch?
2. Another export from connectRoutes that gets added to our sagas, effectively mapping them to each route?

[faceyspacey]

so bottom line is we make it a plugin package (of which we have several that function exactly like that is, i.e. as an option). That means we dont have to bundle anything that makes it work into RFR. and it does all the work for you, and lets you get back to your primary sagas work.

Essentially RFR has a budding plugin ecosystem that functions exactly like this.

• restoreScroll – ScrollRestoration functions like this (Its also another package)
• navigators – React Navigation support functions like this (Its also another package)
• querySerializer – for query params support (Its also another package)
• callbacks are in the same boat (i.e. onBefore/AfterChange)
• initialDispatch is similar
• and now mainSaga or whatever it ends up being called. (Its also another package)

And as far as the amount of sagas code in RFR, it’s the same as any other plugin: checks if it exists, and in 1-2 lines fires something on the plugin; then all the work is offloaded to the 3rd party package.

[iansinnott]

Just wanted to chime in on here because this issue has implications for the larger direction of RFR. Since many people are using many different async solutions if RFR took a stance on async by supporting some solutions out of the box it could risk fragmenting the community around this project. Redux itself is a great example of taking the opposite approach and letting users solve their async problems on their own by being extensible.

Admittedly route.thunk may seem to contradict my point here, but it seems to be the de facto standard for async in redux if you don’t have an existing solution and @faceyspacey’s points about the 80% use case are fair.

So I would suggest that RFR not provide explicit support for anything outside of thunks, but RFR should work fine with any redux middleware. So if there is a bug that keeps RFR from working along side redux-saga then we should address that, but if it’s a matter of developer ergonomics there are other options that would not involve modifying the core of RFR. For example, a redux-first-router-saga package could be created that does any plumbing necessary to provide a more seamless API. Or perhaps RFR itself could become extensible and the thunk functionality could also be separated into its own package.