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.