Hacker News new | ask | show | jobs
by ricardobeat 2232 days 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...

1 comments

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 also disagree about the big re-write. Converting a hook's data/state to come from a prop instead is a very simple change.

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