redux-saga in 2022

[neurosnap]

Hey all!

I'd like to compile a community list of features that are missing in redux-saga in 2022.

I still use redux-saga in all my work and personal projects. I think long-running tasks work extremely well on the front-end. Coupling that with complex flow control and you can handle pretty much any business logic using redux-saga.

Having said that, with the addition of libraries like react-query, rtk-query, remix, and jotai people are seeing less utility in using redux-saga especially when considering the upfront cost of learning it's flow control model using generators.

I have ideas on how to bring redux-saga back into the zeitgeist of front end engineers but I want to read from you as well.

Some probing questions:

• what don't you like?
• what do you want to see changed?
• what are some missing features?
• what is stopping you from using this library in your next project?

Thanks!

[3plusalpha]

Hi @neurosnap! I am the author of the issue #2151. That's why I was notified that the issue was closed.

Let me try to give my very personal opinion on redux-saga after having used it at a large clients project with like 8-10 JS developers.

what don't you like?

The default coupling with redux is not really useful anymore in 2022. A message listener and a dispatcher without any state management would be enough for the lib.

Another point I heard from colleagues was the yield syntax and that it confuses the DEVs. I personally don't have any issues with that but it's a commonly thing I heard.

Get some docs right: things like USER_FETCH_REQUESTED is not what inversion of control (what redux wants) is all about. You can not enforce a certain behaviour with just sending a message. Not a big deal, but kinda wrong. Just send messages what has happened.

what do you want to see changed?

Call redux-saga what it is: a process manager. Even the author of this lib stated that it's not the correct term: https://survivejs.com/blog/redux-saga-interview/#sagas
Not a big thing, but also just a bit wrong.

what is stopping you from using this library in your next project?

The coupling of Redux and the slow progress in development in this lib, which makes me think that newly discovered bugs will be solved in years or never.

Another reason: I never need the power of the lib. You can manage most side effects with async/await and call it a day. If you really need to store a state of a process (like for a user onboarding) you might just use a state machine to store the name of the state or use eventsourcing to store and recreate a state from you data. The only reason to use redux-saga takeEvery. The rest could be (in most use cases I assume ™️ ) just async/await.

:)

[Andarist]

The default coupling with redux is not really useful anymore in 2022. A message listener and a dispatcher without any state management would be enough for the lib.

Redux Saga can totally be used without Redux: https://redux-saga.js.org/docs/advanced/UsingRunSaga

Another point I heard from colleagues was the yield syntax and that it confuses the DEVs. I personally don't have any issues with that but it's a commonly thing I heard.

That's also something I've heard a lot but there is nothing we can do about it. The API shape and capabilities of the Saga are both built on top of generators.

Call redux-saga what it is: a process manager. Even the author of this lib stated that it's not the correct term:

We could make this more prominent in the docs but it would be rather hard to rename the lib itself now.

the slow progress in development in this lib, which makes me think that newly discovered bugs will be solved in years or never.

We can't fix what is not broken 😉 I've been monitoring this repo for years and we didn't have any major bug reports for the core of the lib.

The rest could be (in most use cases I assume ™️ ) just async/await.

https://twitter.com/DavidKPiano/status/1495798463052886019 😅

[neurosnap]

Redux Saga can totally be used without Redux

I hear you on this one. My biggest apprehension with using this outside of redux is the fact that I'm installing a library called redux-saga in order to do it. It feels more like we are making redux-saga work without redux instead of building something without redux to begin with in mind. What do you think about publishing a core package without any notion of redux in its code / naming?

I wrote cofx as an experiment to see if I could rebuild redux-saga without redux. Another thing I wanted to bake into the idea was the ability to build custom effects.

The only effects that were available to cofx were: call, all, race, fork, spawn, delay. I didn't need to accommodate put and select in order to use it and the API was a little more pleasant than runSaga.

[Andarist]

What do you think about publishing a core package without any notion of redux in its code / naming?

We could do that, but also... it's just a name and then the actual code for redux-saga would be just a couple of lines of code. This is a nice to have a thing and I'm not sure if this would really attract a lot of people to the library. I'm not opposed to it but the organizational cost might not be worth the effort. At the end of the day, it's just a name. If a library would solve my issue then I wouldn't be bothered what it is called. I guess though that most people might get "scared away" by Redux being in the name, in a sense that they might expect strong coupling between two. Perhaps this is an educational/marketing issue though?

I didn't need to accommodate put and select in order to use it and the API was a little more pleasant than runSaga.

The put effect (+ take) is suuuuper useful though. I agree that perhaps select is somewhat specific to Redux but IMHO put is a core feature of the Redux-Saga. Perhaps a global std channel is a side effect of being focused on Redux but I would consider put+take+channels as Redux Saga "primitives".

I'm open to making this library here more flexible but OTOH if some things would be changed... would it still be the same Redux Saga? There are a few similar libraries that are decoupled from Redux right from the start and I'm not sure if Redux Saga needs to compete with them.

[neurosnap]

I'm open to making this library here more flexible but OTOH if some things would be changed... would it still be the same Redux Saga?

Yeah as I've been getting more involved with the codebase, at that point, it probably wouldn't be redux-saga and it would be something else entirely. Maybe that's an interesting direction to ponder. I've been seeing https://frontside.com/effection/docs/guides/introduction gaining some traction.

[rickwebiii]

I worked on Tableau Prep for about 4 years and we got a ton of mileage out of Redux Saga. While we usually used call and put effects, we definitely used some of the others (race between the user clicking Ok and Cancel). We ran into a few challenges, some of which we were able to solve.

• Unit testing: testing sagas by asserting they produce a sequence of effects is generally counterproductive (the tests frequently break and don't catch real regressions); we wanted an integration testing framework. Redux Saga Test Plan worked beautifully.
• Cancellation: Tableau Prep is almost completely asynchronous by design; make a change and data loads in the background without blocking you from making more changes. This led to a bunch of bug farms. For example, if a saga is currently fetching metadata about a widget and another saga deletes the widget before the REST call comes back, our first saga would try to update state that no longer exists and the app would throw an exception. I wrote redux-saga-observer to address this. By putting observer-likes in Redux Sagas, you could spawn a saga that only continues running while some facts about the Redux state are true. This fixed a ton of bug farms. I made an issue asking if it made sense to merge this functionality into the main library. This library also allowed you to implement the observer pattern without adding additional middleware; i.e. a saga spawns whenever some facts about the Redux state becomes true rather than an particular action.
• Traceabililty: This I guess is an issue with all Redux middleware, not just sagas. We had a few actions that that would trigger both reducers and sagas and reasoning about the order of operations and what would happen was a pain. Ideally, there would be some mechanism to mark an action as handled and you get an exception if the wrong things handled it.
• Scalability: If I had to guess, Tableau Prep had like 100kLOC of sagas and they tended to be far more spaghetti-like than our React code. Sagas would spawn other sagas via call effects and functions would be spread all across our codebase. It organically spread out like a 90s C codebase. Some sort of structure and organization of sagas could help here.

[ghost]

I had an experience with hefty code base too, and can relate to this comment. But I'd like to also add:

• Debuggability: Stacktraces of redux-saga are polluted by intermediate and recursive calls. At times it's really hard to pinpoint the exact place where bug happened and it's hard to trace it's path on call stack, not just to an action/trigger that launched the sequence.
• Typing: Using generators opens a lot of opportunities, but at the same time it makes typing a nightmare. typed-redux-saga tries to cover this, but the problem is still not solved. Using yield* is the only way to tackle the issue but it's syntactically ugly.

[neurosnap]

I totally agree with you here. I would argue these are the two biggest issues with using redux-saga in 2022. Typing can only be solved upstream with a change in typescript. There is an outstanding PR that if it gets merged would unblock us from getting types as good as async/await: microsoft/TypeScript#43632

With debugging redux-saga, here is our current open issue discussing stacktraces: #1171

I agree that I would love to see this improved. I'd love to take a stab at it or have someone from the community try to fix this issue.

[simarmol]

• Missing features: better type inference for Typescript. Any results from yield call seem to require me to explicitly declare the type in the saga, even though the called function is typed properly. I guess merge https://github.com/agiledigital/typed-redux-saga into the core library, essentially?
• What do you want to see changed: Sagas feel like they involve a lot of boilerplate, between having to set up your takeEvery and whatnot for every action you need to handle.
  • One thing that I would like personally is integration into the redux-toolkit, specifically in createSlice and/or as an alternative to asyncThunks. Maybe this wouldn't be great as a direct part of the library, but as an extension/wrapper for redux-toolkit?
  • Decorators, maybe? If I could do, oh, @takeEvery someAction over each generator function, I feel like it would be much more legible to newcomers.

[Andarist]

I guess merge https://github.com/agiledigital/typed-redux-saga into the core library, essentially?

That was once a plan but I never got to it (although I've promised to do it multiple times). I think that this effort could be revived if there is an interest in this from the community and if such a merge would get approved by typed-redux-saga maintainers.

[neurosnap]

I'm against bringing in typed-redux-saga. When using yield* you lose the testability of redux-saga. Instead of yield a JSON object, you now yield the response of the yielded function. Having said that, the react world has slowly moved away from unit testing and has settled more heavily on integration testing so maybe it's not as big of an issue. If it's true we no longer value the testability of sagas, then I think we might need to revamp our feature-set and what we think makes redux-saga worth using in 2022.

Basically, de-emphasize testing in our docs.

[Andarist]

While I'm in the "don't unit test this stuff" camp (😅 ) I don't think that using yield* must change all that much. All that has to happen is to encapsulate current effects in "proxy" generators as those are the ones that can be typed.

async function foo() {}

function _call(arg) {
  return { type: "call", arg };
}

function* call(arg) {
  return yield _call(arg);
}
function* saga() {
  const res = yield* call(foo);
  console.log({ res });
}

const it = saga()
it.next()
it.next(42)

Here, we still have the very same testing traits as we have with bare yield, after all, the yield* is opaque to the caller and is not really "observed" by it.

This adds some runtime cost as we introduce more generators just for the sake of typing but that potentially could be fixed by a Babel plugin (or similar) that would rewrite yield* call() to yield call() etc

[neurosnap]

Woops, you're right. I must have been thinking about type-redux-saga incorrectly. I redact my concern about testing with typed-redux-saga.

[neurosnap]

One of the first GH issues for this project DevTools for Sagas is still relevant to us today. Improving callstacks or providing a devtools that could make it easier to debug errors that happen within sagas would be really beneficial. I know that since it is one of the original issues for this project, it probably won't be easy.

[Nantris]

Could we put together a bounty for this? I'll pitch in.

The only way to debug sometimes is to pass extra args with the source of the calling functions so that we can trace them back to their source - because the call stack isn't any help sometimes. I love sagas so much, but that is madness.

[neurosnap]

Thanks for commenting on this issue. I agree it's important. One way I was able to provider better debugging was to have a global catch that outputted some extra information -- like what function triggered the exception.

You might be interested in saga-query which bakes that traceability automatically via an error middleware. This is an experimental library that is meant to compete with react-query but leveraging sagas. It also has a lower-level createPipe which provides an express-like middleware system for sagas. I've been using it with great success.

[emarcha]

I'm pretty new to this, but how does redux-saga fit into the ecosystem with redux-toolkit?

[neurosnap]

Great question! This is one area where we'd like to update the docs to address recent changes in redux. I use redux-toolkit and redux-saga together. I primarily use the toolkit to build reducer slices and then let redux-saga handle all the side effect management.

[emarcha]

I guess I'm confused regarding which portions you wouldn't use from redux and redux-toolkit. Which use cases are a better fit for redux-saga?

[neurosnap]

createSlice will help build the reducers and actions for you. redux-saga doesn't handle any of the redux side of things. redux-saga is great for side-effect management.

So I would primarily use createSlice inside of redux-toolkit and then create actions separately that redux-saga listens to. Here's a simple example:

import { createSlice } from '@reduxjs/toolkit';
import { takeEvery, put } from 'redux-saga';

const users = createSlice({
  name: 'users',
  initialState: {},
  reducers: {
    add: (state, action) => {
      action.payload.forEach((user) => {
        state[user.id] = user.id;
      });
    }
  }
});

const fetchUsers = () => ({ type: 'FETCH_USERS' });
function* onFetchUsers() {
  // perform fetching logic
  yield put(users.actions.add(/* ... */));
}

function* watchFetchUsers() {
  yield takeEvery('FETCH_USERS', onFetchUsers);
}

[martinkadlec0]

1. It would be amazing if Typescript final had support for generator coroutines so we could avoid yield* :D

2. (sorry for the long post)

One of the most common question I see when people use sagas is ~"how do I return some data back to react when dispatching an action" (usually fetched data). Of course, the primary way is modifying the redux store but that has multiple issues:
a) All data communicated from sagas to react now must be in redux store even if its not needed in any other part of the app
b) If you want to return something that is not serializable, you are polluting your store with non-serializable data

The other option is some form of a callback. This is also not ideal because sagas by themselves don't guarantee that the action is going to be handled or that it is going to be handled just once. + Now again you have non-serializable function in your actions.

Now, I know there is another issue here about a useSaga hook, including some proof of concept implementation, but the big problem with it is that it blocks some effects until the component rerenders. Also it tries to replace redux with react state, which could be useful in lots of cases (especially since like other mentioned you don't always want to use redux with sagas today). However I think it would be amazing to have an option to keep access to both component & redux state at once.

The idea is to keep your usual effects as they are and have an useSaga hook in addition that would run a saga with a parameter that would have additional effect creators to work with the provided react state/reducer.

E.g.

function * mySaga(reactEffects) {  
  yield reactEffects.take('FETCH_DATA')
  const token = yield select(reduxState => reduxState.token)
  const result = yield fetch('/foo', token )
  reactEffects.put({type: 'RESULT', payload: result})
}

const Component = () => {
  const [state, dispatch] = useSaga(mySaga, reducer, initialState);
  return <button onClick={() => dispatch({type: 'FETCH_DATA'}) />
}

I've tried to have a stab at this few years back, but struggled a lot with how unpredictable react is with calling the the reducer function and bail outs so it never fully worked + I never got my head around the saga internals so I used standard saga effects instead, which of course wouldn't work for official implementation.
https://codesandbox.io/s/react-redux-saga-6y0h4?file=/src/index.js

[neurosnap]

I would highly recommend checking out https://github.com/redux-saga/saga-query which attempts to solve the problem of "how do I get data out of a saga and into react?"

Essentially we bake into redux a couple of slices that saga-query manages on behalf of the user which allows us to do a couple of things:

• Automatically cache data into redux
• Create the concept of a "loader" which tracks the status of sagas

With those two features enabled for a codebase, we can now more easily pull data out of sagas via react hooks. There's a lot more to saga-query but it does solve a bunch of problems that have historically haunted redux-saga.