Proposal: Add top level useMount/useUnmount to improve scannability/prevent fragmentation

[scottmas]

This is a feature request.

The current hooks API provides everything that is necessary to create sophisticated and elegant applications. However, the current api is something of a step backwards in terms of scannability - e.g. Understanding when various code will execute in the component's lifecycle.

As a trivial example, suppose I simply want to log some information everytime a component unmounts for some analytics purpose. That's it. Right now, the simple implementation is:

useEffect(() => {
  return () => {
    fetch('some-analytics-api.com');
  }
}, [])

There's no issue with whether this code works. Clearly it does. However, when developers are scanning the code base littered with multiple useEffect invocations, all of which have different memoization arrays, it takes a second to realize what this code is supposed to be doing - "Hmm, I see we're sending some analytics request. Okay, it's a callback returning a callback, so it's a disposer function. Oh, and there's an empty array as the final parameter, so the disposer only fires when the component unmounts". That fraction of a second to make that determination is just a bit too long in my opinion. With a new topLevel API useUnmount it is grokkable almost instantly:

useUnmount(() => {
  fetch('some-analytics-api.com');
})

This proposal is to add a set of top level primitives that map more directly to the API's that developers are already familiar with and that correspond more closely to the lifecycle events developers think about when reasoning about application flow. The proposed top level hooks include useMount, useUnmount with either an optional flag to run inside a layout effect, or else two additional top level hooks useLayoutMount, useLayoutUnmount.

A likely concern with this proposal is that it will unnecessarily bloat the top level API. The reasoning goes: Why add to the top level API convenience wrappers that can be coded in userland? It's a legitimate concern. In this case however, I argue that the use case is so common that the benefits outweigh the cost. To borrow an analogy, developers have been able to perform Array.map since the invention of Javascript, but once it's usefulness and ubiquity was established, it was added to the language proper. I'm making this same argument for useMount and useUnmount.

As evidence that these convenience wrappers are going to become extremely popular, simple Github searches for uses of useUnmount and useMount (https://github.com/search?q=useUnmount+react&type=Code and https://github.com/search?q=useMount+react&type=Code) return some 100+ repos already declaring their own convenience wrappers for these effects. Unless added to core, this number will expand drastically once hooks leave alpha. Clearly developers want these convenience wrappers, and will either write them themselves or import an external library (lodash for React? Please no...) that does it for them.

Another likely concern with this proposal is that developers will use these syntactic sugar functions to write less optimized and self contained code. To borrow an example from the documentation, the fear is that instead of:

useEffect(() => {
  ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
  // Specify how to clean up after this effect:
  return function cleanup() {
    ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
  };
}, []);

Devs will inefficiently do:

useMount(() => {
  ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
})

useUnmount(() => {
  ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);      
})

From a practical performance perspective though, these two implementations are basically identical and not worth worrying about. Function definitions and invocations are cheap in modern javascript. As to the issue of the code being less self contained, in most instances I believe that won't be a problem since developers will simply extract the logic into a self contained custom hook like useFriendStatus that encapsulates all the logic into an atomic piece.

One small additional benefit: With useMount/useUnmount being in React Core, instead of dozens of different snowflake implementations, there may feasibly be future optimizations on the hooks that React core will then be able implement on an ecosystem wide basis.

So in summary, it seems to me that React can either fight the inevitable or embrace it.

As a purely stylistic (for now at least) question, there's no real right or wrong answer to this proposal and barring extremely strong technical reasons against the proposal, I'm not sure how it can be discussed cooly and objectively. Maybe a developer survey?

[muqg]

I think that the idea of useEffect returning a cleanup callback is based on the fact that you almost never need to perform actions on unmount unless you first performed some kind of mount or update action which caused a side effect that has be reversed.

Besides a simple useUnmount as you suggest can be implemented relatively easy:

function useUnmount(cb, args) {
  useEffect(() => cb, args)
}

[scottmas]

It is clearly possible to write useUnmount and useMount in userland code. No one is disputing that. But I think you are incorrect in your belief that they're almost always used together. They are commonly used together, but not always. For example, a common pattern is to perform useRef cleanup inside a dedicated unmount callback. For instance the popular library Mobx does this in it's React hooks implementation (link).

Arguably most important is the added scannability and mental model benefits of useMount and useUnmount primitives. People are going to write useMount and useUnmount helpers if React doesn't include them in core. We can either force a substantial portion of React developers to do this themselves or else provide a React core implementation.

[gaearon]

We considered this, and decided not to do it. In practice when you do something like this your code is often buggy. You’ll likely fail to handle the update case: https://reactjs.org/docs/hooks-effect.html#explanation-why-effects-run-on-each-update. The analysis in your first comment suffers from the same problem: the two ChatAPI code examples are not equivalent for this very reason. The useEffect version handles updates correctly, but useMount + useUnmount don’t.

These kinds of pitfalls is why we discourage helpers like useMount and useUnmount and don’t intend to provide them either. They tend to lead to buggy code. Another example of this is when you use props inside of the effect code — but your useMount runs only once. Now your code doesn’t handle prop changes. When you useEffect, the move from [] "no dependencies" to [props.something] is more obvious.

Another important part that’s worth mentioning is that effects aren’t intended for data fetching in the longer term. You use them for that today because there isn’t a better alternative, and because you did that in lifecycle methods. But in longer term, Suspense is the solution for data fetching. With Suspense, most of the reasons people want to “just fetch during an effect” disappear.

There is no denying that data fetching is awkward with effects though. I totally see where you’re coming from. But I think the cure is worse than the decease here. And we want to solve the root of the problem rather than get back to class-like “three lifecycle methods” semantics.

[scottmas]

Actually, I totally get it now. Best practice is for developers to use the useEffect inputs argument. Full stop. We want component lifecycle to die as mental model for developers so they begin thinking in terms of memoization based on input data.

https://reactjs.org/docs/hooks-effect.html#tip-optimizing-performance-by-skipping-effects explains this well I think.

Nice job guys. This is going to be a game changer for application development. An idea for the documentation is to call out a bit more explicitly why thinking in terms of component lifecycle is usually a bad idea.

[scottmas]

@gaearon One question though: What is the best practice with regards to instantiating objects withuseRef that require cleanup after use? There's really no place to do it besides when the component unmounts. For instance, that Mobx hooks implementation I referenced (https://github.com/mobxjs/mobx-react-lite/blob/f80ba0884180fbd6156111e6161ab27dae200264/src/useObserver.ts)

[gaearon]

When does that ref subscribe? I don't understand that code's implications.

[scottmas]

He instantiates an object with useRef that has an dispose()/unsubscribe() method that must be run when the component is unmounted so that useless RxJS style streams subscriptions aren't left lying around.

[scottmas]

More generally, since useRef is the new replacement for class instance variables, I'm describing those situations where you would need to do any cleanup for a class instance variable before losing access to it. As another example, lots of old jQuery libraries need to be both instantiated before usage and then and torn down to prevent memory leaks. In that situation, useRef coupled with an unmount cleanup seems like the only way to approach it.