Skip to content

Extract easing definitions from MotionProperty & Target #502

@zsoltk

Description

@zsoltk

We should separate these concerns, both because a Target value is cleaner without an easing attached to it, and also because we might want to go to that target with different easings per occasion.

Idea for the API, this could be a mapping in the MotionController:

override val easing = {
    uiStateA to uiStateB using LinearEasing
    uiStateC to uiStateB using FastOutSlowInEasing
}

This mapping could be read in BaseMotionController before passing it to the relevant MutableUiState object to use.

A difficulty I can see is with TargetUiState instances that are not held in a val but created by some fun with some dynamic parameter. So we need to figure out a way how to match them against the mapping.

Another, more complex case is if the individual MotionProperties need to have a different easing, then the above API would not suffice. In that case instead of an Easing instance we could have a 2nd class generated from TargetUiState so that it has all the corresponding field names:

private val generatedEasing1 = UiStateEasing(
  field1 = LinearEasing,
  field2 = FastOutSlowInEasing,
  // ...
)

override val easing = {
    uiStateA to uiStateB using generatedEasing1
    uiStateC to uiStateB using generatedEasing2
}

With this second approach we can also generate a simple enough constructor so that not all fields needed to be defined in every case:

override val easing = {
    uiStateA to uiStateB using generatedEasing1
    uiStateC to uiStateB using UiStateEasing(LinearEasing) // <-- should apply LinearEasing to all fields internally
}

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions