Summary:
Changelog:
[Internal][Add] - Build the basic RCTLocalizationProvider
RCTLocalizationProvider is to enable the localization in fabric. But I'd start with internal apps now.
Reviewed By: PeteTheHeat
Differential Revision: D22704051
fbshipit-source-id: 845693a131c325f3c3d92b2ff491d5421966ad3e
Summary:
Changelog:
[Internal] - Add default value for accessibilityState "checked" and handle unhandled states.
It is also work for the case that accessibilityRole = "switch" and accessibilityState is set.
Reviewed By: sammy-SC
Differential Revision: D22914427
fbshipit-source-id: 4767a21f3bd109019b57bc09918758a38fbdea93
Summary:
as title. The output of Buck suggested I add this, so I did and it let me build.
Changelog:
[Internal][Fixed] - Added iOS 10 method compatibility macro
Reviewed By: PeteTheHeat
Differential Revision: D22955013
fbshipit-source-id: 6aa03b164adca480e7c6f661b221c9bd3ee6c4f1
Summary:
Changelog:
[Internal] - Add UIContentSizeCategoryDidChangeNotification to re-render text
We don't need to restart the app to re-render text now, but we still need to swipe the screen or click on buttons to force to refresh. We may address this in the future.
Reviewed By: PeteTheHeat
Differential Revision: D22867293
fbshipit-source-id: 4747a45adc2bdc638cf7ef9c07a9484e48600583
Summary:
The implementation of RuntimeExecutor must execute all provided callbacks. However, the implementation of RCTRuntimeExecutorFromBridge cannot guarantee it because it relies on Bridge to make the call. In this diff, we wrap the callback into a callable that asserts if it's not being called before destruction.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D22810439
fbshipit-source-id: f11932019ab6ccbab7e65db5919e0c64dcaf37ed
Summary:
The implementation of RuntimeExecutor must execute all provided callbacks. However, the implementation has some branches that lead to such cases. To understand if this happens and when we need to add some asserts.
Changelog: [Internal] Fabric-specific internal change.
Differential Revision: D22810440
fbshipit-source-id: 7c29b765045b644fe0ad9d56b4c253dfe9395c31
Summary:
Hook up onSuccess and onFailure callbacks to LayoutAnimations.
Note that in non-Fabric RN, onSuccess is not known to work in Android. I could not find any uses of onFailure and it's not documented, so for now, it is only called if the setup of the animation fails.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22889352
fbshipit-source-id: 4306debb350388dd2b7a2cbfe295eb99723988e2
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
Summary:
Using RCTFabricSurface in bridgeless mode, this comment seems incorrect to me.
`[_surface start]` needs to be called after initialization, or else the stage and `SurfacePresenter` registration never happen.
Maybe this comment used to be true, but it is misleading with the current implementation.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22800934
fbshipit-source-id: c396cbd3fc1749b8e7ab571c9e7bc05cd352fc14
Summary:
Changelog:
[Internal] - Add additional tests to cover other features in RCTParagraphComponentView.
I mainly test the correctness of attributedString and fragments in the RCTParagraphComponentView.
Reviewed By: shergin
Differential Revision: D22668022
fbshipit-source-id: 6879eb6b6a6ace9e6e05f1486d4e4034ebfd73bc
Summary:
Changelog:
[Internal] - Build the basic RCTParagraphComponentViewTests. Add the content of tests.
I mainly test the cases of text with multiple links inside, text with link which crosses multiple lines and truncated text with link.
Reviewed By: shergin
Differential Revision: D22607097
fbshipit-source-id: c98b8d4c5424a3e51e2869f50bc5038f969e45e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29470
Changelog:
[Internal] - Build the framework of the RCTParagraphComponentViewTests and do some setup.
I built a shadowNode tree here for future tests.
Reviewed By: shergin
Differential Revision: D22536626
fbshipit-source-id: c74b63b3319693b90c9d64b7f782a1a922b0d499
Summary:
This is an implementation of `BackgroundExecutor` on iOS.
In case if the experiment is successful, we will make it mandatory for all platforms.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D22743722
fbshipit-source-id: 7756d2947e962720b9970d48c74929ab407c0440
Summary:
This notification was never used, I'd rather not have someone start relying on it, and need to figure out how to migrate them in bridgeless mode.
Changelog:[Internal]
Reviewed By: cpojer, RSNara
Differential Revision: D22513602
fbshipit-source-id: 80b179af8408abc6646a73380b4a66cade3f75f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29453
Problem Statement: A native module needs to call a function on `ReactInstance` (in this case `loadScript`). Typically, this is handled by the bridge.
Current Bridgeless Solution: Create a new protocol (in this case `RCTJSScriptLoaderModule`) which lets a block be passed in TM init to forward the method call to `ReactInstance`. This is the best thing I could think of right now.
Changelog:[Internal]
Reviewed By: RSNara
Differential Revision: D22512748
fbshipit-source-id: e6559279b6e299e17d1199407129ad3902c41e6b
Summary:
Changelog:
When the JSLocation is nil, checking whether the address is running is unnesarry and wasting time, adding a JSLocation length check to mitigate that.
Reviewed By: cpojer
Differential Revision: D22644574
fbshipit-source-id: c51fc1a8976ebc25cba2653581e1bfa479a1d70d
Summary:
Changelog: [Internal] Fabric-specific internal change.
This diff introduces a new value for `YGPositionType`: `YGPositionTypeStatic`.
No part of Yoga, RN, Litho or CK uses this value yet. `relative` and `static` values behave the same way for now. We also do not change any defaults. So, it should be fine.
Reviewed By: SidharthGuglani
Differential Revision: D22386732
fbshipit-source-id: 39cd9e818458ac2a91efb175f24a74c8c303ff08
Summary:
Changelog:
[Internal] - Add an condition to exclude accessibilityRole that not currently used
Since I've added all the possible values in accessibilityRole enum, it is necessary to gate what needs to be an accessibilityElement. SO I add a condition to exclude accessibilityRole that not currently used.
Reviewed By: shergin
Differential Revision: D22559136
fbshipit-source-id: 910d59132984872b5a9816b8e390117b7b1e2e71
Summary:
Here we use `TelemetryController` to instrument mounting transactions in RCTMoutingManagers and wire that with RCTMountingTransactionObserving protocol. Now, performance trackers (flags) that we use can obtain this information and report to some server-side infrastructure. (Which will be implemented in future diffs.)
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22490581
fbshipit-source-id: 37695560437ae0e27845c3bda2030fe6fa4c6735
Summary:
Changelog:
[Internal] - Reword the guide words to make it more generic.
Considering the case that some languages are RTL so swiping right cannot guarantee to move to the link. iOS can handle the order of the words and accessibilityElements according to the language. But the accessibilityHint we hardcoded would be an issue. So we decided to reword it to be more generic.
Reviewed By: PeteTheHeat
Differential Revision: D22422498
fbshipit-source-id: 175711317961663d0b0b47e04d2ab600f63446fe
Summary:
Changelog:
[Internal] - Add a `accessibilityHint` to the first accessibilityElement so that it will tell user double tap to expand or truncate the text after reading the whole text. Also add the `accessibilityRole` in `FBTextWithEntities` when shouldTruncated is true, which allow us to specially distinguish the shouldTruncated text.
Reviewed By: sammy-SC
Differential Revision: D22339875
fbshipit-source-id: ce22fe9d86eeba5a2750022acd2cdd2c06a1dc79
Summary:
TurboModule eager initialization is a bit dangerous if we get it wrong, which we did (twice): T69449176.
This diff gates TurboModule eager init behind a MC, so that we can control (i.e: turn off/on, and do gradually rollout of) TurobModule eager initialization in isolation from the larger TurboModules experiment.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22460359
fbshipit-source-id: 3b8dce0529f1739bd68b8b16d6a28aa572d82c2c
Summary:
## Why?
1. RCTTurboModuleLookupDelegate sounds a bit nebulous.
2. In JS and Java, we use a `TurboModuleRegistry` interface to require TurboModules. So, this diff will make JS, Java, and ObjC consistent.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22405754
fbshipit-source-id: 30c85c246b39d198c5b8c6ca4432a3196ca0ebfd
Summary:
## Context
1. In FBReactModule jsExecutorForBridge, we asynchronously initialize a list of TurboModules on the main queue: https://fburl.com/diffusion/i56wi3px
2. After initializing the bridge, we start executing the JS bundle, here: https://github.com/facebook/react-native/blob/e23e9328aa164d0a70fe4f16042c982e7801d924/React/CxxBridge/RCTCxxBridge.mm#L414-L417. Since bridge initialization knows nothing about TurboModule eager initialization, this happens concurrently with 1, and starts requiring NativeModules/TurboModules on the JS thread.
## The Race
1. Both the main thread and the JS thread race to create a TurboModule that requires main queue setup.
2. The JS thread wins, and starts creating the TurboModule. Meanwhile, the main thread blocks, waiting on a signal here, in RCTTurboModuleManager: https://github.com/facebook/react-native/blob/e23e9328aa164d0a70fe4f16042c982e7801d924/ReactCommon/turbomodule/core/platform/ios/RCTTurboModuleManager.mm#L430
3. The JS thread tries to dispatch_sync to the main queue to setup the TurboModule because the TurboModule requires main queue setup, here: https://github.com/facebook/react-native/blob/e23e9328aa164d0a70fe4f16042c982e7801d924/ReactCommon/turbomodule/core/platform/ios/RCTTurboModuleManager.mm#L402
4. We deadlock.
## The fix
Succinctly, NativeModule eager initialization finishes before execute the JS bundle, but TurboModule initialization doesn't. This diff corrects that mistake.
The changes in this diff:
1. The RN application via the TurboModuleManager delegate can now optionally provide the names of all eagerly initialized TurboModules by implementing two methods `getEagerInitModuleNames`, `getEagerInitMainQueueModuleNames`.
2. The TurboModuleManager grabs these two lists from the delegate, and exposes them to its owner via the `RCTTurboModuleRegistry` protocol.
3. The RCTCxxBridge, which already owns a `id<RCTTurboModuleRegistry>` object, uses it to eagerly initialize the TurboModules in these two lists with the correct timing requirements.
This is exactly how we implement eager initialization in Android.
**Note:** Right now, phase one and two of TurboModule eager initialization happen after phase one and two of NativeModule eager initialization. We could make the timing even more correct by initializing the TurboModules at the exact same time we initialize the NativeModules. However, that would require a bit more surgery on the bridge, and the bridge delegate. I think this is good enough for now.
Changelog:
[iOS][Fixed] - Fix TurboModule eager init race
Reviewed By: PeteTheHeat
Differential Revision: D22406171
fbshipit-source-id: 4715be0bceb478a8e4aa206180c0316eaaf287e8
Summary:
`RCTModuleData gatherConstants` is [used by `RCTModuleData exportedConstants` to compute and return the constants exported to JS](https://fburl.com/diffusion/ssg4jbeu). However, `RCTModuleData gatherConstants` is also [used by `RCTCxxBridge` to pre-compute NativeModule constants during bridge startup](https://fburl.com/diffusion/nfmjc1ke). Therefore, since `RCTModuleData gatherConstants` can be used outside the context of a JS require, we cannot start the JSRequireEnding marker inside `RCTModuleData gatherConstants` directly.
This diff moves the body of `RCTModuleData gatherConstants` into `gatherConstantsAndSignalJSRequireEnding:(BOOL)startMarkers`:
- `RCTModuleData gatherConstants` calls `RCTModuleData gatherConstantsAndSignalJSRequireEnding:NO`
- `RCTModuleData exportedConstants` calls `RCTModuleData gatherConstantsAndSignalJSRequireEnding:YES`. **Note:** This is okay, because `RCTModuleData exportedConstants` is only called inside `RCTNativeModule::getConstants()`.
This should make sure that we don't start the JSRequireEnding marker outside of a JS require.
Reviewed By: PeteTheHeat
Differential Revision: D22371889
fbshipit-source-id: de17b857259572fb0f840a22072a16b5e465cabd
Summary:
This diff inlines all mount-instruction functions into a single one - RCTPerformMountInstructions.
The main purpose is to reduce the number of calls to `RCTComponentViewRegistry` for some instructions. E.g., before the change, the `Insert` (or `Update`) instruction had seven identical calls to the registry. That's not a huge deal but there is no need to pay for it either. Maybe it can save us a couple of milliseconds during TTI.
The code of those functions is quite straight-forward, so this change probably even improves readability.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22402987
fbshipit-source-id: 043a4114ba42622e9ed226f4d5e41ed45c1b066c
Summary:
Changelog:
Adding packager running check when RCTBundleURLProvider is returning JSLocation, this prevents an invalid address from being returned which might cause various issues.
Reviewed By: cpojer
Differential Revision: D22390156
fbshipit-source-id: a20dbf63103158a34cbf6dc0ae8349b2f9e5b0a8
Summary:
This refined algorithm now takes a zoom/scale into account and deals with `contentInset` properly.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22382482
fbshipit-source-id: 7e9d34d3bababf68e624c045c308957e7e5c9d84
Summary:
Changelog: [Internal]
When JS Inspector is activated, ScrollView is unmounted and then mounted again with same state.
ScrollView's content offset was being set to 0 inside `[RCTScrollViewComponentView prepareForRecycle]` during unmount but when it is mounted again, we ignored value inside state.
Reviewed By: shergin
Differential Revision: D22333125
fbshipit-source-id: f232dc95b695605f4819f29d8e0bf14b2f3e9150
Summary:
Pet Peeve: Metro is a brand name. You don't say "the Metro server" just like you don't say "the iPhone phone". This is a leftover from when it used to be called "the packager server".
Note: It makes sense to refer to "the Metro server" when talking about it in the context of Metro's features, like if you are discussing "Metro's bundling" and "Metro's server". However, when talking about the tool itself, just Metro is enough.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22330966
fbshipit-source-id: 667618363c641884df543d88cac65d1e44956ad3
Summary:
Changelog:
[iOS][Added] - This is the first step to build RCTParagraphComponentAccessibilityProvider. The main idea of RCTParagraphComponentAccessibilityProvider is to provide an array of accessible elements for the AttributedString in PCTParagraphComponentView.
Reviewed By: sammy-SC
Differential Revision: D22214855
fbshipit-source-id: 69d47555e86452620f89a4b2e21ed6065c8e669c
Summary:
The change contains a bunch of additional asserts that verify some assumptions on which mounting relies on. Working on the previous diffs I realized that it's very easy to broke those and then spend hours trying to understand what exactly went wrong.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22324087
fbshipit-source-id: 1152c40248885d02bde62a493a574868c3732273
Summary:
This is the first implementation stage of on-demand child views mounting for <ScrollView> feature.
It works this way. When mounting layer requests mounting of a subview of <ScrollView>, the component does not mount it immediately. Instead, it stores it in an internal collection, and then after the transaction finishes use that to mount views that are in a visible area.
Then we re-evaluate which child views are should be mounted and unmounted on every significant onScroll event. We use some leeway to do it not so often to save CPU cycles on scrolling.
This feature already works fine but to make it shippable we need to integrate it with an `overflow inset` feature to make it 100% reliable in complex cases when some views have overflow content.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22304012
fbshipit-source-id: be4ae21378d9d1c457cad2826da7d8c8d6395be5
Summary:
Changelog: [Internal]
Do not log warning for "Invalid view set to be the JS responder".
{F242140509}
Fabric doesn't store views in view registry, therefore this warning would be shown to the developer everytime `[RCTUIManager setJSResponder]` is called.
Reviewed By: shergin
Differential Revision: D22309447
fbshipit-source-id: cac8985cdc79ab2d03a246cc2d9377472a64a683
Summary:
The method does not do anything besides calling a super method. Even if this method does nothing special, overriding it can have negative performance implications.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22309895
fbshipit-source-id: bd8237d15df20017629223f278b1b6ac628b0cc7
Summary:
Changelog: [Internal]
Introducing InputAccessoryView.
There is one big difference between Fabric's implementation and Paper's implementation.
Fabric searches for text input from InputAccessoryView, unlike Paper where it is the other way around.
Reviewed By: shergin
Differential Revision: D22160445
fbshipit-source-id: 55313fe50afeced7aead5b57137d711dd1cfd3ae
Summary:
Here is why:
* It was with us from the very beginning but we never use it.
* The main purpose of this - snap-to-pixel layout - was moved to Yoga, where it should be.
* The current implementation has a bug.
* It's not really correct conceptually because the value becomes incorrect when an immutable subtree is being reused as part of a new tree.
* It over-complicates a new feature I am working on.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22284645
fbshipit-source-id: c4c2df8d24e8fe924725b465e04e8154d097d226
Summary:
Changelog: [Internal]
In D8552360 (https://github.com/facebook/react-native/commit/48b9a6f887c09f78944053a6658106a01dc20fea) an experimental integration between old and new UIManager has been introduced.
It isn't needed anymore.
I did some measurements and it is the slowest part of `[RCTComponentViewDescriptor dequeueComponentViewWithComponentHandle]`.
{F241943384}
Reviewed By: shergin
Differential Revision: D22274782
fbshipit-source-id: 799ba047f1c57f68f00b0b6fa7c58782874991bc
Summary:
Changelog: [Internal]
The methods were out of order, this diff reorders them.
Reviewed By: shergin
Differential Revision: D22233255
fbshipit-source-id: ea66bc701c4d021ec5721e191bc0d3413b3d36ae
Jiayan Zhuang
Nicholas Tinsley
Yogev Ben David
Samuel Susla
Joshua Gross
David Vacca
Peter Argany
Valentin Shergin
Jimmy Zhang
Ramanpreet Nara
Christoph Nakazawa
