Skip to content

Conversation

kirillzyusko
Copy link
Owner

📜 Description

💡 Motivation and Context

Closes #470

📢 Changelog

JS

iOS

Android

🤔 How Has This Been Tested?

📸 Screenshots (if appropriate):

📝 Checklist

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

@kirillzyusko kirillzyusko added enhancement New feature or request KeyboardToolbar Anything related to KeyboardToolbar component labels Mar 25, 2025
@kirillzyusko kirillzyusko self-assigned this Mar 25, 2025
@kirillzyusko kirillzyusko force-pushed the feat/keyboard-toolbar-exclude branch from 0c409b6 to cf36b65 Compare March 25, 2025 14:22
Copy link
Contributor

github-actions bot commented Mar 25, 2025

PR Preview Action v1.6.0

🚀 View preview at
https://kirillzyusko.github.io/react-native-keyboard-controller/pr-preview/pr-881/

Built to branch gh-pages at 2025-03-25 14:33 UTC.
Preview will be ready when the GitHub Pages deployment is complete.

Copy link

argos-ci bot commented Mar 25, 2025

The latest updates on your projects. Learn more about Argos notifications ↗︎

Build Status Details Updated (UTC)
default (Inspect) ⚠️ Changes detected (Review) 1 changed Mar 25, 2025, 2:35 PM

Copy link
Contributor

📊 Package size report

Current size Target Size Difference
174761 bytes 173319 bytes 1442 bytes 📈

@kirillzyusko
Copy link
Owner Author

A slightly better approach would be to introduce a component:

<KeyboardToolbar.Group name="group1" discoverable>
</KeyboardToolbar.Group>

In this what effectively we would do is to split inputs in group under their own names. Such approach is more flexible in my inderstanding, because if we would have tab-view written in pure JS:

Tab1 Tab2 Tab3

Then we in last input of tab 1 we could easily go to the second tab. If we would use KeyboardToolbar.Exclude it would serve our purposes, but the mental model here would be slightly corrupted. What effectively we want to achieve is to have groups of inputs and not "exclude" part of inputs from main view hierarchy.

I think a new API should offer better extendability for future goals.

if (isValidTextInput(child)) {
result = child as EditText
} else if (child is ViewGroup) {
} else if (child is ViewGroup && child !is KeyboardToolbarExcludeReactViewGroup) {
Copy link
Contributor

Choose a reason for hiding this comment

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

this check repeats twice, would it be better to use helper function for this?

return validTextInput
}

guard String(describing: type(of: view)) != "KeyboardToolbarExcludeView" else { return nil }
Copy link
Contributor

Choose a reason for hiding this comment

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

  1. is it possible to use instance check instead of comparing two strings?
  2. it repeats twice

@kirillzyusko kirillzyusko requested a review from Copilot April 4, 2025 17:12
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Copilot reviewed 6 out of 16 changed files in this pull request and generated 1 comment.

Files not reviewed (10)
  • android/src/base/java/com/reactnativekeyboardcontroller/KeyboardControllerPackage.kt: Language not supported
  • android/src/main/java/com/reactnativekeyboardcontroller/managers/KeyboardToolbarExcludeViewManagerImpl.kt: Language not supported
  • android/src/main/java/com/reactnativekeyboardcontroller/traversal/ViewHierarchyNavigator.kt: Language not supported
  • android/src/main/java/com/reactnativekeyboardcontroller/views/KeyboardToolbarExcludeReactViewGroup.kt: Language not supported
  • android/src/paper/java/com/reactnativekeyboardcontroller/KeyboardToolbarExcludeViewManager.kt: Language not supported
  • android/src/turbo/java/com/reactnativekeyboardcontroller/KeyboardControllerPackage.kt: Language not supported
  • docs/docs/api/components/keyboard-toolbar/index.mdx: Language not supported
  • ios/traversal/ViewHierarchyNavigator.swift: Language not supported
  • ios/views/KeyboardToolbarExcludeViewManager.h: Language not supported
  • ios/views/KeyboardToolbarExcludeViewManager.mm: Language not supported

: ({ children }: KeyboardGestureAreaProps) => children;
export const RCTOverKeyboardView: React.FC<OverKeyboardViewProps> =
require("./specs/OverKeyboardViewNativeComponent").default;
export const RCTKeyboardToolbarExcludeView: React.FC<OverKeyboardViewProps> =
Copy link

Copilot AI Apr 4, 2025

Choose a reason for hiding this comment

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

The type for RCTKeyboardToolbarExcludeView should use KeyboardToolbarExcludeViewProps instead of OverKeyboardViewProps for consistency with the rest of the bindings.

Suggested change
export const RCTKeyboardToolbarExcludeView: React.FC<OverKeyboardViewProps> =
export const RCTKeyboardToolbarExcludeView: React.FC<KeyboardToolbarExcludeViewProps> =

Copilot uses AI. Check for mistakes.

@kirillzyusko kirillzyusko mentioned this pull request Sep 18, 2025
2 tasks
kirillzyusko added a commit that referenced this pull request Sep 23, 2025
## 📜 Description

Added compound pattern to `KeyboardToolbar` component.

## 💡 Motivation and Context

This component started as a very simple component with limited
customization. However, over the time it got many new props, such as
`onNextCallback` etc. and right now we have too many props for
customization.

Since I'm planning to add
#881
I decided that it'll be a good time to refactor the component and apply
compound pattern. So in the end I come up with next API design:

```tsx
<KeyboardToolbar>
  <KeyboardToolbar.Background />
  <KeyboardToolbar.Prev />
  <KeyboardToolbar.Next />
  <KeyboardToolbar.Content />
  <KeyboardToolbar.Done />
</KeyboardToolbar>
```

> I intentionally changed `blur` prop to `background`, because with iOS
26 we may use liquid glass as a container

Closes
#1121

## 📢 Changelog

<!-- High level overview of important changes -->
<!-- For example: fixed status bar manipulation; added new types
declarations; -->
<!-- If your changes don't affect one of platform/language below - then
remove this platform/language -->

### JS

- added new compound `KeyboardToolbar` API;
- moved props declaration into `types.ts` file.

### Docs

- added new API reference;
- added migration guide.

## 🤔 How Has This Been Tested?

- tested that old code works with new API and doesn't introduce visual
regressions (via e2e tests)
- started to use new API and assure that it doesn't break e2e tests.

## 📸 Screenshots (if appropriate):

<img width="614" height="422" alt="image"
src="https://github.com/user-attachments/assets/8d2cc932-7fd8-4f29-89d4-bf4961bd97dc"
/>

## 📝 Checklist

- [x] CI successfully passed
- [x] I added new mocks and corresponding unit-tests if library API was
changed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request KeyboardToolbar Anything related to KeyboardToolbar component

Projects

None yet

Development

Successfully merging this pull request may close these issues.

KeyboardToolbar's button click will suddenly open the BottomSheet and immediately focus on the BottomSheetTextInput inside the BottomSheet

2 participants