You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 14, 2020. It is now read-only.
Currently when animating an exiting component it ends up cloning the target element to keep it around for the duration of the motion (see FocalConcealMove).
This works - but leads to weird behaviour - and more importantly isn't as performant. Until there is an official solution (or we can wrangle trying to use React Suspense cleverly) - let's introduce a component to persist the element for the duration of the motion.
As a benefit we also no longer need to write explicit motions just for exit animation.
An API could look like (with react router):
<Routepath="/details/:id">{({ match })=>(<MotionPersistence>{match&&(// Somewhere inside the route there would be a motion. It more than likely won't be top level though.<div><Motion>{motion=><div{...motion}/>}</Motion></div>)}</MotionPersistence>)}</Route>
Note: Currently the Motion component has an in prop. We could also do something with that perhaps. Historically the in prop was always used for an element which never left the DOM. And generally from a list view (that persists behind some content) to a details view (which is loaded in/out on demand).
<Routepath="/details/:id">{({ match })=>(<Motionin={match}>{motion=><div{...motion}/>}</Motion>)}</Route>
However that would also mean introducing more kB into the primary Motion component. And mixing logic. But the API is a little simpler...
Both API's should enable persisting the element when being removed from the DOM over the duration of the motion.
Then there is the problem of applying motion. Currently exiting elements are the origin and the entering elements are the destination - whereby in the motion components you would setChildProps() to apply some styles... to the destination... hopefully you're seeing the problem.
We want to setChildProps() on the origin element. How do?
We also want to know when the motion is finished. In the current world the destination motion is the one that will do the actual triggering.
The text was updated successfully, but these errors were encountered:
Currently when animating an exiting component it ends up cloning the target element to keep it around for the duration of the motion (see FocalConcealMove).
This works - but leads to weird behaviour - and more importantly isn't as performant. Until there is an official solution (or we can wrangle trying to use React Suspense cleverly) - let's introduce a component to persist the element for the duration of the motion.
As a benefit we also no longer need to write explicit motions just for exit animation.
An API could look like (with react router):
Note: Currently the Motion component has an
in
prop. We could also do something with that perhaps. Historically thein
prop was always used for an element which never left the DOM. And generally from a list view (that persists behind some content) to a details view (which is loaded in/out on demand).However that would also mean introducing more
kB
into the primary Motion component. And mixing logic. But the API is a little simpler...Both API's should enable persisting the element when being removed from the DOM over the duration of the motion.
Then there is the problem of applying motion. Currently exiting elements are the
origin
and the entering elements are thedestination
- whereby in the motion components you wouldsetChildProps()
to apply some styles... to thedestination
... hopefully you're seeing the problem.We want to
setChildProps()
on theorigin
element. How do?We also want to know when the motion is finished. In the current world the
destination
motion is the one that will do the actual triggering.The text was updated successfully, but these errors were encountered: