React-native: [iOS/TextInput] Impossibility to use `inputAccessoryView`

Created on 23 Sep 2017  路  11Comments  路  Source: facebook/react-native

Is this a bug report?

It is a incorrect behavior introduced in version 0.47.0, commit https://github.com/facebook/react-native/commit/2b1795c5add2e1442878a884d6dcd8f0ec5c1572

This commit brought a problem to those who use a custom ToolBar in TextInput, like IQKeyboardManager. And there is no option to disable this behavior.

Environment

Environment:
OS: macOS Sierra 10.12.6
Node: 6.11.0
Yarn: 1.0.2
npm: 5.4.2
Watchman: 4.9.0
Xcode: Xcode 9.0 Build version 9A235
Android Studio: EAP AI-171.4316950 AI-171.4316950

Packages: (wanted => installed)
react: 16.0.0-alpha.12 => 16.0.0-alpha.12
react-native: 0.48.2 => 0.48.2

Steps to Reproduce

  1. $ clone https://github.com/douglasjunior/react-native-inputAccessoryView.git
  2. $ cd react-native-inputAccessoryView
  3. $ yarn install
  4. $ react-native run-ios

Expected Behavior

It is expected that when typing, the Toolbar will not disappear. As in react-native 0.46.4.

correct

Actual Behavior

When typing, the Toolbar disappears, because the inputAccessoryView is set to null.

incorrect

Locked

Most helpful comment

Okay, I will fix that, I think I know how to do it.
I am doing it because:

  • Seems it will not increase complexity of current implementation;
  • I cannot guarantee that it will work forever because... see the previous point;
  • RN does not support customizing inputAccessoryView;
  • I love you, guys.

All 11 comments

I thought about this issue for awhile after it was reported as a commit comment. And I think that we should not fix this in RN.
We should not because this is a problem inside IQKeyboardManager, not inside RN.
IQKeyboardManager has (controversial) "magical" design that assumes that it is okay to interfere with actual product code (which actually is unaware of this). So, if the authors of this framework went this way (which is perfectly fine), they need to add even more magic to workaround this problem.
From other side, even if can "fix" this issue on RN side, we should not overcomplicate internal logic just to be compatible with one specific library.

Sorry, I dont think that you understood the problem, and I dont think that issue should be closed.

  1. I think that the feature of managing the inputAccessoryView should not be responsability of the RN TextInput. And if it is, there should be an option for disable this. It's an evasive feature, it broke the default behavior.

  2. The problem here is not with IQKeyboardManager, I just used it as an example. Today you can not use an inputAccessoryView anyway. It's impossible. So I think this is a problem in the RN.

  3. This functionality broke the framework to add irrelevant value to it.

There is no magic, what the library does is simple, and the library is not the focus of the problem here. In conclusion, I just want to be able to add my own inputAcessoryView. Today I can not.

Let me put it this way: It is RN's UITextView/UITextField instance, RNText lib owns this and controls it. If some another library access it directly and the result is undesirable, it should be fixed in that library.

Forget the library, the question here is that I cant use my own inputAccessoryView.

Before using any library I, and several others developers, used an own inputAccessoryView to create navigation buttons and offer a better UX. RN simply put an end to it, in an undemocratic way.

I worked on this problem for a few days and could not find a solution. Because the RN overrides the inputAccessoryView and there is nothing that can be done externally.

I just want to make sure if you really understand the problem and are if you making the right decision. Everything would be resolved with an option to disable this new "feature".

My suggestion is to create an option that will change this:

- (void)didSetProps:(NSArray<NSString *> *)changedProps
 {
   [self invalidateInputAccessoryView];
 }

To something like this:

- (void)didSetProps:(NSArray<NSString *> *)changedProps
 {
   if (automaticToolbarEnabled) {
        [self invalidateInputAccessoryView];
   }
 }

Okay, I will fix that, I think I know how to do it.
I am doing it because:

  • Seems it will not increase complexity of current implementation;
  • I cannot guarantee that it will work forever because... see the previous point;
  • RN does not support customizing inputAccessoryView;
  • I love you, guys.

I really appreciate your help 馃帀 . We love you too 鉂わ笍 .

I have tried to solve this in several ways, but I could not. My temporary bad solution was to create an extension to override the invalidateInputAccessoryView.

Please, if you have any documentation that can help me to understand the flow of RN internal components, I can try to help you better in the next time.

@douglasjunior bf3698323d81508fc77174df2b1ffe5fb03224e7 should fix your problem.

Amazing, thank you @shergin. 馃帀

I tested it with the master branch and it really worked. However when using numeric input the RN inputAcessoryView will override the custom inputAcessoryView yet. But I think this can be solved in other ways.

@douglasjunior Can you elaborate on how you accessed inputAccessoryView? My project is currently dependent on react-native-textinput-utils and I would like to remove this dependency since the repo is extremely out of date. Did you go with the extension approach you mentioned above?

@rplankenhorn checkout the react-native-keyboard-manager and IQKeyboardManager.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

anchetaWern picture anchetaWern  路  3Comments

despairblue picture despairblue  路  3Comments

aniss picture aniss  路  3Comments

upbit picture upbit  路  3Comments

jlongster picture jlongster  路  3Comments