That seems a bit unfair.

There are some weird edge cases with useEffect, no question.

I don’t think they’re bad enough to want to go back to using classes... but I think the OPs post was a bit more specific than you’re giving them credit for, and they stuff like useAsyncEffect exists because it is a common pain point.

For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-ts-zhvuha

The behaviour is weird sometimes; just because you can use the trivial use case easily doesn’t mean you won’t stumble, and if you do, good luck trying to understand what went wrong.

> ...they're very simple to understand...

They’re not simple.

They just superficially appear simple, which is good enough most of the time.

I think it’s entirely fair to complain that’s not ideal... even if you still think there’s a major benefit to the trade off compared to classes (which I do think is true too).

...but I’m very sympathetic to people hitting edge cases.

> For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-ts-zhvuha

On this particular point, the reasoning is that refs are meant for values that don't need to trigger a rerender[1] -- an escape hatch, rather than something you reach for by default.

In that sandbox, you can accomplish what you mean to accomplish by using state rather than a ref.

[1] https://github.com/facebook/react/issues/14387#issuecomment-...

I've seen a ton of people make that mistake, though. I think it's because what you write is accurate - "refs are meant for values that don't need to trigger a rerender" - but most people think of refs (or at least refs of DOM elements, which for many people are the only refs they ever use) as just a way to access a DOM element. They expect it to just be a DOM element in a normal variable.

I'm not sure if there is a less confusing way of doing it, but it's damn confusing.

But it's a pretty straightforward rule once you know it right?

This is simply a matter of reading the docs (or making the mistake until you learn). Not an inherently more complex characteristic than, say, Class component lifecycle methods, which also required understanding their rules and reading the docs.

Once you know refs updates won't re-render, you won't make this mistake.

I don't understand why "a thing you need to learn then you're good" is somehow inherently more complicated than ... other apis that you need to also learn.

> but most people think of refs as...

This sounds like Dan Abramov's comment that some of the struggles with hooks is from people who have experience with react without hooks, vs people coming new to the whole thing. So maybe it's about relaxing pre-conceived notions until experience takes over.

Tons of shitty "here's how to use hooks for X" articles on Medium make the mistake, so people learning hooks right at the beginning will not be completely immune.

Also that the fix is "instead of using this one kind ref, use another kind of ref and put it in state"... I don't know, like I said I'm not sure if there is a better solution, but it still feels kind of unintuitive and complicated.

Now that I'm thinking about it... what is the reason that DOM refs and other refs need to be handled by the same concept? Every time I make a DOM ref, I'm doing something with it in a hook like useEffect. Why make me jump through hoops to re-run the hook if the DOM ref changes?

(I recognize there are probably good answers to those questions, the React folks are great, I just don't know the answers! Is it just to avoid introducing one more "type of thing", and instead making refs and DOM refs the same "thing"?)

What is the use case for re-rendering based on change of DOM ref? (that can't be accomplished by putting some data in state?)

Ref's are basically a 1 to 1 replacement for instance fields for mutable data (that doesn't cause rerenders).

https://reactjs.org/docs/hooks-reference.html#useref

There's always need for escape hatches and maybe I'm missing your use case, but in the context of a discussion about how hooks are more complicated than classes, what were you doing before with refs to solve your "re-render" on change scenario?

Your example was likely contrived, but modifying innerHTML should be replaced by putting whatever in state and simply rendering it. And use state for dependencies where you want to re-run on change. Refs are just another way to keep state but not have it affect render cycle.

Stuff like https://reactjs.org/docs/hooks-faq.html#how-can-i-measure-a-...

If you're not aware of that, it is very tempting to use `useRef`, which is what I have often seen. Before hooks, we did not have the temptingly-named footgun `useRef` for this scenario (although we did have other footguns for other scenarios, and overall I love hooks).

It’s obviously a contrived case.

It’s harder to just use state for example, when you need a ref to a canvas to get the 2d context.

I suspect this may be one of those cases where there's an 'aha' moment involved, and people who get that moment early find it simple to understand, people who haven't got to that moment yet are going argh, and people who got to it late sigh and/or write "yet another X tutorial" in the hopes that how they got their aha moment will work for other people.

The classic X here, of course, is monads.

But as personal examples, it took me ages of headbanging to get the 'aha' moment for git, even though a bunch of people I know got it almost immediately.

In the case of hooks, once I built a mental model of how they were (theoretically) implemented, I went 'ooh' and found them obvious and relatively easy from then on. It looks to me like the author of this piece didn't have that luck, and so for him, they're not simple (although maybe later, post-aha-moment, they will be).

tl;dr: "They seem simple to understand once you understand them, but are mystifying up until that point" seems to me to be the most likely hypothesis here.

I think you can make that first useEffect block fire by passing in an empty array as your params. This should run the code block on mount. To run a function on unmount, return it from the same useEffect with the empty array params.

My frustration with this is that it's completely unintuitive and doesn't read very well. Yes, you'll get used to it once you work with hooks enough, but at first glance, the empty array and the return value from the function passed to `useEffect` don't give me any useful information as to what the code is actually doing. It's an entirely React-specific abstraction that forces you to memorize a bunch of obtuse rules in order to use it effectively, as opposed to building on simpler primitives, which had previously always been the appeal of React.

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 they're doing. 3. A whole class of unergenomic solutions disappears when you use hooks.

[1] https://www.youtube.com/watch?v=dpw9EHDh2bM

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.

I feel of all the arguments against hooks, the whole “order of hooks” thing is the thinnest. You just learn about it and then it’s not a problem again.

I definitely get that there are some more complex cases where you have to jump through a couple of useRef hoops to do what you need. On balance though, I think the way the behaviour becomes declarative is worth the trade off.

Coming from the FP world, hooks are a terror because they break all the nice rules functions are supposed to uphold. Hook components don't necessarily return the same value when given the same arguments, making them impure (stateful). The benefit of function components IMO has always been that you can use the function scope as a container for pure, stateless rendering logic. With the introduction of hooks I can no longer ensure that.

Nothing stops you from using pure function components, and you should where possible. But eventually, you need to hold state somewhere. You don't need to put it in your components, but you do need to deal with it. If anything, hooks are a nice middle ground where the behaviour becomes declarative.

My personal opinion is that state should be contained in some sort of class or data structure, separate from functional architectures where the notion of state is generally avoided. So my usual suggestion would be to use either a class component (or redux or insert favorite state mgmt solution here) for your state, and then inject the state as props to your function components

That's fine, you can use React's Context API and reducers just like Redux, for which the useContext and useReducer hooks exist. Then it's just like Redux, inject a Provider and Consumer and you're good to go.

How does the existence of hooks preclude you from using function components without state (without any hooks)?

They don't, but before I could look at a function component and go "ah, a nice stateless component" whereas now I have to wonder whether the _function_ contains _state_

If you see "useWhatever"... then it has a hook.

And you already have to wonder if a function has state if you didn't write it. If you did, you should know.

The issue I have with the "rules of hooks" is that it makes some previously trivial things cumbersome at best, and downright complicated at worst. For a quick example, something as simple as mapping an array onto a series of elements with a callback requires (as far as I can tell) that the inner element be broken out into its own component that calls `useCallback`, since you can't create a unique callback for each item in the parent.

You don't need to use hooks there. You can just define your functions and be done with it.

You do if you don't want those child components to be re-rendered needlessly when some higher-level state changes.

I don't quite get the obsession with the order of hooks... You call all the hooks in your component function and don't optionally do so. In the end, if you're optionally calling different hooks differently in the same component, you're probably doing something wrong, and/or they should be separate components.

I've found that the hoop jumping type stuff, while potently annoying, can at least be abstracted into a custom hook (and then mocked in tests) easily so that the code is clean.

It's not classes themselves, it's the lifecycle methods, the constructor, this, state, and it all interacts. Hooks let you do more or less the same thing, but IMHO with a simpler and clearer API.

You have more control too. Look at the parameters to useState to see what I mean.

I feel like there is an alternative world that we aren't seeing, where instead of changing the paradigm, the react team redesigned the class API instead.

The class API lifecycle methods are kind of a mess, and useEffect() seems like a more convenient abstraction. But I could imagine replacing the lifecycle methods with hooks that are added at object construction and get similar benefits. I wonder if the problem is not so much classes, but just the API that happened to evolve.

Nothing is simpler than a function. Easier to write, debug, and test.

* Removed "pure" to make my main point clear.

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.

But functions that use hooks aren't pure because hooks break referential transparency.

Simplicity does not necessarily imply clarity.

> 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

“Just burn it to the ground and start over,” isn’t an inspiring endorsement of the methodology...

`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.

I understand how contexts can replace Redux, but can you please elaborate how they can be used instead of Apollo? Do you mean the whole of Apollo or Apollo local state?

Note that context and useReducer do _not_ completely replace Redux.

See the following resources for more details:

- Mark Erikson - Reactathon 2019: The State of Redux (https://blog.isquaredsoftware.com/2019/03/presentation-state...)

- Mark Erikson: Redux - Not Dead Yet! (https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...)

- Dave Ceddia: React Context API vs Redux (https://daveceddia.com/context-api-vs-redux/)

- Mike Green: You Might Not Need Redux (But You Can’t Replace It With Hooks) (https://www.simplethread.com/cant-replace-redux-with-hooks/)

- Sergey Ryzhov: From Redux to Hooks: A Case Study (https://staleclosures.dev/from-redux-to-hooks-case-study/)

- Eric Elliott: Do React Hooks Replace Redux? (https://medium.com/javascript-scene/do-react-hooks-replace-r...)

- Chris Achard: Can You Replace Redux with React Hooks?](https://dev.to/chrisachard/can-you-replace-redux-with-react-...)

We're slowly refactoring our class-heavy React app to functional components with hooks.

One thing we haven't been able to replace, though, are classes that depend on refs. How to do this, since there's no instance with functions like there are with classes?

That's what the very-rarely-used `useImperativeHandle` hook is for - exposing "instance methods" from function components:

https://reactjs.org/docs/hooks-reference.html#useimperativeh...

useRef was designed for this purpose: https://reactjs.org/docs/hooks-reference.html#useref

If you ran into something that isn't quite covered by this hook, I'm also curious! Can you write a minimal example in codesandbox and share?

I certainly found on one occasion where I felt I had to break the laws of hooks, that it worked much better split into two components.