Hacker News Reader

Comment by antoineMoPa | Hacker News Reader

Every React + Redux I've worked with were needlessly bloated & slow. I think that there is something that leads to bloat and slow performance in the react+redux world, but I can't quite identify it yet.

View on HN

I have had exactly the opposite experience. I recently rolled onto a React project without Redux and the code was pretty gross. Multi hundred line React components with markup, API calls, and business logic all mixed together in an untested and untestable cocktail garnished with a heavy dose of prop drilling and deeply nested callbacks.

Adding Redux to this app was a huge improvement. Test coverage is now almost 100%. The views are now tiny and simply render props and dispatch actions. Complex workflows are handled beautifully by Redux sagas. Overall, the codebase is now one of the cleanest I have ever worked on.

I am not saying you have to have Redux to have a good frontend codebase, but it definetly helps a lot. If your app is even remotely complex, its hugley helpful to have a global data store. If you are going to have workflows with asynchronous components, Redux sagas are an incredible tool.

My hunch is that the apps that don't use Redux either 1. suck or 2. have had some smart person hand roll a framework that has most of the core principles of Redux in it. I am not that smart, and I don't want my codebase to suck, so Redux is the best choice for me.

Where can we see examples of clean testable redux code like your app?

Have you used redux-sagas on any projects before this one? How do you feel it compares with redux-thunk?

I've used redux-thunk for all of my past projects but recently inherited a project using sagas. It seems to be pretty unorganized and I'm wondering how much effort I should put into cleaning it up, if it's even possible.

I far prefer redux-sagas personally. I find the generator/yield style to really reduce the mental overhead of a saga's flow as compared to a thunk.

Have you tried thunks using async/await? IMO its all the benefits of being easy to read and understand without having to learn a totally new concept (generators).

Yep, agreed. The biggest missing capability there is being able to _respond_ to dispatched actions, which thunks can't do. But, most apps don't immediately need to do that anyway.

Sagas are an incredibly powerful tool... and 95% of Redux apps don't need them. Most apps should stick with thunks until they truly have a need for very complex async logic.

See this Redux FAQ entry for more details:

https://redux.js.org/faq/actions#what-async-middleware-shoul...

I don't think there's anything about React + Redux that is inherently slow, but I don't think it's as "idiot proof" as other frameworks out there. One app at my previous employer cargo-culted redux to the point where no component was allowed to have its own state. With its massive global state, every keystroke was painfully slow (thanks, redux-form).

And that is something we explicitly suggest that people _not_ do:

https://redux.js.org/faq/organizing-state#do-i-have-to-put-a...

https://redux.js.org/faq/organizing-state#should-i-put-form-...

I've seen a couple of apps that have the same anti-pattern. They have a connected component that is basically a global container of all other components. They don't do anything sophisticated with shouldComponentUpdate, so whenever something changes all child components (i.e. basically the whole app) is rendered again.

On its own that isn't necessarily that bad, but combine that with form fields directly manipulating the Redux state (i.e. an action for every keypress) and it's easy to build an app that has poor performance.

Selecting only the needed data for each component should mitigate this, since react-redux automatically compares the selected data only.

I will agree that it's too easy for components to watch too much of the state, but it's not necessarily wrong to have all the state in one tree.

Doesn't ring true to my experience at all. I recently polished off a ~50k LoC application that runs blazingly fast even on IE10.

My experience is when people complain about slowness it's usually because the application architecture/design is poor and not because of any particular technical choice.

Bloated and slow are not terms I typically associate with React and Redux... What else is being used in the application(s)?

An app I've been working on even does some simple SVG overlays via React/Redux and responds to mouse events with very little issue. It's probably the biggest example of pain I've felt with it.

Of course, an app can be written very badly depending on how "clever" a developer tries to get, or how it may be using remote resources and how that interacts. Without more detail, hard to tell.... of course there's the matter of publishing without "production" mode being set too.

The app in question does have about a 500kb payload, which is larger than I'd like... but using material-ui and a few complex features it's not nearly as bad as many other apps I've used.

I thought I was alone. Hello like-minded stranger.

Reply on news.ycombinator.com