Generalizing the easing timing function?

[@greweb]

Hi,

I don't think you remember me but we quickly met on React Europe but we didn't talk much, there was lot of people ;)

Anyway..

I'm the author of bezier-easing that solves a simple problem: implementing the cubic bezier easing in JavaScript (like the one available in CSS Transitions).
It basically would allow react-tween-state to move from a limited set of primitive easings to infinite number of (cubic) easings.

That's quite simple to use:

var easing = BezierEasing(0, 0, 1, 0.5);
console.log(easing.get(0.5)); // 0.3125

I really like the idea to make bricks out of micro libraries :) Because every tiny library can focus on performance (which is the case of bezier-easing, it is based on efficient firefox implementation).

Do you think this could make sense to generalise the easing part of react-tween-state with that approach?

Thanks

PS: This micro library is being used by Apple.com for a few years as part of their animation library in product pages, and is also used in velocity.js.

[Cheng Lou]

Hey! The easing function has always been pluggable, see this section: https://github.com/chenglou/react-tween-state#thistweenstatepath-string--arraystring-configuration-object

Does this answer your question?

[@greweb]

Ok, so the idea is to use easing functions externally?

like

this.tweenState("...", { easing: (x) => x*x })

To my mind there are 2 kind of library approaches:
(1) the framework approaches: it compose all the micro libs so you have a nice API that covers all use-cases.
(2) the micro lib approach: libs are not embed but users are free (and required) to use external libraries if they need extra features.

In your current approach, it is not clear if you want to be (1) or (2).
IMHO, being somewhere in the middle does not feel beautiful and consistent to me and you tends to not solve all features with the best solution.

This feel inconsistent that you depends on predefined easing functions (tween-functions) while you indicated me they are pluggable.
Why not either, integrating bezier-easing (that generalize them) OR letting the user completely decide about what easing library to use?

Thanks

[Cheng Lou]

(Just checked your profile, yeah I remember you!)

Because if I don't expose sensible defaults, you end up passing 7 configuration params when you want to simply tween from a number to another. And 90% of the time that's what people do: they just want to tween a number. This point has nothing to do with the whole library vs framework debate. If I actually expose stackBehavior for extra pluggability while providing the same current default, does that suddenly make tween-state a framework instead of a library? =)

(And the alternative of exposing a side-effectful method to inject defaults makes things more complicated. Overridability and future API bloat, etc.)

But while we're on the point, literally including an external library (I intentionally pulled out tween-functions to avoid this debate) doesn't make tween-state a framework. The method of composition doesn't imply you necessarily need to consider every piece of code as a graph. A tree (where you include a dependency, wrap around it and re-expose a modified version) counts too.

Last point on this matter: the whole thing really isn't black and white. If I go and ask the tween-state users their usage of the library, I'm positive 50% will tell me they don't care about the tweens and the rest will tell me they plug in their own easing functions. Exposing defaults (external and pluggable ones too!) is the best tradeoff to make here imo. If that indeed makes the 5% power-users feel this is less beautiful, then so be it.

I'll close this issue (no hard feelings) because I'm very afraid of meta-debates in the JS community, particularly this issue. But I guess the least I can do is to warn you that I will most likely be taking the same approach in the future with react-animation: finish iterating on it, publish the library, and gradually expose some pluggable parts if there are demands. There's no way I'm bloating it up into a framework, but there's also no way I'll ask users to obligatorily provide their own Decay/Gravity equations.

[@greweb]

OK makes sense.
Thanks a lot for the detailed answers :-)
Le 4 juil. 2015 18:35, "Cheng Lou" [e-mail] a écrit :

(Just checked your profile, yeah I remember you!)

Because if I don't expose sensible defaults, you end up passing 7
configuration params when you want to simply tween from a number to
another. And 90% of the time that's what people do: they just want to
tween a number. This point has nothing to do with the whole library vs
framework debate. If I actually expose stackBehavior for extra
pluggability while providing the same current default, does that suddenly
make tween-state a framework instead of a library? =)

(And the alternative of exposing a side-effectful method to inject
defaults makes things more complicated. Overridability and future API
bloat, etc.)

But while we're on the point, literally including an external library (I
intentionally pulled out tween-functions to avoid this debate) doesn't make
tween-state a framework. The method of composition doesn't imply you
necessarily need to consider every piece of code as a graph. A tree (where
you include a dependency, wrap around it and re-expose a modified version)
counts too.

Last point on this matter: the whole thing really isn't black and white.
If I go and ask the tween-state users their usage of the library, I'm
positive 50% will tell me they don't care about the tweens and the rest
will tell me they plug in their own easing functions. Exposing defaults
(external and pluggable ones too!) is the best tradeoff to make here imo.
If that indeed makes the 5% power-users feel this is less beautiful, then
so be it.

I'll close this issue (no hard feelings) because I'm very afraid of
meta-debates in the JS community, particularly this issue. But I guess the
least I can do is to warn you that I will most likely be taking the same
approach in the future with react-animation
https://github.com/chenglou/react-animation: finish iterating on it,
publish the library, and gradually expose some pluggable parts if there are
demands. There's no way I'm bloating it up into a framework, but there's
also no way I'll ask users to obligatorily provide their own Decay/Gravity
equations.

—
Reply to this email directly or view it on GitHub
#40 (comment)
.

[Cheng Lou]

Np! Btw, keep the comments coming for the new library too =)