KeyboardProvider changes windowSoftInputMode about react-native-keyboard-controller

[itsramiel]

Thank you @kirillzyusko. I think I had a wrong understanding of adjustPan. And I think I get your point for the goal of the library.

Thank your for the clarification 🙏. I'll be closing this as it is not really a bug.

[kirillzyusko]

Hey @itsramiel

When you wrap app in KeyboardProvider it will move app in edge-to-edge mode on Android (and in this mode app is not resizing window automatically - this is your first video).

Note

If you want to return to default behavior, then you'll need to use useKeyboardController and disable/enable module where you need calling setEnabled(false) or setEnabled(true) (on Provider level you can disable module initially and enable only where you need).

Regarding adjustPan behavior - yes it'll affect how window is resized. Again if you want to match iOS behavior and write cross platform code, you need to go to edge-to-edge mode and set windowSoftInputMode to adjustResize (and in this case you need to handle keyboard appearance on your own).

I hope I answered on your question - but if not, then please feel free to ask additional questions 😊

Maybe documentation can be somehow improved?

[itsramiel]

Hey @kirillzyusko

Hmm okay so I think I got the first point and that is when you wrap the app with the provider that app stops resizing because that how android behaves in edge to edge.

However I still don't get the second point. If wrapping the app with the provider stops the resizing why does it go back to resizing when I was setting the windowSoftInputMode to adjustPan? From what I understood that windowSoftInputMode will not longer affect and it will always pan.

Now just a general comment here. I think integrating this library to an existing brownfield project is quite cumbersome annoying. I would have loved if the library only affects where it is used. If I need a KeyboardAvoidView then I just use it in that screen while knowing my windowSoftInputMode is not altered. I see how this can be worked around by enablind/disabling the module but yeah I would have loved it if it was less intrusive

[kirillzyusko]

However I still don't get the second point. If wrapping the app with the provider stops the resizing why does it go back to resizing when I was setting the windowSoftInputMode to adjustPan? From what I understood that windowSoftInputMode will not longer affect and it will always pan.

Actually it will affect. adjustPan will move a content. To understand the difference between soft input modes you can have a look on this post.

When you enter edge-to-edge and specify adjustResize -> window will not be resized anymore:

Screen.Recording.2024-03-07.at.17.52.29.mov

But If you are in edge-to-edge and use adjustPan - it will translate the content of the screen:

Screen.Recording.2024-03-07.at.17.54.37.mov

I think I wrote slightly incorrect information in documentation? Would you mind to point me to the documentation where I wrote such information (that window with edge-to-edge and adjustPan will not move the content? I remember I wrote something somewhere, but can not find it right now...).

Now just a general comment here. I think integrating this library to an existing brownfield project is quite cumbersome annoying. I would have loved if the library only affects where it is used. If I need a KeyboardAvoidView then I just use it in that screen while knowing my windowSoftInputMode is not altered. I see how this can be worked around by enablind/disabling the module but yeah I would have loved it if it was less intrusive

The problem is that in react-native you can not simply rely on the component usage. For example if you are using react-navigation and use KeyboardAvoidingView on screen A. Then you go in stack navigator to screen B (and in this screen you want to use default resizing mechanisms). On screen A the KeyboardAvoidingView is still mounted - does it mean that you want to use library functionality? No, because you want to use default resizing mechanism based on windowSoftInputMode.

That's why this library provides primitives (enabling/disabling module, setting windowSoftInputMode in runtime) so that you can implement any logic inside your app (with any navigation library) and assure a gradual adoption.

If you want to write the component that will enable library when it gets mounted, you can create your own component, for example:

const KeyboardAvoidingViewWithAutoActivation = ({children}) => {
  const {setEnabled} = useKeyboardController();

  // or any other condition for activation, for example when screen becomes focused/unfocused
  useEffect(() => {
    setEnabled(true);
    
    return () => setEnabled(false);
  }, []);
  
  return (
    <KeyboardAvoidingView>{children}</KeyboardAvoidingView>
  )
}

[kirillzyusko]

@itsramiel my pleasure 😊

By the way, if you have an suggestions for documentation improvements - I'll be happy to hear them 😊