React-spring: RFC: @react-spring/resize-observer for "auto" support and better percentage support

[aleclarson]

🚀 Feature Proposal

Add a new package called @react-spring/resize-observer that plugs into react-spring to provide support for "auto" (#302) and support for animating from a number to a percentage (#643). This should be possible once we can inject custom logic into animated components.

Motivation

• Painless animation between dynamic size constraints.
• Avoid need for user to manually wire up resize handling.

Example

No example yet.

[drcmda]

The problem i see is that automatic "auto" will only make sense in a few scenarios. It will never fulfil all usecases and that makes it problematic. As an example, consider: https://twitter.com/0xca0a/status/1094683974679621633 and the following comment: https://twitter.com/brunolemos/status/1094714113685639169

Without that manual intervention the resize would essentially be unusable because css "auto" behaves very differently from resize measurement. But this is just one of many. In the previous versions where i've had this inbuilt there were countless of such cases.

Not to mention all the weird css edge cases, starting with little things like box model and parent position (absolute, relative, static, etc). These can completely wreck assumptions and lead to wrong calculations.

With things like useMeasure around they'll give the user more fine grained control and they always get what they expect. That's the beauty of hooks and we should embrace inter-op more than baked-in:

const [ref, bounds] = useMeasure()
const props = useSpring({ height: ... // do whatever is needed

Putting "auto" into react-spring kind of adds something very magical that works sometimes, and sometimes not. And to fix it we'll create rules, and more rules, and they'll stack up. Some users will be happy, some will rip their hair out over css issues we have no control over. I would prefer to keep react-spring as explicit as possible. I've had the same worry about gestures.

What i would be in favour of is putting a really good battle tested useMeasure micro lib hook onto the react-spring org, maybe one that can solve some of the crazier edge cases for us. react-spring could open up some interop here, for instance the multi-element ref problem, see: https://codesandbox.io/embed/7mqy09jyq (look for refMap)

[aleclarson]

The problem i see is that automatic "auto" will only make sense in a few scenarios. It will never fulfil all usecases and that makes it problematic.

It doesn't need to solve every use case, no? Something like useMeasure is the more flexible (but less convenient) alternative. A lot of people prefer auto because it doesn't require another import wherever it's used.

Without that manual intervention the resize would essentially be unusable because css "auto" behaves very differently from resize measurement. But this is just one of many. In the previous versions where i've had this inbuilt there were countless of such cases.

Can you point me to some of those cases?

we should embrace inter-op more than baked-in

This would be an optional package that injects its behavior via Globals. It's not an either-or question. People can use what they prefer. 👍

I've had the same worry about gestures.

Gestures and natural size are two different things. The auto keyword is how natural size is expressed in CSS. The closest thing to gestures is the :hover selector, but of course that's extremely limited in comparison to useGesture. The real question is whether auto provides more convenience to the user when their needs are simple.

Putting "auto" into react-spring kind of adds something very magical that works sometimes, and sometimes not.

We can make it explicitly limited in the docs. (eg: "Only use this for these use cases, else be on the lookout for bugs and remember that useMeasure can be used if auto doesn't work!")

What i would be in favour of is putting a really good battle tested useMeasure micro lib hook onto the react-spring org, maybe one that can solve some of the crazier edge cases for us. react-spring could open up some interop here, for instance the multi-element ref problem, see: https://codesandbox.io/embed/7mqy09jyq (look for refMap)

I'm down for this as well 👍

[drcmda]

A lot of people prefer auto because it doesn't require another import wherever it's used.

That will always be the case, but a lib it has to take a stand for its principles. Do you want something explicit or implicit. If you go with the implicit these requests will never stop. People will ask for interpolations between 1% to auto to 1px and 100rem. I kinda lean the way React structures out their foundations, things sometimes are constrained for good reason, and often solutions present themselves out of the confines.

Can you point me to some of those cases?

The one in the tweet for instance. But nested auto is generally hard. https://github.com/react-spring/react-spring/issues?utf8=%E2%9C%93&q=auto

Gestures and natural size are two different things.

IMO not so much. One is interaction, one is measurement (which is platform specific) and the other is animation. useGesture for instance can do its job really well, but the day React merges x-platform declarative events, react-spring will naturally comply. That's the beauty when things are modular. I believe a very good modular useAuto would be a benefit - also for other projects, not just spring.

We can make it explicitly limited in the docs.

In my experience we can't make it explicit enough, b/c the underlying css and cross browser rules are too complex. I've had a section about this, but it just couldn't solve deeper issues like nesting. When i had auto merged i was answering issues pretty much on the regular.

I'm down for this as well 👍

Awesome! I'm thinking, something like this could create good opportunities for better interop between libs and some shared responsibility. There are a couple of libs doing this of course, but they're mostly not concerned with complex issues (nesting again).

[aleclarson]

I've thought about this some more. I have a plan where every spring animates under-the-hood from 0 to 1, then the animated components (created with platform-specific animated function) will interpolate those values based on the configured from and to props. That would let users animate from 0px to auto/100%/100vh or whatever, because the animated component has the context of which style prop is being animated.

I can only think of one drawback. Any interpolator functions will run once per animated component that depends on it, instead of always being called just once. Not really an issue, IMO.