Summary:
Right now having a javascript error like an invalid import statement during first bundle load results in a disappearing redbox screen.
https://github.com/user-attachments/assets/ab9c64f5-6e32-481c-a58f-6d37bb920acb
The `invalidate` call removed in this PR cleans up all turbomodules, including the RedBox module, which in turns calls `dismiss` in `RCTRedBox`.
After removing this line the result is as following:
https://github.com/user-attachments/assets/6eeb4d43-f883-440f-ade3-5628f85f833a
I made sure that the `invalidate` function is still called when executing only two possible ways to reload the bundle:
- the Reload button
- Cmd+R
The HMR/hot reload is not connected if the bundle has an error on initial load, so we don't need to worry about it.
Longer term, it would be better to establish HMR and use a different redbox in this case:
Doing this requires larger changes to the bundle loading flow – happy to to try and land that change if there's any guidance you could give.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS][FIXED] – Fix disappearing redbox on initial load of an invalid bundle.
Pull Request resolved: https://github.com/facebook/react-native/pull/50867
Test Plan: I have tested this change using RN from main and RNTester app (see videos).
Reviewed By: cortinico
Differential Revision: D73511154
Pulled By: cipolleschi
fbshipit-source-id: dfe149ebc15d845f07fd3926db2e063b468870af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50802
The plugin analyses the source of all `import`, `require`, and `export` statements and injects the `console.warn` statement for each path targeting deep react-native source code. It runs only on a dev mode so there is no need to keep that in the `if (__DEV__) ` block. It is possible to disable this plugin by setting `disableDeepImportWarnings: true` and **resetting** the Metro cache:
```js
module.exports = {
presets: [['module:react-native/babel-preset', {
"disableDeepImportWarnings": true
}]],
};
```
Changelog:
[General][Internal] - Added plugin to react-native/babel-preset injecting `console.warn` for each react native deep import in dev mode.
For a given code:
```js
import { Image } from 'react-native';
import View from 'react-native/Libraries/Components/View/View';
const Text = require('react-native/Libraries/Text/Text');
export { PressabilityDebugView } from 'react-native/Libraries/Pressability/PressabilityDebug';
```
The transformed output should look like:
```js
import { Image } from 'react-native';
import View from 'react-native/Libraries/Components/View/View';
const Text = require('react-native/Libraries/Text/Text');
export { PressabilityDebugView } from 'react-native/Libraries/Pressability/PressabilityDebug';
console.warn("Deep imports from the 'react-native' package are deprecated ('react-native/Libraries/Components/View/View').");
console.warn("Deep imports from the 'react-native' package are deprecated ('react-native/Libraries/Text/Text').");
console.warn("Deep imports from the 'react-native' package are deprecated ('react-native/Libraries/Pressability/PressabilityDebug').");
```
For more information about why this plugin was needed, please check [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/894).
Reviewed By: huntie
Differential Revision: D70783145
fbshipit-source-id: ae145db6471d861099566a8faf2fbd93bd136450
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50894
changelog: [internal]
adding more tests to cover all branches of `calculateShadowViewMutationsFlattener`.
calculateShadowViewMutationsFlattener is over 400 lines of code and covers quite a few edge cases. I plan to cover every branch with a test to make it easier to refactor Differentiator in the future.
Reviewed By: rubennorte
Differential Revision: D73543444
fbshipit-source-id: b0b22aba4b9cc4718edd2a6c4535993be437ed9f
Summary:
As the repository is moving towards Kotlin and the tests have also been moving towards mockito-kotlin, I'm doing another round here.
## Changelog:
[INTERNAL] - Flip mockito usages to mockito-kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50878
Test Plan:
```sh
yarn test-android
```
Reviewed By: javache
Differential Revision: D73569293
Pulled By: rshest
fbshipit-source-id: 9bfe7d3f69480367384eafdde429db15eb81d11c
Summary:
Rewrite of JavaModuleWrapper from Java to Kotlin in scope of https://github.com/facebook/react-native/issues/50513
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [CHANGED] - Migrated JavaModuleWrapper to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50882
Test Plan:
Test RNTester using old arch. SampleLegacyModule is the one I've used, it needs to be enabled for old arch though (RNTesterApplication.kt -> getPackages & getReactModuleInfoProvider).
I may enable SampleLegacyModule for old arch to make testing easier. mateoguzmana
It breaks on `getDynamic` on old arch, but I could filter these from examples or add some fallback in SampleLegacyModule.kt for old arch.
Reviewed By: cortinico
Differential Revision: D73576099
Pulled By: javache
fbshipit-source-id: c940be27133258fa589571a600435fa478e6b51e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50863
No need for `shouldReturnInteropModule` if we can just use the nullability of what's returned by `getInteropModule` instead.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D73501845
fbshipit-source-id: 9b7628707edc3eb288733baffaca59a9d3c40b40
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50870
As explained in the doc block, now that ReactInstance is in Kotlin we can move this logic to StackTraceHelper and migrate it to Kotlin
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D73503879
fbshipit-source-id: 38a9ff346e00d68bbc3c383834e2a1763dbba9b8
Summary:
While upgrading a project to React 19, I noticed React.ElementRef is deprecated (see [types/react/index.d.ts#L199](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L199)). I think we can replace it for the RN types as well.
Not sure if this is considered as a breaking change.
## Changelog:
[GENERAL] [CHANGED] - TypeScript: Replace deprecated React.ElementRef usages to React.ComponentRef
Pull Request resolved: https://github.com/facebook/react-native/pull/50883
Test Plan:
Create a RNTesterPlayground.tsx next to the normal .js just to validate the type checking is not throwing an unexpected error.
<details>
<summary>Code snippet:</summary>
```tsx
import React, { useRef, useEffect } from 'react';
import { FlatList, Text, View } from 'react-native';
type Item = { id: string; title: string };
const data: Item[] = Array.from({ length: 10 }, (_, i) => ({
id: i.toString(),
title: `Item ${i + 1}`,
}));
const FlatListScrollRefExample: React.FC = () => {
const flatListRef = useRef<FlatList<Item>>(null);
useEffect(() => {
if (flatListRef.current) {
const nativeRef = flatListRef.current.getNativeScrollRef();
console.log('nativeRef', nativeRef?.componentWillUnmount);
}
}, []);
return (
<FlatList
ref={flatListRef}
data={data}
keyExtractor={(item) => item.id}
renderItem={({ item }) => (
<View style={{ padding: 16 }}>
<Text>{item.title}</Text>
</View>
)}
/>
);
};
export default FlatListScrollRefExample;
```
</details>
Reviewed By: cipolleschi
Differential Revision: D73569274
Pulled By: rshest
fbshipit-source-id: f72477b9b3c0eda1007187c7dac3da0433410e86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50886
changelog: [internal]
Group tests related to reparenting in "describe" block. Differentiator is two algorithms hidden behind a single interface: regular and reparenting. The tests are structured this way as well where regular tests focus on common scenarios and reparenting section focuses on reparenting and special cases around that. The reparenting implementation is considerably more complex as it handles edge cases that don't happen often.
Reviewed By: mdvacca
Differential Revision: D73541053
fbshipit-source-id: c3905a0f0117cb1aa6c468e24e6bb982de48545d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50885
changelog: [internal]
a special case inside of Differentiator handling parent-child switching from unflattened-flattened to flattened-unflattened. If a child has view that is culled, this needs to be handled.
This diff also simplifies the implementation inside of calculateShadowViewMutationsFlattener by passing only one cullingContext.
Reviewed By: mdvacca
Differential Revision: D73523523
fbshipit-source-id: d6f314da6b9ff40bcf3362243b03de1b39e7aabb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50881
Rename Codegen Component Descriptors Entrypoint for FAC and hook it up in DefaultComponentsRegistry
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D73535745
fbshipit-source-id: dad68e7e6c8d7ba2ed86bbd1c06131101e00689e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50851
## Changelog:
[General] [Added] - Add pan gesture animation example to rntester
Including examples of
* using native driven Animated.event + touch event (which will not be interrupted by busy js thread, and is potentially a boost to performance) - the code requires some hacks but it's doable
* using js PanResponder to drive pan gesture animation
Reviewed By: sammy-SC
Differential Revision: D68909931
fbshipit-source-id: 484ecb0646fb249b31362013725219a1c1ec6181
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50879
The view for a view manager should not be nullable. Let's fix that.
These are also all bound specifically to `ReactTextView` instead of the generic constraint, so I just changed the constraint. Really this should just be totally merged with `ReactTextViewManager`.
Changelog: [Internal]
Reviewed By: cortinico, rshest
Differential Revision: D73453631
fbshipit-source-id: 74bcadeef0e83a719dfe2b989784501575b58168
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50753
Runtime Shadow Node Reference Updates (RSNRU) is currently implemented through the clone method which on each internal clone updates the runtime reference to point to the new clone. This guarantees that the runtime reference always points at the latest revision of the shadow node.
This came with the constraint that RSNRU could only run from one thread at all times, otherwise the React renderer state (current fiber tree) would end up being corrupted by receiving reference updates from multiple threads cloning shadow nodes.
This change moves the reference update step to the locked scope of the commit phase. Since the runtime is blocking on the commit and the scope is locked, it is safe and correct to update the runtime references with the latest revision of the shadow node after running state progression and layout.
By moving the reference update to the commit, we can support shadow node syncing from any thread since the actual runtime references are now executing at a safe time and the renderer state will stay valid at all times.
This change is gated behind the `updateRuntimeShadowNodeReferencesOnCommit` feature flag, which enabled shadow node syncing from any thread and reference updates only during the commit.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D73038439
fbshipit-source-id: d90308498f3c0625dc87158f15311d1088aad8b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50752
Storing the runtime reference for a shadow node and updating the runtime reference to point at a specific shadow node should be separated so that these actions can be done at different moments in time.
We want to keep a reference to the runtime reference of a shadow node for all revisions cloned internally (not triggered by the React renderer, e.g. on layout or shadow node state updates).
We also want to support updating that runtime reference to point at a specific shadow node revision, ideally the one that will end up being used to mount the host component.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D73038438
fbshipit-source-id: 68c3912cbb077d790dd8d2abe8291548b12c8231
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50877
At some point I made some changes to how alpha works on BackgroundDrawable. This inadvertently broke BackgroundImage because we need a non transparent color to apply shaders.
Setting the alpha to 255 temporarily when drawing background-image layers fixes it
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D73520952
fbshipit-source-id: b8017bb06adc0d3d328d9831fbc4c74f2ec0b783
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50876
This diff is temporarily reverting the code shipped in D72671083 to wait for more data before fully release this change
changelog: [internal] internal
Reviewed By: rshest, arushikesarwani94
Differential Revision: D73515903
fbshipit-source-id: 6566e9533ebffc93348e24eb6c0512020b220eae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50533
Builds upon https://github.com/facebook/react-native/pull/49446
On iOS, by default, every EditText accepts DragEvent and will automatically focus themselves to accept these data. In some rare cases, it might not be desirable to allow data from arbitrary drag and drop events to be pasted into a text input.
This change adds a new prop `acceptDragAndDropTypes` to do exactly that: reject drag and drop events by telling the system to ignore certain types of drag data and, by proxy, disabling behavior that automatically focuses the text input.
The prop accepts a list of [Uniform Type Identifiers](https://developer.apple.com/documentation/uniformtypeidentifiers) that iOS supports. It's important to note that these are *not* MIME types. A MIME type would be something like `text/plain` but the equivalent for iOS is `public.plain-text`.
It's important to note that this is an experimental prop, as is evident by the `experimental_` prefix on the JS side. Its signature could change before the prop has fully matured, use at your own risk
Changelog: [iOS][Added] - Add new prop for filtering drag and drop targeting to text inputs
Reviewed By: javache
Differential Revision: D70992749
fbshipit-source-id: 22b5aa1b4ced14147bf16a844361acf6f99c5a40
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49446
On Android, by default, every EditText accepts `DragEvent` and will automatically focus themselves to accept these data. In some rare cases, it might not be desirable to allow data from arbitrary drag and drop events to be pasted into a text input.
This change adds a new prop `acceptDragAndDropTypes` to do exactly that: reject drag and drop events by telling the system to ignore certain types of drag data and, by proxy, disabling behavior that automatically focuses the text input.
The prop accepts a subset of MIME types supported by Android as documented [here](https://developer.android.com/reference/android/content/ClipDescription#MIMETYPE_TEXT_HTML).
It's important to note that this is an experimental prop, as is evident by the `experimental_` prefix on the JS side. Its signature could change before the prop has fully matured, use at your own risk
Changelog: [Android][Added] - Add new prop for filtering drag and drop targeting to text inputs
Reviewed By: javache
Differential Revision: D69674225
fbshipit-source-id: 4dbbdd81bb0f394b6206da5a377c75ea71671626
Summary:
Some libraries still use the `folly_flags` method provided by our infra. When updating how folly should be installed in an app, we removed that function.
We are putting it back as deprecated, to avoid unnecessary breaking changes in libraries
## Changelog:
[iOS][Fixed] - Put back the `folly_compiler_flag` function to make libraries install pods
Pull Request resolved: https://github.com/facebook/react-native/pull/50875
Test Plan: Tested locally in a nightly app, using the react-native-exit-app library which still uses these flags
Reviewed By: cortinico
Differential Revision: D73512830
Pulled By: cipolleschi
fbshipit-source-id: 28f099064e93ecd5a5a6a7b82e3f7e9db4d35cb9
Summary:
`SocketRocket` and `fmt` are part of React Native dependencies.
If a library is written in swift and depends on them, it will fail to install the pods because these pods are not compatible with Swift.
This change makes sure that the pods are installed in a way that is swift compatible.
## Changelog:
[iOS][Fixed] - Make fmt and SocketRocket Swift friendly
Pull Request resolved: https://github.com/facebook/react-native/pull/50874
Test Plan:
Tested locally in a nightly app.
### Before the change:
```
yarn add react-native-video
cd ios
bundle exec pod install
```
This script resulted in this error:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `react-native-video` depends upon `fmt` and `SocketRocket`, which do not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
### After the change
```
yarn add react-native-video
cd ios
bundle exec pod install
```
This script installed pods successfully.
Reviewed By: cortinico
Differential Revision: D73512109
Pulled By: cipolleschi
fbshipit-source-id: 222d85dba1cbdf4044e3c8459008a4083a720016
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50846
## Motivation
After a more rigorous search through GitHub uses of the restricted APIs, and consultation with framework authors, it became apparent that this restriction should be lifted.
Changelog: [Internal]
Reviewed By: zeyap
Differential Revision: D73267844
fbshipit-source-id: e6c0c146690c07debf74c51f82171a9239be5c15
Summary:
the `react-native-maps` library has a complex setup for iOS. It doesn't work with autolinking, therefore we need to disable the test with the nightlies
## Changelog:
[Internal] - Disable nitghtly test for react-native-maps
Pull Request resolved: https://github.com/facebook/react-native/pull/50873
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D73510995
Pulled By: cipolleschi
fbshipit-source-id: a8abadfc8f0656de1288aa28e65abeab07bb9074
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50852
changelog: [internal]
Adding a test to verify view culling in scenario where a subtree is revealed and part of it is culled.
Reviewed By: lenaic
Differential Revision: D73454202
fbshipit-source-id: 6c4fb2ec4757b9ed1460bec8d3f02a661470266f
Summary:
Fixes https://github.com/facebook/react-native/issues/50010
On the initial render of a Text with the `selectable` prop set as `true`, the Text view is not making itself selectable. I debugged this quite a lot, and by changing the state from false to true using `setState` on the JS side, I made it work.
It turns out that we are setting this property in `onAttachedToWindow`, but somehow if `super.setTextIsSelectable` was already set as `true`, it won't re-apply it and we have to reset it to false before setting it again to true. This PR adds this reset.
I couldn't understand yet why this is not breaking in Fabric.
## Changelog:
[ANDROID] [FIXED] - Fix `selectable` prop not working correctly on initial render (old-arch)
Pull Request resolved: https://github.com/facebook/react-native/pull/50822
Test Plan:
- Test in both Fabric and Paper architectures to ensure there won't be a regression with this change in Fabric, as the issue occurs only in Paper.
- To test this, I created a small example in the RN-Tester playground to toggle the selectable property on/off. Notice in the first video that initially the prop is set as true, but it won't allow selecting. If you toggle to false and then back to true again, it works. With the provider fix it should also allow selecting the text on initial render.
Use this code snippet:
```tsx
function Playground() {
const [selectable, setSelectable] = React.useState(true);
return (
<View style={styles.container}>
<Text selectable={selectable} selectionColor="blue">
TESTING: is selectable? {selectable ? 'true' : 'false'}
</Text>
<Button title="Press me" onPress={() => setSelectable(!selectable)} />
</View>
);
}
```
Videos:
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/6a24dd0d-7f45-4a38-b18d-5142801ea1c3
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/ce5f9e6e-9a4c-44d7-9d97-f607f2fdc1b4
</details>
Reviewed By: cortinico
Differential Revision: D73421487
Pulled By: rshest
fbshipit-source-id: c0b9d76076ef2e05930996953015fb58ad2a3d5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50858
changelog: [internal]
This test verifies that React commits can override values previously set by `setNativeProps`. The test demonstrates the proper reconciliation behaviour between imperative updates via `setNativeProps` and declarative updates via React renders.
Reviewed By: lenaic
Differential Revision: D73463364
fbshipit-source-id: 3504d9a23bfc36a46fdfc4e9bf585f64088ab518
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50849
changelog: [internal]
Previously we didn't have a way to properly test bug reported in https://github.com/facebook/react-native/issues/47476. But with Fantom we do! Let's write a test for it to make sure this is not broken in the future.
Reviewed By: rubennorte
Differential Revision: D73432279
fbshipit-source-id: dbc1ce9d7b34bbe4275f6b8b1ce3a1c48bca3504
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50854
changelog: [internal]
In D73437449 I accidentally introduced a deadlock for single threaded testing environments. Here, I resolve the flakiness and the deadlock.
Reviewed By: mdvacca
Differential Revision: D73457182
fbshipit-source-id: 242edd4443b354cda4b082c2d45d8df04033cfd0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50827
This diff addresses a crash caused by view duplication in React Native Android. The issue occurred when a view was not already clipped and was laid out again, resulting in duplicated views.
This problem was particularly noticeable when using nested FlatLists, which triggered a custom focus search with an incomplete and buggy duplicated FlatList container view.
The fix involves preventing the duplication of views by checking if a view is clipped already before laying it out again. Additionally, this diff includes two other improvements:
- Preventing clipping issues: When a view is nested within a non-ReactClippingViewGroup ancestor, focus searching would fail due to the needUpdateClippingRecursive logic only running on instances of ReactClippingViewGroup. By excluding these ancestors, we ensure that the next focusable view can be properly excluded from being clipped.
- Minor fix: A minor fix was made to prevent potential issues in deeply nested cases.
- Add a Kill switch with a feature flag and mobile config combo. For Facebook we can kill through MC and for all other apps we can kill with the feature flag default value
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D73213775
fbshipit-source-id: 51a667a0c22eb35f0ec46ac4cbe430e2e62b407b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50826
Pull Request resolved: https://github.com/facebook/react-native/pull/50105
Pull Request resolved: https://github.com/facebook/react-native/pull/49543
When using `ReactScrollView` or `ReactHorizontalScrollView` Views with `removeClippedSubviews` keyboard navigation didn't work.
This is because keyboard navigation relies on Android's View hierarchy to find the next focusable element. With `removeClippedSubviews` the next View might've been removed from the hierarchy.
With this change we delegate the job of figuring out the next focusable element to the Shadow Tree, which will always contain layout information of the next element of the ScrollView.
We then prevent the clipping of the topmost parent of the next focusable view to lay out the entire containing element in case we have some necessary context in the parent
Changelog: [Android][Fixed] - Fix keyboard navigation on lists with `removeClippedSubviews` enabled
Reviewed By: NickGerleman
Differential Revision: D73114782
fbshipit-source-id: 081a2216037e033a4638151e5226f430ac093ea5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50825
Pull Request resolved: https://github.com/facebook/react-native/pull/50404
Add another function to fabric to get the topmost stacking context parent given a root and a child.
This is to be used on focus searching algorithm in the case where the next focusable child is deeper in the hierarchy meaning we need to find the top most parent in the Android hierarchy and lay that out as well before transferring focus.
If we don't lay out the parent as well as the next focusable view:
- The next focusable view might lack context given by the parent
- If the parent is a scrollview and has removeClippedSubviews enabled then laying out the next focusable view will not work
- If the view is deeper in the android hierarchy in some cases it won't be layed out unless the parent is
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73114933
fbshipit-source-id: 081720199943eff78966982a5fd1c921d4e105fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50824
Pull Request resolved: https://github.com/facebook/react-native/pull/50196
Currently when `removeClippedSubviews` is enabled on Android keyboard navigation breaks and we can never focus the elements that are clipped. iOS has a similar issue but not as drastic, it only happens when elements on the FlatList have a lot of margin between them.
This algorithm aims to find the next focusable view and return it to native so that we can prevent the clipping of the view on the view clipping algorithm and hence fix keyboard navigation. For more information see D71324219
Fabric algorithm to find the next focusable view given:
`parentTag`: Top most relevant parent of the focused view
`focusedTag`: Tag of the currently focused view
`direction`: Direction in which focus is moving
EDIT AFTER AMA SEV 3 S510469:
This whole algorithm was based on the idea of fixing focusing within a ScrollView. What we didn't consider is that focus search could be triggered when focusing a pop-up view. This includes transfering focus to an element on a new page or a modal which means that in some cases the parent view could be removed from the hierarchy.
Just add null checks to the parent node and the currently focused node to prevent unexpected crashes.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73115104
fbshipit-source-id: b9c9314fbd4b97da23c0b941d34f4dc2a1a3b883
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50823
Introduce a trait to be able to tell if a ShadowNode is focusable by keyboard. This will be used for focus ordering that delegates the work to the shadow tree when Native platforms don't have enough information to define the next focusable node
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73114986
fbshipit-source-id: eed8642db0c65b6f54808d681640bb605cb6e0aa
