Two goals for this:

1. Introduce new animations and make a suite of good looking examples, taking inspiration from https://material.io/design/motion
2. Make internal changes if needed for more advanced animations

Move

• Disable scale via prop
• Investigate API to make multi-element animations easier
• Scale inverse via prop or component
• Move expand example

Focal reveal move

• FocalRevealMove animation
• FocalConcealMove animation
• FocalTarget util
• Email threads example
• Contact cards example

Arc move

• Arc move example #92
• Introduce API for a reveal arc move
• Reveal arc move example
• Reveal arc move example 2

Fixed focal cross fade

• Introduce API to reveal cross fade contents but move focal target
• Video example
• Video grid example

Loose focal cross fade

• Cross fade reveal with focal element example

Fixed cross fade

• Add ability to disable scaling when move from origin
• Investigate if we need a new API to cross fade reveal
• Cross fade reveal example (Slow-mo here)
• Cross fade example
• Cross fade reveal example

Material expanding

• https://twitter.com/i/status/1132899285480042496

Reshaping container

• Add move motion to child elements

Notes

Material motion repo is gold for some animations https://github.com/material-motion/material-motion-swift !

Depending on the CSS of the child we need to override some styles so it looks correct.

This could be as simple as providing a hook for consumers to pass in extra styles on transition, or as complicated as automatically setting style values dependent on already set styles.

Devils advocate: Maybe it's ok to force consumers to style their elements a particular way?

This would be a win for DRY code, and for creating new transitions. Would mean we don't have to worry about ensuring they're all done correctly.

We already precalculate from node. But only expand and move transitions use them.

This will have to be specific to the implementing view.

So for React we'd try and use TransitionGroup and piggy back on the transition hooks it adds.

• Setup travis yml
• Write publish script that calls out to lerna during publish script step
• Setup bundle to not include externals (react)
• Get rid of unneeded files in package
• Update changelog on npm version

Which results in the previous animations element(s) still being visible, so you can see it above the expander, for example.

Fadeout or (un)reveal, probably.

Currently it uses componentWillMount hook to register its listener before anyone else. This is because it needs to be told when the show itself. We need to figure out how to add all listeners before they're notified on mount.

I tried allowing the listener to be notified post initial set, but it broke things.

It should be moved into the core library.

These styles seem to affect it:

• Using positional styles (top/left/etc)
• Using padding (actually this is fine. padding shouldn't be used in place of a margin. point this out in docs?)

• Add typescript support
• Support react only
• Rip out core library
• Swipe animation
• Remake examples in react-next module
• Support drag and drop patterns (ala google image search mobile) (supported via in prop)
• Support imperative method of triggering animations (not needed anymore)
• Support destination node already existing when source node unmounts (implemented with prop in)
• Work around current limitation of in prop where series of events matters to ensure we have the stored data.
• Transition aborting
• Cross browser support regression test (ie11, latest 1 version)
• NPM deployment
• Readme

I.e. we can start both the from and to nodes at the from location, transition them to the to location, half way through fade in to node clone and fadeout from node clone.

Also: #30

Obviously we don't want to handle this - but it's a good pattern to use to keep transitions nice and fluid.

E.g. Scroll down to and click an item on items page, transition to details page, close details page, initial scroll position from items page should be set again.

Potentially we could just pass props down to the children, but it would require some extra work from consumers if they nest a custom component (need to pass the props + ref down).

Caveats:

• We pass ref down. We'd have to handle both native and custom components (ref for native, refFunc for custom, since you can't set ref to custom directly)
• We pass style down. Consumers would be slightly inconvenienced if they too use style (need to merge them)

Instead of moving in a straight line they could curve to their destination, this would be opt in only as it would be a more expensive animation.

Since we'll eventually be introducing other types of movement (FlipMove), would be great if we renamed Move to something more explicit.

CloneMove?
CrossFadeMove?

First step would be to rename in docs and add a new export.
Second step (breaking change) would be to remove the old export.

Atm it's quite cumbersome to start a new animation, it requires the developer to manually create their own react instance and then mount in the DOM themselves in the animation hooks.

Wouldn't it be nice if we had some way of doing this generically, instead of each animation doing it themselves?

Obviously we don't want to handle this - but it's a good pattern to use to keep transitions nice and fluid.

E.g. Scroll down to and click an item on items page, transition to details page, close details page, initial scroll position from items page should be set again.

Fixed position will be important if we want to be able to transition between routes and support immediately scroll to top on the incoming page.

This will enable nice transitions at the cost of having to disable the user from scrolling, else the illusion will be broken.

Do the same for reveal

E.g list of things that can all transition if clicked on.

This results in the position potentially being incorrect if the user resizes or scrolls in the viewport.

One work around ATM is to put the freshly "mounted" match after the "in" baba component, so by series of events the fresh mounted one has its lifecycle events triggered after the "in".

Each transition should be able to either

• Wait for the previous transition
• Have a delay of x

• How this works
• Better examples
• Use cases for the library

Two things come to mind:

1. "Prewarm" the animations by deferring the "start" for 1~n frames (see: android examples of doing just this)
2. Use css will-change

This is linked with #14

Need to update the animation definition to use {num}px instead of num

This would be trading off versatility for performance (probably).

See:
https://github.com/joshwcomeau/react-flip-move
https://github.com/aholachek/react-flip-toolkit

For some inspiration.

Quick refresher of how it would work:

• Get position difference of start/end elements
• Apply difference to end element via transform immediately
• Next animation frame remove the transform, watch it animate into place

👌 👌 👌

This will be about as performant as we can make it, but will make other things slightly harder (hiding content around element, cross fade elements, etc).

This is already started.

Main thing todo will be to change the animation prop to pass in a function instead of the name of the animation.

Problems

• If a component changes size on mount and we are transitioning to it, we currently transition to the initial state of the animation, not the end. So for example we might transition to a smaller version of the target. I think we can solve this by using offsetHeight and offsetWidth instead of element.getBoundingClientRect() when calculating the to element.
• When a yubaba animation is happening, we'd want to delay the on mount animations for a little bit. Maybe.

Essentially this is to support "cancelling" animations.

However - this isn't a true cancel. It's basically creating a new animation with the from element being the inflight element, and the to element being the freshly mounted target.

Atm transitions are starting at the start point then applying the transforms.

To get some gainz we can flip it, and start at the destination, apply transforms to get back to the start point, and then remove the transforms to start the transition. This will result in more performance animations.

However, we are using the web animations api. Can FLIP even work in this scenario?