Shared element transitions

[brentvatne]

This is a very common pattern in Android apps. @lintonye made a heroic effort in react-navigation/react-navigation#941 to implement this, but it's out of date and to land new significant features now, we need to go through the RFC process. This is a good place to discuss before taking it into a formal RFC.

[dantman]

Specifically rather than being an Android thing, this is a Material Design thing. Material Design is just the preferred design for apps on Android and is used by most of the system apps. So this goes beyond just Android, it's also used anywhere else you might want Material Design.

[janicduplessis]

This is really hard to make things smooth with the current RN primitives, especially on iOS since the Image component tends to flicker. I worked on a snapshot API a while back to allow creating a copy of a view using platform primitives so it is performant. Implementation is Android only currently: janicduplessis/react-native@5284d89.

I think if we want production quality shared element transitions we will need to upstream something like this in RN.

[ericvicenti]

Personally I think that RN primitives should be robust enough to implement SET. If they aren't, we can fix them. Problems like the iOS Image flicker need to get fixed for so many reasons, not just navigation.

There may be cases where a new native API could be exposed to optimize performance. For example, native reparenting would be extremely valuable for this use case. But native reparenting may come in handy for other reasons, so I don't think it necessarily makes sense to implement SET in RN core. Also, the RN team is trying to make core lighter right now, so a heavy feature would probably get a lot of pushback.

[lintonye]

I wouldn't have the bandwidth to create an RFC in the next few months. However, I want to chime in quickly in case if someone wants to get started soon.

I think it makes more sense to start with a more generic custom transition API, and then use that API to implement SET, compared to the other way around.

Since SET is a really common use case, we'd want a simplified API for it, but under the hood, it'd be useful to be based on a generic transition framework which can do a lot more, such as disabling transition altogether.

The feedback to my previous effort on the generic API (#175) has been that it was too complicated and difficult to use. I think the first step would be to put together a better API proposal.

[chrfalch]

I just published a project as an add-on to React Navigation supporting shared element transitions and regular transitions when navigating. Not an update to the RFC, only my 2 cents on an implementation.

Creds to @lintonye for his initial work.

Github:
https://github.com/fram-x/FluidTransitions/

Medium Article:
https://medium.com/@christian.falch/fluid-transitions-with-react-navigation-a049d2f71494

@brentvatne @ericvicenti

[freysie]

Whoa, this sounds awesome, @chrfalch! 😄 I’m going to try out your add-on later today. The Transition component looks like a nice, succinct way of handling this.

[brentvatne]

nice work @chrfalch! I'll have to read this over more carefully later but I love the API!

[narendrashetty]

I like the API suggested by @chrfalch.

To summarize what I know, we need to depend on useNativeDriver for a smooth 60fps animation and for that we can only animate non layout properties. Considering that we need to think about how we animate for Text which needs to change from one size to another and also Image with different aspect ratio.

To get started, I see a beta version which is only for position and scaling.

What do you think?

PS: I would love to contribute for this RFC and api :)

[chrfalch]

@narendrashetty A new version is already in the works with support for non-native animations for properties like width/height, background color etc.

[narendrashetty]

@chrfalch Nice! Are you using useNativeDriver with it?

[chrfalch]

I'm using a little trick where the native driver drivers a non-native animation through an Animated.event ;-) My hope is that we can use a combination to achieve both performance and great looking results.

[narendrashetty]

Interesting! I should dig into your code

[narendrashetty]

@chrfalch I have gone through the implementation and it's really clever but I am afraid that would not work :(.
Was not sure if my findings are useful for everyone here, so I have created an issue in your repo. (fram-x/FluidTransitions#5).

If we think it's fine to discuss here about it, I am happy to continue.

[narendrashetty]

I was also thinking, since it's not possible for layout properties with native driver, is it realistic to build an addon which works with layout properties too. Just thinking out loud. @brentvatne @ericvicenti

[jrwpatterson]

Is anybody still looking at this as fluid transitions doesn't play nice with tab navigation I would like it just supported as a first class citizen???

[chrfalch]

Fluid Transitions does not support the Tab Router. A new version in the making will probably support both Stacks and Tabs.

[jrwpatterson]

Do you know when that will be we go live in production in July?

[chrfalch]

Don't think it would be ready that soon for production. Sorry.