101–110 of 133 posts
previous comments, when this may have actually been news: https://news.ycombinator.com/item?id=16918003 why post it again?
(tbh I'd forgotten it actually hit the front of HN when I wrote it the first time!)
Earlier quoted context omitted.
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 correctl…
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])
So yeah, your statement confuses me, because it doesn't seem to describe how React-Redux actually works.
Earlier quoted context omitted.
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 correctl…
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. Bot…
Earlier quoted context omitted.
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. Bot…
Most redux users use mapStateToProps and rely on it to notify you when a redux change has happened.
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.
https://redux.js.org/faq/organizing-state#should-i-put-form-...
Earlier quoted context omitted.
In the vast majority of React apps you do not need this. I work on an app that has a total of about 400 separate Redux actions across half a dozen reducers and a couple of stores. There's a lot of things that cause side effects. Being about to see what actions fired with various props is immensely useful for debugging. redux-devtools and Reactotron are immensely useful. You're right that the majority of React apps do…
Can you give me an example how you got to 400 actions? Just enumerate like 5 or so, I’m assuming you are building features where groups of actions are just necessary based on the patterns you are using. I’m genuinely curious because I feel like this kind of inflation of actions/reducers in Redux is what makes it nightmarish.
That's 76 actions just for the NFS/CIFS-as-a-service UI.
(I'm not saying this is the best way to do it, but that's what's happening right now.)
One underrated thing that I miss from using Redux is the "action trace". You can literally sit down with the stakeholders [1] and explain the exact things that caused a screen to render . And these things are not cryptic function calls with stack-traces, but simple and chronologically ordered sets of human readable "actions" (I like to think of them as events) like UserFetched -> PlanFetched ( ) -> FrozenUser. One ca…
Overrated. In what kind of application do you need this? In the vast majority of React apps you do not need this.
One underrated thing that I miss from using Redux is the "action trace". You can literally sit down with the stakeholders [1] and explain the exact things that caused a screen to render . And these things are not cryptic function calls with stack-traces, but simple and chronologically ordered sets of human readable "actions" (I like to think of them as events) like UserFetched -> PlanFetched ( ) -> FrozenUser. One ca…
I was about to ask what kind of stakeholder gives a damn about sitting down with you and going through an action trace to see why a certain screen rendered, but I’m glad you added the note at the bottom. Regardless, yourself or another developer as the “stakeholder” in this scenario is a bit of a cop out. In the real world stakeholders aren’t technically inclined and even if they are they don’t care about this minuti…
Earlier quoted context omitted.
I was about to ask what kind of stakeholder gives a damn about sitting down with you and going through an action trace to see why a certain screen rendered, but I’m glad you added the note at the bottom. Regardless, yourself or another developer as the “stakeholder” in this scenario is a bit of a cop out. In the real world stakeholders aren’t technically inclined and even if they are they don’t care about this minuti…
Please start thinking of "stakeholder" as everyone who has a stake in a project. This includes those who have to maintain the code and those who have to operate the service. Thinking this way will help ensure requirements gathering includes all stakeholders.
I've recently tried using Redux for a side-project. While it solves the problem (organizing state), I feel there is too much boilerplate for my small project. Are there any popular alternatives which don't use reducers? EDIT: thanks for all the responses, I'll check them out :)
You can use a React Context and have simple global state in your React app. If you like reducers, throw in a useReducer hook and you have a large part of what people use Redux for.
I can implement this thing in vanilla JS, and it would not take more than a few milliseconds. React is cool, but so damn hard to optimize.