Hacker News Reader

Comment by geraldwhen | Hacker News Reader

You need redux saga because api interactions can be complex.

I need to update a remote resource. But wait! Sometimes that can fail. I need to capture the failure logic and make appropriate ui changes. There are 4 types of errors and they require doing some library logic to figure out what to display.

But wait! I want to wait 250ms before triggering any state updates, or else the ui transitions will feel buggy.

Oh, and product now wants to make sure we capture some random third party tracking event in between specific state changes. The ui MUST NOT change until the tracking call succeeds.

This and more is trivial in redux saga, and you can write tests around it.

View on HN

For the record, we actually have recommended _against_ using sagas in most cases for a long time now, and especially for data fetching.

Today, our recommendations are:

- Data fetching: default to using RTK Query, fall back to thunks if needed

- Responding to actions or state changes: use the new RTK "listener" middleware as the main approach

See my recent talk "The Evolution of Redux Async Logic" for details:

- https://blog.isquaredsoftware.com/2022/05/presentations-evol...

as well as my recent presentation going through "Modern Redux with Redux Toolkit":

- https://blog.isquaredsoftware.com/2022/06/presentations-mode...

Oh my. What is this ecosystem where the maintainers are downvoted for explaining the current recommendations for those using their library?

I was called in to rescue a redux-saga based project that had gone badly off the rails. It was one of the worst codebases I've ever had to work with in many years of coding. Stack traces were useless and debugging with anything higher level than log statements was impossible.

Apparently you don't need to debug if you're a good programmer. This explains why many modern tech stacks (JS, Scala, Kotlin, ...) have a horrible debugging experience.

We specifically moved off thunks because the capricious whims of changing network calls with logic to support it is so much easier in redux saga. Stuff just works. You can handle every edge case.

And now there are multiple deployed production apps with real users, so it’s almost certainly never going to be replaced. The cost would be enormous.

Yeah, I'm not questioning whether you _can_ do things with sagas, and there's definitely cases where their capabilities are valuable.

But as I put it in my "Evolution" talk: "Sagas are like a chainsaw. Really powerful, and really dangerous. If you actually _need_ that power, great! But most of the time you don't actually _need_ to use a chainsaw on a daily basis."

As the sibling comment said, a lot of times sagas really do end up as spaghetti code, largely because they are so event-driven, and with all the use of generator functions that can make debugging hard. (Ironically, the original Flux Architecture was created to _avoid_ the problems of Backbone-style event triggers causing events to ricochet around the app without a way to understand how things would update in response, and sagas can end up recreating that problem with Redux apps.)

Saga is so heavy and overly complex and you don't really get much out of it if you understand how middleware works. There's really no reason to add a huge dependency to your project.

You can do all of that pretty easily with a vanilla redux.

Reply on news.ycombinator.com