7 ms·

Maybe a good place to ask this: I've been hearing a lot of "oh we don't use Redux, we use hooks" lately, as if this obviously makes sense. Am I missing someth

Maybe a good place to ask this: I've been hearing a lot of "oh we don't use Redux, we use hooks" lately, as if this obviously makes sense. Am I missing something? To me this seems like "oh we don't use Redux, we use arrays". I'm gonna need quite a few more details before I can make any sense of a statement like that. Like... what? How... how does that explain what you're doing? One of these things is not like the other. "Oh we don't use doors on our buildings anymore, we've switched entirely over to trees". Huh? What the actual hell does that mean?

searchableguy 6y ago
They might be using context. The problem with that though is it will cause performance issues due to unintentional rerendering. Not something to worry about for a small app. https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html
- karatestomp 6y ago
  Are people just using "hooks" to mean "all new functionality in React that happens to be available to/as hooks"? To me it's like (actually very like) "oh we're doing that with methods". Uh. OK? Cool I guess? That's not informative.
  - searchableguy 6y ago
    Maybe. I really don't know. There are some places where functionality is dependent on hooks. React fast refresh won't work with class components. (useState is the hook alternative to class style state management and fast refresh is fancy hot reloading but with persisted state and only reloading modified modules/components). There are few escape hatches only built as hooks mostly for improving performance issues which weren't previously available. But most of the hooks are basically reimplementation of features from class style components. There are differences in how hooks work though. Hooks are executed as they are laid out. Previous life cycle methods were dumped into a single useEffect hook. It's easy to change hooks and introduce separation in how you build your logic is what I assume they might be referring to. Instead of <Consumer> {({text}) => { return <div> {text} </div> }} </Consumer> You can do const [data] = useConsumer() return <div> {data.text} </div> It gets messy with a real complex application. typing on mobile is sad.
    - hombre_fatal 6y ago
      Indenting by four spaces gives you preformatted text on HN. It's for code.
  - jerrycruncher 6y ago
    You're probably not far off. For the Redux case, that statement almost certainly means using at least one top-level Context Provider along with `useContext` in consuming components to replace or avoid the use of a Redux store and `connect`.
speg 6y ago
Perhaps they mean instead of Redux, they are using Context + useReducer.
tildedave 6y ago
I'd guess comments like this come from people thinking the primary complexity of Redux is the data store, rather than the "all changes to your state are represented as plain objects". The Redux FAQ goes into this: https://redux.js.org/faq/general#when-should-i-use-redux https://redux.js.org/faq/general#when-should-i-use-redux Can't blame them missing the forest for the trees when you spend all your time writing the reducers and connectors vs the actions themselves.
- acemarke 6y ago
  Note that our new official Redux Toolkit package [0] simplifies most Redux use cases and logic, including eliminating the need to write action creators and action types by hand and allowing "mutating" immutable update logic in reducers. The React-Redux hooks API [1] is also generally simpler to use than `connect`. We're now recommending that people use RTK as the default approach for Redux apps [2], and I'm working on a new set of tutorials that will teach RTK and React-Redux hooks as the standard approach [3]. [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://react-redux.js.org/api/hooks https://react-redux.js.org/api/hooks [2] https://redux.js.org/style-guide/style-guide#use-redux-toolkit-for-writing-redux-logic https://redux.js.org/style-guide/style-guide#use-redux-toolk... [3] https://github.com/reduxjs/redux/pull/3740 https://github.com/reduxjs/redux/pull/3740
brlewis 6y ago
I can't say for sure what they mean, but I'd guess it's saying they keep shared state in a parent component rather than having a global data store for their app. The useState hook might explain their chosen wording.
alexbanks 6y ago
This might be of benefit: https://blog.logrocket.com/use-hooks-and-context-not-react-and-redux/ https://blog.logrocket.com/use-hooks-and-context-not-react-a... If Redux is a a vanilla-ish JS store and a Reactified access pattern, keeping the store but replacing the access pattern with React Contexts. I am not a React expert.
- RobertKerans 6y ago
  This is replacing Redux with hand-rolled Redux. The pattern works, and is useful for very small apps, but get anything more complex where a state container is a useful thing and the tradeoff makes it pointless. Redux is extremely simple, very easy to test, and has excellent tooling. React-redux has necessary optimisations already written into it. And the boilerplate argument holds much less weight with hooks and redux toolkit.
ctidd 6y ago
One of the problems Redux is used to solve (as a global store) is peace of mind that you won't need to refactor large swathes of component trees to reparent state and callbacks that need to be shared or persisted across different subtrees as new business requirements arise. Hooks (especially custom hooks, which are just a composition of other hooks packaged together as a single function) make the reparenting/hoisting/anchoring of state and callbacks trivial compared to other mechanisms, providing similar peace of mind that you're not boxing yourself into an inextensible component tree. (This is regardless of context; passing down props isn't a large pain point, and is often misguided to try to solve because it leads to importable components and hidden contracts.) Render props and HoCs solve similar problems for composition/reuse of functionality (these are all mixins at heart), but the hoistability of hooks is really the distinguishing mark in my experience.
- ricardobeat 6y ago
  Replacing redux with hooks that return local state can be a road to hell, as calling the hook somewhere down the tree will duplicate the state and there is no good way to prevent developers doing that.
  - nightski 6y ago
    IMO that's not much different than introducing a new variable in your global state to represent the same thing because you didn't realize there was already one there. If you have a team you need discipline, code reviews, and leadership. No state solution is going to solve this for you.
    - diob 6y ago
      I always try to tell folks that frameworks won't save them from themselves.
    - ricardobeat 6y ago
      It is not a matter of discipline. Avoiding this gotcha requires you to manually inspect your entire parent component hierarchy looking for uses of that hook - sometimes that is a plain grep away, but it is a very much invisible error. You also have to be familiar with the inner workings of the hook itself, and any other nested hooks, to verify if they use any local state or not. If it does, and you need to share that state, well, that's a big rewrite which kind of defeats the initial argument. Maybe extra tooling could be built to avoid this, if we weren't already drowning in linter plugins...
acemarke 6y ago
Hi, I"m a Redux maintainer. Context and hooks don't "replace Redux", but they do overlap with some of the scenarios and use cases that previously led people to choose Redux. Please see my post "Redux - Not Dead Yet!" [0] for information on how Redux compares to tools like React context + hooks and GraphQL, as well as situations in which it makes sense to use Redux. I'd also suggest reading my post "React, Redux, and Context Behavior" [1] and watching my Reactathon 2019 talk on "The State of Redux" [2] for additional information on these topics. As you noted, "hooks" and "Redux" are not exclusive. We released our React-Redux hooks API [3] last year, and it's been pretty enthusiastically adopted. We're now updating our docs to show using the hooks API as the default instead of `connect`. [0] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet... [1] https://blog.isquaredsoftware.com/2020/01/blogged-answers-react-redux-and-context-behavior/ https://blog.isquaredsoftware.com/2020/01/blogged-answers-re... [2] https://blog.isquaredsoftware.com/2019/03/presentation-state-of-redux/ https://blog.isquaredsoftware.com/2019/03/presentation-state... [3] https://react-redux.js.org/api/hooks https://react-redux.js.org/api/hooks
deleted 6y ago
[deleted]
wdb 6y ago
Normally they mean they are using React Context, useReducer and React.memo/useMemo. Most of the people saying that are using that are suggesting it lowers the code complexity as in the code is easier to understand or follow. They probably will also split up the application state in multiple React context, one for auth, one for settings, things that aren't depending on one another. Especially, when you are application doesn't have to manage that much state yet. I think it's a reasonable approach to get started with it. You can always switch to something like Mobx state trees or Redux at later time.
dceddia 6y ago
The implication behind “we don’t use Redux, we use hooks” is that they’re using React’s Context API directly as a “store”. A component at the top level has some state, probably using the useReducer hook, that state is passed down using a Context Provider, and child components can access the data with useContext. You can DIY a Redux imitation with hooks pretty easily but making it as performant as Redux is harder.
- ricardobeat 6y ago
  Indeed. IIRC redux itself tried that in an earlier version but reverted to a custom update / forced render mechanism due to performance bottlenecks with Context.
  - acemarke 6y ago
    Yep. References with the details on what we tried to do in v6, and how we rewrote things in v7: - https://github.com/reduxjs/react-redux/issues/1177 https://github.com/reduxjs/react-redux/issues/1177 - https://blog.isquaredsoftware.com/2018/11/react-redux-history-implementation/ https://blog.isquaredsoftware.com/2018/11/react-redux-histor...
wnevets 6y ago
It seems like the react community just hops on whatever the latest & hottest blog post of the month is about. Whenever I ask react devs(in real life) why they use feature X or library Y they usually just regurgitate the latest talking points they saw on reddit as if react is some sort of political party. Follow up questions never go anywhere that isn't covered by the latest group think.
- davedx 6y ago
  Personally, hooks have vastly simplified my code bases by giving me an out-of-the-box toolset for managing and fetching state. Not using redux means tons less boilerplate and actually means each "page" of my SPA's are totally decoupled from each other. (You can do this with redux by giving each page its own store but you need to be disciplined and refactoring can be tricky).
  - wnevets 6y ago
    Why was redux chosen in the first place if it had tons of boilerplate, etc?
- woah 6y ago
  I don't think that you'd be able to get a very clear answer from your average frontend developer on why their non-React framework of choice uses the state management pattern that it does. For that matter, most DBA's wouldn't be able to answer detailed questions about their chosen database's query optimizer, and most ML researchers wouldn't be able to answer questions about Numpy's choice of linear algebra algorithms. Sometimes people just need to do their jobs without understanding every nuanced choice all the way down the stack. Luckily, software libraries let us do that.
  - wnevets 6y ago
    I feel going out of one's way to use a 3rd party library like Redux with React is a bit different than a database's internal query optimizer. Quite frankly the fact so many developers are replacing Redux with hooks is proof it was never the right choice for their project in the first place.
davedx 6y ago
I can give my take on this. Until hooks I used redux in every app because it was the default way to manage state. Now I use hooks, I have more tools to help me manage state (and also load things via useEffect), I find I simply don't need redux anymore. The only compelling reason for me to pull in redux now would be if I wanted a centralised cache, but the kind of line of business apps I mostly work on lately just don't need to cache things like that, so each route/page just reloads the data from the server.
- dceddia 6y ago
  If you want a lightweight cache, check out react-query[0]. It's a nice abstraction around fetching data, and it handles caching out of the box, as well as refetching data when the browser regains focus and a lot of other nice things. 0: https://github.com/tannerlinsley/react-query https://github.com/tannerlinsley/react-query
  - davedx 6y ago
    Thanks, I'll check it out. I find using apollo's graphql client library solves this reasonably well too, though the syntax is a bit clunky and knowing when you need to explicitly define a cache function or not is tricky.
ratww 6y ago
If you ask a random sampling of Redux users why they're using it, you'll get tons of different answers. Some people use it as a caching layer. Other people use it because their SSR solution requires it. Other people use it because they like the action-command pattern. Other people just use it because they see it as the "M in MVC" and consider it mandatory in their projects. Other people just use it because it's the default. Some people use it for more than one reason. If something else comes along and fits one of those niches, it's no wonder people will get interested in it. It was the same with Apollo. A lot of projects replaced Redux with it. And to answer your question: some people are moving to hooks because of useReducer. Others because of useContext. Others because they can create custom Hooks. Some because of third-party hooks. Others for a mix of those.
dcre 6y ago
You are correct. The variety of replies makes that pretty clear if it was in doubt.
pacomerh 6y ago
saying "we use hooks" is a very broad term, a hook can do almost whatever you want. So I understand people that say that aren't being specific but it's assumed they're using a combination of hooks that would do a similar task like useContext, useReducer, etc
sjogress 6y ago
We decided on the useReducer-hook instead of using a proper state library. We did this since the thing we are currently building is essentially just a set of forms with a lot of client-side and server-side validations. Of course, if we were building a large SPA we would probably reconcider at this point. It feels like we're already at the edge of what useReducer was designed to do and I do not think what we are doing now would scale cleanly to a larger project or a larger team.

searchableguy 6y ago

They might be using context. The problem with that though is it will cause performance issues due to unintentional rerendering. Not something to worry about for a small app. https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html

karatestomp 6y ago
Are people just using "hooks" to mean "all new functionality in React that happens to be available to/as hooks"? To me it's like (actually very like) "oh we're doing that with methods". Uh. OK? Cool I guess? That's not informative.
- searchableguy 6y ago
  Maybe. I really don't know. There are some places where functionality is dependent on hooks. React fast refresh won't work with class components. (useState is the hook alternative to class style state management and fast refresh is fancy hot reloading but with persisted state and only reloading modified modules/components). There are few escape hatches only built as hooks mostly for improving performance issues which weren't previously available. But most of the hooks are basically reimplementation of features from class style components. There are differences in how hooks work though. Hooks are executed as they are laid out. Previous life cycle methods were dumped into a single useEffect hook. It's easy to change hooks and introduce separation in how you build your logic is what I assume they might be referring to. Instead of <Consumer> {({text}) => { return <div> {text} </div> }} </Consumer> You can do const [data] = useConsumer() return <div> {data.text} </div> It gets messy with a real complex application. typing on mobile is sad.
  - hombre_fatal 6y ago
    Indenting by four spaces gives you preformatted text on HN. It's for code.
- jerrycruncher 6y ago
  You're probably not far off. For the Redux case, that statement almost certainly means using at least one top-level Context Provider along with `useContext` in consuming components to replace or avoid the use of a Redux store and `connect`.

speg 6y ago

Perhaps they mean instead of Redux, they are using Context + useReducer.

tildedave 6y ago

I'd guess comments like this come from people thinking the primary complexity of Redux is the data store, rather than the "all changes to your state are represented as plain objects". The Redux FAQ goes into this: https://redux.js.org/faq/general#when-should-i-use-redux https://redux.js.org/faq/general#when-should-i-use-redux Can't blame them missing the forest for the trees when you spend all your time writing the reducers and connectors vs the actions themselves.

acemarke 6y ago
Note that our new official Redux Toolkit package [0] simplifies most Redux use cases and logic, including eliminating the need to write action creators and action types by hand and allowing "mutating" immutable update logic in reducers. The React-Redux hooks API [1] is also generally simpler to use than `connect`. We're now recommending that people use RTK as the default approach for Redux apps [2], and I'm working on a new set of tutorials that will teach RTK and React-Redux hooks as the standard approach [3]. [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://react-redux.js.org/api/hooks https://react-redux.js.org/api/hooks [2] https://redux.js.org/style-guide/style-guide#use-redux-toolkit-for-writing-redux-logic https://redux.js.org/style-guide/style-guide#use-redux-toolk... [3] https://github.com/reduxjs/redux/pull/3740 https://github.com/reduxjs/redux/pull/3740

brlewis 6y ago

I can't say for sure what they mean, but I'd guess it's saying they keep shared state in a parent component rather than having a global data store for their app. The useState hook might explain their chosen wording.

alexbanks 6y ago

This might be of benefit: https://blog.logrocket.com/use-hooks-and-context-not-react-and-redux/ https://blog.logrocket.com/use-hooks-and-context-not-react-a... If Redux is a a vanilla-ish JS store and a Reactified access pattern, keeping the store but replacing the access pattern with React Contexts. I am not a React expert.

RobertKerans 6y ago
This is replacing Redux with hand-rolled Redux. The pattern works, and is useful for very small apps, but get anything more complex where a state container is a useful thing and the tradeoff makes it pointless. Redux is extremely simple, very easy to test, and has excellent tooling. React-redux has necessary optimisations already written into it. And the boilerplate argument holds much less weight with hooks and redux toolkit.

ctidd 6y ago

One of the problems Redux is used to solve (as a global store) is peace of mind that you won't need to refactor large swathes of component trees to reparent state and callbacks that need to be shared or persisted across different subtrees as new business requirements arise. Hooks (especially custom hooks, which are just a composition of other hooks packaged together as a single function) make the reparenting/hoisting/anchoring of state and callbacks trivial compared to other mechanisms, providing similar peace of mind that you're not boxing yourself into an inextensible component tree. (This is regardless of context; passing down props isn't a large pain point, and is often misguided to try to solve because it leads to importable components and hidden contracts.) Render props and HoCs solve similar problems for composition/reuse of functionality (these are all mixins at heart), but the hoistability of hooks is really the distinguishing mark in my experience.

ricardobeat 6y ago
Replacing redux with hooks that return local state can be a road to hell, as calling the hook somewhere down the tree will duplicate the state and there is no good way to prevent developers doing that.
- nightski 6y ago
  IMO that's not much different than introducing a new variable in your global state to represent the same thing because you didn't realize there was already one there. If you have a team you need discipline, code reviews, and leadership. No state solution is going to solve this for you.
  - diob 6y ago
    I always try to tell folks that frameworks won't save them from themselves.
  - ricardobeat 6y ago
    It is not a matter of discipline. Avoiding this gotcha requires you to manually inspect your entire parent component hierarchy looking for uses of that hook - sometimes that is a plain grep away, but it is a very much invisible error. You also have to be familiar with the inner workings of the hook itself, and any other nested hooks, to verify if they use any local state or not. If it does, and you need to share that state, well, that's a big rewrite which kind of defeats the initial argument. Maybe extra tooling could be built to avoid this, if we weren't already drowning in linter plugins...

acemarke 6y ago

Hi, I"m a Redux maintainer. Context and hooks don't "replace Redux", but they do overlap with some of the scenarios and use cases that previously led people to choose Redux. Please see my post "Redux - Not Dead Yet!" [0] for information on how Redux compares to tools like React context + hooks and GraphQL, as well as situations in which it makes sense to use Redux. I'd also suggest reading my post "React, Redux, and Context Behavior" [1] and watching my Reactathon 2019 talk on "The State of Redux" [2] for additional information on these topics. As you noted, "hooks" and "Redux" are not exclusive. We released our React-Redux hooks API [3] last year, and it's been pretty enthusiastically adopted. We're now updating our docs to show using the hooks API as the default instead of `connect`. [0] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet... [1] https://blog.isquaredsoftware.com/2020/01/blogged-answers-react-redux-and-context-behavior/ https://blog.isquaredsoftware.com/2020/01/blogged-answers-re... [2] https://blog.isquaredsoftware.com/2019/03/presentation-state-of-redux/ https://blog.isquaredsoftware.com/2019/03/presentation-state... [3] https://react-redux.js.org/api/hooks https://react-redux.js.org/api/hooks

deleted 6y ago

[deleted]

wdb 6y ago

Normally they mean they are using React Context, useReducer and React.memo/useMemo. Most of the people saying that are using that are suggesting it lowers the code complexity as in the code is easier to understand or follow. They probably will also split up the application state in multiple React context, one for auth, one for settings, things that aren't depending on one another. Especially, when you are application doesn't have to manage that much state yet. I think it's a reasonable approach to get started with it. You can always switch to something like Mobx state trees or Redux at later time.

dceddia 6y ago

The implication behind “we don’t use Redux, we use hooks” is that they’re using React’s Context API directly as a “store”. A component at the top level has some state, probably using the useReducer hook, that state is passed down using a Context Provider, and child components can access the data with useContext. You can DIY a Redux imitation with hooks pretty easily but making it as performant as Redux is harder.

ricardobeat 6y ago
Indeed. IIRC redux itself tried that in an earlier version but reverted to a custom update / forced render mechanism due to performance bottlenecks with Context.
- acemarke 6y ago
  Yep. References with the details on what we tried to do in v6, and how we rewrote things in v7: - https://github.com/reduxjs/react-redux/issues/1177 https://github.com/reduxjs/react-redux/issues/1177 - https://blog.isquaredsoftware.com/2018/11/react-redux-history-implementation/ https://blog.isquaredsoftware.com/2018/11/react-redux-histor...

wnevets 6y ago

It seems like the react community just hops on whatever the latest & hottest blog post of the month is about. Whenever I ask react devs(in real life) why they use feature X or library Y they usually just regurgitate the latest talking points they saw on reddit as if react is some sort of political party. Follow up questions never go anywhere that isn't covered by the latest group think.

davedx 6y ago
Personally, hooks have vastly simplified my code bases by giving me an out-of-the-box toolset for managing and fetching state. Not using redux means tons less boilerplate and actually means each "page" of my SPA's are totally decoupled from each other. (You can do this with redux by giving each page its own store but you need to be disciplined and refactoring can be tricky).
- wnevets 6y ago
  Why was redux chosen in the first place if it had tons of boilerplate, etc?
woah 6y ago
I don't think that you'd be able to get a very clear answer from your average frontend developer on why their non-React framework of choice uses the state management pattern that it does. For that matter, most DBA's wouldn't be able to answer detailed questions about their chosen database's query optimizer, and most ML researchers wouldn't be able to answer questions about Numpy's choice of linear algebra algorithms. Sometimes people just need to do their jobs without understanding every nuanced choice all the way down the stack. Luckily, software libraries let us do that.
- wnevets 6y ago
  I feel going out of one's way to use a 3rd party library like Redux with React is a bit different than a database's internal query optimizer. Quite frankly the fact so many developers are replacing Redux with hooks is proof it was never the right choice for their project in the first place.

davedx 6y ago

I can give my take on this. Until hooks I used redux in every app because it was the default way to manage state. Now I use hooks, I have more tools to help me manage state (and also load things via useEffect), I find I simply don't need redux anymore. The only compelling reason for me to pull in redux now would be if I wanted a centralised cache, but the kind of line of business apps I mostly work on lately just don't need to cache things like that, so each route/page just reloads the data from the server.

dceddia 6y ago
If you want a lightweight cache, check out react-query[0]. It's a nice abstraction around fetching data, and it handles caching out of the box, as well as refetching data when the browser regains focus and a lot of other nice things. 0: https://github.com/tannerlinsley/react-query https://github.com/tannerlinsley/react-query
- davedx 6y ago
  Thanks, I'll check it out. I find using apollo's graphql client library solves this reasonably well too, though the syntax is a bit clunky and knowing when you need to explicitly define a cache function or not is tricky.

ratww 6y ago

If you ask a random sampling of Redux users why they're using it, you'll get tons of different answers. Some people use it as a caching layer. Other people use it because their SSR solution requires it. Other people use it because they like the action-command pattern. Other people just use it because they see it as the "M in MVC" and consider it mandatory in their projects. Other people just use it because it's the default. Some people use it for more than one reason. If something else comes along and fits one of those niches, it's no wonder people will get interested in it. It was the same with Apollo. A lot of projects replaced Redux with it. And to answer your question: some people are moving to hooks because of useReducer. Others because of useContext. Others because they can create custom Hooks. Some because of third-party hooks. Others for a mix of those.

dcre 6y ago

You are correct. The variety of replies makes that pretty clear if it was in doubt.

pacomerh 6y ago

saying "we use hooks" is a very broad term, a hook can do almost whatever you want. So I understand people that say that aren't being specific but it's assumed they're using a combination of hooks that would do a similar task like useContext, useReducer, etc

sjogress 6y ago

We decided on the useReducer-hook instead of using a proper state library. We did this since the thing we are currently building is essentially just a set of forms with a lot of client-side and server-side validations. Of course, if we were building a large SPA we would probably reconcider at this point. It feels like we're already at the edge of what useReducer was designed to do and I do not think what we are doing now would scale cleanly to a larger project or a larger team.