[RFC] Universal animation component library

[nandorojo]

This issue is more of a RFC.

What

There is an opportunity to make something like react-native-animatable that is powered by Reanimated 2.x. I think it would follow an API similar to CSS transitions. I'm looking to framer/motion for inspiration on that, since it's super clean and easy to use.

How

My top priority would be to achieve transitions at the component level, without any hooks, and with the least amount of code. It should be as simple as possible – no config. This seems like a great DX:

const color = loading ? 'blue' : 'green'

<Text transitionProperty={'color'} sx={{ color }}/>

Under the hood, it would only use reanimated on native. Components would intelligently transition properties you tell it to. I don't have experience with Reanimated 2 yet, but it seems like they provide hooks that would make this remarkably doable. We could even default components to have transitionProperty: all, such that all you have to write is this:

const color = loading ? 'blue' : 'green'

<Text sx={{ color }}/>

...and you get smooth transitions. Not sure if that's desired, but just spit balling.

We could use CSS transitions and keyframes on web, since RNW supports that. I'm not married to a specific method of solving this problem, though, so maybe Reanimated will work on web too.

In addition to property transitions, animations would be great:

<View from={{ opacity: 1 }} to={{ opacity: 0 }} />

Today

With react native web, CSS animations are really straightforward:

const animationKeyframes = { from: { opacity: 0 }, to: { opacity: 1 } }
<View 
  sx={{ animationKeyframes }}
/>

Same goes with transitions:

const color = loading ? 'blue' : 'green'

<Text sx={{ color, transitionProperty: 'color' }}/>

The problem is that this code is not universal. It only works on web. In my opinion, using Platform.select or Platform.OS === 'web' is an anti-pattern when it comes to styles. That logic should all be handled by a low-level design system. Dripsy has made strides for responsive styles in this regard. Smooth transitions with a similar DX would be a big addition.

Final point: good defaults

In the spirit of zero configuration, this library should have great defaults. It should know the right amount of time for the ideal transition in milliseconds. I would look to well-designed websites to see what the best kind of easing function is, and this would be the default.

There is a plethora of "unopinionated" animation projects for React Native. There are few that are dead-simple, highly-performant, and have professional presets from the get go. I don't want to create an animation library. Only a small component library that animates what you want, smoothly, without any setup.

[nandorojo]

There has been discussion about native support from Framer Motion: motiondivision/motion#180

I'm not aiming to recreate every feature they have. Only the simple parts. This needs to solve 80% of the problems, not all of them.

[cmaycumber]

This would honestly be awesome.

Reanimated v2 in of itself is a leaps and bounds improvement API over the API in v1 imo.

What do you would be the most important features to knock out right out of the gate?

[nandorojo]

Reanimated v2 in of itself is a leaps and bounds improvement API over the API in v1 imo.

Agreed, I found v1 almost unusable.

What do you would be the most important features to knock out right out of the gate?

I'm torn between animations and transitions, but I think simple style transitions would be the most important at first.

Expo + Next.js is an incredible stack. And yet, achieving this is a hassle:

const color = loading ? 'blue' : 'green'

<Text transitionProperties={['color']} sx={{ color }}/>

That doesn't make sense to me.

Doing this for responsive style arrays, and for function style props would be more difficult. I think that could be step 2.

Tracking if this variable changed to drive an animation is more of a challenge on native:

const color = loading ? 'blue' : 'green'

<Text transitionProperties={['color']} sx={{ color: [loading && 'blue', loading && 'green'] }}/>

On web, doing the above already works for me if I use the transitionProperty CSS key in sx.

---

I'm not sure if transitions or animations are more important, but I think transitions happen more often, and are currently a bit more difficult to drive on native. You can use Reanimated v1's Transition, which is actually pretty nice, but it requires you to imperatively call ref.current.animateNextTransition() which is annoying.

Another idea could be to use Reanimated's Transitioning.View component under the hood, and when a certain style prop changes, we could run a transition (on native) by calling ref.current.animateNextTransition(). The downside with this is you get less control over the style change, and it won't look consistent with web. Could still be worth playing with, though. If we went in this direction, we could rely on the useImperativeHandle hook to make sure we forward the refs down properly.

[nandorojo]

It’s possible that running the animations is an easier start than the transitions, I’ll look into both. I wonder if this should live separately from the core Dripsy package. It would maybe be nice if it did, but I’m not sure if that’s possible, since it might have to read in the internal styles after the sx prop has been parsed.

[cmaycumber]

I wonder if this should live separately from the core Dripsy package. It would maybe be nice if it did, but I’m not sure if that’s possible, since it might have to read in the internal styles after the sx prop has been parsed.

I was wondering the same thing. Maybe it's possible to somehow merge the base style property and sx when the animations are being applied. But that I'm not sure of. It does however make sense for the library to be separate I can definitely see people choosing to use this even if they don't use dripsy.

[nandorojo]

Maybe it makes the most sense for it to be its own package that dripsy uses under the hood. If you use dripsy, you get it out of the box, but otherwise you don’t have to.

This way, the animation lib is receiving the final parsed style objects from dripsy itself.

I’d have to think through how creating a themed component would work in that case. It could be messy if every lib just re-exports React Native in its entirety.

One argument in favor of including it in Dripsy (which I’m not stuck to) is that you could use it for only animated styles and not even know about anything else. If you don’t use responsive styles or a theme, dripsy works just like a normal RN element (or at least it should...)

[nandorojo]

Another thought here, the animated library would basically only need to export View and Text now that I think about it. And an HOC for making your own.

[nandorojo]

I just checked out the Framer Motion docs. Pretty crazy how simple this is: https://www.framer.com/api/motion/animate-shared-layout/

[cmaycumber]

That's pretty crazy. Some of those were relatively complex animations with just a few lines. I've never used framer personally but have definitely kept an eye on it.

If we could replicate something even close to that it would be super useful in RN.

[nandorojo]

Yeah...would be awesome. For now, even looping through object keys isn’t really supported in Reanimated 2, so I’m trying to put together a demo that can loop though each style change.

[nandorojo]

I put together an idea here: https://github.com/nandorojo/redrip

<View animate={{ width }} />

It takes an animate prop which acts essentially as a CSS transition for values that change. I haven't taken a stab at animations yet, such as from -> to keyframes.

[cmaycumber]

This is pretty sweet. I have some basic animations that might be able to use this on the app I'm working on I'll try it out.