Hacker News Reader

Comment by wotamRobin | Hacker News Reader

Principal eng working with 3 teams on a ~500k loc React site here. After lots of experimentation, we’re just using React contexts.

- Redux is cool but there’s so much decoupling that it gets hard to read the code. New hires would take too long to start, TS types got crazy, it was too much.

- XState is very good for state machines… but you barely ever need that level of control. Most of the time understanding it ends up being overhead. We’ve had maybe one good case for using it in about 10 years.

- React’s contexts are minimum overhead and work very well with “jump to definition” functionality and TS types. You can choose to use a reducer if you want, or skip it if it isn’t appropriate.

YMMV of course. This is just us.

View on HN

I came into a fairly complex app using redux. I asked the developer about why contexts wouldn’t be a better fit, and within a week we’d dropped redux for contexts. There are certainly uses where Redux really is the right tool, but it’s nice how flexible the built in stuff is.

Sure, but as a senior I could get juniors up to speed on redux mostly within a day, the longest was 3 days. It's not that difficult if you have a working codebase they need to contribute to.

This is not my experience at all.

I had senior developers, who have worked with RTK before, misusing simple features such as the "createSlice" API.

By contrast, I have never once sat down with a junior to walk through React's Context. I assume, they just read the docs and were good to go.

I'm genuinely curious - do you have any examples of "misusing `createSlice`"?

FWIW I see folks misusing / misunderstanding Context on a near-daily basis, mostly around misunderstanding what components will re-render and when. That's part of what led me to write my "Guide to React Rendering Behavior" post, to clarify when/why/how React renders:

- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

A common issue with "createSlice" even with seasoned developers is they're introducing useless nesting and weird imperative-functional constructs because they fundamentally do not understand how "immer" works.

I've read your blog post, and I might be missing something, but you do not seem to be highlighting any re-rendering issues specific to context. Juniors will have to learn how React works anyway. Context or not.

The usual misunderstandings about context are:

- Thinking that if you change a field in the context value only components that read that field will re-render

- Thinking that _only_ the components that consume the context will re-render, not realizing that normal recursive rendering behavior resumes from there

- Not realizing that updating a context requires a `setState` call in the parent that renders the `<MyContext.Provider>`, and you can easily end up in a situation where the _entire_ component tree renders just because of default recursive rendering

Can you point to some examples of the "useless nesting" and "weird constructs" you're referring to? I'm curious to see what's happening, and if there's any docs improvements we can add to help provide guidance.

These "misunderstandings about context" are not specific to context. React developers will have to learn about them whether they are using context or not.

> Can you point to some examples of the "useless nesting" and "weird constructs" you're referring to?

Example: Create a slice with a list of items as initial state and truncate it in a reducer.

Moved to context in full also but I will say Redux's toolkit thing they released is a nice addition that was much needed. I do enjoy using some RxJS still for certain problems. Agreed on XState. Want to use it but its way overdoing it often.

Got any comment on the re-rendering argument? "Renders should be cheap anyway" or are you doing some specific optimizations?

Yep when I was rewriting the MVP at my current place I looked into them all and decided that context + hooks (and a server side pass for first paint) was all we needed. It was hairy at first keeping things in store etc but we wrote some lib functions that we haven’t had to touch since.

Redux is nice, but it’s be nice to have a very minimal framework for adding a global and local states via hooks and syncing their data structures to the indexed db

What are your thoughts on MobX?

We use mobx and I think it’s great. The observable / computed model is really familiar from spreadsheets so it’s very easy to reason about code and computations. You always just think about your data in terms of being computed from dependencies without worrying about pushing state though the system.

We have an object graph (updated via web socket subscriptions) and then twist and turn slices of that data on the way up to the components. I hardly think about the fact that mobx is there and instead just think in terms of reshaping data for display.

i like mobx because it encourages you to separate state from presentation more than React Context does, but doesn't discourage keeping logically separate state trees separate the way Redux does.

Other poster here -

Success with MobX on a project. I worked as lead picking up an existing code base - none of us had any MobX experience so came in fresh.

My employer was kind enough to offer up FrontendMasters subscriptions - I watched a MobX course there over a couple of nights - link: https://frontendmasters.com/courses/redux-mobx/

I enjoyed it! Got the job done, no scaling issues

What do you do for modifying the data that is shared across the app? It seems like you’d either have one huge context that’s very hard to manipulate, or many deeply nested small ones?

We’re using redux (with a copious amount of selectors) and it’s the only reason I have a little bit of confidence where all our data is.

I have built a lot of apps, including huge react apps. The problem you are describing is usually a result of people representing too much in state of as part of the same state.

Now I could be wetting but it's hard to have these sorts of discussions on the abstract.

Can you name examples of such state?

It can be combinations of both. Many deeply nested small ones is convenient for objects/actors/agents/entities with different lifetimes.

You can have many small states within a larger context, and each consumer component can choose which states it wants from the context. Basically it's a bunch of global variables.

Right but every time that context changes it triggers a re-render of every child component regardless of if it’s consuming that bit of state or not. These comments are making me really question other peoples’ understanding of what I thought were kind of basic principles of how react, context, or redux work…

Agreed. For large apps with even a little bit of complexity, context doesn't seem like much of a solution. You either have a million contexts for every shared state slice to optimize re-renders or you have a single context that takes a huge hit on performance. A single large context object is redux except redux knows how to intelligently update components based on what changed.

I don't get the hesitation to use redux. I've used it on every single FE app I've worked on and never regretted it. I can make redux do exactly what I want it to do and with the power we get from memoization of selectors via reselect, there really is nothing that beats it.

I'm also convinced that most people praising react-query are hugely missing out on the level of control you get with redux. Further, coupling side-effects -- e.g. fetching data from api -- with react component lifecycles is wrought with awkward edge-cases that you don't have to deal with in redux.

The Redux system is really hard to trace through in an IDE. It turns every simple function into lines of boilerplate spread across multiple files, and simple business logic becomes so much harder to read.

Maybe I'm just not smart enough, but I've been working with Redux for a few months and I get more confused every time I look at it, despite hours of videos and documentation and tutorials. It's just not at all clear to me what it's doing behind the scenes and how the typings get transfered and what's happening during async operations.

I don't think I'd ever want to use Redux again after this experience. I'd much rather deal with performance problems than the layers of unreadable abstractions that Redux uses...

Maybe that's where part of your confusion lies, the redux flow itself is completely synchronous. I've seen people write async dispatch(), then getting confused as to why it's not taking effect. Probably writing lots of state machines in C helped. Redux at its core is basically just a state machine. Through functions (actions) you invoke the reducers which change the state. And then you use that state in your app. I do agree that the documentation around redux is not very clear at the minute. And I will add that the best tool is the one you understand the best.

Like most systems, it’s all about how it is setup. I’ve learned over 5-7 years how to organize FE (with redux) code so it is readable. Also inheriting a system can be quite the burden and I could see how it was be difficult to grok.

I also heavily leverage https://github.com/neurosnap/robodux to treat redux as a database.

At the end of the day, redux is an event emitter (pub/sub) with a single object that stores all of your state that multiple components need to reuse.

Just to check, are you using "modern Redux" with Redux Toolkit + React-Redux hooks, or the older-style legacy "handwritten" Redux patterns that existed before Redux Toolkit?

If you haven't seen RTK, we designed it to make Redux a lot simpler to learn and use:

- https://redux.js.org/introduction/why-rtk-is-redux-today

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

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

Does it really? Hmm, I never noticed that. Will have to check for optimization opportunities then.

Does memoizing the state help?

> Does it really?

It doesn't. Updating state in a component triggers the re-rendering of all its children. This is what they are referring to. You can stop that propagating effect as usual by wrapping direct descendants in React.memo().

Be aware, that an anonymous list of components will show up as "re-rendering" in the browser tools. You can verify that this is not(!) the case by looking at the profiler instead.

Additionally, if you cannot tolerate even just one component re-rendering, you can simply use React.useSynExternalStore() instead of Context.

The same is true in redux, every action calls every reducer, every connected component renders. Thats why with and without redux you need performance optimizations like memoizing components and/or selectors

Not that with just react contexts, you can chose to split them up instead of or in addition to employing memoization

That's not true though. Every connected component subscribed to a particular slice of state updates...not every connected component, e.g. `useSelector(appState => !!appState.someThing)` only causes a re-render of the subscribed component if the value of `!!appState.someThing` changes. Unless that's what you meant in the first place but your tone and talk of memoization seemed to imply otherwise.

No issues with needless rerenders?

My takeaway from these comments is that people either don’t care or literally don’t know how context works but are talking about how it’s better than redux lol

Could you elaborate?

He's probably talking about this thread... https://news.ycombinator.com/item?id=34134290

This is your brain on Redux.

Context does not trigger the re-rendering of all children. Updating state does. And you prevent that propagating effect by wrapping direct descendants in React.memo().

Guess what, this entire thread is literally people discussing using context for… app state. But yeah thanks for being patronizing

FWIW I think hooks have made types a lot easier to deal with in Redux.

Absolutely, and that's a major reason why we specifically teach the React-Redux hooks API as default today, and have guidance on setting up "pre-typed" hooks with the store types baked in:

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

- https://redux.js.org/tutorials/typescript-quick-start#define...

I thought the issue with that is that it re-renders if any part of the context changes.

You’re correct and these people advocating for this are definitely re-rendering every component in their tree with every change

It just means you need more granular contexts right?

Right, but then you have a ton of contexts littered everywhere. Seems like that would be a lot of clutter.

In my experience most of my state in contexts changes infrequently (auth information, or the “current client” for a dashboard, or whatever), and then local state is sufficient for the rest. The few times I have sufficiently complexity in the “middle” I indeed have been annoyed and had to be careful to avoid over-frequent rerenders.

It’s just rare enough that “prefer contexts” is a good rule. Simpler, easier to understand code, with no Redux nonsense.

Redux isn’t nonsense you’re just being dismissive and not taking the time to learn to understand it properly.

Thanks for sharing

React Router moved to contexts some number of versions ago...as I look into libraries for React, I see most leveraging Contexts. I've had success with it over the past year and appreciate your affirmation

Reply on news.ycombinator.com