Summary:
... and slighly new behaviour for one of them.
The method does nothing if given `key` already exists in the container.
This diff finishes the transition of ContextContainer from an internal bag of things with unclear yet ownership into a legit dedicated dependency injection container for the product code.
The original names of methods imply that the container can have only one object of a given type which is no longer true. The new API is much more generic and idiomatic to C++, it mimics `std:map` API which is intuitive to anyone who familiar with C++ containers.
Besides the naming, `insert` method changed the semantic a bit; now it does nothing in case of inserting an object with a key that already exists. That might seem counterintuitive for "normal" people, but C++ has some wired reasons for that and, hopefully, it's expected behavior in the C++ community.
Fun fact: We need this to fix hot-reload.
Reviewed By: sahrens
Differential Revision: D15681736
fbshipit-source-id: 194f342528446a911eaf072ba3a94a5d8af3cb52
Summary: Move PtrJNodeMap to header file so that it can be accessed in events subscribers outside yoga
Reviewed By: davidaurelio
Differential Revision: D15619629
fbshipit-source-id: 1bf213efd38ec7bcac6a38070f21fa837c5f17da
Summary:
`/*` is the standard throughout open source code. For example, Firefox uses single /*: https://hg.mozilla.org/mozilla-central/file/21d22b2f541258d3d1cf96c7ba5ad73e96e616b5/gfx/ipc/CompositorWidgetVsyncObserver.cpp#l3
In addition, Rust considers `/**` to be a doc comment (similar to Javadoc) and having such a comment at the beginning of the file causes `rustc` to barf.
Note that some JavaScript tooling requires `/**`. This is OK since JavaScript files were not covered by the linter in the first place, but it would be good to have that tooling fixed too.
Reviewed By: zertosh
Differential Revision: D15640366
fbshipit-source-id: b4ed4599071516364d6109720750d6a43304c089
Summary: We just need to protect access to the cache, we don't need to protect the entire module lookup, because a module initialization may try to lookup another module, causing deadlocks.
Reviewed By: RSNara
Differential Revision: D15690645
fbshipit-source-id: cbb780db8699a94f2c9a2e121b35ddad2b125b65
Summary: Restores the bridge description in the debug menu on iOS.
Reviewed By: fkgozali
Differential Revision: D15680775
fbshipit-source-id: c17ad44f2287e03bb2039b4aa4b1311e7ec9106b
Summary:
And, btw, the tests show that performance of that is not so great:
```
Running /Users/shergin/fbsource/fbobjc/buck-out/cells/fbsource/gen/xplat/js/react-native-github/ReactCommon/fabric/core/benchmarks
Run on (12 X 2900 MHz CPU s)
CPU Caches:
L1 Data 32K (x6)
L1 Instruction 32K (x6)
L2 Unified 262K (x6)
L3 Unified 12582K (x1)
--------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------------------------------
propParsingUsingComponentDescriptor 79630 ns 77991 ns 8864
propParsingUsingComponentDescriptorWithNoSourceProps 70200 ns 69099 ns 8362
```
Which means 70ms per 1000 prop parsing processes.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15608677
fbshipit-source-id: ed4feca489e1243adc73de4741c287256c3aaec3
Summary:
First of all, seems it's the right thing to do. Fabric C++ code is cross-platfrom and should run on *all* platforms including Windows, Linux, and Mac.
While we don't have a real *production* use cases where we need compilation for desktops, having CXX target is really handy for two reasons:
* It simplifies local test running process. Instead of going to `/fbandroid/` and executing something like `buck test fbsource//xplat/js/react-native-github/ReactCommon/fabric/core:coreAndroid` (note the suffix). We can just do `buck test fbsource//xplat/js/react-native-github/ReactCommon/fabric/core:core` everywhere and it works now out of the box. Running tests with "Apple" flavor never worked for me.
* It allows creating synthetic benchmark tests (using Google Benchmark) that can be used as a rough approximation of code micro-optimizations.
Reviewed By: JoshuaGross
Differential Revision: D15608678
fbshipit-source-id: d2449035685dbca6ab983480f5334ec4ac11cd35
Summary: This adds the testlib.cpp/h files to external JSI. They're in a `test/` subdirectory so that build scripts using globs like `*.cpp` won't include them.
Reviewed By: mhorowitz
Differential Revision: D15582281
fbshipit-source-id: 1785ee5071fcf98e92fbf3a11eddb21fe84b3799
Summary: Right now we render a surface by calling `AppRegistry.runApplication`, but the way we do this relies on the batched bridge. For Venice (bridgeless RN) I created a new module for registering a surface called SurfaceRegistry, which uses a global variable instead of registering itself as a callable module on the bridge. If that global variable exists, we can use that to start the surface instead of calling AppRegistry.
Reviewed By: sahrens
Differential Revision: D15502241
fbshipit-source-id: 0b8d4677f1df41f46d84444567a30e40e21fed3d
Summary: The `_rctTurboModuleCache` `std::unordered_map` can be accessed by multiple threads at the same time via the `provideRCTTurboModule` method. Since `provideRCTTurboModule` both reads and writes to `_rctTurboModuleCache`, this is really bad because we could end up reading from `_rctTurboModuleCache` while it's in an invalid state. Therefore, in this diff, I'm making it so that only one thread at a time can enter `provideRCTTurboModule`.
Reviewed By: fkgozali
Differential Revision: D15609987
fbshipit-source-id: e24e1f5cc2351d8cbb820b7a97074aacd06eec9d
Summary: Move PtrJNodeMap to header file so that it can be accessed in events subscribers outside yoga
Reviewed By: davidaurelio
Differential Revision: D15602627
fbshipit-source-id: bb5bd5bbf8dcb279f5f87a4fd7287909d4e895d8
Summary:
unistd.h isn't a header available in the windows SDK, so we can't include it from react-native-windows.
I moved the usage of dup, to JSBigString.cpp in a previous PR, so this header should only be needed in the cpp file, not the header. (And react-native-windows doesn't use the cpp file)
## Changelog
[Internal] [Fixed] - Header cleanup
Pull Request resolved: https://github.com/facebook/react-native/pull/25107
Differential Revision: D15602265
Pulled By: cpojer
fbshipit-source-id: 6a62bf8fe6758e400810f37834e8646485120d71
Summary:
Co-Authored: zamotany
With React Native 0.59.8 the app keeps crashing with indexed RAM bundle on Android with the following error:
```
2019-05-09 11:58:06.684 2793-2856/? E/AndroidRuntime: FATAL EXCEPTION: mqt_js
Process: com.ramtestapp, PID: 2793
com.facebook.jni.CppException: getPropertyAsObject: property '__fbRequireBatchedBridge' is not an Object
no stack
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:193)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:232)
at java.lang.Thread.run(Thread.java:764)
```
After investigation we found that when using any bundle, let it be non-ram, FIle RAM bundle or Index RAM bundle, the `CatalystInstanceImpl.java` is always using `loadScriptsFromAsset`, which is calling `CatalystInstanceImpl::jniLoadScriptFromAssets` in C++. This method when checking if bundle is a RAM bundle, uses `JniJSModulesUnbundle::isUnbundle` which only check for js-modules/UNBUNDLE - file generated when building File RAM bundle. There is no other logic to handle Indexed RAM bundle, so it figures that the bundle is not RAM, cause there is no js-modules/UNBUNDLE file and tries to load as regular bundle and fails.
In this PR we added check if it is indexed RAM bundle in `jniLoadScriptFromAssets` and handle it if it is.
## Changelog
[Android] [Fixed] fix indexed RAM bundle
Solves https://github.com/facebook/react-native/issues/21282
Pull Request resolved: https://github.com/facebook/react-native/pull/24967
Differential Revision: D15575924
Pulled By: cpojer
fbshipit-source-id: 5ea428e0b793edd8242243f39f933d1092b35260
Summary: This diff creates the base classes for MapBuffer and its tests
Reviewed By: shergin
Differential Revision: D15550730
fbshipit-source-id: a5a47edebd7c3e1b8b2c3ad2006aee0f8bdb7866
Summary:
While ViewConfig infra isn't perfect we need to check that for correcness.
See the task for more details.
Reviewed By: JoshuaGross
Differential Revision: D15578675
fbshipit-source-id: c99c2be9c215e6b9d7ee8e6e50d85e822c1f007e
Summary:
Replace the *copy on write* vector with an atomic pointer to a linked list.
This allows to publish without locking a mutex, at the cost of the slower traversal of a linked list (a vector has better locality).
At the moment, the typical use case is to have one subscriber, meaning that the afforementioned slower traversal is not a problem.
Adding subscribers is implemented as atomic *compare and swap.*
Reviewed By: SidharthGuglani
Differential Revision: D15546964
fbshipit-source-id: 41bfa41f1ac6be5c9b6bf4288ea3271ee995877e
Summary:
We want to phase out usage of config pointers on nodes. Setting configs is no longer needed, as a config is unly used during construction.
Here we deprecate the setter, as it is no longer working as it used to (e.g. changing `useWebDefaults` after a node is constructed).
Reviewed By: SidharthGuglani
Differential Revision: D15416474
fbshipit-source-id: a2cc06cad0c5148cecce056ece5f141b3defe9a9
Summary: Create structure of C++ side of mapbuffer project
Reviewed By: shergin
Differential Revision: D15529650
fbshipit-source-id: b563d3fbcfddcf46802ccb202e372233baad123d
Summary:
We currently have two different codepaths for actually rendering a surface with Fabric on iOS and Android: on iOS we use Fabric's `UIManagerBinding.startSurface` to call `AppRegistry.runApplication`, but on Android we don't; instead we use the same codepath as paper, calling `ReactRootView.runApplication`.
This diff does a few different things:
1. Unify iOS and Android by removing the `#ifndef` for Android so that we call `startSurface` for both
2. Pass through the JS module name on Android so that this actually works (it currently passes in an empty string)
3. Remove the call to `ReactRootView.runApplication` for Fabric so that we don't end up doing this twice
4. Copy over some logic that we need from `ReactRootView.runApplication` (make sure that root layout specs get updated, and that content appeared gets logged)
Reviewed By: mdvacca
Differential Revision: D15501666
fbshipit-source-id: 5c96c8cf036261cb99729b1dbdff0f7c09a32d76
Summary:
We are not sure yet how exactly this should work semantically (e.g. should unbatched events flash previously dispatched batched or not).
So, let's disable that until we have all answers.
Reviewed By: mdvacca
Differential Revision: D15498191
fbshipit-source-id: 77f07c5e86bfbfd212505df8cc6530e39531b5ef
Summary:
Right now calling FabricUIManager.addRootView() doesn't actually start running the application on Android. This diff:
1. Removes the #ifndef so that we actually call UIManagerBinding.startSurface() on Android
2. Passes through the JS module name from addRootView so we can render the surface (falls back to an empty string if not provided, which is the current behavior)
3. Adds an option for starting the surface using `RN$SurfaceRegistry` instead of `AppRegistry`, if that global property has been defined in JS. This is used for Venice (bridgeless RN)
Reviewed By: shergin
Differential Revision: D15366200
fbshipit-source-id: 4a506a589108905d4852b9723aac6fb0fad2d86e
Summary:
Set `sizeMultiplier` to `1.0` if default value is `NAN`, otherwise, text cannot show properly.
## Changelog
[iOS] [Fixed] - Add NAN check for text font sizeMultiplier
Pull Request resolved: https://github.com/facebook/react-native/pull/24966
Differential Revision: D15466559
Pulled By: shergin
fbshipit-source-id: 6f8b47eb8e521cb120d7f351cba02dbf1c5411fd
Summary:
## Summary
This diff does a bunch of things:
1. The TurboModule resolution algorithm on Android now supports C++ TurboModules.
2. `SampleTurboCxxModule` is moved from `ReactCommon/turbomodule/samples/platform/ios/` to `ReactCommon/turbomodule/samples` so that both iOS and Android can share it.
3. `CatalystTurboModuleManagerDelegate::getTurboModule(std::string, JSCallInvoker)` now understands and returns `SampleTurboCxxModule`.
Reviewed By: mdvacca
Differential Revision: D15253477
fbshipit-source-id: 3def91911b091f8cf93be17decd245a0499ed718
Summary: Removes a check introduced in D6969537, comparing `totalFlexGrowFactors` and `resolveFlexGrow` to both `0.0` *and* undefined.
Reviewed By: SidharthGuglani
Differential Revision: D15431425
fbshipit-source-id: 13c8f24e1bc8c49496097a6aa78e20ee5d3964a7
Summary:
This diff restores the original role of StateData as a dummy class that has only one purpose - designate that there is no state associated with the node.
I believe having an abstract StateData class for all data types is not necessary and actually slightly harmful. And here the reasons:
* Having virtual dispatch enabled for classes introduces some overhead, and it should be used only if it is absolutely necessary. In this case, we don't need to have virtual dispatch enabled for Data classes because it's already enabled for State classes; therefore all virtual resolution is done there and that's sufficient. No need to pay for what we don't need.
* Continuing the previous point, yes, we expect some API being exposed for Data classes (such as `getDynamic`), but introducing a base abstract class for that is *not* an idiomatic C++ solution; in C++ it's by design that most of the template contracts are actually duck-typed. This is a well-known design issue/concern that will be addressed with an effort called "Concepts" in C++20. Anyway, we should not use abstract classes as *only* indication of conformance to some interface.
* StateData does not introduce any convenience. As it is clear from several subclass implementations, we don't really use base methods from it.
* The previous issue actually happens especially because of the interface of StateData class. Consider constructor that accepts `folly::dynamic` and does nothing, it actually useless because it's impossible to use it unless it's called inside superclass's constructor. That's the case because C++ does not support virtual dispatch for constructors (for good).
* Avoiding subclassing StateData counter-intuitively enforces the desired conformance to imaginary interface: it does not compile otherwise.
Reviewed By: JoshuaGross
Differential Revision: D15342338
fbshipit-source-id: 1f04f7fc5247499e7cfc09cd4b3cccffdc0b6b06
Summary:
`YGNode::setAndPropogateUseLegacyFlag` was only used for debugging purposes.
Here, we replace it with a free function in `Yoga.cpp`.
Now that we have events, the diffing functionality should go into a separate debugging package and be implemented in terms of an event listener. Let's do that as soon as we can support multiple listeners.
Reviewed By: SidharthGuglani
Differential Revision: D15316863
fbshipit-source-id: db929eba7c2de8aa1550e362dd2c175929c0070e
Summary:
In order to remove the config pointer from nodes, we have to keep track of whether the node is using web defaults.
This information fits into one bit that we can place in padding (i.e. no extra memory needed).
This allows us to get rid of config usage withing `YGNode` with some exceptions:
- `iterChildrenAfterCloningIfNeeded` -- this function will simply receive the configuration, or the cloning callback.
- `setAndPropogateUseLegacyFlag` -- will be removed in D15316863
- in `YGNode::reset` -- will go away utomatically once we remove the config pointer
Reviewed By: SidharthGuglani
Differential Revision: D15391536
fbshipit-source-id: 0fa0d0805c6862bd741fe4a7d9b637ed534f56a4
Summary:
Updates the paragraph component to use State instead of Local Data, part of the path to a Fabric TextInput 💯
## Changelog
[General] [Changed] - Fabric: Use State instead of Local Data for Paragraph
Pull Request resolved: https://github.com/facebook/react-native/pull/24873
Differential Revision: D15410979
Pulled By: shergin
fbshipit-source-id: 3c9517d2495a64c4dbd213b6efb5ff55287900e3
Summary: Using Mutex lock_guard mechanism when writing to subscribers and when accessing them in publish to make a copy
Reviewed By: davidaurelio
Differential Revision: D15391679
fbshipit-source-id: 16713ff28ce1762a5ca4c48c152897a92417e80b
Summary:
Straightforward.
Rick, I rename some stuff, I hope you are cool with that.
Reviewed By: mdvacca
Differential Revision: D15403306
fbshipit-source-id: 1dbd34060052a9bd39ed4211010f14b76fffcde6
Summary: This is implementation of standard PullToRefresh component that uses standard iOS component and modern integration approach.
Reviewed By: mdvacca
Differential Revision: D15403308
fbshipit-source-id: 5c877f7c18af9f5ac40e15a4ba44118614ba80bc
Summary:
Adds one byte of private storage to `YGNode`, intended to be used by Yoga itself.
This is in previously unused alignment space, and won’t cause more memory to be allocated.
Reviewed By: SidharthGuglani
Differential Revision: D15296732
fbshipit-source-id: 3caf0a3cd506e4e324e51c31869c69be5781d476
Summary: Style bits had overlap, because `dimensionBit` was set with an incorrect increment.
Reviewed By: SidharthGuglani
Differential Revision: D15335134
fbshipit-source-id: 370e1a73547d76b0e26bc6ab67acb96d33ddf180
Summary:
This is a TODO, we met crash if we don't call `retainArguments` when return type is like `NSDictionary`, the reason is `getReturnValue` don't retain the return value, so we need to using `__bridge` to transfer ownership to OC type.
Also add `resolveBlock` and `rejectBlock` to `retainedObjectsForInvocation`.
cc. cpojer
## Changelog
[iOS] [Fixed] - Remove retainArguments && do retain by us explicitly
Pull Request resolved: https://github.com/facebook/react-native/pull/24849
Differential Revision: D15369209
Pulled By: fkgozali
fbshipit-source-id: 8431d03705d8476f38c8b5d29630489a545d373a
Summary:
Some ObjC NativeModules conform to `RCTInvalidating` protocol and implements `invalidate` method. This is typically used to clean things up during bridge teardown or reload. In TurboModule system the invalidate method can be replaced by pure destructors, but for backward compatibility, we call existing invalidate method on each module during teardown.
This also cleans up all existing LongLivedObject's.
Reviewed By: mdvacca, RSNara
Differential Revision: D15365655
fbshipit-source-id: 802844b39b5b7adb54970ea541f4d744bbf9e480
Summary:
With the introduction of TurboModules, it would be beneficial to measure the setup time of these modules, as we currently have it in place for NativeModules.
The instantiation of the TMs occurs in the `RCTTurboModuleManager`. In order to successfully measure the time it took to setup the module, we need to ensure that we don't take into account cached modules. As such, we need to:
1. Check if module is in `_turboModuleCache`
a. Start mark for `RCTPLTurboModuleSetup` tag if not found
2. Get the TM via `[self provideTurboModule:]`
3. Check if module is in `_turboModuleCache`
a. Stop mark for `RCTPLTurboModuleSetup` if we did not find module in cache prior to **step 2** and if it's now present in the cache.
b. Notify about setup time if the above is true.
4. Return TM
## Changelog
[iOS] [Added] - Gain insights on the the turbo module setup times by observing `RCTDidSetupModuleNotification`. The userInfo dictionary will contain the module name and setup time in milliseconds. These values can be extracted via `RCTDidSetupModuleNotificationModuleNameKey` and `RCTDidSetupModuleNotificationSetupTimeKey`.
Pull Request resolved: https://github.com/facebook/react-native/pull/24732
Differential Revision: D15362088
Pulled By: RSNara
fbshipit-source-id: e6a8044e4aba5a12ae63e9c7dbf707a17ec00180
Summary:
This is the final piece of change that makes measuring (`LayoutableShadowNode::getRelativeLayoutMetrics()`) take ScrollView content offset into account (on iOS).
It works pretty simply: at the end of scrolling (or zooming) action ScrollView updates the state which later can be used for computing `transform` which measuring uses to adjust values in LaoutMetrics.
Reviewed By: mdvacca
Differential Revision: D15323688
fbshipit-source-id: fdf86c6cd9bdfd56caddd4b39bdd1185760b9f94
Summary: Seems we need this now to enable future improvements in ScrollView such as correct measure, pull-to-refresh and so on.
Reviewed By: mdvacca
Differential Revision: D15323687
fbshipit-source-id: fae37431ccbbf2faec9c84752396153689b873ef
Valentin Shergin
Sidharth Guglani
Rain
Kevin Gozali
Tim Yung
zhongwuzw
Joshua Gross
Will Holen
Emily Janzer
Ramanpreet Nara
REDMOND\acoates
Dratwas
David Vacca
David Aurelio
Michal Sienkiewicz
Eric Lewis
RCiesielczuk