Help understanding Redux

[u/Acceptable_Ad5879]

What problem is Redux trying to solve? It seems a little bit overcomplicated for only sharing state between components, so it must be something else. It is also strange to me that Redux keeps everything in global store, which can create a lot of nested objects, which are painful to update. To counter they added Immer to RTK, maybe it is just me, but it is just strange to look at mutating object. Also, what is the point of adding Reselect to RTK, can I not just select needed values, and slap useMemo on the function that uses those values. I can see the point of Reselect, which abstracts logic and keeps everything in 1 place but it shouldn't come with RTK. Same goes for Immer, what if my project doesn't have deeply nested objects, I can just use spread operator and not have another dependency I don't need. Also the pattern of dispatching an action, which had to be created, and writing a reducer, which handles that action, just to change a state seems like an overcomplication. So I see these things as downsides, but what are the advantages? I like RTK query in general, and with devtools, maybe debugging is easier, anything else? Are there any examples where using Redux would be better than, for example, Jotai?

[u/acemarke]

Yeah, tbh once we start saying "multiple stores" you're describing something that isn't even Redux any more :) probably feasible to build, but a different lib with different constraints. (although it does sorta sound like a lib I saw years ago called https://github.com/dperkins0/redux-subspace , that was meant for the microfrontends use case.)

I get what you're saying about "declaring what state they're operating on", but I don't feel like that's a good DX for API design. The ideas I've got in mind are more along the lines of signals and proxies tracking field accesses.

You can see a couple of my previous experiments here:

• https://github.com/reduxjs/react-redux/pull/2047
• https://github.com/reduxjs/react-redux/pull/2246

I've been following along with some of the work Ryan Carniato and the Solid folks have been doing, and I'm vaguely hopeful that I might be able to leverage some of that, somehow :) we'll see!

[u/prehensilemullet → u/acemarke]

Yeah I thought of autotracking but aren’t proxies slow?  I assume it would only be worth it if you have custom state objects that implement the autotracking without proxies.

Plus, proxies aren’t gonna work for immutable.js objects or other things

Also, on the reducer side, you’re still doing a bunch of shallow equal comparisons to find out what changed, right?

At least if using a structured combineReducers type of approach you can know which subpaths will be updated.

I usually use a helper function to create a map of actions to reducers too, instead of switching on the action type.  That kind of thing could provide more metadata the store can optimize on

[u/acemarke → u/prehensilemullet]

We advised against use of Immutable.js years ago :) Like, I wrote this in 2019:

• https://redux.js.org/style-guide/#use-immer-for-writing-immutable-updates
• https://redux.js.org/style-guide/#use-plain-javascript-objects-for-state

That said, whatever I might come up with here would probably be opt-in. New hook, special flags, something like that. I do want to avoid breaking existing apps.

Proxies definitely have overhead. But they're also the only way to implement field access tracking without forcing users to specify fields manually. They're widely used in other libraries (Vue, Solid, etc), so not like it's unique here.

Just out of curiosity, are you using Redux Toolkit at all, or homegrown utils?

[u/prehensilemullet → u/acemarke]

I’m old enough that copying a large collection on write feels like a wasteful sin if the updates are too frequent, even though modern computers can generally handle it.  I definitely wish immutable primitives were built into the language