4 ms·

> The third reason is TypeScript. We have all felt the pain of Redux boilerplate and with TypeScript it does not become better. Redux btw, is redundant now; an

by jeswin 6y ago

> The third reason is TypeScript. We have all felt the pain of Redux boilerplate and with TypeScript it does not become better. Redux btw, is redundant now; and offers very little value over useContext + useState. And they work wonderfully with TypeScript.

ZephyrBlu 6y ago
This is definitely not true, especially if you co-locate your data fetching in your reducers, which is a common pattern. It also provides a single, centralized store instead of needing many context's and lets you abstract data shape/formatting logic away instead of having it in your application. Context and State are great, but they serve a different purpose than Redux.
- chansiky 6y ago
  Having used hooks to replace my state at some point I couldn't agree more. Application state should not be dependent on components, rather components should be dependent on application state. My recommendation is keep hooks and contexts for ui state only, like form fields/validations, modal popups, drawer collapse, filter options, etc, but for things dealing with more general application state which the ui will display, like user information, products list, project data, application settings, etc, a separable state machine should be used. This works well because components are responsible for their own state leaving the state manager clean from individual ui component information, and ui components are free to be passed whatever data improving reusability.
  - Emanation 6y ago
    Why should a seperate state machine be used? Redux doesn't magically seperate state information from the tree. It's built upon react context/provider system, which in effect can be seen as a component. The special sauce, in regards to seperation, is that it can be wired into the component tree without passing it down, which is a property of provider/context and not redux itself.
  - jeswin 6y ago
    > Application state should not be dependent on components Sorry, I don't follow. When using Context, how does the application state become dependent on Components any more than it is with Redux? You can accomplish pretty much the same thing with far less code. Can you provide an example?
- jeswin 6y ago
  > This is definitely not true, especially if you co-locate your data fetching in your reducers, which is a common pattern. How can it be definitely not true, when you have to say "especially"? Most code I've seen (including the official docs) don't data fetch in reducers. But even then, I'm not sure what you mean. > It also provides a single, centralized store instead of needing many contexts... Which you can very well do with useContext and useState.

by jeswin 6y ago

ZephyrBlu 6y ago

This is definitely not true, especially if you co-locate your data fetching in your reducers, which is a common pattern. It also provides a single, centralized store instead of needing many context's and lets you abstract data shape/formatting logic away instead of having it in your application. Context and State are great, but they serve a different purpose than Redux.

chansiky 6y ago
Having used hooks to replace my state at some point I couldn't agree more. Application state should not be dependent on components, rather components should be dependent on application state. My recommendation is keep hooks and contexts for ui state only, like form fields/validations, modal popups, drawer collapse, filter options, etc, but for things dealing with more general application state which the ui will display, like user information, products list, project data, application settings, etc, a separable state machine should be used. This works well because components are responsible for their own state leaving the state manager clean from individual ui component information, and ui components are free to be passed whatever data improving reusability.
- Emanation 6y ago
  Why should a seperate state machine be used? Redux doesn't magically seperate state information from the tree. It's built upon react context/provider system, which in effect can be seen as a component. The special sauce, in regards to seperation, is that it can be wired into the component tree without passing it down, which is a property of provider/context and not redux itself.
- jeswin 6y ago
  > Application state should not be dependent on components Sorry, I don't follow. When using Context, how does the application state become dependent on Components any more than it is with Redux? You can accomplish pretty much the same thing with far less code. Can you provide an example?
jeswin 6y ago
> This is definitely not true, especially if you co-locate your data fetching in your reducers, which is a common pattern. How can it be definitely not true, when you have to say "especially"? Most code I've seen (including the official docs) don't data fetch in reducers. But even then, I'm not sure what you mean. > It also provides a single, centralized store instead of needing many contexts... Which you can very well do with useContext and useState.