
React Hook Pitfalls - praveenscience
https://www.youtube.com/watch?v=VIRcX2X7EUk
======
tony
Love react hooks (along with TypeScript)

Just for the sake of readability. Easier to grok. Perhaps all along though
classes I had were just making inefficient/incorrect use of lifecycles though.

React's lifecycles still mystify me. I can't tell where and how renders come
from. If there was an easier way to trace it, it'd be nice.

I'm making use of `React.forwardRef` and `useImperativeHandle` also. It's neat
because you can forward information from a inner component for "direct" access
in its parent. ([https://reactjs.org/docs/hooks-
reference.html#useimperativeh...](https://reactjs.org/docs/hooks-
reference.html#useimperativehandle))

My pitfall is variables inside callbacks that used to be "live" are stale upon
invocation. So if you have a complicated components where you fishline
callbacks, it doesn't behave the same.

In my case, the solution was to wrap the callbacks in `useEventCallback`
[https://reactjs.org/docs/hooks-faq.html#how-to-read-an-
often...](https://reactjs.org/docs/hooks-faq.html#how-to-read-an-often-
changing-value-from-usecallback)

~~~
acemarke
Out of curiosity, what about renders confuses you?

I can try to summarize:

\- React stores an internal tree of bookkeeping objects ("fibers") that store
info on what component is being rendered at each location in the tree

\- Any state update function (class component `setState()`, `useState`
setters, `useReducer` dispatch) queue a re-render pass, and mark this
component as needing an update

\- During a re-render pass, React walks that fiber tree to find components
that need to render, either because they're marked as dirty, or because the
parent re-rendered. For function components, React calls
`funcComp(fiber.props)`. For class components, it attaches `instance.props =
fiber.props`, and then calls `instance.render()`

\- Class component lifecycles and function component lifecycles are called at
appropriate points during that render pass

Hmm. Re-reading, are you asking how to determine what _causes_ a given render
pass? That one's more opaque. However, the new React DevTools 4.0 will at
least tell you why each component re-rendered during a specific pass.

~~~
swyx
i believe they dont even want people fixated on when and why things rerender.
write your code right (with effects and suspense boundaries in the right
places) and let react figure it out.

not sure if they'll succeed in making people not care about optimizing for
number of renders vs overall speed tbh. we're so used to one way of thinking
about perf.

------
antigirl
Classes made it easier [for me anyway] to understand how react is setup. I
understand Component is a prototype, and it gets instantiated first by calling
the constructor method - followed by its life cycle methods, like
componentDidMount etc. The new hooks API just looks to replicate alot of these
methods to make up for losing classes and its life cycle methods. The API
seems quite terse. I dont like having lots of nested functions, it makes
readability worse IMHO

I also dont like the idea of 'useState' overwriting the whole state object.

~~~
simplify
You might be approaching hooks suboptimally. `useState` should be used for
simple values, different than the catch-all `this.state` from class
components.

How do you arrive at nested functions? Hooks have generally flattened my
indentation, and they are refreshingly easy to abstract over, making way for
even cleaner code.

For example, I have the following custom hook in multiple components:

    
    
        useNavigationWarning(() => !!commentBody)
    

which adds an event listener to the window that warns the user about unsaved
work, but only if `commentBody` has any content. Because it's a function, I
can reuse the hook and swap out the callback body's conditional for each
situation.

With class components I would either have to use a higher-order component (bad
and clunky), or copy/paste code across two separate lifecycle methods across
each of my components that need this behavior.

------
jbaudanza
I use `useCallback` all over the place. I don't do it because I'm worried
about performance. I do it because I'm worried about invalidating some
dependency array somewhere down the tree.

Am I falling into speakers pitfall? I definitely agree with him that this
creates a lot of unnecessary complexity.

------
weq
Is this the state of JS conference scene in 2019? Download create-react-app
then NPM install

[https://www.youtube.com/watch?v=pZZ60jrw6cg](https://www.youtube.com/watch?v=pZZ60jrw6cg)

Pro tip: If cant use an API corectly, even with the developer of that API
sitting next to you. The API is the problem, not you.

