KeyboardExtender doesn't immediately show children when enabled prop changes to true

[woals4815]

Describe the bug

KeyboardExtender component doesn't immediately show its children when enabled prop changes from false to true. There appears to be a delay or the component doesn't render correctly on the first state change, requiring user interaction or additional re-renders to display properly.

Code snippet

import { KeyboardExtender } from 'react-native-keyboard-controller'

const [showExtender, setShowExtender] = useState(false)

useEffect(() => {
  if (someValue) {
    setShowExtender(true) // This should immediately show the KeyboardExtender
  }
}, [someValue])

return (
  <KeyboardExtender enabled={showExtender} >
    <Banner onPress={onPress} />
  </KeyboardExtender>
)

Repo for reproducing

Unfortunately, I cannot provide a public repository due to proprietary code, but the issue occurs in a React Native app with TypeScript using the KeyboardExtender component from react-native-keyboard-controller.

To Reproduce

Steps to reproduce the behavior:

1. Initialize KeyboardExtender with enabled={false}
2. Change the enabled prop to true programmatically (e.g., through useState)
3. Observe that the children components inside KeyboardExtender are not immediately visible
4. User interaction or additional re-renders are required to make the content appear

Expected behavior

When the enabled prop changes from false to true, the KeyboardExtender should immediately render and display its children components without delay or requiring additional user interaction.

Screenshots

N/A - Visual behavior issue where component simply doesn't appear when expected.

Smartphone (please complete the following information):

• Desktop OS: macOS (Darwin 24.5.0)
• Device: iPhone Simulator & Physical iOS devices
• OS: iOS
• RN version: 0.74.5
• RN architecture: New Architecture (Fabric)
• JS engine: Hermes
• Library version: 1.18.2

Additional context

• The issue seems to be related to the timing of when KeyboardExtender renders its children
• We have applied a patch to add height prop support: patches/react-native-keyboard-controller+1.18.2.patch
• As a workaround, we implemented animations using react-native-reanimated to provide visual feedback, but the underlying rendering issue with KeyboardExtender remains
• The issue is consistent across different iOS devices and simulators
• Component works correctly after the initial render issue is resolved through user interaction

[woals4815]

Additional Information: Native Code Modifications

We have applied a custom patch that modifies both the native iOS code and TypeScript interfaces to add height prop support to KeyboardExtender. Here are the key changes:

iOS Native Code Changes (.mm file):

1. ViewManager - Expose height property:

// Expose the `enabled` prop to React Native
RCT_EXPORT_VIEW_PROPERTY(enabled, BOOL)
+// Expose the `height` prop to React Native
+RCT_EXPORT_VIEW_PROPERTY(height, NSNumber)

2. KeyboardExtender interface - Add height property:

@implementation KeyboardExtender {
  UIView *_contentView;
  UIView *_sharedInputAccessoryView;
+  NSNumber *_height;

3. Height setter method:

+- (void)setHeight:(NSNumber *)height
+{
+  _height = height;
+
+  // Recreate inputAccessoryView when height changes
+  if (_sharedInputAccessoryView) {
+    _sharedInputAccessoryView = nil;
+    
+    // Reconnect if there's currently active text input
+    if (_enabled) {
+      UIResponder *firstResponder = [UIResponder current];
+      if ([firstResponder conformsToProtocol:@protocol(UITextInput)]) {
+        [self attachToTextInput:(UIView *)firstResponder];
+      }
+    }
+  }
+}

4. Updated createSharedInputAccessoryView method:

- (void)createSharedInputAccessoryView
{
+  CGFloat viewHeight = 44; // Default value
+  
+  // 1. Use height prop if provided
+  if (_height && [_height doubleValue] > 0) {
+    viewHeight = [_height doubleValue];
+  }
+  // 2. If no height prop, use first child view's height
+  else if (_contentView.subviews.count > 0) {
+    viewHeight = _contentView.subviews[0].frame.size.height;
+  }
+  
   _sharedInputAccessoryView = [KeyboardExtenderContainerView
-      createWithFrame:CGRectMake(0, 0, UIScreen.mainScreen.bounds.size.width, internalFrame.size.height)
-          contentView:_contentView];
+      createWithFrame:CGRectMake(0, 0, UIScreen.mainScreen.bounds.size.width, viewHeight)
+        contentView:_contentView];
}

TypeScript Interface Changes:

export type KeyboardExtenderProps = PropsWithChildren<{
   /** Controls whether this `KeyboardExtender` instance should take an effect. Default is `true`. */
   enabled: boolean;
+  /** Optional height for the keyboard extender. If not provided, uses the height of the first child. */
+  height?: number;
}>;

React Component Changes:

const KeyboardExtender = (props: PropsWithChildren<KeyboardExtenderProps>) => {
-  const { children, enabled = true } = props;
+  const { children, enabled = true, height } = props;
   const { width } = useWindowDimensions();

   return (
-    <RCTKeyboardExtender enabled={enabled}>
+    <RCTKeyboardExtender enabled={enabled} height={height}>
       <View style={{ width }}>{children}</View>
     </RCTKeyboardExtender>
   );

[kirillzyusko]

@woals4815 thank you for opening a detailed issue!

1️⃣ Height problem

I use children height of children when I create input accessory view:

react-native-keyboard-controller/ios/views/KeyboardExtenderManager.mm

Lines 148 to 149 in 6c641a5

	createWithFrame:CGRectMake(
	0, 0, UIScreen.mainScreen.bounds.size.width, internalFrame.size.height)

I think a correct solution here would be a detection of children layout changes and reflecting it in a container.

We always can pass additional props and invalidate layout when these props change, but in my opinion it's not a very good developer experience. Such things should be handled automatically 🙂

If you can show a problem when height is not properly set I'll try to look into it and will try to fix the problem (I guess it happens whenever child component changes its layout?).

2️⃣ Async enabled reaction

Looking at your code there is a lot of async stuff happens:

• we update someValue asynchronously (since it's a state variable)
• we run useEffect asynchronously
• we again update showExtender asynchronously

If it's possible to get rid off first two steps I think it'll be more responsive?.. But anyway you are right - enabled prop will have to go through the bridge (in old architecture) which is also async operation. On Fabric (theoretically) it should be sync? May I kindly ask you to attach a video to show the problem? 🙏 If you don't want to share whole screen recording you can move your button that activates KeyboardExtender closer to keyboard itself and capture only keyboard + button interaction ignoring all other screen areas 👀

---

P. S. I know about async nature of KeyboardExtender. I met this first time in example app when I want to have KeyboardExtender specific to a particular field of the app (like donation amount and disabling it for all other fields). I used onFocus/onBlur and changed enabled prop via state there. And for a fraction of a second I Could see how keyboard gets changed from numeric to QWERTY and it has attached KeyboardExtender and then in next frame it disappears. But I suppose to think that events + state update takes some time to come and because of that I see a delayed update (while on native side keyboard will change its type instantly). I had an idea of adding textInputNativeID prop to KeyboardExtender (similar to how KeyboardGestureArea works) to be able to associate a specific KeyboardExtender instance with specific TextInput. But for me it looks like you have a similar issue, but a different root cause/interaction to produce this problem? Would appreciate if you could attach a video to show what happens in your case 🙏

[woals4815]

Hi @kirillzyusko,

Thank you for the detailed technical analysis! I really appreciate your investigative approach to this issue.

Current Workaround We've Implemented

Our team has been experiencing the same issue, so we created a temporary patch that might be helpful for the community. Here's what we implemented:

1. Added height prop to KeyboardExtender

export type KeyboardExtenderProps = PropsWithChildren<{
  enabled: boolean;
  height?: number; // New optional prop
}>;

2. iOS Implementation Changes

// KeyboardExtenderContainerView.swift
// Changed from UIInputView to regular UIView to fix background issues
let inputView = UIView(frame: frame)
inputView.backgroundColor = .clear

// KeyboardExtenderManager.mm  
// Height priority: height prop > first child height
let viewHeight = _height ? _height.floatValue : 
                (_contentView.subviews.count > 0 ? 
                 _contentView.subviews[0].frame.size.height : 44.0)

3. Usage in our app

<KeyboardExtender enabled={showExtender} height={40}>
  <SomeComponent />
</KeyboardExtender>

Technical Ideas for Automatic Layout Detection

Based on your suggestion for automatic children layout change detection, here are some approaches we could explore:

Option 1: onLayout-based Detection

const KeyboardExtender = ({ children, enabled }) => {
  const [childrenHeight, setChildrenHeight] = useState(0);
  
  const handleChildLayout = useCallback((event) => {
    const { height } = event.nativeEvent.layout;
    if (height \!== childrenHeight) {
      setChildrenHeight(height);
    }
  }, [childrenHeight]);

  return (
    <RCTKeyboardExtender enabled={enabled} height={childrenHeight}>
      <View onLayout={handleChildLayout}>
        {children}
      </View>
    </RCTKeyboardExtender>
  );
};

Option 2: ResizeObserver Pattern

// Using ref-based measurement with useLayoutEffect
useLayoutEffect(() => {
  if (contentViewRef.current) {
    contentViewRef.current.measure((x, y, width, height) => {
      setDynamicHeight(height);
    });
  }
}, [children]);

Addressing the Async enabled Issue

You mentioned the async flow: someValue update → useEffect → showExtender update. In our case, this happens exactly as you described:

// This is the problematic async chain in our code
useEffect(() => {
  if (someValue) {
    setShowExtender(true); // Async state update
  }
}, [someValue]);

Video Demo

I'll record a screen capture showing the delay issue and share it here. Would that help you understand the specific timing problem we're experiencing?

Questions for Discussion

1. Which automatic layout detection approach would fit better with the library's architecture?
2. For the async enabled issue, would moving to a more synchronous prop calculation help? (e.g., enabled={someValue})
3. Would you be interested in a PR with our current patch as a stepping stone toward the automatic solution?

I'd love to collaborate on finding the best long-term solution for this. Let me know if you'd like me to create a minimal reproduction repo or if there's any other information that would be helpful!

Thanks again for maintaining this excellent library! 🙏

[kirillzyusko]

Which automatic layout detection approach would fit better with the library's architecture?

@woals4815 yes, option like with onLayout, but on a native side completely, something like this:

  - (void)updateInputAccessoryHeight {
      if (!_sharedInputAccessoryView || _contentView.subviews.count == 0) return;
      
      CGFloat newHeight = _contentView.subviews[0].frame.size.height;
      if (fabs(_sharedInputAccessoryView.frame.size.height - newHeight) > 0.1) {
          // Create new accessory view instead of resizing existing one
          [self recreateInputAccessoryViewWithHeight:newHeight];
          
          // Find the active text input
          UIResponder *firstResponder = [UIResponder current];
          if (![firstResponder conformsToProtocol:@protocol(UITextInput)]) return;
          
          UIView<UITextInput> *textInput = (UIView<UITextInput> *)firstResponder;
          
          // Only update if it's our accessory
          if (textInput.inputAccessoryView == _sharedInputAccessoryView) {
              // Reset to nil first
            if ([textInput isKindOfClass:[UITextField class]]) {
              ((UITextField *)textInput).inputAccessoryView = nil;
            } else if ([textInput isKindOfClass:[UITextView class]]) {
              ((UITextView *)textInput).inputAccessoryView = nil;
            }
              [textInput reloadInputViews];
              
              // Assign new accessory after delay
              dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.01 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
                if ([textInput isKindOfClass:[UITextField class]]) {
                  ((UITextField *)textInput).inputAccessoryView = self->_sharedInputAccessoryView;
                } else if ([textInput isKindOfClass:[UITextView class]]) {
                  ((UITextView *)textInput).inputAccessoryView = self->_sharedInputAccessoryView;
                }
                  [textInput reloadInputViews];
              });
          }
      }
  }

  - (void)recreateInputAccessoryViewWithHeight:(CGFloat)height {
      // Preserve content view
      UIView *content = _sharedInputAccessoryView.subviews.firstObject;
      
      // Create new instance
      _sharedInputAccessoryView = [KeyboardExtenderContainerView
          createWithFrame:CGRectMake(0, 0, UIScreen.mainScreen.bounds.size.width, height)
              contentView:content];
  }

  // Update layoutSubviews
  - (void)layoutSubviews {
      [super layoutSubviews];
      [self updateInputAccessoryHeight];
  }

Would love if you could test this implementation and let me know if it works for you or not. This is just a scratch, so it needs to be re-worked anyway - feel free to open a PR and I'll suggest what to improve etc.

For the async enabled issue, would moving to a more synchronous prop calculation help? (e.g., enabled={someValue})

Yes, I think it should improve performance.

Would you be interested in a PR with our current patch as a stepping stone toward the automatic solution?

I think we can try to adopt solution with layoutSubviews straight away. It should work well and it's almost the same approach as with onLayout, but more synchronous and we'll avoid additional JS -> native round pass.

I'll record a screen capture showing the delay issue and share it here. Would that help you understand the specific timing problem we're experiencing?

Thank you. It'll definitely help a lot!

I'd love to collaborate on finding the best long-term solution for this. Let me know if you'd like me to create a minimal reproduction repo or if there's any other information that would be helpful!

I used this code sample to reproduce a problem with height:

import React, { useEffect, useMemo, useState } from "react";
import {
  Alert,
  Image,
  Keyboard,
  StyleSheet,
  Text,
  TextInput,
  TouchableOpacity,
  TouchableWithoutFeedback,
} from "react-native";
import {
  KeyboardExtender,
  useKeyboardState,
} from "react-native-keyboard-controller";
import Reanimated, {
  useAnimatedStyle,
  useSharedValue,
  withTiming,
} from "react-native-reanimated";
import { SafeAreaView } from "react-native-safe-area-context";

export default function KeyboardExtendExample() {
  const appearance = useKeyboardState((state) => state.appearance);
  const [showExtend, setShowExtend] = useState(true);
  const opacity = useSharedValue(1);

  useEffect(() => {
    // opacity.set(withTiming(showExtend ? 1 : 0));
  }, [showExtend]);

  const animatedStyle = useAnimatedStyle(
    () => ({
      opacity: opacity.value,
    }),
    [],
  );
  const textStyle = useMemo(
    () => [
      styles.priceText,
      appearance === "light"
        ? styles.lightKeyboardText
        : styles.darkKeyboardText,
    ],
    [appearance],
  );

  return (
    <>
      <Image source={require("./background.jpg")} style={styles.background} />
      <TouchableWithoutFeedback onPress={() => Keyboard.dismiss()}>
        <SafeAreaView edges={["top"]} style={styles.container}>
          <TextInput
            keyboardType="numeric"
            placeholder="Donation amount"
            placeholderTextColor="#5c5c5c"
            style={styles.input}
            testID="donation_amount"
            onFocus={() => setShowExtend(true)}
          />
          <TextInput
            keyboardType="numeric"
            placeholder="Postal code"
            placeholderTextColor="#5c5c5c"
            style={styles.input}
            testID="postal_code"
            onFocus={() => setShowExtend(false)}
          />
        </SafeAreaView>
      </TouchableWithoutFeedback>
      <KeyboardExtender enabled>
        <Reanimated.View
          style={[
            styles.keyboardExtend,
            animatedStyle,
            showExtend ? { height: 44 } : { height: 84 },
          ]}
        >

        </Reanimated.View>
      </KeyboardExtender>
    </>
  );
}

const styles = StyleSheet.create({
  background: {
    ...StyleSheet.absoluteFillObject,
    flex: 1,
    width: "100%",
  },
  container: {
    flex: 1,
    paddingHorizontal: 20,
  },
  input: {
    height: 40,
    borderWidth: 2,
    borderColor: "#1c1c1c",
    borderRadius: 8,
    padding: 10,
    fontSize: 18,
    marginBottom: 20,
  },
  keyboardExtend: {
    width: "100%",
    flexDirection: "row",
    justifyContent: "space-around",
    alignItems: "center",
  },
  priceText: {
    fontSize: 18,
    fontWeight: "600",
    padding: 20,
  },
  lightKeyboardText: {
    color: "black",
  },
  darkKeyboardText: {
    color: "white",
  },
});

Let me know if it's enough to reproduce the problem. If your case is trickier, then I'll need to have the same code to reproduce the issue 😊

[woals4815]

@kirillzyusko Thanks for your responding! I prepared a video that is recorded about this problem. Also please take a look reproducible code.

simulator_recording_file.mp4

[kirillzyusko]

Thanks @woals4815

I hope I fixed it in #1065

The fix will be published in 1.18.3 🤞