These were just moved down (with useKeyboardHeight replaced by useRatchetingKeyboardHeight)

These values are now determined in vanilla JavaScript by the getPanelPaddingTop worklet

This block was just for initializing values. It arguably was never needed in the first place (we could have just initialized the values above)

This logic is for handling when we set keyboardHeightValue to -1, which used to happen below in onPressLogIn and onPressRegister. The intention of that behavior was to wait for the keyboard to start appearing before starting the animation. The particular logic was there so that if the keyboard never appeared (eg. in an iOS simulator where the keyboard is disabled), then after the timeout clock ran out we would reset it to 0.

In this diff, I got rid of the logic that sets keyboardHeightValue to -1. In my experience playing around with the animations it didn't seem very important. Perhaps it mattered more before, or perhaps the new Reanimated 2 logic is snappier for some reason.

This logic was for deciding when to initiate a new animation.

Reanimated 2 and 3 seem to handle this slightly differently. It looks like they allow you to set a shared value to a withTiming repeatedly, and then the C++ logic somehow intelligently decides whether a new animation needs to be initiated based on whether the target value has changed, and whether there is an animation in progress

This was replaced by useRatchetingKeyboardHeight . I initially tried to use useAnimatedKeyboard from Reanimated directly, but found that the animation seems a bit slower than the keyboard. Here's a comparison:

This actually ran the animation, and is replaced by the withTiming call in the getPanelPaddingTop worklet

This block was just for initializing values. It arguably was never needed in the first place (we could have just initialized the values above)

This logic was for deciding when to initiate a new animation.

Reanimated 2 and 3 seem to handle this slightly differently. It looks like they allow you to set a shared value to a withTiming repeatedly, and then the C++ logic somehow intelligently decides whether a new animation needs to be initiated based on whether the target value has changed, and whether there is an animation in progress

This actually ran the animation, and is replaced by the withTiming call in the getPanelOpacity worklet

This is replaced by the completion callback (third parameter) passed to withTiming in getPanelOpacity. I could have alternately used useAnimatedReaction instead of the completion callback – can change to that if preferred

I added these types when I was initially trying to use useAnimatedKeyboard, but I decided against it (see video in inline comment above). Decided to keep the types for completeness's sake

This replaces ratchetAlongWithKeyboardHeight

What is this replaced by?

In docs this is called AnimatedKeyboardInfo, can we call it that as well?

The docs say that state can have four values. Why do we have five?

It's actually not replaced. I'm not sure it needs to be, given that the Keyboard.dismiss() call will result in it eventually being set to 0... the animation is clean without it, and having this here breaks the clean separation introduced in D12207

Sure, I'll rename it

The docs for version 3 have an additional section where they spell out the types explicitly, and an UNKNOWN is mentioned there that isn't covered in the "Possible values" section you reference. It's possible that UNKNOWN is only there for version 3, but I suspect it's there for version 2 as well, and I'm sure we gain anything from excluding it given we plan to upgrade to Reanimated 3 soon. Nevertheless, I can go ahead and check the actual source to confirm this

Here it is https://github.com/software-mansion/react-native-reanimated/blob/2.12.0/src/reanimated2/commonTypes.ts#L151-L157