Build 3rd party plugins that optimize Sagas usage (following this blueprint) [and another for Redux-Observable]
See original GitHub issueWould like to get some ideas from the community on ways to improve the experience of using redux-first-router with redux-saga.
Some thoughts:
- Adding a reference to a saga to fire before firing our action dispatch?
- Another export from
connectRoutes
that gets added to our sagas, effectively mapping them to each route?
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:22 (14 by maintainers)
Top Results From Across the Web
Epics - Redux Observable
Once you're inside your Epic, use any Observable patterns you desire as long as any output from the final, returned stream, is an...
Read more >Redux-Observable will solve your state problems. - ITNEXT
For this example, I'll be communicating with a 3rd party service and telling it to start logging only after I've stored the user's...
Read more >State Management in React (with React-Redux ... - YouTube
This is a comprehensive exploration of React with using a redux state management framework. I use redux - observable as the async code...
Read more >Untitled
gunjs-server. Dec 07, 2020 · XenderMd. Current job: Software Engineer Trainee. /. Focused samples showing API usage patterns for common scenarios with each ......
Read more >Senior UI Developer Resume Lincolnshire, IL - Hire IT People - We ...
Expertise in using frameworks like CSS blueprint, used CSS Sprites to increase the efficiency of web pages. Well - versed with JavaScript, jQuery, ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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)onBefore/AfterChange
)initialDispatch
is similarmainSaga
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.
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.