Hi, I'm the author of the second library you mentioned. It's natural to represent easing functions as, well, functions.
One way to avoid this would be to change (or supplement) elm-community/easing-functions <https://github.com/elm-community/easing-functions> to contain a big union type of all the easings possible. Then we could have a function that turns that type into an easing function. The animation models would contain a reference to this EasingDescription rather than the function itself. There are some major downsides to this approach, not counting the work involved and library clutter. First, consumers of the animation library will have to know about the EasingDescription; it couples the two libraries and causes the abstraction to leak. Second, animations will only be able to use easing functions that have descriptions, not any easing function they like. Finally, my library allows animations to be undone or retargeted, which involves working with the easing function in ways beyond the description. So, a better approach might be to sample the easing function provided (perhaps 100 times in 0..1) and use linear interpolation between these samples. Many samples gives a more accurate animation but consumes more memory. This approach also means that retrieving an easing function from an animation will be inexact. Even so, until someone tells me that everything will explode if you have functions in your model, I'm going to sit tight. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
