Summary:
This diff fixes an issue in `TextInput` where `TextInputState.currentlyFocusedInputRef` could maintain a ref to a view that no longer exists. This issue was exposed when upgrading React, where cleanups for passive effects are deferred. This change means that `inputRef.current` would no longer reference the host view *to be* destroyed; it would be null because the view was *already destroyed*.
There are two fixes here that would independently fix the bug and fix the issue better together.
First, we convert `useEffect` to `useLayoutEffect`. `useLayoutEffect` is intended to fire synchronously after all host view mutations, and the cleanup function is intended to fire synchronously before the host view is destroyed, similar to the behavior assumed before. This change is now the correct function to use semantically. However, if we made this change without the second then any change in the order the effects fire would surface the same bug.
So second, move the `inputRefValue).blur()` call to the same effect as unregistering. This is because we currently require the `blur` effect to be called to null out `currentlyFocusedInputRef` in addition to calling `unregisterInput`. That makes the semantic ordering of effects in `TextInput` meaningful. Instead, when a TextInput is unregistered we should always `blur` to clear the `currentlyFocusedInputRef`, which will prevent dispatching events to a view that doesn't exist. If we made this change without the first then there's would be a race condition between calling blur on a TextInput and when that TextInput has been unregistered.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23035358
fbshipit-source-id: ab686b8046d85e2becd8b879b0b4b7e69e672754
Summary:
just a minor change - uses the [count api](https://reactjs.org/docs/react-api.html#reactchildrencount)
> Returns the total number of components in children, equal to the number of times that a callback passed to map or forEach would be invoked.
## Changelog
not needed I think
Pull Request resolved: https://github.com/facebook/react-native/pull/28991
Test Plan: tested locally
Differential Revision: D21794081
Pulled By: TheSavior
fbshipit-source-id: bf6d11b2bc854d938aed7268911f89a00bb3f596
Summary:
Consolidates the logic for the default value of `blurOnSubmit` on `TextInput` in the JavaScript component.
This only materially impacts Fabric.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D21491482
fbshipit-source-id: 16d8aba32e7d0321a4583e87e03405ea587e35d4
Summary:
This diff makes the ColorValue export "official" by exporting it from StyleSheet in order to encourage its use in product code.
Changelog: Moved ColorValue export from StyleSheetTypes to StyleSheet
Reviewed By: TheSavior
Differential Revision: D21076969
fbshipit-source-id: 972ef5a1b13bd9f6b7691a279a73168e7ce9d9ab
Summary:
`const ReactNative` is assigned to but never used. Let's get rid of it.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21016502
fbshipit-source-id: afcb0cfc501adf07e0c4d4452a831160e1cda088
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
A few recent imports have explicitly added ".js" to the end of their path. This prevents Metro from resolving platform-specific JS files, e.g. "Foo.android.js" or "Foo.windows.js" instead of "Foo.js".
React Native Windows provides its own implementation of files in a few cases where stock React Native will share them between Android and iOS. We hope to reduce/eliminate these long term, but requiring explicit ".js" files currently breaks us in a couple of places where we have custom implementations.
This change is a quick regex replace of ES6 and CommonJS imports in 'Libraries/" to eliminate ".js".
## Changelog
[General] [Fixed] - Do not explicitly include ".js" in Library imports
Pull Request resolved: https://github.com/facebook/react-native/pull/28311
Test Plan: I haven't done any manual validation of this, but `flow-check` should catch any issues with this during CI.
Reviewed By: cpojer
Differential Revision: D20486466
Pulled By: TheSavior
fbshipit-source-id: 31e1ccc307967417d7d09c34c859f0b2b69eac84
Summary:
Allow JS to keep track of mostRecentEventCount and pass it into each event or prop update. We really don't want to separately keep track of that data.
In non-Fabric, the ShadowNode will keep track of the mostRecentEventCount associated to prop updates. In Fabric, that happens on the C++ ShadowNode.
Changelog: [Internal] Simplification to TextInput native state
Reviewed By: mdvacca
Differential Revision: D20374573
fbshipit-source-id: 385fba6ec69a071c78832a686b397699a6c55d67
Summary:
We will soon be enforcing that flow suppressions will only apply when on an error's primary location ([post](https://fb.workplace.com/groups/179614562644215/permalink/559286354677032/)). This diff uses the codemod created in D20008770 to move all suppression comments to their primary locations in the `xplat/js` flow root, and deletes suppression comments that are not on any primary locations.
This diff was generated with:
```
~/fbsource/fbcode/flow/packages/flow-dev-tools/bin/tool suppression-primary-locations --json-file ~/www/errors.json ~/fbsource/xplat/js
hg st -n | xargs grep -l -P '@(partially-)?generated' | xargs hg revert
hg st -n | xargs grep -l 'format' | xargs prettier --write
```
Changelog: [Internal]
bypass-lint
Reviewed By: dsainati1
Differential Revision: D20122544
fbshipit-source-id: d94e409aadb18bb399a1ddbf9f3f2494fe4fb54c
Summary:
Use codegen'd ViewCommands added in previous diff as a replacement for setNativeProps.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18619298
fbshipit-source-id: 08069e828e92ac3cca9813bbcdca99d99fb50883
Summary:
The migration from classy to functional component partially broke controlled TextInput selections. This fixes it.
The nuance is that even though we have "event counters" sent from native, "onChange" and "onChangeSelection" are separate events;
so even if you receive new text and a new native event counter, your selection may be out-of-date. Incrementing the event counter
when sending selection events breaks text updates; and adding another native event counter seems like overkill. Instead, in JS, we statefully
keep track of (1) the native event counter, (2) whether or not the selection has been updated for that event counter.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D18867152
fbshipit-source-id: c569ecd03ce0042d6feb5fa8af4c756588607a09
Summary:
Added description for rejectResponderTermination prop for the TextInput, which seemed to have been deleted.
Descriptions are taken from https://github.com/facebook/react-native/pull/16755/files
## Changelog
[Internal] [Added] - Add description for rejectResponderTermination prop for TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/28001
Test Plan: This PR only changes comment, which has no effect on actual function.
Differential Revision: D19820886
Pulled By: TheSavior
fbshipit-source-id: 5cbaafcbae0bdbf6932ef9c7c0c1a75cd6d8794e
Summary:
When using `react-native-screen` which uses native view controller animations for navigation `TextInput` with `autoFocus` causes a weird animation glitch.
Removing the requestAnimationFrame will cause the focus command to be sent in the same batch as starting screen transitions which fixes the issue.
It is unclear why the rAF was added in the first place as it was part of the initial RN open source commit. If someone at facebook has more context that would be great to make sure it doesn't cause unintended side effects.
Credits to kmagiera for figuring out this
## Changelog
[General] [Fixed] - Remove requestAnimationFrame when focusing input on mount
Pull Request resolved: https://github.com/facebook/react-native/pull/27217
Test Plan:
- Tested in an app using react-native-screen to make sure the animation glitch is fixed
- Tested in RNTester to make sure it doesn't cause other issues when not using react-native-screens
Before:
After:
Differential Revision: D18666991
Pulled By: TheSavior
fbshipit-source-id: 66664c89e06c9ae65074ddcc4688dc5109fc9c72
Summary:
Modernizing this code a bit more, converting it to hooks.
Changelog:
[General][Changed] Converted TextInput to use React hooks
[General][Fixed] TextInput now properly sends native the end selection location on change
(Note: this ignores all push blocking failures!)
Reviewed By: JoshuaGross
Differential Revision: D18581712
fbshipit-source-id: 62d6ea8489fa019ddf941c520930365f2c4887d8
Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary:
This variable is never set and only ever removed
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D18537317
fbshipit-source-id: bbb084e2ea5408fc59ef3853b2ec74bf22afbe21
Summary:
This is the first diff in the series. It removes Flow types for this feature to verify that we actually do not have any usages. After it lands, we will remove actual support on the native side.
There are several reasons why removing it is a good idea:
* There is no any evidence that this feature is actually useful. That was discussed several times (e.g. see T7936714) during RN lifetime and the overall consensus is: We need something else, something like sync `onChange` event instead of it.
* Supporting the previous point, it's not used (at least inside Facebook). I searched hard and I could find only one place where it's used: in the TextInput Example.
* To deliver more functionality we should lean towards W3C specs, this one is not W3C compliant.
* Supporting this Feature in Fabric is quite challenging, so I want to do it sooner than later.
* This feature was never documented.
Changelog: [Breaking] `<TextInput>::onTextInput` event was removed
Reviewed By: TheSavior
Differential Revision: D18456175
fbshipit-source-id: c7a8ed7a86b33ecc01d45497645fe249556fdf96
Summary:
TextInput now acts as a host component and can be passed directly to our new APIs that require a host component. Callsites no longer need to call
```
inputRef.getNativeRef()
```
We mutate the ref to the host component adding the imperative methods of the TextInput so you can still call `inputRef.clear` and `inputRef.isFocused`.
Changelog:
[General][Changed] TextInput now uses `forwardRef` allowing it to be used directly by new APIs requiring a host component.
Reviewed By: yungsters
Differential Revision: D18458408
fbshipit-source-id: 1f149fd575210d702fa0fdf3d05bb2162436a773
Summary:
When the TextInput class is exported directly Flow complains about some definitions because they don't properly define the export type. This change adds those types but still doesn't export the TextInput directly as there are more things that still need to get fixed.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D18444096
fbshipit-source-id: 18c88bbf1de5504f350681a71ea21d7e41876e49
Summary:
In order to make this more flow typed and modern we need to get it off of createReactClass. This change converts the class as is with no intended behavior changes to an ES6 class.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18443018
fbshipit-source-id: 831921976e9de8e965180cdefd1c4a154f04bfea
Summary:
We need to get rid of NativeMethodsMixin. Normally we'd use forwardRef to the HostComponent, however we can't do this here because TextInput has its own imperative methods. I want to refactor this into a class and after that will revisit how to get rid of these methods.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D18436162
fbshipit-source-id: 0c81fa8b31b3248cbab8680ff680dd09c61c76e2
Summary:
Reordering the methds in TextInput to be a bit more consistent.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18435732
fbshipit-source-id: 05a1d9d2c70a4b5fa00a3dc6be0520a216a24106
Summary:
We don't need a local mutable copy of props.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18435731
fbshipit-source-id: 13ec1a78ca26b1372a4aed484a821204a93b6437
Summary:
The TouchableWithoutFeedback is almost exactly the same between both branches.
The responderReject prop was added in https://github.com/facebook/react-native/pull/16755.
The PR seems to say that it is the default behavior on Android. I don't want to make risky changes in this refactor so I'm not doing anything special about that prop for now.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18435733
fbshipit-source-id: 372d17d8e67884930409a6a863757944cec4737e
Summary:
These functions are quite similar and I'm going to refactor out the shared pieces. To make it easy to review this change just inlines those two functions with no other changes.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18435734
fbshipit-source-id: 826f510359358427856993b536d41054ddf8c792
Summary:
I wrote up a bunch of context for this in response to #27038 by fat. That comment is reproduced here in this commit message. You can see it in it's original contxt here: https://github.com/facebook/react-native/pull/27038
Okay, here is what I think is happening. For context, here is a diagram I have of how focus and blur propagates through the system. This might be interesting to refer back to as you go through the rest of my explanation.
ScrollView's scrollResponder is responsible for blurring text inputs when a touch occurs in the ScrollView but outside of the currently focused TextInput. The code for that is here:
https://github.com/facebook/react-native/blob/6ba2769f0f92ca75fb0eb60ccb8337920a9c31eb/Libraries/Components/ScrollResponder.js#L301-L314
This happens on `scrollResponderHandleResponderRelease` aka, touch up.
It checks for what the currently focused textinput is by calling `TextInputState.currentlyFocusedField()`.
That function is a JS variable that is being updated by calls to `TextInputState.focusTextInput` and `TextInputState.blurTextInput`:
https://github.com/facebook/react-native/blob/6ba2769f0f92ca75fb0eb60ccb8337920a9c31eb/Libraries/Components/TextInput/TextInputState.js#L36-L71
I added some console logs to those methods to see which ones are being called when running your repro (thanks for the repro!). **This is without your fix**
Click on and off:
```
// Click on input 1
focusTextInput input1
TextInput's _onFocus called
// Click on blank space
scrollResponderHandleResponderRelease blur input1
blurTextInput input1
TextInput's _onBlur called
```
Click on input1, then input 2, then off
```
// Click on input 1
focusTextInput input1
TextInput's _onFocus called for input1
// Click on input 2
focusTextInput input2
TextInput's _onBlur called for input1
TextInput's _onFocus called for input2
// Click on blank space
scrollResponderHandleResponderRelease blur input2
blurTextInput input2
TextInput's _onBlur called for input2
```
And now for the bug. Click on input 1, tab to 2, then off
```
// Click on input 1
focusTextInput input1
TextInput's _onFocus called for input1
// Tab to input 2
TextInput's _onBlur called for input1
TextInput's _onFocus called for input2
// Click on blank space
scrollResponderHandleResponderRelease blur input1
blurTextInput input1
```
Notice how `focusTextInput` was never called with input2 in the last example. Since this is the function that sets the `currentlyFocusedField` when we click on the blank space RN is trying to blur the first input instead of the second.
# The root cause
We are tracking the state of which field is focused in JS which has to stay in sync with what native knows is focused. We [listen to _onPress](https://github.com/facebook/react-native/blob/6ba2769f0f92ca75fb0eb60ccb8337920a9c31eb/Libraries/Components/TextInput/TextInput.js#L1103-L1107) and call `TextInputState.focusTextInput` in that handler. However, we don't currently have anything listening to other ways for an input to become focused (like tabbing) so it doesn't end up updating the `currentlyFocusedField`.
We have the same problem with blur that we actually fixed the same way you did here in this PR:
https://github.com/facebook/react-native/blob/6ba2769f0f92ca75fb0eb60ccb8337920a9c31eb/Libraries/Components/TextInput/TextInput.js#L1182-L1189
If you look back at my diagram at the beginning of this post, you'll notice the missing edge from `TextInput._onFocus` to `TextInputState.focusTextInput`. That's the problem. :)
The reason this solution works is because this function **is** the notification from native that an input was focused or blurred. This solution is *fine* because this updates the `currentlyFocusedID` but isn't great because it both sets that value and **calls the native code to focus or blur again**. Luckily the native code doesn't send an event back to JS if you try to blur an already blurred TextInput otherwise we'd have an infinite loop.
# The correct solution
The correct thing would probably be to have all of this tracking in native code and not in JavaScript code. That's a pretty big change though and very out of scope. Something for our team to keep in mind for the future.
A short term term solution would be to refactor `focusTextInput` and `blurTextInput` to pull out the part that sets the `currentlyFocusedID` that we could call from `TextInput` directly from `_onFocus` and `_onBlur`.
# ^This short term term solution is what this commit is doing.
Changelog:
[General][Changed] TextInput no longer does an extra round trip to native on focus/blur
Reviewed By: RSNara
Differential Revision: D18278359
fbshipit-source-id: 417566f25075a847b0f4bac2888f92fbac934096
Summary:
This will allow us to catch cases where we use iOS 10-only APIs on iOS 9
Changelog: [Internal]
Reviewed By: TheSavior, mmmulani
Differential Revision: D18275225
fbshipit-source-id: dc9c515415208db40750be997173ce5bd6eb494f
Summary:
This implementation was replaced in January of 2018 by shergin. I believe everyone should have `RCTVirtualText` at this point, which should make this safe to remove.
Changelog:
[Internal][TextInput] Remove deprecated and unused legacyIOS implementation
Reviewed By: shergin
Differential Revision: D18296981
fbshipit-source-id: b5d5756e7bbc8141f1b826ab07c76a781ab03edc
Summary:
This if statement is older than June 2015. This prop is undocumented, not part of the flow type, not on our public docs, not in the flow type, not in typescript types, and I can't find any blog posts about it.
Changelog:
[Breaking][TextInput] Removing undocumented `inputView` prop. Use children instead.
Reviewed By: yungsters
Differential Revision: D18296894
fbshipit-source-id: 95373d24659e6f06e212095b57e8f6d713323c11
Summary:
I've been working on a new iOS experience with lots of text inputs and this has been driving me a bit nuts…
If you're in a scrollview with `keyboardShouldPersistTaps="handled"` and you tab through your text-inputs, you aren't able to tap outside of a given text-input to blur it (and dismiss the keyboard).
I wrote up a quick explanation and some repo steps here: https://snack.expo.io/BJBcKgrqB
The patch i came up with, after poking around for a little bit seems terrifying - so almost certainly not it. But if it's helpful at all - decided to just got ahead and submit it.
## Changelog
[iOS] [Fixed] - TextInput blur when tabbing in iOS simulator.
Pull Request resolved: https://github.com/facebook/react-native/pull/27038
Test Plan:
I tried to think of a way to test this in jest… but i didn't get very far sorry 😢
I did create a snack here so you can demo the issue: https://snack.expo.io/BJBcKgrqB
I also created two videos…
**Here's the text input not working when i try to blur it after tabbing in simulator**
**Here's it working after I applied this patch**
Thanks!
Differential Revision: D18262867
Pulled By: TheSavior
fbshipit-source-id: 4087f3a27a7e6a146f7f84d7c6e9e8e2b6adc75d
Summary:
Deletes the `selectionState` prop from `TextInput`.
It does not provide meaningful value over `onBlur`, `onFocus`, and `selectionState`.
Changelog:
[Breaking][TextInput] Removing `selectionState` prop, use `onBlur`, `onFocus`, and `onUpdate` instead.
Reviewed By: zackargyle, TheSavior
Differential Revision: D17879667
fbshipit-source-id: 03a4e239406932adad898d6d2a092e3bc2e6b064
Summary: Reverts D14176217 so we can do the partial React sync in the next diff which removes this API
Reviewed By: TheSavior
Differential Revision: D17828977
fbshipit-source-id: 7dd98c19890aeee0a153746ce65fd3b148b4ca7b
Summary:
In React Native there are three types of "Native" components.
```
createReactClass with NativeMethodsMixin
```
```
class MyComponent extends ReactNative.NativeComponent
```
```
requireNativeComponent('RCTView')
```
The implementation for how to handle all three of these exists in the React Native Renderer. Refs attached to components created via these methods provide a set of functions such as
```
.measure
.measureInWindow
.measureLayout
.setNativeProps
```
These methods have been used for our core components in the repo to provide a consistent API. Many of the APIs in React Native require a `reactTag` to a host component. This is acquired by calling `findNodeHandle` with any component. `findNodeHandle` works with the first two approaches.
For a lot of our new Fabric APIs, we will require passing a ref to a HostComponent directly instead of relying on `findNodeHandle` to tunnel through the component tree as that behavior isn't safe with React concurrent mode.
The goal of this change is to enable us to differentiate between components created with `requireNativeComponent` and the other types. This will be needed to be able to safely type the new APIs.
For existing components that should support being a host component but need to use some JS behavior in a wrapper, they should use `forwardRef`. The majority of React Native's core components were migrated to use `forwardRef` last year. Components that can't use forwardRef will need to have a method like `getNativeRef()` to get access to the underlying host component ref.
Note, we will need follow up changes as well as changes to the React Renderer in the React repo to fully utilize this new type.
Changelog:
[Internal] Flow type to differentiate between HostComponent and NativeMethodsMixin and NativeComponent
Reviewed By: jbrown215
Differential Revision: D17551089
fbshipit-source-id: 7a30b4bb4323156c0b2465ca41fcd05f4315becf
Summary:
We need to get rid of findNodeHandle calls so migrating scrollResponderScrollNativeHandleToKeyboard to take a ref to a host component.
I made this change with Flow, and tested by rendering UserJobApplicationForm
Reviewed By: mdvacca
Differential Revision: D17099280
fbshipit-source-id: 96af692006aace2c206f268f5416984b00f8a438
Summary:
We added the accessibilityState property as a more semantically rich way for components to describe information about their state to accessibility services. This PR removes the old accessibilityStates property.
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
## Changelog
[General] [Change] - Remove accessibilityStates property.
Pull Request resolved: https://github.com/facebook/react-native/pull/26168
Test Plan: Ensure that RNTester accessibility examples function properly on both iOS and Android.
Differential Revision: D17152891
Pulled By: cpojer
fbshipit-source-id: d71d3cf0f2e0846979d2ba104b6c69e4e5725252
Summary: Include AndroidTextInputNativeComponent so we can rely on codegen and flow typing in a future diff.
Reviewed By: TheSavior
Differential Revision: D16903634
fbshipit-source-id: 767d7c854533d641eb7fcb2147bf584621581411
Summary:
The documentation from the Flow types' respective proptypes have been copied over to `TextInput`.
## Changelog
[Internal] [Changed] - Added documentation to TextInput's Flow types
Pull Request resolved: https://github.com/facebook/react-native/pull/26054
Test Plan: `yarn flow-check-ios` and `yarn flow-check-android` both pass.
Differential Revision: D16801435
Pulled By: TheSavior
fbshipit-source-id: 7f3d75ba149259d5bbf719375320e2e325188826
Summary:
This pull request moves `TextInput`'s proptypes to `DeprecatedTextInputPropTypes`. This is in line with what is happening with other components.
## Changelog
[General] [Deprecated] - Moved `TextInput`'s proptypes to `DeprecatedTextInputPropTypes`
Pull Request resolved: https://github.com/facebook/react-native/pull/26042
Test Plan: Flow checks pass.
Differential Revision: D16782322
Pulled By: cpojer
fbshipit-source-id: c5f9caa402c0c5cd878e7fff502d380c7b468cbd
Rick Hanlon
Vojtech Novak
Manvir Singh
Tim Yung
Zack Argyle
Samuel Susla
Michael Bolin
Nick Gerleman
Joshua Gross
Janic Duplessis
Hans Halverson
Eli White
Jesse Katsumata
George Zahariev
Valentin Shergin
Jacob Thornton
Andres Suarez
vasilich
Marc Mulcahy
empyrical
