[BUG] ResizeOvserver loop limit exceeded - webpack-dev-server related

[martinchrzan-workday]

Describe the bug
After upgrading to 4.2.0 (upgraded from 4.0.9), I am getting this error locally immediately on loading React-Virtuoso component
It seems like I can just close this error overlay, but it always come back as I scoll in the list and load new items.

Reproduction
Happens immediately upon landing on the react-virtuoso component

Expected behavior
Not getting the error.

Screenshots

Desktop (please complete the following information):

• OS: MacOS.
• Browser: Chrome

[petyosi]

I need a reproduction to fix this. In general, this error is to be ignored, but I can't say if there's something else happening. Can you isolate in a sandbox?

[petyosi]

@martinchrzan-workday - did you find something? Let me know once you get to that.

[dylanwulf]

Hi @petyosi @martinchrzan-workday, I was able to reproduce the issue here: https://github.com/dylanwulf/virtuoso-error.
All I did was fork the "Endless Scrolling" demo from the react-virtuoso docs and I updated react-scripts to the latest version. Just run the reproduction and keep scrolling to the bottom. It doesn't show the error 100% of the time but it does eventually show up.
We're seeing this error in our app which is still on react-virtuoso v3.1.5

[petyosi]

Thank you @dylanwulf - I managed to reproduce that on my side. For reliable reproduction, longer items should be used so that variance in item heights is present.

To start off with the most important part, the error is "harmless", it just denotes that certain updates could not be executed in a frame. See this response in StackOverflow.

Next thing I found out is that upgrading the version of React to the latest one and changing the initiation script to the recommended React 18 createRoot approach solved the issue in the example.

import React, { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import "./styles.css";

import App from "./App";

const root = createRoot(document.getElementById("root"))
root.render(<App />);

With that in mind, I think that the component should work without any issues in new setups, and the problem is present when a certain combination of react versions, react scripts and react initiation techniques are used.

I will, however, re-open this issue. The examples in the website need to be updated to the above and to the latest react version.

Let me know if changing the initiation script works for you. If it does not, I may suggest you remain at an older version of virtuoso and react-scripts.

[iamterryclark]

Hey there,

I also have this issue,

Using React 17.0.2 with electron, I found that react-virtuoso was the issue, even after I updated to 4.2.1 , and your fix with useMemo.

This is just a debug issue and not in production.

I found that wrapping the useSizeWithElRef function with a requestAnimationFrame works well. the information came from here

https://stackoverflow.com/questions/49384120/resizeobserver-loop-limit-exceeded/58701523#58701523

line 467 in your index.mjs i am now doing this

return new ResizeObserver((entries) => {
  // We wrap it in requestAnimationFrame to avoid this error - ResizeObserver loop limit exceeded
  window.requestAnimationFrame(() => {
    if (!Array.isArray(entries) || !entries.length) {
      return;
    }
    // your code
    const element = entries[0].target;
    if (element.offsetParent !== null) {
      callback(element);
    }
  });
});

[petyosi]

@iamterryclark My guess is that some development mode utility is eagerly catching this error and promoting it when it should not. Something similar was happening with react-beautiful-dnd.

Regarding your suggestion: unfortunately, I've tested the route of requestAnimationFrame and ultimately had to revert it for multiple reasons, performance lag being one of them.

If you can reproduce the problem in something I can run, it will help me help you a lot. Electron is not my jam, though.

[petyosi]

@iamterryclark Forgot to mention - notice that v4.2.1 does not fix this problem :) but something else I discovered while testing. Right now, I believe it's a setup problem, not something that can be addressed from within the component (unfortunately).

[iamterryclark]

Thanks for getting back so promptly,

I forgot to mention also that I am using virtuoso with dnd-kit as the context. I read about styling being an issue in some cases.

Trying to reproduce the sample inside codesandbox.io, but not able to see this issue just yet. That does suggest to me also what you mentioned about the error capture.

https://codesandbox.io/s/mystifying-water-57173v

I tried to apply the window.addEventListener for 'error' from your examples also doesn't seem to help resolve my issue (block the message from appearing).

[petyosi]

@iamterryclark I don't think it will be reproducible in a sandbox. I suspect react-scripts in a local environment being the culprit. Give it a try, happy to see if there's something that can be fixed or at least "officially" worked around.

the sandbox above seems unsaved, did I miss something?

[iamterryclark]

sorry missing character ^^ edited

ill try this locally also and see if I can get a reproducible example

[dylanwulf]

Some more info I found: looks like this error started showing up with webpack-dev-server v4.12.0 webpack/webpack-dev-server#4771. They added a config option to hide it

[martinchrzan-workday]

Thanks for the investigation, I can confirm that webpack-dev-server was the culprit of this issue. Using their new config to hide runtime errors fixes the issue

[petyosi]

Folks, thanks for your help here, it looks like there's not much that can be done on the component level. If someone finds something different, let me know.

[mankittens]

It appears this bug has popped up again in v4.7.0. It does not present in v4.6.3 for me.

[petyosi]

@mankittens I will need a bit more from your side, there are several different topics discussed in this issue. Can you can open a new one with a reproduction?

[Arkellys]

I've just installed this library and noticed this error too. In my case, I use webpack-dev-server, so I guess it's nothing new. The workaround I have in my code is to use a ponyfilled version of ResizeObserver in development:

if (isInDevelopment) {
  global.ResizeObserver = (await import("@juggle/resize-observer")).ResizeObserver;
}

I'm actually using this because I also have a bug with another library using ResizeObserver and the ponyfill fix it. I only noticed the resize loop error because I was doing some refactoring and temporarily commented out the workaround.

In the docs of @juggle/resize-observer, it's mentionned it has a resize loop detection, which prevents the loop error to be dispatched. I guess it's an alternative for those who don't want to change their dev server configuration.

[trainoasis]

We had to revert react-virtuoso from 4.7.1 to 4.6.3 to make this work, otherwise our Cypress tests are failing with ResizeObserver errors (even if handled in Cypress and ignored, it then fails with memory issues).

Is there anything specific that we can fix in the app to avoid this?

[nowaylifer]

We had to revert react-virtuoso from 4.7.1 to 4.6.3 to make this work, otherwise our Cypress tests are failing with ResizeObserver errors (even if handled in Cypress and ignored, it then fails with memory issues).

Is there anything specific that we can fix in the app to avoid this?

same

[petyosi]

@trainoasis @nowaylifer Did any of you bring this to Cypress?