TimingAnimation: alternatives, bugs with newer versions

[runningjump]

Hey there! Thanks for all your work on such a wonderful library. My only frustrations thus far have revolved around timings.

It seems very strange to me that Spring components do not having a duration prop by default. The only way I've found to define the length of an animation is with TimingAnimation. Importing that from "react-spring/dist/addons" and adding it to the Spring via the impl prop worked fine, but felt a little convoluted. Is there any alternative for defining the length of each animation?

More importantly, this implementation seems to have broken in the last few weeks. When I upgraded from 5.6.6, TimingAnimation stopped working entirely. No errors were thrown, but my duration values -- as well as, notably, our delay values -- were ignored. Once we removed impl={TimingAnimation}, delay worked again, but we lost our duration and easing (obviously). Any idea what changed? Is this addon included some other way, now?

Thanks again!

[drcmda]

I will look into it, could you make a quick sandbox for it? Try the latest beta, too.

Duration isn’t the focus of this lib because it’s mostly an inferior tool for ui animation. Springs are physics driven and adapt to their current position. but I’m open to make it easier. Though isn’t impl easy enough? Any ideas how you’d ideally like it?

[runningjump]

Thanks for the quick response!

What do you mean that it's an "inferior tool for UI animation"? Do you mean that's it's more intended for transitions between states than it is for keyframed, multi-stage animations? I think that duration controls would be vital in either case.

My problem isn't so much with impl as with the fact I need a value for impl for my config.duration value to have an effect. It'd be nice if I could define duration (in config or as a prop) and have that work without any imports from /dist, which feels hacky to me.

I tried a few versions, including 5.7 and 5.8, with no luck. I'll try to make a sandbox for it tonight!

[drcmda]

Here is an explanation: http://react-spring.surge.sh/gotchas

There are use cases for sure where you'd definitively want duration, and if i can make it more comfortable i'll gladly do it, but it still comes down to exchanging the engine from physics to duration-based easing.

The bug on the other hand shouldn't be and i'll fix it with your box once you post. :-)

[runningjump]

Ahh I see! Ok, well that's all very interesting. I definitely had a fundamental misunderstanding of how it all works, then -- what appealed to me what how declarative the library is and how you don't need to define starts and stops and callbacks and whatnot, but I didn't make the next logical step, which is that duration would also be dynamic and not defined directly. Cool! You should totally add some of that philosophy to the README!

I saw some performance issues when running about 100 manually-timed animations at once, is that what you mean about it being the wrong tool for that use case? Would defining that many springs without timings be performant?

[drcmda]

Haha, yeah i just did, updated gotchas (http://react-spring.surge.sh/gotchas), probably worth it to include a small section explaining this :-)

As for performance, it depends on what you animate, which props (the browser can only animate composition props speedily like transforms and opacity), but the most impact is probably if you're using springs in native mode or not, see: http://react-spring.surge.sh/native

[runningjump]

Very nice! Thanks again, and I'll update once I put together a demo.

[drcmda]

I think it should be fine now, could you try 5.9.0-beta.3?

      <Spring impl={TimingAnimation} config={{ delay: 1000, duration: 1000 }} from={{ opacity: 0 }} to={{ opacity: 1 }}>
        {props => <div style={props}>hello</div>}
      </Spring>

worked for me