wix-incubator / react-native-keyboard-input

Use your own custom input component instead of the system keyboard
MIT License
819 stars 150 forks source link

FlatList not responding to keyboard (looking for help) #45

Closed davidpaulsson closed 6 years ago

davidpaulsson commented 6 years ago

So I'm sure I've probably missed something, but I'd like to never cover any content with the keyboard. Basically, KeyboardAvoidingView's behavior="padding", but I cannot figure out to implement it with KeyboardAccessoryView.

Attaching gif to illustrate (this is what I have, not the behavior I want :)) kapture 2018-04-10 at 15 24 31

My code is as following

  return (
    <View style={{ flex: 1 }}>
      <FlatList
        inverted
        data={data}
        ...
      />
      <KeyboardAccessoryView
        renderContent={this.keyboardAccessoryViewContent}
        kbInputRef={this.textInputRef}
        kbComponent={this.state.customKeyboard.component}
        kbInitialProps={this.state.customKeyboard.initialProps}
        onItemSelected={this.onKeyboardItemSelected}
        onKeyboardResigned={this.onKeyboardResigned}
      />
    </View>
  );

Using "react-native-keyboard-input": "^5.2.0" "react": "16.0.0" "react-native": "0.53.0"

davidpaulsson commented 6 years ago

Android works as I want it without any modifications.

artald commented 6 years ago

hey,

I'm not really sure what's going on there, but if you take a look at KeyboardAccessoryView you'll notice there's a prop called scrollBehavior. This controls what happens to the scroll container when the keyboard is shown.

By default the behavior is set to "fixed offset", which means that the scroll container will maintain its position (I think that this is what you also want for your case), but in your gif it seems as if it's set to "none" even thought you are not overriding it.

One option is that the package fails to recognize the scroll container and perform this "magic" for you :). Check if you can scroll to see the whole content or if the keyboard covers it and makes the part under it unreachable - if thats the case then this is why the scroll behavior is not working.

It's also worth to mention that even though everything compiles and runs, this package wasn't tested thoroughly in RN > 0.51, so it's possible that there are issues.

davidpaulsson commented 6 years ago

Thank you @artald for your time!

I've tried to set scrollBehavior, (and iOSScrollBehavior) but without any success 😔 But I don't know If I'm maybe doing it wrong? I've tried with strings, like iOSScrollBehavior={'KeyboardTrackingScrollBehaviorFixedOffset'}, and also from NativeModules like iOSScrollBehavior={NativeModules.KeyboardTrackingViewManager.KeyboardTrackingScrollBehaviorFixedOffset}.

When the keyboard is open, the FlatList height seems to be the same (I can't scroll to the end to see all messages. See gif) kapture 2018-04-10 at 16 00 10

Can I test/report anything that would help to figure out if it's broken in RN > 0.51?

artald commented 6 years ago

Yes, It seems that the case is as I said. The content is covered by the input even when the keyboard is not open because there is a failure to recognize the scroll container, so the automatic scroll handling, insets handling (and more stuff) that this package provides simply doesn't work

Is it an option for you to downgrade to RN 51 to test it and verify that it's indeed an RN > 51 issue? In anyway, it would be really hard to identify the problem without a minimal demo project which reproduces it..

davidpaulsson commented 6 years ago

I can try to set up a small repo reproducing this. A question: with this coming in RN 55, will that change snytning going forward? It only handles the toolbar above the keyboard, not the keyboard it self, but still.

artald commented 6 years ago

The new RN 55 component handles showing a view that tracks the keyboard by associating it to a text input, but it doesn't handle setting a keyboard input view.

If nothing works for you, you can still use this package just for showing a custom keyboard.

davidpaulsson commented 6 years ago

Thanks for clarifying that. I'll see if I can get a repo reproducing this going tomorrow.

davidpaulsson commented 6 years ago

Ok, so I did a test run with different RN versions. And it's great because they all work. Soooooo I guess it's not a problem with RN, but rather something in my project. Annoying since I don't know what, but at least we can eliminate RN as the cause.

They all work.

¯_(ツ)_/¯

artald commented 6 years ago

thanks for checking it with all the versions 😃 as I understand they all work as expected... if you can create a demo that reproduces your issue I can look into it.

davidpaulsson commented 6 years ago

Yup, I've probably messed up along the way somehow. Will try to fix and/or reproduce it and report what I can find. Thank you for your time!

stwiname commented 6 years ago

@davidpaulsson did you manage to fix this? I'm having the same problem

davidpaulsson commented 6 years ago

Unfortunately no. I have my guesses it's because how my app is structured. We're using a mix of modals and NavigationExperimental and when there are multiple views stacked on top of each other react-native-keyboard-input does not seem to work. If I tried the same code, but as the only child in the hierarchy it did work, so even though I can't say exactly what's up, I think react-native-keyboard-input adjusts/listens on the first mounted scrollview/flatlist/whatevs from the root component (and not necessarily the one in that's viewable at the moment)

Jarred-Sumner commented 6 years ago

having the same problem too

Jarred-Sumner commented 6 years ago

@davidpaulsson

I have a hunch that a fix is:

Will try this out tomorrow.

requiresSameParentToManageScrollView: https://github.com/wix/react-native-keyboard-tracking-view/blob/master/lib/KeyboardTrackingViewManager.m#L177

stwiname commented 6 years ago

Setting requiresSameParentToManageScrollView to true solved it for me

@Jarred-Sumner thanks

Jarred-Sumner commented 6 years ago

glad to hear that worked for you @stwiname!

An update on this: https://github.com/wix/react-native-keyboard-input/issues/45#issuecomment-389452077

requiresSameParentToManageScrollView works...but in my case, the scroll view it thinks is the correct one is not the correct one.

Specifically, I have a scrollview in the screen that precedes the screen that the <KeyboardAccessoryView /> is on. Since it does a breadth-first search from the top of all UIView's, it finds the scrollview on the page before the the current one...and tracks scrolling of the scrollview on the wrong page.

When I unmounted that scrollview when it's not focused...it works. But this isn't a great solution. It would be much better if there was some way to provide a tag to a scrollview.

Jarred-Sumner commented 6 years ago

I have a fix for this issue in this PR: https://github.com/wix/react-native-keyboard-tracking-view/pull/15

davidpaulsson commented 6 years ago

I'd just like to say this is working now thanks to your PR @Jarred-Sumner landing in react-native-keyboard-tracking-view v5.4.4. Thank you very much for your effort! Will close this now. ❤️

alexandregiordanelli commented 5 years ago

@davidpaulsson can you share the final code?

stanislav-sidorov-empeek commented 2 years ago

another solution, measure keyboard height and add margin-bottom to FlatList container:

<KeyboardAvoidingView` behavior={'height'}><FlatList /></KeyboardAvoidingView>

  const handleShowKeyboard = (e: KeyboardEvent) => {
    const height = e.endCoordinates.height;
    setKeyboardHeight(height);
  };

  const handleHideKeyboard = () => {
    setKeyboardHeight(0);
  };

  React.useEffect(() => {
    if (IS_ANDROID) {
      return;
    }
    const keyboardDidShowSubscribtion = Keyboard.addListener(
      'keyboardDidShow',
      handleShowKeyboard,
    );
    const keyboardWillHideSubscribtion = Keyboard.addListener(
      'keyboardWillHide',
      handleHideKeyboard,
    );
    return () => {
      Keyboard.removeSubscription?.(keyboardDidShowSubscribtion);
      Keyboard.removeSubscription?.(keyboardWillHideSubscribtion);
    };
  }, []);

also for IPhone X need to get to attention a height of the home indicator