Earlier quoted context omitted.
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.
No, I keep a very mercenary mentality when it comes to projects. I’m told what needs to be done and I do it and get paid for it. Early on in my career I cared too much, and it brought nothing but unnecessary stress. I will never sit down and watch a redux stack trace, it’s not my job and I got better things to do.
Redux – Not Dead Yet (2018)
111–120 of 133 posts
Re: Redux – Not Dead Yet (2018)
#112One 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…
https://cerebraljs.com/
it's also not clear how this is a replay to the above...
Re: Redux – Not Dead Yet (2018)
#113Earlier quoted context omitted.
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've done that recently, and I had many performance issues. I have a long-ish list of very simple components that are in a sorted order. So when I change the value of one, I re-sort the list. I was hoping React would only rerender the changed items (remove old, insert new). But no, it rerenders the whole list, which takes 500ms. I made sure object references in the list stay the same, that didn't help. I can implemen…
React's default behavior is that when a component renders, React will recursively re-render _all_ of its descendants. it then diffs the VDOM render output to see if you've asked for any changes to the UI since the last time it updated. If the two VDOM trees are the same, React says "nope, nothing to do here!", and ends the render pass. _If_ you requested changes, it then gathers them up and applies them all to the DOM in one step.
You can optimize the rendering behavior in some ways if needed. The `React.memo()`, `PureComponent`, and `shouldComponentUpdate` APIs [0] allow you to tell React to skip re-rendering if you know that a component's props haven't meaningfully changed, and thus would result in the same UI output as the last time. This does require that the child components be separate component types (ie, ``), not just the parent rendering a bunch of plain elements (like ``).
For lists in particular, React needs to know how to identify which items are which. React doesn't care about object references, but you can pass a special prop called a `key` when rendering items in a list. That way, if you move a list item up, swap a couple others, delete one, and add a couple more, React knows what existing list items ended up where, and can update the DOM efficiently in response. Otherwise, changes to lists without good use of keys can result in more DOM work being done than actually necessary.
Re: Redux – Not Dead Yet (2018)
#114One 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…
Re: Redux – Not Dead Yet (2018)
#115Earlier quoted context omitted.
Most redux users use mapStateToProps and rely on it to notify you when a redux change has happened.
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.
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.
Re: Redux – Not Dead Yet (2018)
#116Earlier quoted context omitted.
Overrated. In what kind of application do you need this? In the vast majority of React apps you do not need this.
Have you used it? That’s like saying the Chrome debugger or CPU call stacks are overrated. It’s a debug feature that any React+Redux app can use to trace back why something happened. I’ve used it a few times, and when you need it because you don’t understand why an action was triggered, it’s super convenient.
Re: Redux – Not Dead Yet (2018)
#117Re: Redux – Not Dead Yet (2018)
#118One 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…
Even better to combine this with sentry. So you can see all the actions that led to the error.
Re: Redux – Not Dead Yet (2018)
#119One 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…
Re: Redux – Not Dead Yet (2018)
#120Earlier quoted context omitted.
Overrated. In what kind of application do you need this? In the vast majority of React apps you do not need this.
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…