A Critique of React Hooks Addendum • Hacker News Board

Re: A Critique of React Hooks Addendum

#51

Post by schwartzworld » Fri, May 08, 2020, 1:19 AM UTC

nightski wrote: post #48

ricardobeat wrote: post #40

Earlier quoted context omitted.

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…

Again this isn't a problem with hooks. You could easily connect a redux store and reducer to some component low in the hierarchy with it's own state. Or use a class based component with some state. A developer can introduce random state anywhere and it has nothing to do with hooks themselves. If you can't trust your team to make the right decisions about where to place state, then you need to provide more guidance. I…

I love how every criticism of hooks is like "if you don't take care to use them well, you get bad code".

Re: A Critique of React Hooks Addendum

#52

Post by dceddia » Fri, May 08, 2020, 3:13 AM UTC

davedx wrote: post #24

karatestomp wrote: post #4

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 oth…

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 do…

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

Re: A Critique of React Hooks Addendum

#53

Post by sjogress » Fri, May 08, 2020, 8:28 AM UTC

karatestomp wrote: post #4

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 oth…

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.

Re: A Critique of React Hooks Addendum

#54

Post by davedx » Fri, May 08, 2020, 9:50 AM UTC

dceddia wrote: post #52

davedx wrote: post #24

Earlier quoted context omitted.

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 do…

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

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.

Re: A Critique of React Hooks Addendum

#55

Post by [deleted] » Fri, May 08, 2020, 11:29 AM UTC

nightski wrote: post #48

ricardobeat wrote: post #40

Earlier quoted context omitted.

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…

Again this isn't a problem with hooks. You could easily connect a redux store and reducer to some component low in the hierarchy with it's own state. Or use a class based component with some state. A developer can introduce random state anywhere and it has nothing to do with hooks themselves. If you can't trust your team to make the right decisions about where to place state, then you need to provide more guidance. I…

[deleted]

Re: A Critique of React Hooks Addendum

#56

Post by ricardobeat » Fri, May 08, 2020, 11:51 AM UTC

ctidd wrote: post #50

ricardobeat wrote: post #46

Earlier quoted context omitted.

Of course it's not a bug, that is not in question. As I mentioned above, the problem is that even if you are fully aware of this, you still have to check that whatever `useSomeStatefulThing` hook you used to replace a global store does not use local state. So the assumption you can simply replace a global store with localized hooks to manage state is not true, and will certainly lead to bugs. You must use Context ins…

Since you provided a concrete scenario, I should probably do the same to clarify what I'm referring to in re-parenting or hoisting hooks. It doesn't really map to the statement "replace a global store with localized hooks", so I'm probably doing a poor job communicating. Similarly, I do not assume "you can simply replace a global store with localized hooks", because like you say, that's not true, and I can appreciate…

You're right when it comes to hooks vs classes, that is a major plus. But this is not the aspect I was commenting on, I was specifically addressing the idea of custom hooks as a trivial replacement for Redux:

> 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.)

My earlier example was to show that re-parenting/hoisting when you replace a global store like Redux, with custom hooks using local state, is not straightforward, and unsafe except for very localized components where you shouldn't be using Redux anyway.

So you'll eventually end up doing prop drilling, or resorting to Context, or back to Redux; in the end hooks did not solve those issues as you proposed (other than the increased portability compared to classes, which you already have with redux or context).