Refactor transition-group to use per-element state machines #474
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WIP
This PR is an effort to resolve Issue #466 by taking the best of both worlds from
transition-group
andpresence
As mentioned in #466
presence
primarily works by deriving element appearance from transition state. However, it is missing:In opposition,
transition-group
works by attaching callbacks to elements that have already rendered. It is lacking:This PR resolves these differences by introducing the
TransitionItemContext
type, an instance of which holds the transition state for each element in a list.createListTransition
now returns an array of tuples:[T, TransitionItemContext]
. The user can useTransitionItemContext
to register transition events or track the transition state independently for each element.Currently only
createListTransition
has been modified. If this PR goes over well I will extend the functionality tocreateTransition
as well.This also has the added benefit of removing from jank from the playground's transitions.
Old:
Screen.Recording.2023-07-18.at.4.26.14.PM.mov
New:
Screen.Recording.2023-07-18.at.4.01.44.PM.mov