Remove potentially unnecessary use of useEffect in usePrevious

[RickHuizing01]

Is your feature request related to a problem? Please describe.

The current implementation of the usePrevious hook relies on useEffect to store the previous state. While this approach works, I believe that the use of useEffect might not be necessary. The usage of useEffect could be considered an anti-pattern according to the official React documentation (as described in You Might Not Need an Effect) if I interpret it correctly.

Describe the solution you'd like

Initially, I considered removing the useEffect altogether, resulting in the following implementation:

import { useRef } from "react";

export const usePrevious = <T>(state: T): T | undefined => {
    const ref = useRef<T>();

    const previousValue = ref.current;
    ref.current = state;

    return previousValue;
};

While this solution works, my colleague @dasblitz pointed out that reading or writing to a ref during rendering is also considered an anti-pattern, as highlighted in the official React documentation here: https://react.dev/reference/react/useRef (see the pitfall section). Consequently, I created an alternative version that avoids both useRef and useEffect:

import { useState } from "react";

export const usePrevious = <T>(state: T): T | undefined => {
    const [current, setCurrent] = useState<T>(state);
    const [previous, setPrevious] = useState<T>();

    if (JSON.stringify(current) !== JSON.stringify(state)) {
        setCurrent(state);
        setPrevious(current);
    }

    return previous;
};

However, there is a significant pitfall with this implementation: the useState hook maintaining the current value essentially duplicates the state of the component using this hook. Based of that, the second implementation would make more sense if it was the useStateHistory hook as it naturally handles the "main" state.

I am still exploring alternative approaches but wanted to share my progress so far.

[FleetAdmiralJakob]

I saw an interesting video about this today: https://www.youtube.com/watch?v=B-Xb_8n5wRg

And I'm just curious why we would need JSON.stringify() and not just do it like https://github.com/uidotdev/usehooks/blob/90fbbb4cc085e74e50c36a62a5759a40c62bb98e/index.js#L1017-L1027 without it?

[childrentime]

how about this? https://github.com/alibaba/hooks/blob/master/packages/hooks/src/usePrevious/index.ts

[FleetAdmiralJakob]

btw. alibaba has the same discussion 😂: alibaba/hooks#2162

[RickHuizing01]

Cool to see that other libraries are also picking this up. Also, very good video @FleetAdmiralJakob, thanks for sharing! It’s interesting to see other libraries already using this implementation (without the JSON.stringify() as you mentioned).

About JSON.stringify vs ===:
I think we can go with just ===. React ensures that state updates always create a new reference, even when the content is the same, due to its immutability rules. This means === should be sufficient to detect changes, as references will differ for updated states. Using JSON.stringify or deep equality seems unnecessary in this context.

That said, I sometimes get a bit confused when it comes to object equality haha, so feel free to correct me if I’m wrong!

all in all, this would lead to (basically the same implementation as used by usehooks from uidotdev):

export const usePrevious = <T>(state: T): T | undefined => {
    const [current, setCurrent] = useState<T>(state);
    const [previous, setPrevious] = useState<T>();

    if (current !== state) {
        setCurrent(state);
        setPrevious(current);
    }

    return previous;
};

[FleetAdmiralJakob]

Yes, totally agree with you @RickHuizing01. For https://github.com/childrentime/reactuse we went with the version without deep equality too: https://github.com/childrentime/reactuse/blob/main/packages/core/src/usePrevious/index.ts