
A Critique of React Hooks Addendum - vicarrion
https://dillonshook.com/a-critique-of-react-hooks-addendum/
======
karatestomp
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?

~~~
ctidd
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
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
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.

~~~
ricardobeat
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...

~~~
nightski
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.

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

------
stickfigure
I'm not quite sure what the point of this quiz is. I don't know the answer to
those questions, and yet I seem to have no trouble building very large react
applications (with hooks) anyway.

I would also struggle with similar quiz based on the callbacks for class
components. And those I actually had to deal with on a frustratingly regular
basis! At least with hooks I can remain blissfully ignorant of what happens
under the covers of useEffect().

Maybe the answers don't matter and this is a pointless exercise.

~~~
acemarke
I'd definitely agree there's nuances about hook behavior that a lot of folks
aren't familiar with. (Dan Abramov's mammoth post "A Complete Guide to
`useEffect`" [0] ought to be required reading for all React devs, and a lot of
the info in that post ought to be better integrated into the React docs
directly.) That said:

\- The "effect behavior runs bottom to top" has always been true about class
lifecycle methods like `componentDidMount` / `componentDidUpdate`. So, nothing
new there.

\- Somewhat similarly, the aspect of new prop references causing some logic to
run every time is not completely new, either - it's similar to how attempts to
optimize rendering via use of `PureComponent`, `React.memo()`, and
`shouldComponentUpdate` can "break" when the parent component passes down new
callback or data object references every time.

\- The complaint that "there's more stuff to learn" seems superfluous. If
there was never anything new to learn, that would mean that the API was
completely stagnant and that nothing new could ever be introduced. Yes, the
ecosystem is in a somewhat uncomfortable transition state atm given that
there's two different APIs that offer equivalent functionality, but "learning
more stuff raises the barrier to entry" is not a particularly meaningful
argument against hooks.

[0] [https://overreacted.io/a-complete-guide-to-
useeffect/](https://overreacted.io/a-complete-guide-to-useeffect/)

------
ng12
I thought the quiz was really missing the point. The whole point of reactive
programming is to not worry about execution order.

------
hitekker
A clear, concise & clever blog post.

Quizzing the community on its supposed expertise, is such an effective way to
separate rhetoric from reality.

~~~
wbobeirne
While I like the post and associated quiz, I feel like execution order is not
the most important thing to understand with hooks, but it's the main theme of
the quiz. If you're designing your components in an effective way, execution
order shouldn't _really_ come into play. It typically only comes to bite you
if you're manipulating some global state outside of React, or doing some
direct DOM manipulation.

Questions 3 and 4 about anonymous objects and useRef are definitely the kind
of knowledge that someone who aims to understand React and Hooks should focus
on, though.

------
rdgthree
This was a great follow up. I completely agreed with the first post, and I
couldn't help but think those critiquing it didn't quite understand what they
were critiquing. It's rare that you're able to actually definitively prove
that out, but these results are about as conclusive as it gets.

