4 ms·

> The only reason people use redux is that they want a sharable state across the app No. You can do that with a global variable. Redux’s main features are ser

> The only reason people use redux is that they want a sharable state across the app No. You can do that with a global variable. Redux’s main features are serializable actions, serializable state, plus localized updates if you use immutable data. It gives you the ability to throw your state at localstorage, send actions over a websocket, easily traverse history (undo, time travel) and keep a log of changes. It’s ok to not need any of this, most projects don’t, but at least write off the library for the correct reasons. > React is fast by default Also not true. React does basically no optimization at all besides batching state updates. Your computer is just fast enough that you’ll think it doesn’t matter until it’s too late. Optimizing rendering is 100% on the application author.

deleted 4y ago
[deleted]
collegeburner 4y ago
any tips or resources you seen good for optimizing react?
- acemarke 4y ago
  Generally: - Use the React DevTools Profiler to identify components that are rendering more than expected, or taking too long to render - Wrap key components in `React.memo()` to have React avoid recursing through those subtrees unless the component props have actually changed - Avoid putting large state objects into a single context provider, as all components reading that context will re-render whenever it changes (and all of their children too) - Use `useMemo` to cache any expensive transformations that happen during rendering I've got an extensive post that covers how rendering works as a whole, and has a section on understanding React perf optimizations: - https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
brhsagain 4y ago
That doesn't entirely contradict the author's statement. Redux may do all of those things, but the proximate need of most people who use Redux is sharable state. Then they use something like Redux because it provides "structure" and has lots of stars on Github. Incidentally, I have to agree with the author directionally on this point. Redux makes codebases such a pain in the ass to work with. Every new change you want to make to the store, you have to make about five changes across five different files. When you're working on a new feature you spend most of your time just wrestling with Redux, creating an action type, creating an action creator, creating a reducer, importing/exporting all this shit, blah blah blah. Then a new engineer who wants to figure out what the code is actually doing has to trace through the action, then the action creator, then the reducer, blah blah. This is before you throw in stuff like epics and run API calls through your action/reducer pipeline. It is no wonder productivity per capita in tech is so low.
- flippinburgers 4y ago
  Redux toolkit does exist.
  - TheBigSalad 4y ago
    I hated redux until I started using this.
- acemarke 4y ago
  > Every new change you want to make to the store, you have to make about five changes across five different files This has never actually been a requirement to use Redux. Admittedly, having separate folders and files by type _was_ a pattern that was shown in the docs originally ( `reducers/todos.js`, `actions/todos.js`, `constants/todos.js`, etc), but even in the early days the "Ducks" pattern of "put all the logic for a feature in one file" was a thing that you could do. Today, we specifically teach "slice/ducks files" as the standard approach [0] [1], and Redux Toolkit's `createSlice` API makes it trivial to do that - just write the reducers, export the matching auto-generated action creators, and you're done. > throw in stuff like epics We've actually been advising _against_ using both sagas and epics for side effects for years now, and especially against using them for basic data fetching. Today, Redux Toolkit's "RTK Query" data fetching and caching API is a complete solution for caching server state on the client, and we also recently shipped a new "listener" middleware that is a simpler alternative to sagas and epics for other reactive side effects. [0] https://redux.js.org/tutorials/essentials/part-2-app-structure#creating-slice-reducers-and-actions https://redux.js.org/tutorials/essentials/part-2-app-structu... [1] https://redux.js.org/style-guide/#structure-files-as-feature-folders-with-single-file-logic https://redux.js.org/style-guide/#structure-files-as-feature...
5350-uiop-1130 4y ago
I think the author was trying to be brief. There is too much know-it-all-ism in dev.
POPOSYS 4y ago
The most interesting part: x people writing react for many years will have x completely different views on how things should be done.
ironmagma 4y ago
Well, we knew there had to be a reason there was all this React code out there that doesn't abide by reasonable standards. I'd really be interested to hear why anyone prefers working with slow-to-recompile, globally-scoped CSS, or why people feel the urge to mix view and controller code. Can't you just have one component for view, and one component to handle state?

deleted 4y ago

[deleted]

collegeburner 4y ago

any tips or resources you seen good for optimizing react?

acemarke 4y ago
Generally: - Use the React DevTools Profiler to identify components that are rendering more than expected, or taking too long to render - Wrap key components in `React.memo()` to have React avoid recursing through those subtrees unless the component props have actually changed - Avoid putting large state objects into a single context provider, as all components reading that context will re-render whenever it changes (and all of their children too) - Use `useMemo` to cache any expensive transformations that happen during rendering I've got an extensive post that covers how rendering works as a whole, and has a section on understanding React perf optimizations: - https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

brhsagain 4y ago

That doesn't entirely contradict the author's statement. Redux may do all of those things, but the proximate need of most people who use Redux is sharable state. Then they use something like Redux because it provides "structure" and has lots of stars on Github. Incidentally, I have to agree with the author directionally on this point. Redux makes codebases such a pain in the ass to work with. Every new change you want to make to the store, you have to make about five changes across five different files. When you're working on a new feature you spend most of your time just wrestling with Redux, creating an action type, creating an action creator, creating a reducer, importing/exporting all this shit, blah blah blah. Then a new engineer who wants to figure out what the code is actually doing has to trace through the action, then the action creator, then the reducer, blah blah. This is before you throw in stuff like epics and run API calls through your action/reducer pipeline. It is no wonder productivity per capita in tech is so low.

flippinburgers 4y ago
Redux toolkit does exist.
- TheBigSalad 4y ago
  I hated redux until I started using this.
acemarke 4y ago
> Every new change you want to make to the store, you have to make about five changes across five different files This has never actually been a requirement to use Redux. Admittedly, having separate folders and files by type _was_ a pattern that was shown in the docs originally ( `reducers/todos.js`, `actions/todos.js`, `constants/todos.js`, etc), but even in the early days the "Ducks" pattern of "put all the logic for a feature in one file" was a thing that you could do. Today, we specifically teach "slice/ducks files" as the standard approach [0] [1], and Redux Toolkit's `createSlice` API makes it trivial to do that - just write the reducers, export the matching auto-generated action creators, and you're done. > throw in stuff like epics We've actually been advising _against_ using both sagas and epics for side effects for years now, and especially against using them for basic data fetching. Today, Redux Toolkit's "RTK Query" data fetching and caching API is a complete solution for caching server state on the client, and we also recently shipped a new "listener" middleware that is a simpler alternative to sagas and epics for other reactive side effects. [0] https://redux.js.org/tutorials/essentials/part-2-app-structure#creating-slice-reducers-and-actions https://redux.js.org/tutorials/essentials/part-2-app-structu... [1] https://redux.js.org/style-guide/#structure-files-as-feature-folders-with-single-file-logic https://redux.js.org/style-guide/#structure-files-as-feature...

5350-uiop-1130 4y ago

I think the author was trying to be brief. There is too much know-it-all-ism in dev.

POPOSYS 4y ago

The most interesting part: x people writing react for many years will have x completely different views on how things should be done.

ironmagma 4y ago

Well, we knew there had to be a reason there was all this React code out there that doesn't abide by reasonable standards. I'd really be interested to hear why anyone prefers working with slow-to-recompile, globally-scoped CSS, or why people feel the urge to mix view and controller code. Can't you just have one component for view, and one component to handle state?