Hacker News Reader

Comment by vosper | Hacker News Reader

> I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks.

If by "function as children" you're referring to render props, personally I was really happy to see that short-lived fad die out. I don't think render props made things simpler.

Now if we can admit we never needed Sagas just to do some data fetching maybe we can burn that stalled-out old bandwagon, too :D

(Sagas are a powerful pattern, I'm sure someone here is about to reply about how they're making good use of them. But I'd bet 99% of people using the redux-sagas library could be doing something simpler).

View on HN

I'm a Redux maintainer, and yes, I keep trying to tell people that 95% of Redux apps don't need sagas. They're a great power tool for those cases when you have truly complex async workflows, but they're complete overkill for basic data fetching behavior.

I wrote about why I chose thunks as the default in our Redux Toolkit package:

https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh...

and our Style Guide docs page specifically recommends using thunks as a default:

https://redux.js.org/style-guide/style-guide#use-thunks-for-...

I had to rescue a codebase that was all-in on sagas by developers that didn't seem to really understand what they were for. It was one of the most difficult and frustrating projects I've ever worked on. Debugging was a total nightmare because bugs were so decoupled from their causes. I'm sure there are cases where, in the right hands, sagas can help solve complex problems but, like redux, they are overused by people that are just following the herd and can create a ton of accidental complexity.

One of the things I love about ClojureScript's Reagent library is that I will never need something like Redux because Clojure has was Redux does "for free." Reactive state management is baked in at the language level.

I've gone through your recommendations and adopted most of them. This one feels really strange though. In the recommendation you say:

> If you have truly complex async workflows that involve things like cancelation, debouncing, running logic after a given action was dispatched, or "background-thread"-type behavior, then consider adding more powerful async middleware like Redux-Saga or Redux-Observable.

Aren't these kind of things necessary for really robust applications? For instance, let's say my app fetches some "posts" list and shows it as a table. I have so many "posts" that I'll do server-side pagination. With a naive thunk, if the user clicks on "page 2" and then quickly on "page 3" it is perfectly possible that she ends in "page 2" (because that request happened to complete after the one for "page 3").

How are we supposed to deal with these things with thunks?

Cancellation is definitely something that is trickier with thunks. We recently added a new `createAsyncThunk` API [0] to our Redux Toolkit package, which has built-in support for signaling some kind of cancellation using an AbortController [1], but how that gets used in relation to your actual async call and how your reducer processes the responses is up to you.

Cancellation, debouncing, and other "thread-like" behaviors are where sagas are truly useful. But, in most cases folks are just trying to do simple AJAX requests for data fetching, and trying to learn how to configure and use sagas just for that is way too much overhead.

[0] https://redux-toolkit.js.org/api/createAsyncThunk

[1] https://redux-toolkit.js.org/api/createAsyncThunk#cancellati...

I have never fundamentally understood sagas and I've tried a few times. I'm able to wrap my head around redux-loop though https://github.com/redux-loop/redux-loop

They're just redux middleware implemented with generators, so you can do some nifty things with it if your use case requires. I've used sagas on a several projects and they all actually did need that type of tool but I've chosen thunks on other projects when fetching logic was simple.

I tend to use Sagas now as my go to but I am comfortable with them. I would agree with most of the sentiment on here that they are more complex, though not because of Saga's API but because one really has to understand the core workings of the framework to not screw the pooch. For many their first exposure to generators is via Saga and that is just the tip of the iceberg. One really needs to understand what all the takes are doing as well as how Saga utilizes async and await style logic. To me, Saga's a very readable and very easy to debug but some dragons lie below the API and one has to understand that those dragons are doing magic a lot differently that other frameworks do magic. It's just not a framework where you get to ignore what the magic is doing for you as you will create nasty bugs due to lack of understanding about what the framework is trying to do and it becomes easy to fight against it out of ignorance. That being said, my general opinion is that I like Saga and we generally choose to use it as a team.

+1 for being on board with whatever killed render props and a bunch of HOC's.

Mostly like them, but still not sure the canonical way to write update logic comparing prevProps to current props and running something if it changed where there is more than one dependency though. Need to store prev value in state to compare, or best to ignore the exhaustive deps warning and only run when the prop in question changes? Swear I looked all over and couldn't find a good answer.

What's the problem with render props? You need a component to provide values to its unknown children, you either do render props or you need to clone the children injecting them the values. I find render props to be a much more clear pattern than clone. It also works nicely in TypeScript doing the proper type checking. Am I missing something?

Edit: I think I missed the point. Hooks do make providing state to children simpler in a lot of cases. I just don't hate render props that much :)

Reply on news.ycombinator.com