How can I ensure updates to shared values are applied on the JS thread?

[bglgwyng]

I'm writing logic like this:

<Pressable
  onPress={() => {
    sv.value = 1;
    setState(true);
  }}
/>
// ...

return state && <Foo sv={sv} />;

This updates the shared value on the JS thread and triggers a re-render of the component on the UI thread.

However, Foo isn't rendered with the updated value of sv. So, I tried waiting for the next frame before updating the state:

onPress={() => {
  sv.value = 1;
  requestAnimationFrame(() => {
    setState(true);
  });
}}

This partially solves the problem, but it's not perfect—Foo is still sometimes rendered with the old value of sv.

What is the best way to solve this?
Is there any function or recommended approach to ensure that updates to shared values are applied on the JS thread before the next render?

[MatiPl01]

Hey @bglgwyng!

Can you show me how you access the sv SharedValue in the Foo component?

You have to keep in mind that updates of SharedValues aren't performed at the same time as React renders so you might not get the new value when the component renders. To properly use SharedValues, you need reanimated hooks like useDerivedValue, useAnimatedReaction, etc.

[MatiPl01]

I agree that passing a shared value as props is a bit uncommon

I didn't mean that this is wrong. I thought that you are trying to read the sv.value on the JS thread, but you use useAnimatedStyle, so everything looks correct in your code. Passing SharedValues via props is a common and valid approach.

[MatiPl01]

Coming back to the original problem (without the requestAnimationFrame workaround), I can say that I tried to create a repro of this issue and everything looks fine (at least on the simple reproduction example).

Repro code

import React, { useState } from 'react';
import { Pressable, StyleSheet } from 'react-native';
import type { SharedValue } from 'react-native-reanimated';
import Animated, {
  useAnimatedStyle,
  useSharedValue,
} from 'react-native-reanimated';

interface FooProps {
  sv: SharedValue<number>;
}

const Foo = ({ sv }: FooProps) => {
  const animatedStyle = useAnimatedStyle(() => {
    console.log('sv.value', sv.value);
    return {
      height: (sv.value + 1) * 100,
      width: (2 - sv.value) * 100,
    };
  });
  return <Animated.View style={[styles.box, animatedStyle]} />;
};

export default function EmptyExample() {
  const [state, setState] = useState(false);
  const sv = useSharedValue(0);

  return (
    <Pressable
      style={styles.container}
      onPress={() => {
        if (state) {
          setState(false);
          sv.value = 0;
        } else {
          sv.value = 1;
          setState(true);
        }
      }}>
      {state && <Foo sv={sv} />}
    </Pressable>
  );
}

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

Did you notice the issue on such a simple case or you had some expensive computation running in your app at the same time? I wonder why this doesn't work, especially because you read it on the UI thread (in the useAnimatedStyle hook), so you should get the latest value instead of the old one.

The only thing that comes to my mind is trying to wrap the sv.value = 1; line with the runOnUI callback to ensure that this update is scheduled on the UI thread before you are trying to read the value. It should work without this change but you may try and let me know if it changes anything:

onPress={() => {
  runOnUI(() => {
    sv.value = 1;
  })();
  setState(true);
}}

[bglgwyng]

Oh I'm sorry I didn't tell the detail you mentioned. The problem is not easily reproduced with the code I provided. I experienced this in my product often but not in the small reproducer. I suppose that some expensive computations are related.

And I just tested runOnUI approach, however it didn't work well. It's far less effective than requestAnimationFrame approach, although that is another workaround.

Indeed, I posted a very similar issue #4446 in the past. In the both cases, the problem is the absence(maybe?) of a reliable way to sink the updates between UI/JS threads.

[MatiPl01]

Good, thanks for explanation.

Since the problem is not reproducible in the small example but appears in the app code, I suspect one more thing here. This is related to how reanimated works. It batches all animated styles changes and commits them once per animation frame, but, if the React render is heavy, changes from reanimated might be much delayed, after React successfully commits its changes.

There is not an easy workaround for this case and using requestAnimationFrame, timeouts, etc. won't work here.

Possible solution

You can try using the onLayout to check if the proper height was applied before making the view visible. This is a tricky way but I used something similar before to determine if the animated style was applied to the view.

const Foo = (props) => {
  const visible = useSharedValue(false);
  const { sv } = props;

  const animatedStyle = useAnimatedStyle(() => ({
    height: sv.value,
    opacity: visible.value ? 1 : 0,
  }));

  return (
    <Animated.View
      style={animatedStyle}
      onLayout={({ nativeEvent: { layout } }) => {
        if (layout.height > 0) { // or other check here to ensure that the height was applied
          visible.value = true;
        }
      }}
    />
  );
};

Let me know if this helps! I know this is a bit tricky.

[bglgwyng]

Thanks! Your answer let me stop looking for the perfect solution, which is better than wasting more time on it.
I have one more question. Is it possible to provide a function that can be used to sync JS/UI that I was looking for? Is there already one for internal usage, or isn't there?

[MatiPl01]

In general, runOnUI (called from the JS thread) and runOnJS (called from the UI thread) are used to sync threads. For example, if yo want to read the correct value updated on the UI thread from the SharedValue, you can use runOnUI, which will ensure that the value is up to date.

Consider these 2 examples with the modifyValue called from the JS thread:

• invalid usage without synchronization:

const modifyValue = (sv: SharedValue<number>) => {
  sv.value = 1;
  console.log(sv.value); // this will return 0 as the value was updated on UI but not on the JS side
}

• with synchronization:

const modifyValue = (sv: SharedValue<number>) => {
  sv.value = 1;
  runOnUI(() => {
    console.log(sv.value); // returns 1, as expected
  })();
}

You can read more about SharedValues behavior here.

---

When it comes to your exact issue, there is no problem with the SharedValue synchronization. The problem is most likely Reanimated batching and changes committing mechanism, which, in result, can apply changes a bit later than the value of the SharedValue changes.

Your problem is not related to SharedValue synchronization but is caused by the changes committing mechanism in Reanimated. You can never tell when the style will be finally applied to the view, it depends whether React is currently doing its renders, which can delay the style application time.

[bglgwyng]

Sorry, I think I misused the term 'sync'. It was a bit unclear. I think we need a function that ensures the next reanimated frame update should happen at the same time as the next React view update.

This is a rough sketch of the function.

updateSharedValuesOnTheNextReactFrame(() => {
  sv1.value = 1;
  sv2.value = 2;
  // ...
});
setState(true)

With this function, the problem in this discussion and issue #4446 could be completely solved. Here I share a practical usage that can't be employed due to this issue that we don't have a way to force React update and reanimated update to happen at the same frame.

[MatiPl01]

This it not that easy to implement, at least not with the current architecture of the Reanimated core. We are currently in the process of rewriting Reanimated core to a different implementation that might fix some issues known from the current version of the library but I can't tell if this particular one will be fixed with the new approach. It is in a very early stage but we hope that it will help us fix some issues and this one might be fixed as well.

For now, the safest thing is to assume that the synchronization of React and Reanimated style changes is not possible (without doing any tricks as I suggested above).