Skip to content

feat: useAnimatedKeyboard compat layer#1220

Merged
kirillzyusko merged 4 commits intomainfrom
feat/reanimated-compatibility
Nov 24, 2025
Merged

feat: useAnimatedKeyboard compat layer#1220
kirillzyusko merged 4 commits intomainfrom
feat/reanimated-compatibility

Conversation

@kirillzyusko
Copy link
Copy Markdown
Owner

@kirillzyusko kirillzyusko commented Nov 24, 2025

📜 Description

Added useAnimatedKeyboard hook (same as in reanimated, but based on keyboard-controller API).

💡 Motivation and Context

Based on software-mansion/react-native-reanimated#8622 we want to deliver as smooth as possible way to migrate from a deprecated API. In many cases people don't want to copy/paste code and manage it on their own, so in this PR I'm adding a proposed compat layer directly in the core of react-native-keyboard-controller. Using this compat layer devs will just need:

  • install this lib;
  • change the import to use new hook;

📢 Changelog

JS

  • added useAnimatedKeyboard/KeyboardState
  • renamed KeyboardState to IKeyboardState since it conflicts with reanimated name;

🤔 How Has This Been Tested?

Tested via e2e tests that I didn't break anything accidentally.

📸 Screenshots (if appropriate):

image

📝 Checklist

  • CI successfully passed
  • I added new mocks and corresponding unit-tests if library API was changed

@kirillzyusko kirillzyusko self-assigned this Nov 24, 2025
@kirillzyusko kirillzyusko added the enhancement New feature or request label Nov 24, 2025
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Nov 24, 2025

📊 Package size report

Current size Target Size Difference
226542 bytes 224205 bytes 2337 bytes 📈

@kirillzyusko kirillzyusko merged commit 41858c7 into main Nov 24, 2025
14 checks passed
@kirillzyusko kirillzyusko deleted the feat/reanimated-compatibility branch November 24, 2025 20:35
Comment thread src/compat.ts
Comment on lines +34 to +56
{
onStart: (e) => {
"worklet";

state.set(e.height > 0 ? KeyboardState.OPENING : KeyboardState.CLOSING);
},
onMove: (e) => {
"worklet";

height.set(e.height);
},
onInteractive: (e) => {
"worklet";

height.set(e.height);
},
onEnd: (e) => {
"worklet";

state.set(e.height > 0 ? KeyboardState.OPEN : KeyboardState.CLOSED);
height.set(e.height);
},
},
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to memoize this config object with useMemo?

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @tomekzaw You know this part better, so I'll do whatever you say. But let me explain it a little bit. Internally useKeyboardHandler uses useEvent/useHandler hooks from REA. And I tried to have the same API as useAnimatedScrollHandler with only one difference - we attach handler to the view that is located in KeyboardProvider (it kind of makes sense because you have a single keyboard for whole app, but in case with ScrollView you may have multiple of them even on a single screen).

From what I saw useAnimatedScrollHandler doesn't memoize the config with useMemo, right? Is it very expensive to create such object? (from plain react creating an object is a very cheap operation, but I'm not sure about "worklet" part, I think it also should be fast?)

Anyway, the reason why I don't use useMemo is because I was trying to have the same API as useAnimatedScrollHandler and this hook doesn't use useMemo 🙃

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've asked @tjzel about this (he's our expert on memoization and worklets)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think useMemo isn't necessary here, the gains would probably be marginal.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @tjzel for a confirmation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants