Live data from Hacker News

Frustrations with React Hooks

blog.logrocket.com

61–70 of 139 posts

Re: Frustrations with React Hooks

#63
post #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. B…

`useContext` is excellent. React.context is a solid alternative to the likes of Redux and Apollo, but takes a fair amount of boilerplate to add to a class based React component. But with `useContext`, applying global state is a breeze. A lot easier to manage than Redux, at the very least.

The only real dislike I have, is in how `useEffect` confuses the React lifecycle. It took me a little while to grok the lifecycle idea, but it was/is a useful way to conceptualise what happens to your components at runtime.

But now, you have to remap all that knowledge to the hooks workflow. It's not a huge challenge, but it's yet another overhead.

Indeed, starting out, our team ran into a number of issues with infinite rendering loops and the like. Took a fair amount of reading to discover where the pitfalls were.

Re: Frustrations with React Hooks

#64
post #42

Earlier quoted context omitted.

I don't understand the hate against class based components. React class-based components are dead simple to understand.

Have you seen the ReactConf talk on hooks? [1] It's absolutely worth the watch, even if you're somewhat familiar with hooks. They go through the pitfalls of class-based components and how hooks solve them. It more-or-less boils down to: 1. class-based components force your lifecycle logic to live in disparate locations. 2. Class-based hooks are obtuse with hidden gotchas whereas pure functions tell you exactly what t…

I'd argue that hooks didn't really make anything better, they just replaced the pitfalls with different obtuse pitfalls and unergonomic solutions.

Hooks have their share of weird issues; they explode if they're called in a different order/number from how they were called the first time the component rendered (making them not at all pure functions), and it's super easy to screw up the dependency array to useMemo/useCallback (so either your hook is useless and re-installs the event handler on every render, or you get stupid "the callback had a stale copy of the state" bugs not possible with class-components).

I've also seen my fair share of situations where what would have been a this.setState with a callback becomes a tangled mess of useStates and useEffects, or someone bends over backwards to try and avoid re-installing an event handler every time one of the props or state variables it uses changes.

Re: Frustrations with React Hooks

#65
post #32

The dependency array is the single most important improvement that hooks bring over lifecycle methods. You're component gets rerendered when the array changes and not when you got the right mix of lifecycle methods going. But yes, it's not always obvious what changes you really care for.

It actually reminds me of $scope.$watch from Angular 1.

Re: Frustrations with React Hooks

#66
post #46

Earlier quoted context omitted.

How are your functions pure if inside them you call `useEffect`, `useState` ? Where is pureness when at first look they generate side effects, or am I missing something ?

Not all functions needs hooks, not all hooks break pureness. But my point was functions are simpler in all those scenarios, pure or not. Edited my comment to reflect that.

> not all hooks break pureness

Sure, if you define a function called useWhatever that doesn't actually call any hooks, that might be a pure function. But the restrictions described in https://reactjs.org/docs/hooks-rules.html are not restrictions that pure functions have.

Re: Frustrations with React Hooks

#67

What's lost in all this is that classes are simple and understandable. Introducing all these new paradigms removes that simplicity. Everyone is ready to hate on classes but they have been robust structures for a long time

I think it's fair criticism to say that hooks are extraneous to JavaScript. However, they are still a better tool for the job of building components, and they solve real and important issues around safety, maintainability and complexity. There are alternatives to JS, and alternatives to React in JS. I think it's good the React team chose this unique direction to make the best framework possible by taking advantage of JS's strengths to workaround it's weaknesses.

Re: Frustrations with React Hooks

#68
Many people aren't event aware of the unnecessary renders caused by using hooks. If your app is so tiny that it doesn't matter if everything renders all the time, then you might not be aware of your `useCallback` recreating callbacks way too often (https://github.com/facebook/react/issues/14099), or that you're not even using it in the first place. Considering that front end is probably the area of software development that attracts the largest share of people like me - self taught, no computer science background - I'd also assume that many people love the perceived simplicity of hooks without realizing that it makes their code worse.

It'll only become apparent when you app is large and complex enough that it suddenly starts to matter when things re-render and then you'll be faced with tracking down those re-renders and fixing dependency arrays everywhere.

With classes, the naive solution is the right one when it comes to preserving function identities across renders.

Not saying hooks are bad, but they're not all roses and sushine.

Re: Frustrations with React Hooks

#69

Earlier quoted context omitted.

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.

Sure. The app I'd been working on had previously been using the original 'render prop' style of accessing context in functional components and using the this.contextType accessor for class-based components. Both approaches had their downsides: - 'render props' are fairly awkward to write, and add a lot of noise to a component that's working with data from multiple contexts. - this.contextType can only give a componen…

Was there ever any clarification on why the React team went with a single `contextType`, and not something like:

    class MyComponent extends Component {
      static contextTypes = {
        auth: AuthContext,
      }
    }

Re: Frustrations with React Hooks

#70

Many people aren't event aware of the unnecessary renders caused by using hooks. If your app is so tiny that it doesn't matter if everything renders all the time, then you might not be aware of your `useCallback` recreating callbacks way too often ( https://github.com/facebook/react/issues/14099 ), or that you're not even using it in the first place. Considering that front end is probably the area of software develop…

A lot of people don't understand that React's default behavior is to re-render _everything_.

When a component is rendered, React will recursively re-render all descendants of that component. Out of the box, React doesn't do any optimizations like "skip rendering this component if the props haven't changed". Because of that, "re-creating callbacks" isn't an issue in base behavior [0], because there's nothing that cares if it's a new function reference or not.

It's only when child components are attempting to optimize perf by comparing props and avoiding re-renders that having consistent callback function references matters (ie, `React.memo()`, `PureComponent`, and React-Redux's `connect()`).

[0] https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-becau...

Post reply on HN