Roadmap/umbrella for 6.x.x

drcmda commented 6 years ago

Ideas welcome! For now:

[x] Leaner api
[x] Leaner/faster spring implementation
[x] Moving delay back into config
[x] Transitions can trail
[x] Trails can take durations
[x] Trails can reverse direction (start trailing from top/bottom for instance)
[x] Keyframe overhaul
[x] Move parallax into addons
[x] Allow to/enter/leave/update to receive arrays, for chained/multistage animations
[x] Rewrite the spring updater, remove setTimeout and use one RAF instead of many for each individual animated value
[x] Treeshaking & shaking off weight in general
[ ] Move away from animated?

Leaner/faster spring implementation

SSE looks far leaner (and faster) to me than RK4 just by judging the code. When i read that many game engines use SSE for that reason i am thinking maybe react-spring should, too.

https://gafferongames.com/post/integration_basics/#semi-implicit-euler

Moving delay back into config

This was a mistake. Moving it out effectively made duration chaining impossible, where otherwise every animation value can be given its own config.

Keyframe overhaul

The current api is still too complex and unwieldy.

Treeshaking & shaking off weight in general

@Andarist and @TrySound had some great ideas here that should be realized.

Move away from animated?

Animateds overall structure is a given because of interpolation. It doesn't know what interpolates from what before rendering and figures it out runtime. I believe that makes for most of the structural decisions. In a declarative world we can know precisely which interpolator interpolates from which parent interpolator and so on. So maybe it could be a good idea to move away from animated eventually and write a leaner foundation more suitable for declarative purposes. This would be the end for the imperative api we still offer, though.

Move parallax out of this lib?

Mixed thoughts about this one. If it were an add-on or a lib with a dependency on RS, then we would be closer to do-one-thing-well ideals.

jbovenschen commented 6 years ago

First of all thank you for all the effort you put into this library.

I mostly am (surprised?) by "Move away from animated?". What I am curious about is is your opinion of reanimated. Is it an idea to use this library instead of the animated library?

It would solve the following issues you did point out;

More declarative API for writing animations.
Possibility to add another spring implementation
Ability to add your own interpolators.
The native implementation would run all 'native'.

What I am curious about is the following; "It doesn't know what interpolates from what before rendering and figures it out runtime" What do you mean by this exactly would you like to pre generate the whole animation before it runs?

drcmda commented 6 years ago

I think these points are fulfilled. RS is 100% declarative, spring implementations can be exchanged with the impl prop, you can run your own interpolators, and "native" is dependent on the target but it usually means outside of react most of the time.

The problem with animated is the complex parent-child interaction. You have a value that animates into an interpolator, which drives another and so on ... but it can't know the full graph because it functions imperatively and therefore calculates that graph runtime, which costs time. I've already optimized it here, but the whole structural overhead remains. I think i could cut the libs size in half if the foundation is rewritten.

As for reanimated, i think it is still mostly imperative, as in: you wire up a view, then drive it from outside as opposed to: the view is a function of state as usual in react. Bringing animated closer to react-motion was one of the initial goals.

jlarmstrongiv commented 6 years ago

Might as well throw in my two cents 😉

I do like having parallax in the library. I understand the do-one-thing-well approach, but I think parallax is an important part of an animation library.

I‘m all for a leaner API. I think an up-to-date and comprehensive documentation that is all in one place would be a nice priority too 😄

EDIT: I checked http://react-spring.surge.sh/ again, and it looks like a lot more content has been added to it. Looking forward to reading it 🎉

montogeek commented 6 years ago

I should help you updating all demos to latest version, will try to find some space this week.

drcmda commented 6 years ago

New branch: https://github.com/drcmda/react-spring/tree/6.x is almost functional

iammarkps commented 6 years ago

IMO, Multiple packages within this repo is very good ideas.

pmndrs / react-spring