4 ms·

By "over redux" do you mean "with redux" or "instead of redux"? I haven't used hooks yet but if you are using hooks instead of redux, it confuses me on how ho

By "over redux" do you mean "with redux" or "instead of redux"? I haven't used hooks yet but if you are using hooks instead of redux, it confuses me on how hooks work. To me they seems to be replacing the need for a class with local state, not replacing a redux architecture? I'm interested to hear more please :)

dbetteridge 8y ago
Sorry should have been clearer. It's more of a combination of react hooks and react context, hooks to deal with local state and context to provide reducer functionality for global state. Just means you can have functional components that respond purely to effects from state changes locally or at global level
- bestest 8y ago
  From my experience I found this kind of separation to be somewhat redundant and am simply using redux to manage all state — both global and local context. This also means that components are simply components, and setTimeouts and everything else is moved out to redux thunk actions. Which makes hooks totally unneeded in my case.
  - acemarke 8y ago
    I'll point out that we absolutely plan to ship hooks as part of the React-Redux library, but we need to do some internal reworking first to make that feasible. See this roadmap issue I just posted for details: https://github.com/reduxjs/react-redux/issues/1177 https://github.com/reduxjs/react-redux/issues/1177
  - lj3 8y ago
    > am simply using redux to manage all state This only works in small apps. I work on a medium sized app at work and we started that way too. It becomes a huge, sloppy mess in short order. Putting everything in Redux is akin to a desktop application that uses nothing but global state. Hooks are great because it keeps the state local, but it can be re-used across components if we need to.
    - jypepin 8y ago
      I would disagree with you and say that from my own experience (not saying your experience is wrong obviously) it's quite the opposite; in small applications, using local states is fine, but as soon as your application grows, having everything inside a central store makes everything cleaner and much simpler, as multiple independent components might want to share state or listen to shared events, etc.
      - lj3 8y ago
        > as multiple independent components might want to share state or listen to shared events, etc. If you recall, I said... > Hooks are great because it keeps the state local, but it can be re-used across components if we need to. The use case you just defined is exactly why hooks were created.
        jypepin 8y ago
        Are you implying the use of context when you say that hooks allow you to re-use state between components? Legit question because I don't know hooks very well. To my understanding, hooks are just syntactic sugar to use and update local state in a function component. How does that help you share state between components?
        ryansolid 8y ago
        I think he must be implying the use of Context as well. That's where the real power is. Combining the 2. The pattern of use is DI even with a global store like Redux, making it not necessarily truly global. What Context does at a base is potentially use React Components as widely accessed stores. The simplest example usually involves abstracting a Parent Component's state/setState into state, and action functions wrapping a Context Provider. To what degrees the stores should be laid out hierarchically mimicking the render tree is debatable. But often there is clear hierarchical ownership on large portions of the data. And often the question is what needs to be topmost and what belongs only within nested context. I think the opinion is still out on that. As you have suggested you could manage everything topmost. Hooks make this really interesting in that they expose this idea of simple change management primitives to any Function component. So while it is still the Context API that allows the data to be shared, Hooks allow for re-usable patterns that can be used out of the box or compositionally built upon. So the Component that contains the provider has the ability through Hooks to do a really good impersonation of Redux(useReducer) or even MobX(useState + useMemo + useEffect). Does this replace those libraries? Probably not. But it is interesting how it gives a built in solution to choose to scale these solution with how you see fit. You have these tools at your disposal without much investment.
  - danlugo92 8y ago
    You're unnecessarily coupling your components to redux..
    - bestest 8y ago
      The only things that are "coupled" to redux are actions dispatched from components. They themselves are very abstract, and when needed are connected using { connect }.

dbetteridge 8y ago

Sorry should have been clearer. It's more of a combination of react hooks and react context, hooks to deal with local state and context to provide reducer functionality for global state. Just means you can have functional components that respond purely to effects from state changes locally or at global level

bestest 8y ago
From my experience I found this kind of separation to be somewhat redundant and am simply using redux to manage all state — both global and local context. This also means that components are simply components, and setTimeouts and everything else is moved out to redux thunk actions. Which makes hooks totally unneeded in my case.
- acemarke 8y ago
  I'll point out that we absolutely plan to ship hooks as part of the React-Redux library, but we need to do some internal reworking first to make that feasible. See this roadmap issue I just posted for details: https://github.com/reduxjs/react-redux/issues/1177 https://github.com/reduxjs/react-redux/issues/1177
- lj3 8y ago
  > am simply using redux to manage all state This only works in small apps. I work on a medium sized app at work and we started that way too. It becomes a huge, sloppy mess in short order. Putting everything in Redux is akin to a desktop application that uses nothing but global state. Hooks are great because it keeps the state local, but it can be re-used across components if we need to.
  - jypepin 8y ago
    I would disagree with you and say that from my own experience (not saying your experience is wrong obviously) it's quite the opposite; in small applications, using local states is fine, but as soon as your application grows, having everything inside a central store makes everything cleaner and much simpler, as multiple independent components might want to share state or listen to shared events, etc.
    - lj3 8y ago
      > as multiple independent components might want to share state or listen to shared events, etc. If you recall, I said... > Hooks are great because it keeps the state local, but it can be re-used across components if we need to. The use case you just defined is exactly why hooks were created.
      - jypepin 8y ago
        Are you implying the use of context when you say that hooks allow you to re-use state between components? Legit question because I don't know hooks very well. To my understanding, hooks are just syntactic sugar to use and update local state in a function component. How does that help you share state between components?
        ryansolid 8y ago
        I think he must be implying the use of Context as well. That's where the real power is. Combining the 2. The pattern of use is DI even with a global store like Redux, making it not necessarily truly global. What Context does at a base is potentially use React Components as widely accessed stores. The simplest example usually involves abstracting a Parent Component's state/setState into state, and action functions wrapping a Context Provider. To what degrees the stores should be laid out hierarchically mimicking the render tree is debatable. But often there is clear hierarchical ownership on large portions of the data. And often the question is what needs to be topmost and what belongs only within nested context. I think the opinion is still out on that. As you have suggested you could manage everything topmost. Hooks make this really interesting in that they expose this idea of simple change management primitives to any Function component. So while it is still the Context API that allows the data to be shared, Hooks allow for re-usable patterns that can be used out of the box or compositionally built upon. So the Component that contains the provider has the ability through Hooks to do a really good impersonation of Redux(useReducer) or even MobX(useState + useMemo + useEffect). Does this replace those libraries? Probably not. But it is interesting how it gives a built in solution to choose to scale these solution with how you see fit. You have these tools at your disposal without much investment.
- danlugo92 8y ago
  You're unnecessarily coupling your components to redux..
  - bestest 8y ago
    The only things that are "coupled" to redux are actions dispatched from components. They themselves are very abstract, and when needed are connected using { connect }.