Use native SpringAnimation implementation for each platform

[swabbass]

🚀 Feature

See issue : #7044

Have you read the Contributing Guidelines on issues?

yes

Motivation

Today SpringInterpolator is based on third party calculations for spring force, which did not work, has "jumps" in animations for different spring configuration.

Pitch

Use the native SpringAnimation implementation for each platform and write a unique SpringInterpolator that has the platform native SpringAnimation implementation in the implementation.

The platform might include such an interpolator, no need to write one,

• Change the JS API to support platform terminology on the native side (options-parser).
• On the native side, we might use one SpringInterpolator in order to achieve other interpolators through the config, like linear, overshoot, accelerate, etc.
• Preset like configurations.
• Less code.
• Support a wide range of interpolations easily via a simple config of the animation.

@guyca wdyt?

[mrousavy]

we probably have to find some sort of mapping convention so the user can adjust the spring with custom defined values (such as "springiness", and not lower level values such as mass, stiffness, damping), because the spring animation is not timing-based, meaning we have to calculate spring config based on animation duration (and possibly user defined "springiness" value).

[swabbass]

@mrousavy I agree with that, we might create our predefined presets as "springiness", keeping in mind the old interpolators can remain as part of the presets, which might include {"linear", "bounce", "decelerate", ... etc.}

Since soon we will have v8, we might introduce a breaking change, in the animation API, we can change it accordingly.

BUT, if we want to support this before we have to do actual options mapping, I think it is a good idea to have the native side expose the new API always, and in the js OptionsProcessor we can fetch our predefined presents from the native module constants, and use them for keeping old code running, via transformation, and introduce a new API.

About whether or not we have the capacity to do that internally, we need to check this out with @yogevbd :].