Live data from Hacker News

Frustrations with React Hooks

blog.logrocket.com

11–20 of 139 posts

Re: Frustrations with React Hooks

#11
I absolutely love hooks and don't want to use the `React.Component` class ever again.

And yes, hooks need to be grasped, they're quite something else. But once you get the hang of hooks, they're very simple to understand.

OP seems to be a bit stuck in a hole.

If you end up in a situation where your hooks come loose and the code becomes a mess — just delete them all and rethink your code / component logic structure. Believe me, it all can be simplified. Just rinse and repeat until you are satisfied with the outcome. That's when the "aha!" moment comes.

At the moment I only use `useEffect`, `useState`, `useRef` — the rest is unneeded so far even in my large-ish application.

P.S. sorry for the puns!

Re: Frustrations with React Hooks

#12
post #2

interested in hearing more people experiences with React Hooks.

I am starting to use hooks and it is actually way better to do async thunk axios http calls than to put it in a lifecycle method. the code is more succinct and clear and you don't have to keep the lifecycle in mind as much

Re: Frustrations with React Hooks

#13

I was extremely skeptical of hooks in the beginning after having used class-based lifecycle components for a long time. Overall, I _think_ it's been a net positive but I end up feeling that I'm writing more code at the expense of using well defined constructs (lifecycle methods). I usually feel like I'm writing too many effects which update state(s) and the lifecycle flow becomes harder to contain mentally, however t…

Maybe this is because I'm a "developer[] unfamiliar with class-based OO paradigms" but I find hooks components easier to read later. You start at the top, read to the bottom, and assuming you can catch crazy indirection within a hook callback during review, that's what happened. No HOCs. No having to memorize an externally documented lifecycle order. No having to cross-reference methods against the state they update 50-60 lines up the file.

I'm genuinely curious if the difference is because I was doing tons of Recompose/HOC style components before hooks came out.

Also, just FYI, it didn't click for me until this tweet[1]:

> The question is not "when does this effect run" the question is "with which state does this effect synchronize with"

> useEffect(fn) // all state

> useEffect(fn, []) // no state

> useEffect(fn, [these, states])

[1] https://mobile.twitter.com/ryanflorence/status/1125041041063...

Re: Frustrations with React Hooks

#14
post #2

interested in hearing more people experiences with React Hooks.

I've completely stopped using class components after spending some time with Hooks in a small-to-mid-sized application. The big wins for me were: - passing an empty array as the last argument of useEffect makes useEffect work in a similar fashion to the old ComponentDidMount. You can have any number of useEffect invocations in a component, and for a component that is, say, loading data from two different sources, I f…

How do you handle the drawback that changing the context will rerender all components that use the context? Putting too much state into a single context does seem like it could cause performance issues, especially with state that changes often.

Re: Frustrations with React Hooks

#15
Coming from a ClojureScript / Reagent background, functional components and hooks look very natural, useState being largely equivalent to reagent.core/atom. useEffect and useRef look like a logical extension of the same idea.

Re: Frustrations with React Hooks

#16

Earlier quoted context omitted.

I've completely stopped using class components after spending some time with Hooks in a small-to-mid-sized application. The big wins for me were: - passing an empty array as the last argument of useEffect makes useEffect work in a similar fashion to the old ComponentDidMount. You can have any number of useEffect invocations in a component, and for a component that is, say, loading data from two different sources, I f…

How do you handle the drawback that changing the context will rerender all components that use the context? Putting too much state into a single context does seem like it could cause performance issues, especially with state that changes often.

I agree that if you had a large (in the dozens, if not hundreds) number of dependent components, it could be an issue. However, I've noticed no performance degradation with my usage -- I use a top-level AuthContext component to handle user data/login state, and another for access/caching of the app's main data.

In a single view (for lack of a better term), I'd guess the largest number of components that access either context is six.

Re: Frustrations with React Hooks

#17
post #2

interested in hearing more people experiences with React Hooks.

I've completely stopped using class components after spending some time with Hooks in a small-to-mid-sized application. The big wins for me were: - passing an empty array as the last argument of useEffect makes useEffect work in a similar fashion to the old ComponentDidMount. You can have any number of useEffect invocations in a component, and for a component that is, say, loading data from two different sources, I f…

Can you elaborate a bit about Context? I've been curious but wrapping multiple context layers to get multiple values feels awkward and wrapping an object to get CD around that feels like it screws over React rerendering logic.

Re: Frustrations with React Hooks

#18
I never understood the need for hooks and how it's used (the example that react doc has for useState is too simplistic for any useful pedagogical reasons) until I saw divjoy's generated code and studied how it used hooks. Then everything clicked and I've been more productive using hooks than I ever had with react classes. I can attest that cognitive load is lower with hooks than with classes.

Re: Frustrations with React Hooks

#19
Hooks are absolutely fantastic. However, there are still a few pain points:

- useState with an array is bad news if more than 1 component is consuming or setting the state.The clunky alternative is to keep it in a ref & call a forceUpdate whenever you would normally call your setter

- useCallback doesn't scratch the itch for things like document event listeners since everything inside the callback will be stale. The clunky alternative is a custom useEventCallback that keeps your callback function in a ref. (and that might not work in the upcoming sync mode)

- linter rules can be too strict & the --fix flag can actually cause a break in your app by adding things to the dependency list. Sometimes a useEffect depends on the current value of a ref, but linter says that's a no-no. 2 useCallbacks can be co-dependent, but there's no way to write that co-dependence in the dependency list. Sometimes I want to return null before a hook. The clunky alternative for all these is a bunch of eslint-ignore comments.

Re: Frustrations with React Hooks

#20
One major point of the author is complaining that the dependency array in an effect is only compared by reference for objects and arrays.

To me this is a feature rather than a shortcomming: I use immutable data structures all the time (with array and object spread operators it is really easy to do so) and the effect will only update when it really needs to - thus only triggering a re-render (or rather reconciliation) when something has actually changed. This is in contrast to .setState() which triggered reconciliation regardless if a value actually changed.

Post reply on HN