You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Likely due to the way react-use-measure creates a debouncer, r3f canvases delay their initial render by the scroll debounce duration, which is by default 50ms. I would have thought a useLayoutEffect call would be required to get the initial size? It seems react-use-measure is currently relying on a quirk of the observers calling the callback after the initial delay.
In any case, child components aren't rendered until after this initial delay, so if any data fetching happens in them, that is delayed by this duration.
For example under default settings, the initial timer reports 85 ms.
For example, the above results in a delay of 5 seconds which is counter-intuitive.
Ideally the r3f canvas is rendered as soon as possible, and the debounce is created with the immediate setting being true, and only subsequent calls are debounced, in case the resizing / scroll happens in 'one go'.
The text was updated successfully, but these errors were encountered:
I think that's because react-use-measure is based on ResizeObserver which runs its callback a frame after its initialization. One solution would be to call getBoundingClientRect immediately when element is binded.
Likely due to the way react-use-measure creates a debouncer, r3f canvases delay their initial render by the scroll debounce duration, which is by default 50ms. I would have thought a
useLayoutEffect
call would be required to get the initial size? It seems react-use-measure is currently relying on a quirk of the observers calling the callback after the initial delay.In any case, child components aren't rendered until after this initial delay, so if any data fetching happens in them, that is delayed by this duration.
For example under default settings, the
initial
timer reports85
ms.Setting it to 0ms reduces the
initial
timer reporting to35
ms:In an extreme example, setting
debounce
to 10 seconds results in theinitial
timer reporting10
seconds.This seems to be dependent on the
scroll
debounce regardless of whetherscroll
is set to true or false.For example, the above results in a delay of
5
seconds which is counter-intuitive.Ideally the r3f canvas is rendered as soon as possible, and the debounce is created with the
immediate
setting being true, and only subsequent calls are debounced, in case the resizing / scroll happens in 'one go'.The text was updated successfully, but these errors were encountered: