5 ms·

In my experience redux-toolkit + redux-saga for async stuff usually work really well. In case of performance problems one can go with profiling + targeted optim

In my experience redux-toolkit + redux-saga for async stuff usually work really well. In case of performance problems one can go with profiling + targeted optimisations (e.g. a separate store, some locally managed state).

acemarke 4y ago
Glad to hear RTK is working well for you! FWIW, we actually specifically recommend _against_ using sagas in almost all cases. Instead, we recommend using our RTK Query API for data fetching and caching, and the RTK "listener" middleware for reactive logic: - https://redux.js.org/usage/side-effects-approaches#recommendations https://redux.js.org/usage/side-effects-approaches#recommend...
- metta2uall 4y ago
  Thanks, I wasn't aware RTK now has a saga-like "listener" feature - will look into it! What I like about sagas are their simplicity & power (once one understands how generators & effects work), plus the eventChannel feature which lets one integrate with non-redux events. Good TypeScript support is a problem though, and I've had to resort to typed-redux-saga :/
  - acemarke 4y ago
    Yeah, we specifically designed the listener middleware to do ~90% of what you could do in sagas, but with a smaller bundle size, simpler API, and better TS support: - https://redux-toolkit.js.org/api/createListenerMiddleware https://redux-toolkit.js.org/api/createListenerMiddleware - https://blog.isquaredsoftware.com/2022/03/designing-rtk-listener-middleware/ https://blog.isquaredsoftware.com/2022/03/designing-rtk-list... Event channels was something we intentionally _didn't_ try to replicate per se, and tbh I've never tried to use those myself. (But, I _suspect_ that you might be able to do something similar with listeners even though we don't have a specific replacement built into the listener middleware, and if you do I'd love to see an example in action!) If you get a chance to try out listeners in your project, I'd definitely appreciate feedback on how well they work out for you - whether they solve your current saga use cases, what cases they _don't_ handle, anything we can do to improve the listener API, etc.
cageface 4y ago
I had to rescue a redux-saga project that went badly off the rails. It was one of the most inscrutable and difficult to debug codebases I've ever had to work with. Forget completely about ever having a usable stack trace.
- bayesian_horse 4y ago
  Yes, I guess you can abuse every technology. Sagas are always sideeffects and thus have to be used with restraint. Sagas keep state (and you should keep most state in the redux store, anyway). So, yes, you can go wrong, as with everything else. But it's better than using useEffect as an async framework.
bayesian_horse 4y ago
Yes, absolutely. Don't use useEffect as an async framework, use thunks or sagas. Remove most logic from the components into sagas,thunks and selectors. That way your components will be smaller, more testable, easier to change, easier to reason about.

acemarke 4y ago

Glad to hear RTK is working well for you! FWIW, we actually specifically recommend _against_ using sagas in almost all cases. Instead, we recommend using our RTK Query API for data fetching and caching, and the RTK "listener" middleware for reactive logic: - https://redux.js.org/usage/side-effects-approaches#recommendations https://redux.js.org/usage/side-effects-approaches#recommend...

metta2uall 4y ago
Thanks, I wasn't aware RTK now has a saga-like "listener" feature - will look into it! What I like about sagas are their simplicity & power (once one understands how generators & effects work), plus the eventChannel feature which lets one integrate with non-redux events. Good TypeScript support is a problem though, and I've had to resort to typed-redux-saga :/
- acemarke 4y ago
  Yeah, we specifically designed the listener middleware to do ~90% of what you could do in sagas, but with a smaller bundle size, simpler API, and better TS support: - https://redux-toolkit.js.org/api/createListenerMiddleware https://redux-toolkit.js.org/api/createListenerMiddleware - https://blog.isquaredsoftware.com/2022/03/designing-rtk-listener-middleware/ https://blog.isquaredsoftware.com/2022/03/designing-rtk-list... Event channels was something we intentionally _didn't_ try to replicate per se, and tbh I've never tried to use those myself. (But, I _suspect_ that you might be able to do something similar with listeners even though we don't have a specific replacement built into the listener middleware, and if you do I'd love to see an example in action!) If you get a chance to try out listeners in your project, I'd definitely appreciate feedback on how well they work out for you - whether they solve your current saga use cases, what cases they _don't_ handle, anything we can do to improve the listener API, etc.

cageface 4y ago

I had to rescue a redux-saga project that went badly off the rails. It was one of the most inscrutable and difficult to debug codebases I've ever had to work with. Forget completely about ever having a usable stack trace.

bayesian_horse 4y ago
Yes, I guess you can abuse every technology. Sagas are always sideeffects and thus have to be used with restraint. Sagas keep state (and you should keep most state in the redux store, anyway). So, yes, you can go wrong, as with everything else. But it's better than using useEffect as an async framework.

bayesian_horse 4y ago

Yes, absolutely. Don't use useEffect as an async framework, use thunks or sagas. Remove most logic from the components into sagas,thunks and selectors. That way your components will be smaller, more testable, easier to change, easier to reason about.