flushSync was called from inside a lifecycle method

[sunwrobert]

Describe the bug

When using window virtualization, I see the following error in the console:

react-dom.development.js:94 Warning: flushSync was called from inside a lifecycle method. React cannot flush when React is already rendering. Consider moving this call to a scheduler task or micro task.

This flushSync seems to have been added in #608. @piecyk have any recommendations?

I was able to fix this locally by guarding the cb with a isMounted check.

  const observeElementOffset: VirtualizerOptions<
    Window,
    Element
  >["observeElementOffset"] = useCallback(
    (instance, cb) => {
      const tableTopOffset = tableRef.current?.offsetTop ?? 0
      return observeWindowOffset(instance, offset => {
        // Observing the offset during lifecycle methods causes this error, so guard it by mounted.
        // Warning: flushSync was called from inside a lifecycle method.
        // React cannot flush when React is already rendering.
        // Consider moving this call to a scheduler task or micro task.
        // https://github.com/TanStack/virtual/pull/608
        if (isMountedRef.current) {
          cb(offset - tableTopOffset)
        }
      })
    },
    [tableRef],
  )

Your minimal, reproducible example

https://codesandbox.io/p/devbox/cool-haze-j7xfp5?file=%2Fsrc%2Fmain.tsx%3A19%2C30

Steps to reproduce

1. Open console
2. Notice flushSync error pops up on initial load

Expected behavior

There should not be a console error.

How often does this bug happen?

None

Screenshots or Videos

No response

Platform

Chrome

tanstack-virtual version

3.0.0-beta.68

TypeScript version

No response

Additional context

No response

Terms & Code of Conduct

• I agree to follow this project's Code of Conduct
• I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

[jorisre]

I'm encountering the identical problem even after setting initialOffset, and it's not functioning as intended.

[piecyk]

@sunwrobert why do you need this custom observeElementOffset?

[piecyk]

I'm encountering the identical problem even after setting initialOffset, and it's not functioning as intended.

@jorisre hard to say what is happening in your case, initialOffset should not produce this error.

[sunwrobert]

@piecyk

It adjusts when the virtualizer thinks the grid is being scrolled to account for content above the grid. This avoids the hack of needing to increase overscanBy to account for the content, which affects scroll performance.

Let me know if this is no longer the case though

[piecyk]

to account for content above the grid.

@sunwrobert exactly for this we have scrollMargin, that controls how much space is above gird.

[bvisserbb]

I also have this issue in a usage of virtualizer in my app after trying to upgrade to 3.0.1 (from an older beta version). When I remove the initialOffset prop the error is resolved. I don't have an isolated reproduction right now but will be putting some time into it today.

[piecyk]

@bvisserbb It's happening because initialOffset will trigger extra render via scroll, while react is alredy rendering.

[bvisserbb]

Thanks @piecyk were you able to come up with a reproducer? I pulled in the repo and tried to get a page together that had "ambient renders" as well as the initial offset on mount but couldn't reproduce. Definitely have the issue in my app though.

[piecyk]

Thanks @piecyk were you able to come up with a reproducer? I pulled in the repo and tried to get a page together that had "ambient renders" as well as the initial offset on mount but couldn't reproduce. Definitely have the issue in my app though.

Didn't yet, but i'm pretty sure that this is the case, will think how to resolve this.

[sunwrobert]

@piecyk Yeah I think we can close this. I think using scrollMargin instead fixed my issue. But I think the documentation should definitely contain that u need to modify translateY based on the scroll margin as well!

[piecyk]

@sunwrobert ooo nice, glad that it worked for you.

I think using scrollMargin instead fixed my issue. But I think the documentation should definitely contain that u need to modify translateY based on the scroll margin as well!

I agree, we need to mention it as for sure this can be bit confusing at first.

[bvisserbb]

@piecyk fwiw I don't think my scenario involves content above / below the list, or anything that would require scrollMargin. But understand if you need to close this up in favor of a new ticket with a new reproducer -- still haven't been able to come up with an isolated case, but I suspect it may involve dynamic height with async loading.

[piecyk]

@bvisserbb please open a new issue that describes your use case, then we can tackle the flushSync shenanigans.

[ConnorLanglois]

@piecyk

I ran into this issue myself and did a bit of debugging. Not sure what is cause, but I found that after navigating to a page (in nextjs) that had the window virtualizer (am also using scrollMargin with translateY) the page was being instantly scrolled down after load and also caused this flushSync error. It seemed that the page would be scrolled more depending on how far down the previous page (from which it came) was scrolled (but not same amount). Weird.

I found that version 3.0.0-beta.61 specifically PR #592 caused the scroll issue, but notably did not cause flushSync error. After setting "initialOffset: 0" in useWindowVirtualizer this fixed the scroll issue in the latest version, and here's the key --- I also do not get the flushSync error anymore.

Hopefully there's some info here that could help.

Edit: I just realized my scrollMargin is set to (listRef.current?.getBoundingClientRect().y ?? 0) + (typeof window !== 'undefined' ? window.scrollY : 0) which probably conflicts with the change in that PR that changed initialOffset