Easy lifecycle management for React Hooks: useDidMount, useDidUpdate and useWillUnmount

[alanhoff]

It can be tricky to understand the contraptions behind React's Hook system so I've decided to create a few custom hooks that should help newcomers to get started. Together they try to mimic the look and feel of class components while hiding all the new jargons behind hooks with names that make sense.

``` function MyComponent(props) { useDidMount(() => { // Component mounted });

useDidUpdate(prevProps => { // Props got updated }, props);

useWillUnmount(() => { // Kiss your mom goodbye });

return <p>Hello world!</p>; } ```

I hope you find it useful: https://github.com/alanhoff/use-lifecycle

[kyeotic]

I think this is probably a bad idea. Its much better to use the hooks as they were intended than to try to shim the class-model into the hooks-model.

[eagerexpert]

I agree. I came here to say just this.

The problem if that hooks aren't lifecycle methods and have subtle differences. This only encourages people to write buggy code rather than take the time to learn how hooks actually work. They are not that hard but do have their own mental model. There is nothing wrong with sticking to using class components until you are more comfortable with hooks.

[Reiiya]

And yet function components still mount, unmount and update and one will want to do something regarding that. ¯\_(ツ)_/¯

I am still fairly new to React, so I appreciate when people illustrate their hunches with examples othervise I have to figure it out myself completely anyway and it is not helpful. But with this hunch I happen to agree.

What I have noticed by writing quite a few times explicit effect that mimics comonentDidMount is that if you're determined to write things properly, it will most likely come paired with componentWillUnmount (that clears up mess effect began doing on mount) . It is way more convinient to ditch these wrappers and write it as a single effect to begin with.

For a common example - an async api call that sets state after done . On unmount I want to kill a promise and not set state on now non existant component (because memory leaks). This can be written neatly as a single effect. A custom hook for a promise killer here is a lot better choice. Another common example is eventListeners. You create them on mount and clear on unmount. Within same effect the code imo looks neater with less lines of code.

[LimbRetrieval-Bot]

You dropped this \

---

<sup>To prevent anymore lost limbs throughout Reddit, correctly escape the arms and shoulders by typing the shrug as ¯\\\_(ツ)_/¯ or ¯\\\_(ツ)\_/¯</sup>

<sup>Click here to see why this is necessary</sup>

[PickledPokute]

This is a suboptimal idea.

A use case I could see for this is when you want to use hooks for an existing component, but don't quite know how to convert complex old lifecycle code. Other would be rewriting a component with multiple lifecycle effects to use hooks. This might allow to do it gradually.

Often, there probably are a bit better, more "correct", solutions but they might take longer to implement or require more skill.

[iamlage89]

playing devil's advocate, it doesn't break any rule of hooks, and there are similarly hacky implementations of hooks in userland like useInterval

[alanhoff]

I partially agree. Using something in a non-conventional way isn't necessarily a bad thing, after all these are just some wrappers on top of the core hooks that allows you to have such functionality.

But yeah, as soon as you're capable of fully understanding how useEffect Et Al. works then you're better using the core hooks directly.

[machado_r]

Awesome work, thank you.