react: Bug: React 18 Strict mode does not simulate unsetting and re-setting DOM refs

I want to put things a little differently than what has been said here.

By not resetting refs, the React “double render” stress test creates behavior that only exists in development and would never occur in production build and therefore creates a use case that we now have to develop for just for the sake of the “double render” stress test in development. Here’s an example:

In the following code I want this behavior:

• First time a user comes to a page
  • check to see if a scroll position was stored from the last time they were on the page
    • if yes restore their scroll position
    • if no, try to scroll the first appointment of the day into view
• If the user is already on the page and changes the day they want to view, try to scroll to the first appointment of the day into view

const Schedule = ({ day }: { day: string }) => {
  const scrollRef = useRef(null)
  const hasMounted = useRef(false)

  // I think useLayoutEffect is need because we want to get 
  // the scroll position of an element before unmounting
  useLayoutEffect(() => {
    if(!hasMounted.current) {
      hasMounted.current = true
      const scrollPosition = getLastScrollPositionLocalStorage(day)
      if(scrollPosition && scrollRef.current) {
         scrollRef.current.scrollTo(scrollPositon)
         return () => {
           setLastScrollPositionLocalStorage(day,   getScrollPosition(scrollRef.current))
         }
      }
    }

    if(scrollRef.current) {
       const firstAppointmentScrollPosition = getFirstAppointmentScrollPosition()
       scrollRef.current.scrollTo(firstAppointmentScrollPosition)
    }
  
   return () => {
     setLastScrollPositionLocalStorage(day, getScrollPosition(scrollRef.current))
   }
  }, [day])
  return <ScheduleView ref={scrollRef} />
}

This code will have different behavior in development than in production. In development since refs are not reset this component will always try to scroll the first appointment into view and will not try to restore the last scroll position a user had when they were on this page.

Why? In production this effect would only run once if the day never changes. In development this runs twice no matter what.

We have workarounds to make the behavior consistent but again, we have to develop a workaround that would never happen in production just to satisfy the “double render” stress test.

It’s possible React has some future plans to say “hey we are gonna run those damn effects as many times as we please” and if so makes this point moot. Thanks for your thoughts!

Just my two cents here to re-iterate the problem in a different way. In my case, I’m setting up a store instance in a component via a ref hook (simplified version):

const function useCreateStore() {
  const ref = useRef(null);
  if (ref.current === null) {
    ref.current = createStoreFn();
  }
  return [ref.current, () => destroyStore(ref)]; // return the store and a "disposer" function
}

then I have a disposer that looks something like this:

function destroyStore(ref) {
  if (!ref?.current) return;

  const store = ref.current;
  store.beforeDestroy();

  ref.current = null; // set to null so garbage collection deletes the store instance
}

And here’s the bit in the component:

const [storeInstance, storeDisposer] = useCreateStore(storeCreateFn);

useEffect(() => {
  storeInstance.fetch(id);
  
  return () => storeDisposer();
}, []);

console.log(storeInstance.resultData);

In my case, the store is calling an api call that uses cancel tokens. However, in strict mode, because the refs aren’t automatically cleaned up as part of the second rerender, it gets into a weird state where the new component does the whole mounting flow, but the ref link gets lost, causing the component’s second mount to not see the resulting data. As soon as I comment out the ref.current = null; line above, it works because the ref now can keep the link behind the scenes, therefore only a single store instance is actually used. However, this defeats the point of the strict mode, since now you’ve got components rerendering, but a store instance that is shared between the two mounts.

Long story short (and a lot of trial and error later), I landed on this github issue because I had to turn off the strict mode to properly keep my garbage collection flow working. It would be nice to be able to verify the api promise canceling via the strict mode (which is what I would expect), but the refs not getting cleared properly makes this impossible.

On our project we also caught up into that trap. For now we can’t use StrictMode at all as it breaks all our applications. We have usePrevious recommend by react team, which looks like:

function usePrevious<T>(value: T): T | null {
  const ref = useRef<T | null>(null);

  useEffect(() => {
    ref.current = value;
  }, [value]);

  return ref.current;
}

And we have component that display tiled image. Each tile - is independent instance that use custom hooks to load image, cache it, aborts previous call if was invoked. So it looks like:

function useTileLoad<T>(params: T, abortableCallback: AbortableCallback<T>) {
   const abortRef = useRef<() => void>();

   const [tile, setTile] = useState<TileImage | null>(null);

   const prevParams = usePrevious(params); // Store previous params
   
   // Callback to load tile image or re-request new one if params was changed before request completed
   const handleLoad = useCallback(async (params: T) => {
      if (abortRef.current) {
         abortRef.current(); // If abortable is exist - abort it, as we will request new one below
      }

      let aborted = false; // Temp variable to avoid state update, when request was canceled due to new request or when component unmounts

      const abortable = abortableCallback(params); // Call abortable request that returns abortion callback

      // Store current abortion request to ref
      abortRef.current = () => {
         aborted = true;
         abortable.abort();
      };

      try {
         const response = await abortable();
      
         if (!aborted) {
            setTile(response);
         } else {
           throw new Error('Request was canceled');
         }
      } catch (e) {
        console.log('Request was failed or aborted', e);
      }
   }, [abortableCallback]);

   // (1) Abort current request Promise wrapper to avoid unhandled state update
  useEffect(() => {
    return () => {
      abortRef.current?.();
    };
  }, []);

  // (2) Compare next params with previous params and request new tile in prams are different
  useEffect(() => {
      if (!isEqual(params, prevParams)) {
        handleLoad(params);
      }
  }, [props, prevProps, handleLoad])
}

What will happen above in StrictMode? Let’s see:

1. Component mounts, it goes to useEffect (2), compare params and call handleLoad
2. Component immediately unmounts, and goes to useEffect (1), and abort request that was called in p1.
3. Component mounts back, it goes to useEffect (2) and does nothing next. params and prevParams are equal. usePrevious was not re-created. As result - tile image was not loaded, nothing displayed to the developer.

useRef is useState under the hood. Why does React keep state in StrictMode between mounting/umounting? What if I want it only in few components? What if want decide by myself when it should happed to component or even custom hook, but not React?

Hi! Any updates for this?

While the issue discussed here might be legit (we’re discussing that), can you share what kind of code you have that doesn’t work?

For example, useChangeEffect hook, quite commonly used, I guess. Initial implementation was based on the fact, that after mount ref always has initial value, but now it isn’t true: https://codesandbox.io/s/dry-grass-0uyhx4

Basically, it was like axiom - refs always have initial values after mount. Now the axiom is broken.

Of course, for this particular case you can use cleanup function to set isMounted ref back to false, but if you want to implement useChangeEffect with cleanup functions provided by user, you need to use two useEffects instead of one - one for setting isMount ref (without deps), and the other for actual effect with deps. Something like this:

const useChangeEffect = (effect, deps) => {
  const isMounted = useRef(false);
  
  useEffect(() => {
    if (isMounted.current) return effect();
    
    isMounted.current = true;
  }, deps);

  useEffect(() => {
    isMounted.current = true;
    
    return () => {
      isMounted.current = false;
    };
  }, []);
};

And now we have to use two effects instead of one for implementing the same functionality, just because of artefact of dev mode. That’s kind of strange to me.

@HenrikBechmann I think what you’re getting it is at the core of the issue with this (possible) bug. I think an effective way to check whether a component is mounted would be to use a ref to a jsx/DOM element in the component:

const isMountedRef = useRef(null);
const isMountInitialized = useRef(false);

useEffect(() => {
    if(isMountedRef.current && !isMountInitialized.current) {
        // do something to initialize the mount
        isMountInitialized.current = true;
    }
    return () => {
        if(!isMountedRef.current) { // on unmount, isMountedRef.current should be null. This isn't currently the case on simulated unmounts though
            // perform unmount cleanup
            isMountInitialized.current = false; // in case the component state is being saved to remount later
        }
    }
});

return (
    <div ref={isMountedRef}>
        {/*contents*/}
    </div>
)

That is the main issue with the functionality mentioned in the issue. If the simulated unmount doesn’t clear the refs like a normal unmount, this pattern can’t be properly used and tested in development StrictMode.

That’s also not to say that this pattern is good or even necessary to use, but in my opinion it should be expected to work this way, however it can’t work this way at the moment due to the (possible) bug.

@huynhit24 That’s intentional behavior in Strict Mode and unrelated to this thread. Please refer to https://reactjs.org/blog/2022/03/29/react-v18.html#new-strict-mode-behaviors.

in React 18 every time I render the component mount, the callback runs twice, I don’t know what to do?