[Feature request] [Layout animations] Option to skip layout transitions, one-shot layout transitions

[mhoran]

Similar to #2513, I'm looking for an easier way to selectively disable layout transitions. For example, I'd like to animate the layout change of an input box when a button appears in the same row. I achieved this easily with React Native LayoutAnimation.configureNext previously. In moving to Reanimated, I've been able to recreate this behavior by reacting to the state change and swapping out the configured layout between LinearTransition and undefined. I've also added a withCallback to the animation which disables the animation once it has fired, effectively making it one-shot.

I could see extending LayoutAnimationConfig with a skipTransition argument. That takes care of half of the problem. Regarding one-shot animations, I have added a single withCallback to one of the animations that will fire, which sets the layout to undefined. I wonder if this should be pulled up higher, e.g. to the LayoutAnimationConfig or similar, to help with readability/discoverability.

[MatiPl01]

Hey @mhoran!
I raised the topic during our today internal meeting and we decided that this problem is very specific to your use case and we wouldn't want to add a possibility to skip the next layout transition via the LayoutAnimationConfig.

If you want to create one-shot layout transitions, you can use your approach with withCallback and useState and pass undefined when you no longer want to use a LayoutTransition. You can also write a custom wrapper component if you want to have a simpler and reusable implementation but it depends on your use case.

[mhoran]

Thanks @MatiPl01! Appreciate you bringing this forward for discussion.

I had tried to write a custom wrapper component using a SharedValue but it didn't work. I don't remember if it was only an issue on New Arch, but disabling the transition within the wrapper resulted in the layout getting "stuck". I'll give this another try and open up an issue if I can't get it to work.

[MatiPl01]

Thanks @MatiPl01! Appreciate you bringing this forward for discussion.

I had tried to write a custom wrapper component using a SharedValue but it didn't work. I don't remember if it was only an issue on New Arch, but disabling the transition within the wrapper resulted in the layout getting "stuck". I'll give this another try and open up an issue if I can't get it to work.

You likely won't be able to implement it with SharedValues because layout animations and transitions are tightly coupled with the react's rendering system. I thought that we may be able to implement a possibility to change the layout animation/transition state based on a SharedValue but, after talking about this idea with other teammates, I think that this might be very problematic, so we would prefer to stick to the current implementation in which you can configure layout transitions via component render with a different layout prop value.

[MatiPl01]

If you still feel that we should provide an easier way to disable or enable a layout transition, please describe your use case more in detail and we may reconsider adding something in the future.

[bglgwyng]

Ah, I see. I misunderstood your statement.

As I mentioned before, there is currently no other way to disable exiting animations after your view is mounted (rendered for the first time) with an exiting animation specified.

Then I think the situation is worse. However, I wasn't trying to achieve disabling layout animation dynamically by updating exiting props. Swipable example might be quite confusing, as it contains things irrelevant to layout animation.

Here I made a minimal example of configuring animation using a shared value. The core logic is here. You can run the example and see it work.

The reason I was asking how to describe null animation is that disabling animation is just achievable if I can replace SlideOutRight.build() in the example with NullAnimation.build(). I wanted to implement and show it work, but I couldn't find a way to define null-animation correctly.

Also, I don't think this approach is some kind of hack. I rather think it's the very natural implementation of configuring layout animation. I'd like to hear opinions on it.

[bglgwyng]

@MatiPl01 Did you raise this topic in the meeting? Please share any updates if you have.

[MatiPl01]

Hey @bglgwyng!

Sorry that I didn't reply. I raised the topic and we decided together that we won't add API to enable/disable layout animations without renders.

I have one note related to what I wrote here:

I think that what you are trying to do is to disable the exiting animation for views that have already been mounted (rendered for the first time). In general, this is not possible by replacing the exiting property by undefined as layout animations are configured when the view mounts.

This is a bug and we should be able to remove exiting animations by replacing them with undefined. Unfortunately, this still will require an additional render to change this prop.

[MatiPl01]

But I also asked if your SharedValue approach should work and it should be fine to use a SharedValue like this. I also tested if the following code works and everything seems to work fine, at least with latest beta of reanimated 4 with latest RN version.

Code snippet

import React, { useMemo, useState } from 'react';
import { Button, StyleSheet, View } from 'react-native';
import type { SharedValue } from 'react-native-reanimated';
import Animated, { useSharedValue, withTiming } from 'react-native-reanimated';

const exitingFactory = (enabled: SharedValue<boolean>) => () => {
  'worklet';
  if (!enabled.value) {
    return {
      animations: {},
      initialValues: {},
    };
  }

  const animations = {
    opacity: withTiming(0, { duration: 1000 }),
  };
  const initialValues = {
    opacity: 1,
  };
  return {
    animations,
    initialValues,
  };
};

export default function EmptyExample() {
  const enabled = useSharedValue(true);
  const [show, setShow] = useState(true);

  const exiting = useMemo(() => exitingFactory(enabled), [enabled]);

  return (
    <View style={styles.container}>
      <Button title="Toggle" onPress={() => setShow((prev) => !prev)} />
      <Button
        title="Toggle enabled"
        onPress={() => (enabled.value = !enabled.value)}
      />
      {show && <Animated.View style={styles.box} exiting={exiting} />}
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    alignItems: 'center',
    justifyContent: 'center',
  },
  box: {
    width: 100,
    height: 100,
    backgroundColor: 'red',
  },
});

Sorry for all the confusion about that but I didn't use such a hacky solution before.

Did you have problems with the exiting animation like this one?

[bglgwyng]

Thanks for considering my approach!
I believe this approach isn't a hack but rather an elegant solution.

I also suggest that helper functions like existingFactory would be better included in the Reanimated library and its documentation.
Alternatively, if I could get your confirmation that this won't cause any issues, I would feel more confident proceeding with this development direction.

The remaining challenge is how to handle null animations to disable the exiting animation. I haven't figured this out yet. Is it possible to achieve this with the current interface, or would we need to modify the interface?