Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract easing definitions from MotionProperty & Target #502

Open
zsoltk opened this issue Jun 29, 2023 · 0 comments
Open

Extract easing definitions from MotionProperty & Target #502

zsoltk opened this issue Jun 29, 2023 · 0 comments
Labels
appyx-interactions complexity: medium enhancement New feature or request P2 priority: standard
Milestone

Comments

@zsoltk
Copy link
Contributor

zsoltk commented Jun 29, 2023

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
}
@zsoltk zsoltk added enhancement New feature or request appyx-interactions P2 priority: standard complexity: medium labels Jun 29, 2023
@zsoltk zsoltk added this to the 2.0 milestone Jun 29, 2023
@zsoltk zsoltk modified the milestones: 2.0, 2.1 Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
appyx-interactions complexity: medium enhancement New feature or request P2 priority: standard
Projects
None yet
Development

No branches or pull requests

1 participant