New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bottom Sheet component compatibility/custom native wrapper(long-term feature) #343
Comments
Thank you @VladyslavMartynov10 and sorry for late response 😅 I think the integration is problematic because I think replication of But in ideal case both libraries should work together well, so first of all I'd like to understand which problems did you have trying to integrate bottom sheet and this library? Would you mind to describe it as precisely as possible? |
Hey @kirillzyusko ! No worries, I'm almost available at any time. I agree that replicating a bottom-sheet is a challenging task, especially if we aim for a native implementation. My interest in exploring potential integration originates from my personal experiments. It's important to note that currently, all third-party libraries are using React Native implementation, and we lack a native implementation alternative. Additionally, I've been particularly impressed with the NativeSheet implementation for iOS. This implementation excels, offering excellent functionality with minimal boilerplate required, especially when using the SwiftUI framework. In my situation, I attempted to integrate a KeyboardToolBar component (which I presented to you for KeyboardToolbar feature) with gorhom/bottomsheet to achieve smooth transitions between focused inputs. From this starting point, I'm considering three options:
Overall, I believe we should develop a practical example for others who might encounter this issue in the future. Also, thank you for the suggested idea. I need to review it further, as it seems to me that a custom interpolation approach should work. Perhaps in the near future, we might be able to develop something similar to a native solution, although I'm aware that this would require considerable effort and thorough investigation. |
@VladyslavMartynov10 I followed a guide that I wrote in #445 and it looks like it works pretty well: Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-05-14.at.18.01.52.mp4Can I close this issue and merge this PR? |
## 📜 Description Added docs explaining how to integrate `KeyboardAwareScrollView` and `@gorhom/bottom-sheet`. ## 💡 Motivation and Context It may be no very obvious that you'll need to wrap it in additional HOCs. Inspired by #309 (comment) Closes #343 ## 📢 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 --> ### Docs - added a section about integration `KeyboardAwareScrollView` with `@gorhom/bottom-sheet`; ## 🤔 How Has This Been Tested? Tested via preview and `localhost:3000`. ## 📸 Screenshots (if appropriate): <img width="1300" alt="image" src="https://github.com/kirillzyusko/react-native-keyboard-controller/assets/22820318/e321a355-46fd-41ed-8f39-8a45a9f18c0d"> ## 📝 Checklist - [x] CI successfully passed - [x] I added new mocks and corresponding unit-tests if library API was changed
@VladyslavMartynov10 the issue got automatically closed because I merged PR. If you think that the issue is still present - let me know and I'll be happy to re-open this issue 😊 |
Hey @kirillzyusko !
I was exploring potential improvements for react-native-keyboard-controller and discovered that the package doesn't currently support the popular BottomSheet component(without any additional tricks).
Initially, I thought integrating with the BottomSheet package would be easier than it actually turned out to be. The library has its own pre-built component, BottomSheetInput, and offers additional options for modifying keyboard behavior.
The main challenge I faced was achieving a smooth transition for the BottomSheet between active and inactive keyboard states. Since the library manages the keyboard state based on the BottomSheet's react-native-reanimated state, it requires significant JavaScript boilerplate to make it work with react-native-keyboard-controller. I checked the input behavior to determine whether it was focused or not, and then simply adjusted the snapPoints state, which produced the desired effect.
On the other hand, after implementing a custom BottomSheet solution, I observed improved results:
Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-01-27.at.18.20.32.mp4
Pasting quick implementation:
Finally, it seems to me that the idea of creation own native iOS/Android Bottomsheet wrapper might be a more suitable solution in this scenario, rather than attempting to modify the behavior of an existing JavaScript library.
However, it seems that this approach is not the primary goal of the current library. Perhaps creating a new package would be a better course of action.
I would value your input on this issue, as deciding on this feature involves extensive consideration of its pros and cons. I've shared all the considerations and ideas that have been on my mind for the past three weeks 🙂
The text was updated successfully, but these errors were encountered: