Sunk cost, these people have spent hundreds of hours learning something that ultimately is going to be discarded even more. That's why people are downvoting.
No, I downvoted because all the comments amount to X bad Y good. What they are posting has nothing to do with the article. The article even specifically talks about most of the Ys that are getting commented about and address what use-cases they are for that Redux isn't for. It's clear those people are not here to talk about the thing they are commenting on, they are just here to tell everyone they don't like Redux.
I have yet to be given a good usecase for Redux. All I see is code that ends up causing issues:
- redux pollution (not cleaning up state and things leaking)
- because you can't access redux state directly, components have to copy redux state and store them as props (which makes 0 sense, its state not props). But now you run into the issue where the local prop is not in sync with redux since redux updates are correctly done in chunks.
What do you mean by "can't access Redux state directly" and "copy Redux state"? Neither of those sounds correct.
Components have always been able to extract whatever data they want from the store using the `connect` API, and now our new `useSelector` hook. Those APIs return whatever values _you_ want for use in the component, and that generally is the actual object references to the real data that's in the store.
Both `connect` and `useSelector` subscribe to the store and re-run the logic you've provided whenever the store is updated, and force a re-render of your component with that fresh data. If I have:
const user = useSelector( state => state.users.entities[props.userId])
Any update to that specific `user` object in the store will cause this component to re-render. Same goes for `connect` and `mapState`.
So yeah, your statement confuses me, because it doesn't seem to describe how React-Redux actually works.
Right, and I'm saying that both `mapState` and `useSelector` perform the same behavior: allowing your component to subscribe to portions of the Redux store state, extract that, and update the component when that data changes.
So, I don't understand what points your parent comment is trying to make, because the whole point of React-Redux _is_ to keep your components in sync with the data in the Redux store state.
We have run into several issues where a user clicks a button (which updates redux) and then quickly clicks on something else and the 2nd component has not been updated yet as it used the mapState prop (the update is being batched by redux and hasn't gone out yet to the listeners).
Switched to using a shared model class instance - the value is changed immediately and anyone who needs to know the latest version can do it easily. Much simpler, faster and easier to debug since there is truly only one source of truth, not copies everywhere.
That sounds very surprising. Yes, React-Redux does batching and cascades updates through the UI layer, but that process should happen extremely quickly (far faster than the amount of time needed for someone to click on another button).
I'm also not sure why you keep using the phrase "copies". The Redux store has the only actual copy of that data, and your `mapState/useSelector` functions typically return the actual references to that same data. The only copies made are if you make them yourself. Also, the value in the store _is_ already updated before any of the UI subscribers are notified.
Can you put together a sandbox that reproduces this problem and file an issue? I'm very curious what you're actually seeing.
Pretty easy - component that stores a redux computed value and a setTimeout that calls an action with the value. If the settimeout (or a websocket event, etc) fires before the batched update, you are out of sync.
Most people have simple applications so redux works fine, but once you get complicated async work things just break down.
tbh that doesn't sound like a Redux-specific problem. That sounds like a general async / stale-references problem. If you've captured a value and try to use it later, then yeah, you're probably going not going to be using the latest version.
