Skip to content

Our current animation architecture is prone to conflicts #234

@mttwc

Description

@mttwc

Imagine our UI is like a tree. Let's say some component in the tree wants to animate height, and one of its descendents also wants to animate height, our animators would get into a race condition where the first next-height computation would not account for where subsequent animators will animate to, and will end up animating to the wrong height. This will apply to any css property that involve some sort of 'next-value' computation, e.g., height, width.

The problem lies in the fact that Mithril is kicking off all animations at roughly the same time, meaning each animation's computations will only account for the UI at that given moment (i.e., it cannot see into the future). If we want to do more 'complicated' animations in the future, we need to rearchitect how we do animations, and ideally not reinvent the wheel. This will take a fair bit of effort.

http://velocityjs.org/#uiPack is a consideration. It allows us to chain together animations in a sequential or parallel manner, however, this now means that we likely need to declare all animations in some high-level area that has knowledge of all its children in order to sequence them correctly. It seems like we can no longer have low-level components that handle its own animations without knowledge of its parents, as that's where all the conflicts come from.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions