ResizeObserver loop limit exceeded

👋 Hello. We have a component that’s using this hook with in it’s default form (no custom callback) and have been getting a lot of ResizeObserver loop limit exceeded errors thrown during usage.

From my brief search around the internet it seems as though this is harmless but it does add a lot of noise in common usage and that that noise could be avoided by wrapping the ResizeObserver callback in a requestAnimationFrame.

I could adjust our usage to do this using a custom callback, but that would mean reimplementing the core observer logic which seems rather pointless. Does it make sense as a core adjustment?

[ZeeCoder]

Yeah having a rAF call in there would mean that you no longer get notification of resize events as they happen, but rather with a 16ms delay or so. (Depending where you are in the current tick.)

If you need rAF, then it should be really easy to have a custom local hook, that does something like:

function useResizeObserverWithRAF(opts) {
const [size, setSize] = useState({width: undefined, height: undefined});
useResizeObserver({ ...opts, onResize: (size) => requestAnimationFrame(() => setSize(size)) });

return size;
}

In terms of such optimisations (like throttle and debounce) it’s not as easy to know exactly what people might need, and as you’d pile more feature on top, the harder it would be to maintain this lib, which is meant to be as low-level as it can. 🤷‍♂️

It is a good candidate for a readme entry or a codesandbox demo. (Like the ones I’ve made for throttle and debounce.)

[makenosound]

Sorry, @ZeeCoder — I’m not that familiar with the ResizeObserver API or its usage in practice and so my reading of https://stackoverflow.com/a/50387233 was that that exception is usually caused not necessarily by an infinite loop, but by the observer triggering more events than can be handled in a frame.

What I was musing on as a solution was wrapping the observe callback in a requestAnimationFrame to ensure that it only passes events at a rate that’s actually usable in a consuming app. I imagine that could cause issues with an initial evaluation of their values though so it probably doesn’t make sense after all (and that suggestion was predicated on that SO comment being accurate anyway).