Width is not recalculated properly if the parent has a scaling animation (e.g. MUI Popover)

[NadiaIvaniuckovich]

Hi!

After the latest changes from v1.0.26 old issue #49 seems to be reproducible again, probably due to switch from offsetWidth/offsetHeight to getBoundingClientRect width and height. Here is a fork of initial sandbox example, but with v1.0.26.
Since v1.0.26 changes needed for other issue #96 maybe some alternative approach can be used to avoid both of them, e.g. some recalculations or returning both values, client rect based as primary and offset based as secondary to be used in popovers.

Thanks for your efforts!

[Senkyryky]

Hi,

I can confirm that issue is there, I also created nearly the same sandbox example.

Issue can be avoided temporarily by setting transitionDuration to 0 in mui Popover props, see comment in example

[SimonMueller]

I also have the same issue when using a Popover.

[AntoineArt]

Okay so thanks @NadiaIvaniuckovich for the issue. Thanks to you we now know why recent versions of Nivo are bugged x)

[radiol00]

I have the same issue, I'm using framer-motion to animate scale of my custom modal with AutoSized virtualized list inside. The size of the list stays the same for the whole animation and after the animation is complete. Going back to v1.0.25 solved the issue.

[bvaughn]

If anyone above would like to put together a PR that fixes this, I'm happy to review it.

I may also give it some thought in light of a possible v2 (related to #100)

[bvaughn]

I'm going to address this as part of version 2 (PR #101, docs) which I will try to release sometime this week.

I'll use this as an opportunity to drop the deprecated scaledHeight and scaledWidth values.

[bvaughn]

Just finished refreshing myself on the resolution of #49, aka #49 (comment). The underlying issue was that AutoSizer (like ResizeObserver) is not called again after a CSS transition finishes. The reason the old width/height seemed to work is that they were using offsetWidth/offsetHeight which do not respect scaling.

This component needs to respect scaling (which is why it now uses getBoundingClientRect). Reporting a non-scaled size would be an awkward workaround for what's really being asked for here, and could cause other problems if e.g. the CSS transformation was applied in the other direction.

One possible API solution here could be to add an optional box prop which could be set to "device-pixel-content-box" for pre-scaled size, but that feels a bit awkward to me.

Edit I've decided, for now, to proceed with the optional box prop, as documented here: https://react-virtualized-auto-sizer-git-v2-brian-vaughns-projects.vercel.app/props/auto-sizer