docs(motion-presets): Motion Refresh / Presets RFC 2024

[saurabhdaware]

✨ Preview ✨

[github-actions]

✅ PR title follows Conventional Commits specification.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 0419b6c:

Sandbox	Source
razorpay/blade: basic	Configuration

[rzpcibot]

Bundle Size Report

No bundle size changes detected.

Generated by 🚫 dangerJS against 0419b6c

[chaitanyadeorukhkar]

Our goals should also tie in with design goals... evaluate libraries to see if something we want to do on design whether or not we can do it on dev. Good example you've added is morph animations... do we want to do morph now or later as per design?

[saurabhdaware]

Yup I've added morph and page transitions based on design expectations. We're doing morph now only.

Other things that are on design are simple opacity, slide, fade, etc transitions which are possible in every library

[chaitanyadeorukhkar]

Lets detail out the bundle size for framer motion. How will we load the core module only? In which cases will we need rest of the bundles?

[chaitanyadeorukhkar]

Try doing the morph animation with blade components?

[saurabhdaware]

Yup will do that POC with API decision now

[anuraghazra]

We should try to replicate the Switch animation and see how our primitives plays out.

Switch has a 2 stage animation

Click Hold (Elongate the circle) -> Release (De-elongate the circle + move to the opposite side)

Scale, transformX both will have to animate at once.

[chaitanyadeorukhkar]

Motion one seems super light-weight. What is the difficulty in implementing animations with it? Can you add an example of an animation with framer vs with motion one?

Since we will be exposing presets to our end consumers won't it make sense to use a light-weight library within blade and abstract out complex animations within the presets?

[saurabhdaware]

Will add more details here. Majority of things come from this article https://motion.dev/blog/should-i-use-framer-motion-or-motion-one (Find "Design goals" heading)

Overall its a low-level imperative API so requires us to call animate() function in vanilla JS and write react wrappers on top of it (which is something that we can do with CSS as well)

It lacks support for some important features like layout animations, page transitions, which we're expecting to do. So that will require custom implementation from scratch. It would've worked if we only had opacity, fade, transform transitions but we're doing more than that . If we implement such things from scratch, we'll anyway reach closer to framer-motion minified bundle.

There are projects like modular onboarding, frontend-website which are already using framer-motion and we have't seen load-time issues there. frontend-website had runtime laggy animation issues which are solved in their new update.

[kamleshchandnani]

can we add Cross Platform as a goal as well? even though we might implement it later but we need to evaluate for RN as well. Eg: Vanilla CSS might not work on RN and we might as well use a diff lib for RN like ReAnimated

[saurabhdaware]

I think I can add as a note for react native here. Not sure if it'll make sense to add it as a factor in the library comparison table because no web animation library really supports react native so the library exploration for web and native will be different.

I can add a note saying how we use react-native-reanimated already and some of these presets can be built there. I saw that react-native-reanimated already supports a good amount of these presets. So we can re-export some of these with similar API in future - https://docs.swmansion.com/react-native-reanimated/docs/layout-animations/entering-exiting-animations

[kamleshchandnani]

So I was wondering can we go more specific here and in presets instead of giving like Fade, Scale presets what if we form patterns like PageTransition, Toggle, etc.

pros: this way it will reduce the learning curve and confusion and also minimise random animations for similar things and move us towards our eventual goal of streamlining patterns

cons: We might have to export similar behaviors like Fade, Scale in different components, might be reptitive. This might also feel restrictive at first

[saurabhdaware]

Oh yes I was of similar opinion and I discussed this with design but what we realised is its valid case where card on some page might move up whereas card in some other page might fade in. We can't at one place define how section or component appears without knowing context.

From tech perspective I was also thinking of API like <Card animate> but in that case framer motion will always end up in bundle irrespective of whether animations are used or not since we'll have to define the node as motion node.

What I was also thinking is, once we have overall idea of animation patterns. Similar to how we have components and how we'll have patterns, we can have motion components and motion patterns (or incorporate motion in some our component patterns itself)

[saurabhdaware]

I added our discussion points and why we're going this way in open questions section along with conclusion

[kamleshchandnani]

Suggested change

	- We plan to target 1 project this quarter (Q2) to get motion adopted
	- We plan to target 1 project this quarter (Q3) to get motion adopted

??

[kamleshchandnani]

lets add how will we get this implemented on Figma for easing the hand-off as well here?

[saurabhdaware]

Yup I'll update it here. We're still figuring out the right approach. We discussed few things yesterday, RK will just confirm it once if things are working fine or not

[anuraghazra]

How do we pass duration tokens etc?

[saurabhdaware]

we can't. Which is why we have preset so that we can define durations and easing on preset level and make it consistent

[Rozamo]

define durations and easing on preset level

Do you mean when we define the tokens?

[saurabhdaware]

No like internally durations are defined for each preset. E.g Fade has certain given duration that cannot be changed on design as well

[anuraghazra]

Why do we need to define tap and inview triggers?

Consumers can do this on their end also like so:

const isInView = useIsInView()

<Fade isVisible={isInView} />

Also if we are supporting tap, then we need to support click handlers too?

[saurabhdaware]

I added all the triggers here which are natively supported by framer-motion so API is simpler

https://www.framer.com/motion/scroll-animations/#scroll-triggered-animations

Also if we are supporting tap, then we need to support click handlers too?

Nope. Click handlers can be added to children directly no if they support it? This is purely for animation component. It shouldn't be used to add any logic.

E.g. I can just add click handlers on children if needed for some logic

<Fade>
  <Card onClick={() => } />
</Fade>

[anuraghazra]

Will AnimateInteraction create a new div wrapper? or is this a enhancer component?

[saurabhdaware]

I had to create a div wrapper because something was not working. Lemme check again and see if it can be enhancer component

[anuraghazra]

Should we provide atleast the delay prop to every primitive?

So that consumers can choose to delay the animation run by x duration?

[saurabhdaware]

These props are not finalized. Only structure is. Will add props depending on discussion with design

[jaywalker21]

On the same note, should we have tokens for duration if we don't allow explicit values? Certain use cases might need animations to run for different times. I understand it won't be an issue for looped ones, but for non-looped ones, this will help

[saurabhdaware]

Atleast from design-side we're saying that the enter and exit durations should have same duration always. Do you know any usecase where a single duration won't work? we can also add this prop in future if usecase comes since this anyways won't be a breaking change then.

[anuraghazra]

Will consumer do this or we do this?

We will anyways have to use the framer-motion's provider right because blade components itself may also use the motion primitives.

But if we already have the provider and as a library we can't really do lazy import on our end then we don't really have choice other than to use the full framer motion right?

[saurabhdaware]

Consumer will do it. It will be required peer dependency.

We will use it in our components. Sort of like i18nify.