Summary:
This was added to the flow type and example in D18275225 but not added to the prop-type
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18431253
fbshipit-source-id: ffe4eaa8bd9dd22bf7c1487873c9fbdb7b226e3d
Summary:
This is the second half of https://github.com/facebook/react-native/issues/26976 (the CocoaPods update did not make it to `master`).
RSNara hramos fkgozali PeteTheHeat - Please take a quick look and comment if there are any known issues with using the latest stable version of CocoaPods. Thanks! 🙏
It seems like the older version of CocoaPods has a bug that _lowercases_ the spec repo url, even in the unfortunate case that the repo maintainers use upper case characters. This would essentially revert what was fixed in https://github.com/facebook/react-native/issues/26976.
## Changelog
[General] [Changed] - Update RNTester CocoaPods to 1.8.4
Pull Request resolved: https://github.com/facebook/react-native/pull/27173
Test Plan:
```
cd RNTester
bundle install
bundle exec pod install
```
Reviewed By: RSNara
Differential Revision: D18413420
Pulled By: mdvacca
fbshipit-source-id: 9c8794054f6e831a4a41ca96944767240c1462bf
Summary:
Changing PanResponderExample to use React state instead of setNativeProps. Fabric likely won't have setNativeProps so this is a conversion in that direction. This is probably one of the most complicated usages of setNativeProps and it feels *okay* with React state. I'm sure it is worse on lower end devices though.
In general we know that going to JS for an animation is not the correct approach so this getting worse in Fabric is probably fine for that reason too. Staying in native with something like react-native-gesture-handler is probably more aligned with the future.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D18258130
fbshipit-source-id: eed6a8eb839c6607463f3140191945ea753a697b
Summary:
In this diff we integrate the Picker component on Android in Fabric. Since both AndroidDropdownPickerNativeComponent and AndroidDialogPickerNativeComponent use `style?: ?TextStyleProp`, which is not supported by the JS codegen, I had to handwrite the C++ files and check them in.
The component is not fully functional yet because `setNativeProps` is not supported in Fabric. I will fix this in the next diff.
Changelog:
[Android] [Added] - Integrate Picker into Fabric on Android
Reviewed By: mdvacca
Differential Revision: D17954435
fbshipit-source-id: 6b7b029ab0c84c27a48c7dddd66878c9dea324bf
Summary:
Code frame columns are returned 0 based but displayed in editors 1 based, this diff bumps the column we display by one to match.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18426163
fbshipit-source-id: 2c6aefb6fe7ce161cd768b6748b7739d486ed438
Summary:
Changelog: [internal]
if you called `ContextContainer.insert("key", <value>)` and then again `ContextContainer.insert("key", <new_value>)`, the old value will remain in `ContextContainer`. This seems to be by design however it causes crash when reloading surface that uses `ComponentDescriptorRegistry_DO_NOT_USE_PRETTY_PLEASE`.
We fix it by erasing `ComponentDescriptorRegistry_DO_NOT_USE_PRETTY_PLEASE` in Scheduler before inserting a new one.
Reviewed By: shergin
Differential Revision: D18421153
fbshipit-source-id: a01e5f6ac864fd641674d84e97d447f8cb9114be
Summary:
Changelog: [internal] Fixes fabric specific crash
`_viewRegistry` is not thread safe and accessing it on another thread can cause a crash.
Calling it inside `RCTUnsafeExecuteOnMainQueueSync` shouldn't degrade performance because it is only used as a fallback.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D18421789
fbshipit-source-id: 2adff434afe0a3c19318c95b051ee91ccf6293e5
Summary:
This pull request migrates the animated flip example in `TransformExample` to using React Hooks.
## Changelog
[General] [Changed] - RNTester: Migrate TransformExample to hooks
Pull Request resolved: https://github.com/facebook/react-native/pull/27181
Test Plan: The animation works exactly as it did as when it was a class component
Differential Revision: D18418200
Pulled By: mdvacca
fbshipit-source-id: 129298319dbf1774d06fe5c6e5ab60cd028449bb
Summary:
ScrollView isn't using codegen, therefore we need to manually write commands interface. I also typed commands so it uses `Double` instead of `number`.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D18371887
fbshipit-source-id: 3bd11b9969b80ce6d2302e2f0da28884e9221b7e
Summary:
This pull request adds a missing key attribute to an array of elements in the example for `NewAppScreen`. This results in the "missing key" warning no longer appearing when viewing this example.
## Changelog
[General] [Fixed] - RNTester: Add missing key attribute in NewAppScreen example
Pull Request resolved: https://github.com/facebook/react-native/pull/27180
Test Plan: When viewing this example in RNTester, this warning is no longer printed.
Differential Revision: D18418198
Pulled By: mdvacca
fbshipit-source-id: 8fbe51da7b714e3e94fd2186ea8cc4e3606d9f95
Summary:
This diff fixes the algorithm that collapses mutation instructions in Fabric Android
The problem was that we were always relying on the fact that the oldShadowNode is present as part of the mutation instruction (which is not correct for mutation instructions of type CREATE)
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18411360
fbshipit-source-id: 36f5e75f792db87003fcaef2ddcd9452415a0ad6
Summary:
With this diff (and maybe other coming in the future), we are enforcing a model where Fabric Core actively/architecturally prevents `jsi::Object` to overlive `UIManager`. That never was a promise that but I think it's achievable; it should help to eliminate the whole class of possible crashes (application layer still must ensure that Scheduler is deallocated before `jsi::Runtime`).
Clearing all pointers to `ShadowNode`s in `MountingCoordinator` prevents from extending the lifetime of ShadowNodes stored inside revoked `MountingCoordinator` (the lifetime of `MountingCoordinator` is up to application layer).
That should help prevent crashes (not all of them!) caused by `jsi::Object`s overliving `jsi::Runtime`.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18333708
fbshipit-source-id: 4391998b8f805563cfaff834fc56e85b98bc4d68
Summary:
This diff updates the configuration of collapsing of mounting instructions to be disabled by default (in case the user didn't get any value from the server)
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18411934
fbshipit-source-id: 21f9ca525c28134800e929407c5a1e29a84de68e
Summary:
We are going to be switching event target and current target from being a reactTag to being a host instance.
This doesn't actually change what the actual type of this key is, but is split out like this to make diffs smaller and easier to review. Actual behavior changes will be coming and tested in a future diff.
These are the only callsites I found that use target outside of the React renderers.
The other approach this change could take would be to make all the downstream callsites take both a tag or a HostComponent. That felt too difficult to do at the same time so I'm instead introducing these `findNodeHandle` calls temporarily.
The main thing we need to do is be able to change the callsites in the renderer to start sending the instance. Once everything is passing the instance instead of the tag then we can clean all these up cleanly.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D18384435
fbshipit-source-id: b3a7e6a2778cb7dd9cdfe451cf869cd99641b167
Summary:
We are going to be switching event target and current target from being a reactTag to being a host instance.
This doesn't actually change what the actual type of this key is, but is split out like this to make diffs smaller and easier to review. Actual behavior changes will be coming and tested in a future diff.
These are the only callsites I found that use `currentTarget` outside of the React renderers.
Changelog:
[Internal]
Reviewed By: zackargyle, yungsters
Differential Revision: D18382470
fbshipit-source-id: 23add5498b38dc109b154479826f701c8a1920b9
Summary:
There's a Wilde OOM. We suspect that RCTTiming's conversion to TurboModule could be the cause. There could be a memory leak in the TurboModule system that RCTTiming exposes, or RCTTiming itself could have a memory leak. Therefore, I'm making RCTTiming a regular NativeModule for now.
Changelog:
[iOS][Changed] - Make RCTTiming a regular NativeModule
Reviewed By: fkgozali
Differential Revision: D18410788
fbshipit-source-id: 29567f899dcb82988bc265242e98cc35e878e749
Summary:
`mem` package vulnerability found.
> In nodejs-mem before version 4.0.0 there is a memory leak due to old results not being removed from the cache despite reaching maxAge. Exploitation of this can lead to exhaustion of memory and subsequent denial of service.
ref: https://github.com/sindresorhus/mem/commit/da4e4398cb27b602de3bd55f746efa9b4a31702b
`relay-compiler` depends on that.
```
relay-compiler@6.0.0
└─┬ yargs@9.0.1
└─┬ os-locale@2.1.0
└── mem@1.1.0
```
Pull Request resolved: https://github.com/facebook/relay/pull/2934
Test Plan:
- Tested the Relay compiler briefly on the open source examples project, seems like yargs doesn't error
- `js1 build relay --project facebook`
- `js1 jest`
Reviewed By: alunyov
Differential Revision: D18397131
Pulled By: kassens
fbshipit-source-id: 8b7fc5e237c7b4ce14ff3809cdd59d243e7c4523
Summary:
In D17880909 I migrated `[bridge reload]` to RCTReloadCommand.
One thing I didn't consider too much is the plethora of things which trigger a reload, and the `RCTAssertMainQueue()` constraint. I'd rather use locking (to protect listeners list) than requiring reloads be called from main thread.
Changelog: [iOS][Fixed] Fix potential assert firing in RCTReloadCommand
Reviewed By: rodrigos-facebook
Differential Revision: D18353156
fbshipit-source-id: d20b851fc5fe6c3518dfa3db8f1fc075cf7edee9
Summary:
These NativeModules aren't necessary. So, instead of making them TurboModule-compatible, I'm deleting them.
Changelog:
[General][Removed] - Remove Sample and CrashyCrash
Reviewed By: fkgozali
Differential Revision: D18361526
fbshipit-source-id: 3217130a5fb32bec9db78d53c5429bae7ed7b66c
Summary:
PushNotificationiOS wasn't used by anything in ReactInternal, so I just removed it from the target.
## Codemod
Everywhere we required `ReactInternal`, we now also require `RCTPushNotification`:
```
> xbgr -f 'BUCK$' 'ReactInternal"' -l | xargs -I {} sed -i '' $'s|ReactInternal",|ReactInternal",\"fbsource//xplat/js:RCTPushNotification",|g' $HOME/{}
> xbgr -f 'BUCK$' 'ReactInternalApple"' -l | xargs -I {} sed -i '' $'s|ReactInternalApple",|ReactInternalApple",\"fbsource//xplat/js:RCTPushNotificationApple",|g' $HOME/{}
> arc f
```
Changelog:
[Internal] - Separate RCTPushNotification from ReactInternal
Reviewed By: PeteTheHeat
Differential Revision: D18363643
fbshipit-source-id: b8d123f40741c6d200dc9e736e64e885c2572e15
Summary:
None of the code inside `ReactInternal` depended on the `RCTLinkingManager` NativeModule. So I extracted `RCTLinking` into its own BUCK target. This will make it easier to make `RCTLinkingManager` TurboModule-compatible.
## Codemod
Everywhere we required `ReactInternal`, we now also require `RCTLinking`:
```
> xbgr -f 'BUCK$' 'ReactInternal"' -l | xargs -I {} sed -i '' $'s|ReactInternal",|ReactInternal",\"fbsource//xplat/js:RCTLinking",|g' $HOME/{}
> xbgr -f 'BUCK$' 'ReactInternalApple"' -l | xargs -I {} sed -i '' $'s|ReactInternalApple",|ReactInternalApple",\"fbsource//xplat/js:RCTLinkingApple",|g' $HOME/{}
> arc f
```
Changelog:
[Internal] - Separate RCTLinking from ReactInternal
Reviewed By: fkgozali
Differential Revision: D18314747
fbshipit-source-id: d9b5f536a6e93a0aca8721801a2ee5d446e0d4a6
Summary:
Changelog: [Internal]
Reverting the import to the previous local module style since importing from react-native seems to introduce some perf regression. We'll revisit this later in the future.
Reviewed By: yungsters
Differential Revision: D18383893
fbshipit-source-id: f11d46a4545768f39199fd6fd22fcf14905d0a74
Summary:
This diff changes the LogBox to show the code frame for the first non-collapsed stack frame. Let me know what you think about this change!
Changelog: [Internal] LogBox changes
Reviewed By: rickhanlonii
Differential Revision: D18372456
fbshipit-source-id: ddf6d6c53ab28d11d8355f4cb1cb071a00a7366e
Summary:
This diff adds error handling to logbox so that if there is an error either when parsing logs or when rendering LogBox, we show a native redbox with the error that was thrown and a message explaining that it's an internal React Native error.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18394788
fbshipit-source-id: 5d74d58e4b28ef6d863079e83677fb23ef4ccb34
Summary:
I'll land this once the upgrade to v0.111 is rolled out here. That release turns this flag on by default.
Changelog: [Internal] Adjust Flow configuration
Reviewed By: panagosg7
Differential Revision: D18329245
fbshipit-source-id: a9ab92fda06d546f3246dcdd066e904b5a657062
Summary:
The diff moves an invocation of `_synchronizeAllSettings` from the constructor to `setBridge`. The side-effects of `_synchronizeAllSettings` rely on a bridge not being nil, so we need to ensure that the bridge is assigned to the instance before calling `_synchronizeAllSettings`.
Before the fix, enabling JavaScript debugger caused a stale and opening many copies of a debugger in Chrome.
Changelog: [Internal] Fixed race and possible stale in RCTDevSettings
Reviewed By: RSNara
Differential Revision: D18379596
fbshipit-source-id: 9f64b9bc5426720948113de61bc9ccc8c39193b4
Summary:
The documentation for the method says that it must be called from a subclass, but the methods wasn't marked as protected.
Calling `beat` directly will bypass custom logic implemented in subclasses (because it's not a virtual function (by-design)). That's practically what happened before and what the previous diffs in the stack fix.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18339594
fbshipit-source-id: 3d8c53b69e1b72d447714dd91c9392bdfb05b9ae
Summary:
This diff changes the implementation a little bit:
* We don't use RuntimeExecutor there anymore (because it's already been used in EventBeat). The actual purpose of EventBeatManager was distilled to "provide a tick synchronized with the main run loop";
* Now we use dedicated EventBeatManagerObserver interface to decouple this functionality from EventBeat-intrinsic functionality;
* A bunch of small clean-ups.
* Now we ensure threading and capturing ownership in a single function in AsyncEventBeat class. Before this change, the EventBeatManager called `beat` function of the EventBeat directly bypassing AsyncEventBeat class, and effectively bypassing the check that underlying infra still exists (aka EventBeat::OwnerBox feature). That alone might fix some C++ crashes that we see.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18307655
fbshipit-source-id: 3b582cb71085ed99ee94f8e6d575196c2082557b
Summary:
* We no more pollute the global namespace with JSI stuff;
* We don't use JSI here, so why to include;
* We don't use `Instance`, so why to forward-declare this;
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D18307654
fbshipit-source-id: b6c3ad55d7bd605074db9fa1d4bc58a73e0b2d74
Summary:
The C++ counterpart of EventBeatManager uses RuntimeExecutor for that, so it's redundant to do that in EventBeatManager.java.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18307657
fbshipit-source-id: 65823b25d691a56540247d317e3c0e86685150c8
Summary:
This diff adds the ability to press the file name of a code frame to open the file in your editor.
Note: I re-worked the frame location to extract the frame row and column at parse time so that we don't need to do any clowny regexes down stream.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18358283
fbshipit-source-id: 705e07d229c66ecfd225a8fb65ef2f78b5034c9c
Summary:
This diff adds more information to the meta area so it doesn't look so empty and dims the text so it doesn't jump out so much.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18360434
fbshipit-source-id: d460ffd59ef032d89879f88e309ac81e6d862c30
Summary:
Interop layer can now forward commands to paper components.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D18285766
fbshipit-source-id: 33fe071c3000569d52fedcbcdeccc354dfe277d9
Summary:
Based on feedback "minimize" wasn't clear and "close" is more common so it should be on the right
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18353907
fbshipit-source-id: bccfc9be6c225a9adb31ef11d6a91330a7d4e008
Summary:
This diff lowers the intensity of the shadow on the fatal button based on user feedback that it's weird.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18353498
fbshipit-source-id: 9133aae02e5609e181a55289f349ea6a9e9fdaf6
Summary:
It's nice to be able to still see which stack frames are collapsed even when they're expanded.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18352700
fbshipit-source-id: f76086574677ea58c6b19b3300597681a17a96ae
Summary:
The previous diff mistakenly landed an old version
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18358917
fbshipit-source-id: 284dd6754c4aea3814e5f45dae6f68ed2c261b6a
Summary:
This implement new <UnimplementedView> (only for iOS for now) that relies on the new "reactive component registration" functionality.
The `UnimplementedView` component is the perfect example of that. It's simple and uniquely required some constraints that we want to implement: the same component class registered several times with different handles and names.
This change serves two needs:
1. Providing an example of how that functionality can be used in more complex cases.
2. That will allow removing some `UnimplementedView`-specific code from the core (and very hot pathes of the system) and make them `noexcept`. That will eventually allow removing some public APIs from RawValue (constructing from folly::dynamic) that currently impose some implementation details and probably prevent us from making it slightly faster. There are only two consumers of this API, this is one of them.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D17211913
fbshipit-source-id: df1a1ac1a36289ef79904d509d38ee8b3f5588fb
Summary:
It's a logical error on the application layer if a Scheduler is being deallocated before all Surfaces were stopped. Besides that this requirement must be satisfied to make concurrent deallocation of Scheduler and calling on it from `UIManager` side thread-safe.
Changelog: [Internal]
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D18333709
fbshipit-source-id: 4af0ba488bb4306eb82807c2f0ee5b7c598dcfed
Summary:
There is no need for that functionality to be delegated to Scheduler, that's a leftover of the previous iteration of the design.
Nothing really changed.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18285501
fbshipit-source-id: 4b60445b663a2431fbdc7cc1120f46d56819c430
Summary:
Now `UIManager` serves as `ShadowTree`'s delegate instead of `Scheduler`.
There is no good reason for Scheduler to be a ShadowTree delegate anymore, now UIManager owns all ShadowTree instances (via the registry). The existing configuration causes a crash because `ShadowTree` can overlive the `Scheduler`. Having a `UIManager` as a delegate of `ShadowTree` solves the problem because `UIManager` checks the own delegate for (which is actually a Scheduler) nullability before calling something on it (and `Scheduler` nulls that delegate during own deallocation process).
(No actual ownership relations were changed in the diff.)
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18285500
fbshipit-source-id: 35ac4f37b6abdf4857a23c4869785a323e433317
Summary:
This diff removes `ComponentDescriptorProviderRegistry::remove()` and two derivative interfaces.
First, we don't use that and there is no concrete idea why we would need to use that. Those were originally built only for symmetry with limited knowledge about what exactly we need.
Second, those methods are actually dangerous and probably must not be supported by design. Removing a ComponentDescriptorProvider destroys already registered `ComponentDescriptor`s, and at the same time we might have ShadowNodes referring to that (which will cause a crash), and there is no reasonable way to check for the existence of those nodes.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18285497
fbshipit-source-id: b461e38b923c217a256e1155689311397a994feb
Eli White
Frieder Bluemle
Oleksandr Melnykov
Rick Hanlon
Samuel Susla
empyrical
David Vacca
Valentin Shergin
Ramanpreet Nara
Shingo Sato
Peter Argany
Kevin Gozali
Christoph Nakazawa
Nat Mote
Essam Ewaisha