yield from callback function/event listener?
See original GitHub issueIs there a way to yield from callback function. e.g.
function* mySaga() {
hashHistory.listenBefore(location => {
yield put({ type: 'LOCATION_CHANGE', payload: location });
var state = yield select();
return true; // or false depending on state
// or do some more yield stuff
});
}
How do you handle this kind of side effects?
Issue Analytics
- State:
- Created 7 years ago
- Reactions:3
- Comments:12 (3 by maintainers)
Top Results From Across the Web
Why can't the generators next function be a callback function ...
The way that event listen works is that it will call the function handle using call and assign the this binding from its...
Read more >Cleaning up callbacks with yield - Aaron Powell
In my last post we took a journey on how to make a function execute in a delayed fashion by using the new...
Read more >Developers - yield from callback function/event listener? -
Is there a way to yield from callback function. e.g. function* mySaga() { hashHistory.listenBefore(location => { yield put({ type: 'LOCATION_CHANGE', ...
Read more >A Study on Solving Callbacks with JavaScript Generators
Generator functions can suspend execution with the yield keyword, and pass values back and forth when resuming and suspending. This means that ...
Read more >Creating streams in Dart
Avoid producing events when the listener has requested a pause. An async* function automatically pauses at a yield statement while the stream subscription ......
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 FreeTop 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
Top GitHub Comments
@yelouafi I spent few days trying and debugging a bunch of ways, including generating and handling promises, using callbacks, etc. However all of this complicated my code much and was unreliable (as I want different sagas handle different routes and depend on each other result).
My workaround is not to use sagas in this case. Just a special list or routing handlers, that are called synchronously in predictable order by some general entry point (events of router), get state/dispatch and routing stuff as parameters, with final “fallback” handler that just approves user navigation (it wasn’t handled by routing handlers).
In my case I have a routing directory in src with handleAuth.js, handlePage1.js, handlePage2.js etc. So the order is also important, and event handlers can depend on other handler result. As auth goes first, than page handlers that can fetch some data from store, redirect (using dispatch), etc etc
Hey @evgenyt1.
One solution would be to use channels as described on SO. It is also planned to be supported out of the box.
Another solution would be just to use
dispatch
(andgetState
in your case) parameters passed into rootSaga. Though it seems uglier than above one, I usually use this solution for binding events. A bit harder to test, but cleaner and guaranteed that you’ll not miss any event.