React-native-reanimated: OvershootClamping does not work since v1.5.0

[Sakarisson]

Hey everyone. Thanks for a great library.

I'm trying to implement an animation that runs a spring with overshootClamping. The code was working fine until I upgraded Reanimated to the newest version. Below is the code in question:

function runSpring(
  clock: Animated.Clock,
  animationState: Animated.PhysicsAnimationState,
): Animated.Node<number> {
  const config = {
    ...SpringUtils.makeDefaultConfig(),
    overshootClamping: true,
  };

  return block([
    cond(not(clockRunning(clock)), [
      set(animationState.finished, 0),
      startClock(clock),
    ]),
    spring(clock, animationState, config),
    cond(animationState.finished, stopClock(clock)),
    animationState.position,
  ]);
}

There seems to have been some regression in v1.5.0, because the code above no longer works properly. The animation does not apply the overshootClamping: true to the configuration.

Hopefully this can be fixed in future versions, as this issue prevents me from upgrading past version 1.4.0

[jakub-gonet]

Hi @Sakarisson,

thanks for reporting, could include a snack? I couldn't reproduce this regression on my own.

[felixakiragreen]

Overshoot clamping appears to have regressed for me as well. I can't easily provide a Snack - but I could provide a GIF and the code for that component if that would be helpful.

[jakub-gonet]

@felixakiragreen it would be appreciated, make sure component isn't too complicated and you paste all code with exact version of reanimated

Gifs showing difference between 1.4 and 1.5 would be awesome

[felixakiragreen]

@jakub-gonet Unfortunately my components are very complicated right now. (1k+ LoC– I know it's not good, I'm still learning how to compose things better).

What I can tell you is that all my components use 3 animation presets which are defined like this:

const trueClamp: Clamping = {
  overshootClamping: true,
}
const falseClamp: Clamping = {
  overshootClamping: false,
}

export const presetSpringFast: SimpleSpringConfig = {
  mass: 2,
  damping: 24,
  stiffness: 120,
  ...trueClamp,
  restSpeedThreshold: 0.9,
  restDisplacementThreshold: 0.9,
}

export const presetSpringSlow: SimpleSpringConfig = {
  mass: 8,
  damping: 23,
  stiffness: 24,
  ...trueClamp,
  restSpeedThreshold: 0.9,
  restDisplacementThreshold: 0.9,
}

export const presetSnapSpring: SimpleSpringConfig = {
  mass: 1,
  damping: 40,
  stiffness: 200,
  ...falseClamp,
  restSpeedThreshold: 1,
  restDisplacementThreshold: 1,
}

I do happen to already have GIFs so you can see the difference before and after. Some context:

• There are two animations: "the entry" & "the exit"; both of these are using presetSpringSlow.
• The difference is much more visible in the exit animation (when hexagon moves upwards across the screen)

I confirmed the Reanimated package version (by checking the yarn.lock) at the time of each recording.

Here is Reanimated 1.4.0 (expo set the package to: "react-native-reanimated": "~1.4.0",

Here is Reanimated 1.7.1 (expo set the package to: "react-native-reanimated": "~1.7.0",

It might be a little difficult to see, but notice how the pause is much longer at the end. That is because it is no longer clamping the overshoot.

[jakub-gonet]

I managed to reproduce it on a snappable example in REA Example app.

After bisecting, it seems #468 (2dc3df7) introduced this regression.

@felixakiragreen, @Sakarisson

A possible workaround is to change export default (...) at the end of src/animation/spring.js to export default spring;

[bdrobinson]

@jakub-gonet this is still an issue for me in 1.8.0. I'm not familiar with the codebase but would it be a difficult PR to fix? cc @osdnk

[jakub-gonet]

@bdrobinson,
it's still present in 1.8 because it wasn't fixed 😉

It originates from some bug inside proc and we'll investigate it more sometime in the future, you can use workaround for now if you need this functionality.

However, PRs are welcome, so if you manage to fix that I'll happily merge it.

[bdrobinson]

:joy: well that would explain it! Yeah i was going to ask about the workaround you posted – it looks like it's a source code change, so I'd have to make my own fork or write some script to patch the file in node_modules? Or have I misunderstood?

Thanks for the quick reply!

[jakub-gonet]

You can use patch-package library to do it, here's a quick blog post about it

[bdrobinson]

Nice that's sorted it, thanks for the workaround!