Summary: This is a temporary backout of D14817454, to verify if this is related T45503571
Reviewed By: JoshuaGross
Differential Revision: D15780018
fbshipit-source-id: 455034ce7b7096101db93a8604b77e1233db1137
Summary:
Passing Measure callback data - width, widthMeasureMode, height, heightMeasureMode, measuredWidth and measuredHeight along with NodeMeasure event
This data is then propagated to java layer in this diff
Reviewed By: davidaurelio
Differential Revision: D15697523
fbshipit-source-id: 615463da237175ff88abef3f6528b55333ccd915
Summary: Some native modules methods expects number-based args like `NSDate`. For backward compatibility, the incoming numbers should be converted using RCTConvert, just like object args.
Reviewed By: mdvacca
Differential Revision: D15748968
fbshipit-source-id: 4db2cb0c41eda1bbe8cde7b0365d9c3d675f5fb5
Summary: Some native modules defined `synthesize methodQueue` which will ask the bridge to create a new serial queue for them. TM system needs to preserve this behavior for backward compatibility. In the future though, this magic shall be removed.
Reviewed By: mdvacca
Differential Revision: D15748198
fbshipit-source-id: 66a4b60a2769ac967a8d3bb00c4c635a68daebbc
Summary: Listen to NodeLayout event and passes this event callback to java layer along with the information whether layout or measure was done in this pass
Reviewed By: davidaurelio
Differential Revision: D15696021
fbshipit-source-id: 8c5ca69330a9baca26b77052d4965cc67fe97c75
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:
Tests file exposed in 608b1b5ea2. This break e2e tests, so let's excluded them from JSI pod.
## Changelog
[iOS] [Fixed] - Excluded tests file from JSI pod
Pull Request resolved: https://github.com/facebook/react-native/pull/25151
Differential Revision: D15645046
Pulled By: cpojer
fbshipit-source-id: 19c712e4307cf712b8377d721661a2b476151732
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:
Consolidate sender of notification to `batchedBridge` for TM and old module system, old module implementation can see dc893756b8/React/Base/RCTModuleData.mm (L191-L193).
## Changelog
[iOS] [Fixed] - Conlidate RCTDidInitializeModuleNotification sender to batchedBridge
Pull Request resolved: https://github.com/facebook/react-native/pull/24866
Differential Revision: D15357566
Pulled By: RSNara
fbshipit-source-id: 479575c1e9781d8aea9fa3aea9e0283d24df7e81
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
Summary: A couple of new methods in ConcreteShadowNode allows us to deal with State in more LocalData-like manner.
Reviewed By: mdvacca
Differential Revision: D15323686
fbshipit-source-id: ede4aa1f1d0ad6f876bd963e57a00a0ad470c1c0
Summary:
using shared_ptr for vector of subscribers
Further changes in commit stack support the mutiple subscribers in event system
Reviewed By: davidaurelio
Differential Revision: D15352512
fbshipit-source-id: fac7f4268abf9ca4277734aca2f21cd711eb7d6e
Summary:
Replaced global event subscriber with a vector of subscriber functions
Further changes in commit stack support the mutiple subscribers in event system
Reviewed By: davidaurelio
Differential Revision: D15352451
fbshipit-source-id: 7ca6f0943735bf1f76a906c23e15e14ae3c5f42c
Summary:
The `measure` API receives LocalData and Props, it should also receive State.
This will also be used in future diffs.
Reviewed By: mdvacca
Differential Revision: D15325182
fbshipit-source-id: 6cb46dd603ce7d46673def16f0ddb517e2cf0c4f
Summary: In D15252375 I made JSCallInvoker an abstract class and extended it in BridgeJSCallInvoker, but I forgot to add the `override` keyword for overridden methods.
Reviewed By: fkgozali
Differential Revision: D15328292
fbshipit-source-id: 3e75faf1b4a968b80643b8a97071ab2e122fd643
Summary:
In ContextContainer, only in Debug mode, we store type information alongside with data to detect typemismatch in runtime. We used type hashes before, but seems they are not so stable and can cause some false negative crashes.
This diff changes that to store mangled typenames instead of hashes, so it should be much more reliable now.
Reviewed By: JoshuaGross
Differential Revision: D15325728
fbshipit-source-id: 3a0f1116e1336af79adb51f38ce83c37aee4cad1
Summary: The existing implementation of JSCallInvoker holds a reference to Instance (aka the bridge). This diff makes JSCallInvoker an abstract base class that's extended by BridgeJSCallInvoker, which is what's returned by CatalystInstance to initialize TurboModules. This will allow us to add another class that derives from JSCallInvoker that doesn't rely on the bridge.
Reviewed By: shergin
Differential Revision: D15252375
fbshipit-source-id: 75eee2ca149235a63e2a2cd8cdd361b163d1d1ab
Summary:
Adds `LayoutPassStart` and `LayoutPassEnd` events.
The existing `NodeLayout` event in isolation is not as useful as it could be. Having events that mark start and end of a layout pass are a useful addition.
Differential Revision: D15305467
fbshipit-source-id: 14af6f65e698fb1e3112eb2ffd87a74d31df4840
Summary:
Previously the pointScaleFactor field was not being compared properly in LayoutMetrics equality method.
This diff fixes that
Reviewed By: shergin
Differential Revision: D15303555
fbshipit-source-id: 8863e9e1fbad15b43400afc32b97bf6d252cbe55
Summary: `YogaStylableProps.yogaStyle` is designed to be consumed by Yoga only. Making it `protected` allows us to avoid confusion and misuse of this props.
Reviewed By: JoshuaGross
Differential Revision: D15296474
fbshipit-source-id: cf9e416afee99fb426d72765557b34d303a63dbe
Summary: This diff replaces usage of abort() with assert() when a prop-value is not found during parsing of prop values
Reviewed By: shergin
Differential Revision: D14563338
fbshipit-source-id: c799420e6b49df35e1d7ccdbd4bc4845067d33cc
Summary:
ImageLoader is an actual external dependency, not a ImageManager.
That change allows to remove dependency on ImageManager from SurfacePresenter and make some other code simpler.
Reviewed By: mdvacca
Differential Revision: D15242047
fbshipit-source-id: 8622d15b8fdb5c3a7e25091adf7be1108f87ecd5
Summary:
This diff changes the condition in `ViewShadowNode::isLayoutOnly()` removing checking for `onLayout` event listener.
We needed that before because the mechanism of emitting events was based on analyzing mutation instructures (we needed those to be generated for nodes with `onLayout`).
Recenly we changed that algorithm deeply integrating in layout infra, so we don't need this anymore.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15273491
fbshipit-source-id: 2d43f00d1b87369d5993fe5ba70c2de36b8ce0c5
Summary:
@public
`YGNodeGetInstanceCount` was only ever meant for tests, and caused data races in multi-threaded environments.
It was completely replaced with event-based counting for tests.
Here we remove public API around the counter, and the counter itself.
Reviewed By: SidharthGuglani
Differential Revision: D15174857
fbshipit-source-id: 228e85da565bac9e8485121e956a2e41910b11c8
Summary:
@public
Test utility on top of the new event system that maintains a counter of instantiated nodes. Meant to replace the global node counter.
Reviewed By: SidharthGuglani
Differential Revision: D15174855
fbshipit-source-id: 6998472f95a09b8da652257a26596164bdcf43d6
Summary:
@public
Publish two events, `NodeAllocation` and `NodeDeallocation`, in the same places where the global node counter is changed.
Reviewed By: SidharthGuglani
Differential Revision: D15174858
fbshipit-source-id: 6e4e9add88513b9e987189ca5035d76da2a1de55
Summary:
@public
Reduces measure cache size to a number that is enough for 95% of nodes, according to our (FB-internal) measurements.
Node size: 776b -> 584b
Reviewed By: SidharthGuglani
Differential Revision: D15183567
fbshipit-source-id: 9ae8cc78074271a015e7618b931ba0356de87a0c
Summary: Apparently, Yoga has a "quirks mode" and we have to enable that for Fabric. Which is probably a mistake that we have to make one more time.
Reviewed By: davidaurelio
Differential Revision: D15267852
fbshipit-source-id: 88a910fafc9ff64fb19376f4b74a2f2fd5827eba
Summary:
There are 2 issues:
* RCTTurboModuleManager may be initialized too late, so the module lookup from native via `[bridge moduleForClass:]` may end up going to the old system incorrectly
* In the case where JS is asking for a nativemodule, we may be incorrectly registering modules that are marked as RCTTurboModule - they should be ignored instead
Reviewed By: mmmulani, RSNara
Differential Revision: D15247632
fbshipit-source-id: 4e0fae33923810c74966b38276b206ac00723012
Summary: I don't recall why the mutation function return rvalue reference, but it is totally incorrect (the function cannot own the object, so returning a reference introducing a dungling pointer and will crash).
Reviewed By: mdvacca
Differential Revision: D15156312
fbshipit-source-id: 497d10de22a41906efe71cd10139e3710ae11a79
Summary:
PR https://github.com/facebook/react-native/pull/24633 introduced some inconsistency in crash messaging, this PR fix it. Asked by mhorowitz
[General] [Added] - Consistent reporting native module name on crash on native side
Pull Request resolved: https://github.com/facebook/react-native/pull/24704
Differential Revision: D15237424
Pulled By: cpojer
fbshipit-source-id: ded8db45b2a2ec9998ff33fdbecef3f12c19578f
Summary: Apparently it's not used anymore. And that a good this.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219258
fbshipit-source-id: e3258d851d1eec5955d86f99a0b0d8a1b0304cb4
Summary: I have noticed that `backfaceVisibility` example crashes (because actual value is a string/enum, not a boolean), so I fixed it.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219261
fbshipit-source-id: 27f76cd10903794d597adacb9da7300a42813f8e
Summary: After this change, all measuring operations based on `LayoutableShadowNode::getRelativeLayoutMetrics` will take into account the transformation matrices provided by shadow nodes. This will allow implementing scroll-offset-aware and custom-transform-aware measuring.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219259
fbshipit-source-id: 1d7cd8c0ee4406f4dd0002cd442dc0679391922b
Summary: The diff implements a function that applies given transformation to a point.
Reviewed By: JoshuaGross
Differential Revision: D15219263
fbshipit-source-id: 4cc0595b0dda38c1ede1f2885b800cbe57f54243
Summary:
`LayoutableShadowNode::getTransform` returns a transform object that represents transformations that will/should
be applied on top of regular layout metrics by mounting layer.
Reviewed By: mdvacca
Differential Revision: D15219262
fbshipit-source-id: e7aeb85b5f7e2fce3f8faf9dfcaee5dae3217d36
Summary: This diff implements encapsulating all time metrics in a single class for better extensibility and readability.
Reviewed By: JoshuaGross
Differential Revision: D15179835
fbshipit-source-id: 62bdf94435a0d37a87ad9bad613cc8e38043a235
Summary: iOS TurboModules work in OSS. I pulled out JSCallInvoker from `React-turbomodule-core`, as a part of D15055511. In this diff, I'm adding it back in.
Reviewed By: mdvacca
Differential Revision: D15195007
fbshipit-source-id: 64ee294a68c0a63ba400b8a829864c6619d3311a
Summary:
`CatalystInstanceImpl.cpp` now depends on `JSCallInvoker` and `JavaJSCallInvokerHolder`. Therefore, we need to correctly adjust the OSS builds to include these dependencies into the `libreactnativejni.so` file.
I made `ReactCommon/turbomodule/jscallinvoker` a static library `libjscallinvoker.a`. I then made `ReactAndroid/src/main/jni/react/jni`'s `libreactnativejni.so` depend on that static library. Also, because the Android NDK build system doesn't support header namespaces, I had to use the filesystem to simulate them. This is why all the `.cpp` and `.h` files for `JSCallInvoker` were moved to a `jsireact` folder.
Reviewed By: mdvacca
Differential Revision: D15194821
fbshipit-source-id: 0cee682e41db53d0619f56ad017d5882f6d554aa
Summary:
`TurboModuleManagerDelegate` is an abstract base class with the following API:
```
public TurboModule getModule(String name, ReactApplicationContext reactApplicationContext);
public CxxModuleWrapper getLegacyCxxModule(String name, ReactApplicationContext reactApplicationContext);
```
```
std::shared_ptr<TurboModule> getTurboModule(std::string name, jni::global_ref<JTurboModule> turboModule, std::shared_ptr<JSCallInvoker> jsInvoker) override;
std::shared_ptr<TurboModule> getTurboModule(std::string name, std::shared_ptr<JSCallInvoker> jsInvoker) override;
```
On the C++ side, when asked to provide a TurboModule with name `name`:
1. First, is this a CxxModule? If so:
1. Create the CxxModule and return
2. Otherwise:
1. Somehow get a Java instance of the TurboModule
2. If this Java object represents a CxxModule, like `FbReactLibSodiumModule`:
1. Grab the C++ part of this object, and wrap it in a `TurboCxxModule.cpp` and return.
3. Otherwise:
1. Wrap the Java object in a C++ HostObject and return.
This pseudocode demonstrates how we'd use `TurboModuleManagerDelegate` to implement `__turboModuleProxy`.
```
__turboModuleProxy(name, jsCallInvoker):
let cxxModule = TurboModuleManagerDelegate::getTurboModule(name, jsCallInvoker)
if (!cxxModule) {
return cxxModule;
}
// JNI Call that forwards to TurboModuleManagerDelegate.getLegacyCxxModule
let javaCxxModule : CxxModuleWrapper = TurboModuleManager.getLegacyCxxModule(name)
if (!javaCxxModule) {
return std::shared_ptr<react::TurboCxxModule>(javaCxxModule.getModule())
}
// JNI Call that forwards to TurboModuleManagerDelegate.getModule
let javaModule : TurboModule = TurboModuleManager.getModule(name)
if (!javaCxxModule) {
return TurboModuleManagerDelegate::getTurboModule(name, javaModule, jsCallInvoker)
}
return null
```
Reviewed By: mdvacca
Differential Revision: D15111335
fbshipit-source-id: c7b0aeda0e4565e3a2729e7f9604775782b6f893
Summary:
JSCallInvoker requires a `std::weak_ptr<Instance>` to create. In our C++, `CatalystInstance` is responsible for creating this `Instance` object. This `CatalystInstance` C++ initialization is separate from the `TurboModuleManager` C++ initialization. Therefore, in this diff, I made `CatalystInstance` responsible for creating the `JSCallInvoker`. It then exposes the `JSCallInvoker` using a hybrid class called `JSCallInvokerHolder`, which contains a `std::shared_ptr<JSCallInvoker>` member variable. Using `CatalystInstance.getJSCallInvokerHolder()` in TurboModuleManager.java, we get a handle to this hybrid container. Then, we pass it this hybrid object to `TurboModuleManager::initHybrid`, which retrieves the `std::shared_ptr<JSCallInvoker>` from the `JavaJSCallInvokerHandler`.
There were a few cyclic dependencies, so I had to break down the buck targets:
- `CatalystInstanceImpl.java` depends on `JSCallInvokerHolderImpl.java`, and `TurboModuleManager.java` depends on classes that are packaged with `CatalystInstanceImpl.java`. So, I had to put `JSCallInvokerHolderImpl.java` in its own buck target.
- `CatalystInstance.cpp` depends on `JavaJSCallInvokerHolder.cpp`, and `TurboModuleManager.cpp` depends on classes that are build with `CatalystInstance.cpp`. So, I had to put `JavaJSCallInvokerHolder.cpp` in its own buck target. To make things simpler, I also moved `JSCallInvoker.{cpp,h}` files into the same buck target as `JavaJSCallInvokerHolder.{cpp,h}`.
I think these steps should be enough to create the TurboModuleManager without needing a bridge:
1. Make `JSCallInvoker` an abstract base class.
2. On Android, create another derived class of `JSCallInvoker` that doesn't depend on Instance.
3. Create `JavaJSCallInvokerHolder` using an instance of this new class somewhere in C++.
4. Pass this instance of `JavaJSCallInvokerHolder` to Java and use it to create/instatiate `TurboModuleManager`.
Regarding steps 1 and 2, we can also make JSCallInvoker accept a lambda.
Reviewed By: mdvacca
Differential Revision: D15055511
fbshipit-source-id: 0ad72a86599819ec35d421dbee7e140959a26ab6
Summary: Diffing algorithm uses a small map for every layer of shadow tree; that's a lot of maps. Luckily, it does not need a complex feature-full map (which is not free to allocate and use), it needs a tiny map with a dozen values. Why do we need to pay for what we don't use? This diff introduces a trivial map optimized for constraints that we have here. (See more details in the code.)
Reviewed By: mdvacca
Differential Revision: D15200495
fbshipit-source-id: d859b68b9543253840b403e7430f945a0b76d87b
Summary:
This is a small micro-optimization in Diffing algorithm.
Seems we don't need to store full ShadowView objects in `insertedPairs` map, we can store only pointers to them. That can save memory and CPU cycles because we will not need to store full objects and copy shared pointers (which is somewhat expensive).
Reviewed By: mdvacca
Differential Revision: D15200498
fbshipit-source-id: 2a268c3ee80755555bff3317e10e679be1cf9830
Summary: Diffing is already pretty fast, but using move semantic should make it even faster. ShadowViews have shared pointers, so moving them can save us atomic counter bumps.
Reviewed By: mdvacca
Differential Revision: D15200496
fbshipit-source-id: 6fb0eb79e07cd6ae9b3100713497c634f306bc18
Summary: Convert FabricUIManager.measure params to floats. Currently we convert parameters to ints across the JNI boundary, and then back to floats several times in Java. This is unnecessary and actually makes measurements trickier. The new implementation uses floats across the JNI boundary and uses Float.POSITIVE_INFINITY to represent unconstrained values, which is consistent with Fabric C++ as well.
Reviewed By: shergin, mdvacca
Differential Revision: D15176108
fbshipit-source-id: cf849b3773007637f059279460163872f300a4aa
Summary: Looks like FBJNI exports a C Macro that does exactly what `throwIfJNIReportsPendingException` does. Therefore, I'm replacing `throwIfJNIReportsPendingException` with calls to `FACEBOOK_JNI_THROW_PENDING_EXCEPTION()`.
Reviewed By: mdvacca
Differential Revision: D15174820
fbshipit-source-id: 9dfb519352cbd5f37527675323cbabad05e31d4a
Summary:
`jclass` in `JNI` is just a regular local reference. Therefore, it's unsafe to keep a static reference to it. Link: http://journals.ecs.soton.ac.uk/java/tutorial/native1.1/implementing/refs.html.
This bug made it so that when you clicked on `getConstants` twice in the TurboModule playground, the app would crash.
Reviewed By: mdvacca
Differential Revision: D15174821
fbshipit-source-id: 13b2b8726473acc9b07306558044d26bed0db92d
Summary: Previously, we'd override the `TurboModule::get` method inside the `JavaTurboModule` class to return a special `jsi::Function` in the case that the property being accessed was "getConstants". We really don't need to do this because we can simply special-case the invocation of the `getConstants` method inside the `JavaTurboModule::invokeJavaMethod` method.
Reviewed By: mdvacca
Differential Revision: D15174822
fbshipit-source-id: 0ee705be841757d3870c908da911c3872b977a9f
Summary: We conducted an experiment with different measure cache sizes. This has now been deallocatedi (D15183473). Remove the necessary APIs.
Reviewed By: SidharthGuglani
Differential Revision: D15183486
fbshipit-source-id: a38fa5a3ab0321c2521265f7d1cd6b495efd76cf
Summary:
@public
`YGConfig::YGConfig(YGConfig*)` was not initializing the same fields as the default constructors.
Here, we make the default constructor delegate to the more specialized one to remove duplication.
Reviewed By: SidharthGuglani
Differential Revision: D15164599
fbshipit-source-id: 27247709091b7664386057d09ac67d481877871f
Summary:
* invokeMethod() ends up not useful because each platform has its own way of invoking the platform methods
* invalidate() is not necessary because there's already the destructor of each C++ class
Reviewed By: mdvacca
Differential Revision: D15187833
fbshipit-source-id: 9478ed1e6288da30c67179e03a7bc7da6043280b
Summary:
@public
We want to enable tooling, instrumentation, and statistics within Yoga without coupling these functionalities to our core code.
This commit introduces the foundations of a simple, global event system.
For the time being, we will only support a single subscriber. Should we require more than one, we can add support for it later.
Reviewed By: SidharthGuglani
Differential Revision: D15153678
fbshipit-source-id: 7d96f4c8def646a6a1b3908f946e7f81a6dba9c3
Summary:
Previously we computed the list of nodes that need to be notified about layout changes using a list of mutation instructions. That was fine, but that's not really compatible with some other changes that I plan to make, so I decided to change it (make it better).
Besides the better design (debatable; fewer dependencies to unrelated moving pieces), here is why I believe the new way is more performant:
* The new approach has no `dynamic_casts`, whereas the previous has tons of them (two per a mutation). If a `dynamic_cast` takes 10 ns, for 500 nodes it can take up to 5ms only for casts. (Non-scientific assumption.)
* After removing dependency to mutation instruction, we can enable flattening for views which have `onLayout` event.
Reviewed By: mdvacca
Differential Revision: D15110725
fbshipit-source-id: 31a657ccfd02441734ad1d71a833653223163289
Summary: Instrumentation tests are expensive and flaky. Luckly this one does not need to be instrumentation one.
Reviewed By: mdvacca
Differential Revision: D15158985
fbshipit-source-id: 3c88e5a0d82db2cd00f5866c3f9956409cc8fc7f
Summary:
@public
Makes bitfield getters/setters part of the bitfield ref template.
Since we introduced the tracking bit as template parameter in D14933022, every bitfield ref is an individual class anyway, and having function pointers doesn’t potentially lead to less code generation anyway.
Furthermore, this change can (in the absence of tracking bits) avoid less specialized templates dealing with refs, and to dynamic dispatch as a consequence.
Reviewed By: SidharthGuglani
Differential Revision: D15085495
fbshipit-source-id: 0dd70fa05e9d43a29e38a619cddb642c9ca3f7ab
Summary:
@public
In order to optimise property storage, we have to know how style properties are used in our apps.
Here, we add a bitmask that allows us to track which properties are set explicitely, and use that for our analysis.
Reviewed By: SidharthGuglani
Differential Revision: D14933022
fbshipit-source-id: 1ab8af562b14baba1d02057e527aa36d5c9a7823
Summary:
@public
The extra overload of `updateStyle` introduced in D15078961 can also handle `BitfieldRef`.
That means that we can remove the more specific implementation previously introduced for `BitfieldRef`
Reviewed By: SidharthGuglani
Differential Revision: D15081069
fbshipit-source-id: 98f1f3478627974c5273c85d268ca07350f303d7
Summary:
@public
Change style property accessors to return `Ref` instances instead of references to `CompactValue`.
This will allow to track assignments to properties later on, e.g. for instrumentation or dynamic property storage.
Reviewed By: SidharthGuglani
Differential Revision: D15078961
fbshipit-source-id: 259f05f7d30f093c04bf333c5bd4fb3601b8e933
Summary: This diff exposes the Legacy method UIManager.measureInWindow as part of Fabric
Reviewed By: shergin
Differential Revision: D15110795
fbshipit-source-id: 2b4bf47452f7272fd3edc4e580e65ae7ec2f2622
Summary:
Different frameworks use different kinds of floats, optional floats, and floats with assigned unit names. All those approaches use different ways to represent undefined and empty values. To deal with it we need to have some helper functions.
So, this diff changes some ways that we convert some corner values (like NaN and empty value). That change is motivated by recent personal discoveries in this field that shifted my vision on that. E.g. ComponentKit does not use `CGFloatMax` value as `Infinite` value. UIKit is also (surprisingly to me) okay with using `Infitite` instead of `CGFloatMax`. And, in general, seems using really conceptually appropriate values (instead of UIKit-inspired ones) it's the right thing to do.
Reviewed By: mdvacca
Differential Revision: D15155189
fbshipit-source-id: 33e15141f1ca3efb400a7160811224335de34ba1
Summary: `kFloatUndefined` means "no value here", but in this particular case, we have to have `Infinity` value that represents maximum available space.
Reviewed By: mdvacca
Differential Revision: D15155190
fbshipit-source-id: d2de20681ad04da7444331eff44b93d2bd0200e3
Summary:
We don't need to have those constants because this functionality is available in STL via `std::numeric_limits<YourParticularFloatType>::infinity()` (or `::min()` and `::max()`).
At the same time usage of `kFloatMax` was replaced with `Infinity` (which is a different value). Using `max` instead of `Infinity` was an attempt to mimic iOS/UIKit model where `Infinity` and `NaN` values usually are not being used. However, now this does not seem like a good idea. This concept is not used anywhere else (even in CK which is totally incompatible with it) and de-facto in RN we use it only in few places. So, let's use Infinity in places where it's logically appropriate.
Reviewed By: mdvacca
Differential Revision: D15155191
fbshipit-source-id: 4d24350c7540cec074a8b040d7c13f257aa812e7
Summary: This diff exposes the Legacy method UIManager.measureLayout as part of Fabric
Reviewed By: shergin
Differential Revision: D15103117
fbshipit-source-id: 4cf7ab3776f6a541cf0d6a00789420a0bb008fae
Summary: This adds support for specifying the exact selector name for each exposed ObjC method. This allows us to avoid dynamic method lookup every time a method is called from JS.
Reviewed By: RSNara
Differential Revision: D15141611
fbshipit-source-id: ed2820782ab013369e4e1f22dbce31d9838a17bb
Summary: Apparently we can/should not have in RCTConversions because it creates unnecessary dependency to core iOS module.
Reviewed By: mdvacca
Differential Revision: D15055325
fbshipit-source-id: 507f5a40c03b5c261967de4504297d31ecd02783
Summary: Sometimes we don't know for sure if `ContextContainer` has a value or not (and that's perfectly legit use case). In those cases now we can use `findInstance` method that returns an optional intead of throwing an exeption.
Reviewed By: JoshuaGross
Differential Revision: D15039137
fbshipit-source-id: 95ba8cc7b76e37d1bd17e18c0098e56350ff3fef
Summary: It turns out that just only props is not enought to build an initial state value in some cases for some component. Seems we need at least `surfaceId` and `eventEmitter` in some cases (which seems totally reasonable). So, seems using the whole `ShadowNodeFragment` for that purpose is a good choise.
Reviewed By: mdvacca
Differential Revision: D15039135
fbshipit-source-id: d9a5f47f971ccf6cdb2f888bd31f7948b37b67ef
Summary:
`ShadowNodeFragment` is very cheap by design because it does not own stuff it contains, so it's great. But... sometimes we need to own the stuff (e.g. to pass it on the other thread), in those cases we can use `ShadowNodeFragment::Value` now.
`ShadowNodeFragment::Value` cannot be used alone, it needs to be constructed from `ShadowNodeFragment` and then used as opaque object and then it can be converted to ``ShadowNodeFragment`.
We will need it soon.
Reviewed By: mdvacca
Differential Revision: D15039136
fbshipit-source-id: d40875cac05f4088358d8d418007d17df9ff14f4
Summary:
Trivial.
We are replacing rootTag with surfaceId according to the plan describing here: https://fb.workplace.com/groups/rn.fabric/permalink/1374002366064519/
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15039134
fbshipit-source-id: ec8c3044f9f3f23939488bc01c66e9b653e651dd
Summary: QE expired a while ago. Remove the experiment code.
Reviewed By: fkgozali
Differential Revision: D15133830
fbshipit-source-id: 562c3998cc7860497eefa9899dfb6bfcee4fe210
Summary:
@public
Adds `YGStyle::ValueRepr` to make code depending on the actual type easier to write.
So far, we have treated `yoga::detail::CompactValue` as an implementation detail, and that’s what it’s supposed to stay.
React Native Fabric has one value conversion overload that depends on that type, though, and used `decltype(YGStyle{}.margin()[0])` until now.
That’s problematic for two reasons:
- we want to constrain the parameter of `operator[](...)` to enum types, making the `0` unsuitable
- we want to return the non-const overload of the operator to return a custom `Ref` type, which is not the type needed by Fabric.
Making the storage type explicit allows to write more forward-compatible code.
Reviewed By: SidharthGuglani
Differential Revision: D15078960
fbshipit-source-id: 932c27ef2f2cdc6ce965b79894268170f0ccdce5
Summary:
@public
Some `YGNode*` passed as `const YGNode*`, some const refs to sub-objects introduced.
This helps selecting the desired methods in more places, i.e. `const` overloads of accessors on `YGStyle`.
Reviewed By: SidharthGuglani
Differential Revision: D15078963
fbshipit-source-id: 5013721d6edcc68f42f4504f5c331da647a294bd
Summary:
@public
Having binary operators as member functions has disadvantages:
- the left hand side cannot be converted to `YGFloatOptional` implicitly (which we need for `YGStyle` refs)
- Operators are not necessarily commutative.
By moving these operators into free functions, and adding overloads for both variants if one operand is `float`, we get these properties.
Reviewed By: SidharthGuglani
Differential Revision: D15078962
fbshipit-source-id: 2e228a2ef90a8083c91788caa9eedfd4d140677f
Summary:
After upgrading RN from 0.57 to 0.59.4 we've received a lot of crash reports like `Exception in HostObject::get: <unknown>` with no clue what native module caused the crash. This commit adds native module name on crash in this situations. Related to https://github.com/facebook/react-native/issues/24607.
[General] [Added] - Report native module name on crash when native module has failed to load
Pull Request resolved: https://github.com/facebook/react-native/pull/24633
Differential Revision: D15120225
Pulled By: cpojer
fbshipit-source-id: cf8e3e5953548a58f1d010eb70343da5ee946ae8
Summary:
@public
Takes a const reference to the style of the printed node once, instead of using repeated calls to `node->getStyle()`.
Makes the code a bit shorter, and ensures that we are operating on `const YGStyle&`, which helps selecting the correct methods further up the stack.
Reviewed By: SidharthGuglani
Differential Revision: D14999094
fbshipit-source-id: 814f06b7e3179ac8cfb43d79fbec48ee4115d6e3
Summary: In `ObjCTurboModule::getArgumentTypeName`, I replaced all instances of `':'` with `''` to transform the selector into a TurboModule methodName. This transformation works when the method has 0 or 1 argument, however, it breaks when the method has more than 1 argument. In all cases, we just want to get the substring until the first `':'`.
Reviewed By: fkgozali
Differential Revision: D15056937
fbshipit-source-id: 3a7dce1ce62ca9758e46c0af951b269166d68454
Summary:
Trivial.
Apparently, `DEBUG` is non-standard feature and using `assert` with `DEBUG` is practically asking for bugs. So, if your `assert` relies on some variable which is only defined when `DEBUG` is set, it's easy to get invalid code because NDEBUG and DEBUG can be unsync.
So, we have to use clunky double negative `#ifndef NDEBUG` everywhere where we used DEBUG.
Reviewed By: JoshuaGross
Differential Revision: D15031328
fbshipit-source-id: 036f573e68925741ca46384261885766c87db1e3
Summary:
@public
Introduces `YGNodeConstRef` as `const YGNode*`, i.e. a pointer to a constant `YGNode`.
We also use it for all style getters, which will avoid casts to `const YGNode*` in diffs up the stack.
We should use this pointer type for all functions that do not modify the underlying node.
Reviewed By: SidharthGuglani
Differential Revision: D14999095
fbshipit-source-id: 61cc53bb35e787a12ae12e70438d84c0a4983752
Summary:
@public
In order to encapsulate property access on `YGStyle`, as a first measure we wrap all fields with accessors.
This will e.g. enable dynamic property storage and instrumentation in the future.
All accessors have a `const` version that allows direct access via `const&`. For mutation, bit fields are wrapped with a custom reference object.
This style allows for the least amount of changes in client code. Property access simply needs appended parens, eg `style.direction` becomes `style.direction`.
Reviewed By: shergin
Differential Revision: D14999096
fbshipit-source-id: fbf29f7ddab520513d4618f5e70094c4f6330b30
Summary:
@public
Remove unnecessary `const` and `extern` specifiers from `Yoga.h`.
- Function declarations are `extern` by default
- The removed `const` specifiers for pass-by-valye parameters are only meaningful for the *definition* of functions, not for the declaration.
In this specific case, I found `const YGNodeRef` particularly confusing, as it is a `typedef` for a pointer type. `const` does not refer to the pointed-to object, but to the parameter itself, i.e. `const YGNodeRef` is `YGNode * const`, and not `const YGNode *`.
Reviewed By: SidharthGuglani
Differential Revision: D14999097
fbshipit-source-id: 8350870cb67f4a34722f796c4f4a2fc7dde41b99
Summary: `jClassName_` is unnecessary because you can use `JNIEnv::GetObjectClass` to get the TurboModule's Java class.
Reviewed By: fkgozali
Differential Revision: D14937480
fbshipit-source-id: 2c1c9be53217331152270dbac3d13f372a2ed818
Summary:
UAs must adjust border radius values to fit a content box:
>>> Corner curves must not overlap: When the sum of any two adjacent border radii exceeds the size of the border box, UAs must proportionally reduce the used values of all border radii until none of them overlap.
This diff implements that.
Reviewed By: mdvacca
Differential Revision: D15028325
fbshipit-source-id: 368232ffa2fa0409d13759bbbe7fe10f8474c400
Summary: Additional check verifies that requested type matches the type of a stored value.
Reviewed By: mdvacca
Differential Revision: D14944336
fbshipit-source-id: 6d3a1654d9b9a64ced83f553236093f02f2c97c7
Summary:
ShadowTree commits happen concurrently with limited synchronization that only ensures the correctness of the commit from ShadowTree perspective.
At the same time artifacts of the commit () needs to be delivered (also concurrently) to the proper thread and executed in order (not-concurrently). To achieve this we need some synchronization mechanism on the receiving (mounting) side. This class implements this process.
Practically, this diff fixes a problem with glitching UI during the very first render of Fabric screen.
Reviewed By: JoshuaGross
Differential Revision: D15021794
fbshipit-source-id: 62982425300c515e92b91e1e660b45455a5446e9
Summary:
`MountingTransaction` encapsulates all artifacts of `ShadowTree` commit, particularly list of mutations and meta-data.
We will rely on this heavily in the coming diffs.
Reviewed By: JoshuaGross
Differential Revision: D15021795
fbshipit-source-id: 811da7afd7b929a34a81aa66566193d46bbc34f8
Summary: We have to figure out a different way to request for a fallback component in ComponentDescriptorRegistry and in general, in public APIs. But now, to stop crashing here the fix.
Reviewed By: JoshuaGross
Differential Revision: D15021796
fbshipit-source-id: a60c66838e76ace990f2eb764c86c29d24db2141
Summary: `getContextContainer` should be marked as const so that const instances can call it.
Reviewed By: shergin
Differential Revision: D14969981
fbshipit-source-id: 8812f24ecf0642a38496580689943fbd43cddad1
Summary:
Registries, providers, providers of registries, registres of providers. All that can be really confusing, but that represents best the constraints and desires that we have:
* We need to be able to register components on-the-fly (so we need a mechanism that will propagate changes);
* We don't want to register ComponentDescriptors separately from ComponentView classes;
* C++ not always gives us abstractions that we want (e.g. pointers to constructors).
After the change, we can remove the whole Buck target that has a bunch of handwritten boilerplate code.
There is a still room for polish and removing some concepts, types or classes but this diff is already huge.
Reviewed By: JoshuaGross
Differential Revision: D14983906
fbshipit-source-id: ce536ebea0c905059c7a4d644dc25233e2809761
Summary:
ComponentDescriptorProvider represents unified way to create a particular descriptor.
Now all ComponentViews (which support RCTComponentViewProtocol) expose a `ComponentDescriptorProvider` which will allow creating and registering ComponentDescriptor instances for all visual components automatically as a part of ComponentView registration process.
Don't panic, everything is still being as explicit as it always was, no magic involved; we just will have only one registration step instead of two parallel.
That also opens a way to register components on the fly.
Reviewed By: JoshuaGross
Differential Revision: D14963488
fbshipit-source-id: 9e9d9166fabaf7b30b35b8647faa6e3a19cd2435
Summary: The bridge was not properly isolating isInspectable onto the JS thread.
Reviewed By: fkgozali
Differential Revision: D14991970
fbshipit-source-id: 92a06c90bade8f92bfa81fa3b7dfb23b17db6117
Summary: This installs the sample module to the RNTester.xcodeproj without using any TurboModule infra. This is possible because SampleTurboModule is backward compatible with the existing NativeModules system. This also fixes CI test failure: https://circleci.com/gh/facebook/react-native/84752
Reviewed By: RSNara
Differential Revision: D14987572
fbshipit-source-id: f5f2c4330c7f6558c7d4beeb43198869090dee02
Summary:
Motivation:
* We don't use them much, and we already have `at`-methods, which are better.
* We don't want to expose `ComponentDescriptor`s as shared pointers (because it's not clear, not so performant, and because we don't want to store them as shared pointer in the future);
* In idiomatic C++ `[]` operator has mutating semantic, that's not what we want to communicate via the interface of the class.
Reviewed By: sahrens
Differential Revision: D14963487
fbshipit-source-id: dbfddee2ba90d70c3bb8dcf1959d553571c47bab
Summary:
If you call into a Java method (from C++ using JNI) that raises an exception, the JNI call won't actually raise a C++ error. Instead, the `JNIEnv` will record the pending Java exception and the C++ will continue executing as normal. This is bad because the next time you call into JNI, the app will actually crash, unless you explicitly cleared the exception using `JNIEnv::ExceptionClear()` before the JNI call.
With respect to TurboModules, we need to make sure that RedBoxes show up whenever a native methods raise an exception. We also don't want the app to crash when a JNI method call fails because of a raised exception. Therefore, in this diff, I raise a C++ exception if `JNIEnv::ExceptionCheck()` is true.
Reviewed By: mdvacca
Differential Revision: D14738540
fbshipit-source-id: 4c3063aa93ae7aef025bd2dab6b45059bb8fb409
Summary:
If the return type of a TurboModule method is `Promise`, the infra should create a `com.facebook.react.bridge.Promise` object and pass it as the final argument of the TurboModule Java method call. The Java TurboModule method can then do some work asynchronously and either resolve or reject the promise at some point in time.
**Note:** I stacked a diff for error handling on top of this one.
Reviewed By: mdvacca
Differential Revision: D13653156
fbshipit-source-id: 4c30c3223ad8f47c6ba7f1236527aaced01c8ae8
Summary:
Turns out that storing and using ContextContainer in custom subclasses is a huge pain. At the same time seems that a lot of custom components need some DI instrument, so we need this instrument anyway.
Moving stuff from the template to the base class should also help with codesize a bit.
Reviewed By: JoshuaGross
Differential Revision: D14921356
fbshipit-source-id: 4dbb961fe32bd66c73513d7e053bbed229860a31
Summary:
@public
This allows short methods defined in class declarations to occupy a single line.
The change makes class declarations more readable.
Reviewed By: SidharthGuglani
Differential Revision: D14950012
fbshipit-source-id: 1321949475184181c6cceb86613f730e430763e2
Summary: This sets up RCTSampleTurboModule (and other variants) in RNTester when built with cocoapods. There's no call site yet though. And RNTester.xcodeproj doesn't support it.
Reviewed By: cpojer
Differential Revision: D14932535
fbshipit-source-id: db8eafd6777cbec8f3592dafdccbdd7cf44e38bc
Summary:
This provides various versions of SampleTurboModule, that are:
* compatible with existing NativeModule
* TurboModule compliant
Variants:
* RCTSampleTurboModule (traditional objc module)
* RCTSampleTurboCxxModule (objc++ module using CxxModule)
* SampleTurboModule (pure C++ impl of a TurboModule, no ObjC)
As noted in some files, they need to be codegen'ed based on the `NativeSampleTurboModule.js` (Flow type). The codegen script is not yet usable in OSS (we'll work on it some time in H2 2019). For now, these files need to be manually synced with Flow type.
Reviewed By: cpojer
Differential Revision: D14932539
fbshipit-source-id: fb887192384e5e6e4dff4cac68b4e037a4783cd9
Summary:
For CocoaPods variant only: install TurboModule binding so that sample modules can start using it. This commit only installs `global.__turboModuleProxy` - no sample module is provided.
Note: RNTester.xcodeproj will NOT have TurboModule enabled, due to complication in the .xcodeproj setup (doable, but maybe for some other time...)
To test:
```
console.error(global.__turboModuleProxy == null ? 'BOO' : 'YAY!');
```
Saw `YAY!` in RNTester pod version.
Reviewed By: cpojer
Differential Revision: D14932536
fbshipit-source-id: 3dc083da9154ec320ce6789ec7f2cef5a08fd6a7
Summary:
We were using four edges for margin, padding and border. This diff changes the array size in YGLayout for margin, padding, border to reduce YGNode size and corresponding changes while we are setting values in YGLayout.
Reduces the YGNode size by 24 bytes
Reviewed By: davidaurelio
Differential Revision: D14892666
fbshipit-source-id: 94013d5183ee869901267c4c9941fd94fa05d848
Summary:
This diff replaces all MountItem classes with a bunch of static C functions that do the same job as classes did.
Seems, originally we overestimated the complexity of MountItem classes and that they ended up being notably trivial. Now, maintaining that even longer would mean paying for abstractions and allocations that we don't really need and writing a lot of tedious code.
Besides that, the one particular change that will be introduced in the coming diffs is not particularly fit very well in the existing class-based model.
This change also should save us many hundreds of allocations and atomic counters bumps, so maybe we can get a millisecond-or-two win.
This diff does not introduce any practical behavioral/logical changes in the mounting layer.
Reviewed By: mdvacca
Differential Revision: D14893764
fbshipit-source-id: 6f1247923ae36f29c12a7d358e2d496cf6c3e298
Summary: This fixes a minor bug where the original props (like for styling) got dropped when the system falls back to UnimplementedView.
Reviewed By: mdvacca
Differential Revision: D14898906
fbshipit-source-id: 4a07952ceac66e491a5c0bc1ffd99f21438cda31
Summary:
This diff changes the way views are inserted by the diffing algorithm.
Previously the diffing algorithm inserted views top-down, now it insert views bottom-up (same order as previous version of RN).
Let say we need to create the following tree:
```
A --> B --> C
|
| --> D
```
Before, the diffing algorithm created the following list of instructions:
```
insert(A, B, 0)
insert(B, C, 0)
insert(B, D, 1)
```
After this diff, the insert instructions are going to be:
```
insert(B, C, 0)
insert(B, D, 1)
insert(A, B, 0)
```
Reviewed By: shergin
Differential Revision: D14817454
fbshipit-source-id: 7aac1a1e1784c53bca2747aee80a5bc8ee788e7a
Summary:
This allows an unsupported component to be rendered as a "unimplemented view" for better visualization of which component is missing. It is off by default, but configurable in the component factory.
For now, the layout simply follows regular <View />, which means the width/height etc is based on the react component styling. The side effect is that components with 0 height/width won't show up at all.
Reviewed By: mdvacca
Differential Revision: D14869656
fbshipit-source-id: f31e012fb7dc1c64fcc431ea5aa45079a23a618e
Summary:
For props that expects a struct/object value, like scrollView's contentInset, not all keys may be present. For example:
```
<ScrollView ... contentInset={{top: 10}} />
```
In this example, `left`, `bottom`, and `right` should just default to 0 (or whatever the default is in the platform). Before this fix, an exception occured when calling `fromRawValue()` because it is assuming all 4 keys are present in the prop bag. However, only `top` key was present in this example.
To fix this, we have to loop through the available keys in the prop bag, then assign the values accordingly.
Reviewed By: JoshuaGross
Differential Revision: D14868549
fbshipit-source-id: e25208eb31f6d4061338e9cac48a93fe71859859
Summary:
Related 094f221a0c, restructure the jsi directory, so update the podspec file either.
cc. shergin cpojer
[iOS] [Fixed] - Update jsi podspec to support new directory structure
Pull Request resolved: https://github.com/facebook/react-native/pull/24388
Differential Revision: D14869999
Pulled By: cpojer
fbshipit-source-id: 0a5df7e2ad83702c0498b2f70072735accc7f54c
Summary: This change synchronizes the JSI API with its upstream, aiming to make this easier to automate in the future.
Reviewed By: mhorowitz
Differential Revision: D14783311
fbshipit-source-id: c180d0f728afbeb87a3e8e7331a39c06e73b907e
Summary: This will simplify updating the JSI API from upstream in the future.
Reviewed By: mhorowitz
Differential Revision: D14762674
fbshipit-source-id: fa4a86f08425943e301da4ef3df9893ebaa1493e
Summary:
@public
Regenerating the “golden master” tests with chrome surfaced different bugs around `align-content`:
- a misunderstanding that values in `align-content` only applied *if there is only one line.* In fact, it applies *every time* a container is set to `flex-wrap: wrap`. Chrome had this wrong, and as such our tests were generated with incorrect parameters.
- empty children growing to the cross axis size of the container, even when `align-content` is different from `stretch`. This was implemented incorrectly in Chrome as well. Here, we fix it with an extra check.
Reviewed By: SidharthGuglani
Differential Revision: D14725402
fbshipit-source-id: a45bebdadb9c694dc0eb7e27cb52b3d247f81c50
Summary:
Previously, all placeholders methods have return type `SomeType &` which is not correct because it allows the called to modify enclosed `static` value of the placeholders; the type should be `SomeType const &`.
Besides that this diff migrates some type aliases to the new style (which makes evething much prettier and readable).
Reviewed By: mdvacca
Differential Revision: D14819076
fbshipit-source-id: 87e68d546f16d7a9ad1fb65e1b238859f9381eb7
Summary: Add experimental support for reordering the pages of a file that is mmap:ed by JSBigFileString. The wrapper is auto-detected (by checking file size and magic header) and transparently reorders the pages.
Reviewed By: ridiculousfish
Differential Revision: D14721397
fbshipit-source-id: 34e095350a9eeb9b07105bed6f3379f2fe472ae6
Summary:
Trivial.
Now we can print actual list of mutations in case of some failure in the diffing algorithm.
Reviewed By: mdvacca
Differential Revision: D14715079
fbshipit-source-id: d0af7c756287643892d7120c199bc8028a6b3431
Summary:
Informal `DebugStringConvertible` interface serves the same purpose as `DebugStringConvertible` abstract class (providing universal pretty-printing interface) but relies on C++ static overloading instead of virtual dispatch.
This approach has some advantages and disadvantages:
Pros:
* It's more clear and scoped. It's simpler to implement debug-printing functionality aside of normal production code.
* It's more composable.
* It allows print types that are not classes.
* For some classes using `DebugStringConvertible` means that we have to use virtual inheritance (which might be undesirable and affect *production* performance (if a compiler isn't smart enough to remove empty base class).
* For some highly lean classes (that designed to be as small as possible) adding base (even empty-in-prod) classes kinda... smells.
Cons:
The particular implementations cannot rely on dynamic dispatch which can complicate printing classes with meaningful differences between sampling classes (e.g. ShadowNode subclasses). That's why we don't remove `DebugStringConvertible` class yet.
Reviewed By: mdvacca
Differential Revision: D14715081
fbshipit-source-id: 1d397dbf81dc6d1dff0cc3f64ad09f10afe0085d
Summary:
They need to be in DebugStringConvertible because it depends on they (and because `debugStringConvertibleUtils` depends on `DebugStringConvertible`).
We also moved they implementation to cpp file to avoid leaking Folly's features to consumer namespace.
Reviewed By: mdvacca
Differential Revision: D14715080
fbshipit-source-id: 7277e17b39a14a2d7ba7e5a9b44a70178feb1045
Summary:
* Small improvements in pretty-printing algorirhm (adding spaces and new-line caracters). Now it's even more pretty.
* The `depth` parameter was integrated into `DebugStringConvertibleOptions` which simplifies evething a bit and reduce amount of arguments that `getDebugDescription` requires.
Reviewed By: sahrens
Differential Revision: D14715082
fbshipit-source-id: 3ea0b8db3c1816c5cb43f40ccec9cdc1943f33a5
Summary:
@public
In order to get out of pre-releases again, we move `YGSetUsedCachedEntries` from `Yoga.h` to `Yoga-internal.h`.
This way, it’s obvious that the function is not public, and we can remove it from future versions without breaking semver contracts.
Reviewed By: SidharthGuglani
Differential Revision: D14726029
fbshipit-source-id: 8d7e747e843bf5c4b5e1d4cfbfa37ca9d240dffb
Summary:
There is a timing issue when reloading the bridge (in dev mode) and the tear down of the TurboModules. This causes `Instance` to never get freed, hence the "bridge" isn't cleaning up properly. The side effect can be bogus error saying that it's unable to find a module.
To address this, JSCallInvoker should just take in weak_ptr<Instance>.
Reviewed By: RSNara
Differential Revision: D14739181
fbshipit-source-id: f9f2a55486debaeb28d3d293df3cf1d3f6b9a031
Summary: Add a target for JSBigString tests that can be run with a normal `buck test` invocation. Also fix an issue in the test when `getenv` returns null by defaulting to `/tmp`.
Reviewed By: ridiculousfish
Differential Revision: D14716270
fbshipit-source-id: f2eb6d3aab93c32a4b41f5786aedd04a70468d75
Summary:
We suspect that we have some error in diffing algorithm that cause some crashes in mounting layer, so we decided to write a comprehensive unit tests for that.
Writing them we realized that it would be cool to also enable that for normal app run in the debug more, so we can catch the problem in real environment when/if it happens.
Reviewed By: mdvacca
Differential Revision: D14587123
fbshipit-source-id: 6dcdf451b39489dec751cd6787de33f3b8ffb3fd
Summary: Because it's kinda more logical and we will rely on this in comming diffs.
Reviewed By: mdvacca
Differential Revision: D14587124
fbshipit-source-id: 94ae9410b4ffeffd0fcb4da4a0518f0bb0d2ba63
Summary:
If a NativeModule method requires an optional boolean argument, our codegen translates those optional booleans into `NSNumber*` instead of `BOOL`. The reason why is probably because this is the closest object analogue to `BOOL` in Objective C. The same boxing occurs with numbers. If the type of a number argument in JavaScript is optional, we'll map it to the `NSNumber*` Objective C type instead of `double`. Our existing TurboModules argument conversion code would not take this behaviour into account. Therefore, we'd try to insert a `BOOL` where the `NSInvocation` would expect a `NSNumber*`. This, in turn, would cause the app to crash. (Why would it crash at the point of NSInvocation retainArguments, I'm still not sure).
Our flow typechecking ensures that if the type of a method argument is a boolean, we pass in a boolean. Therefore, on the Native side, if we detect a boolean, we can check the type of the Native argument to see whether we should box the primitive. If the native argument type is an object, then we know it has to be an `NSNumber*` in both cases, so we simply wrap the `BOOL` or `double` in a `NSNumber*`.
Reviewed By: shergin
Differential Revision: D14679590
fbshipit-source-id: c394a878492aab8e98c71d74ec8740a94fc3a6c5
Summary: Before the fix, the algorithm compares ShadowViews to make a decision should it recursively call itself or not; that didn't work properly because a ShadowView doesn't fully represent the state of the subtree tree (e.g. they don't have information about children nodes). After the fix, we compare pointers to ShadowNodes (by comparing pairs).
Reviewed By: mdvacca
Differential Revision: D14696996
fbshipit-source-id: 560d623b15a272f13b08a11745dec6be39a5dbdd
Summary: When calling into JS (e.g. promise resolve/reject, callback) in TurboModule, we bypass the bridge's message queue. At times this causes race condition, where there are a bunch of pending UI operations (in RCTUImanager) waiting to be flushed, but nothing adds calls to the message queue. Usually tapping the screen will trigger the flush because we're sending down touch events to JS.
Reviewed By: JoshuaGross
Differential Revision: D14656466
fbshipit-source-id: cb3a174e97542bf80f0a37b4170b6a8e6780fa35
Summary: Small changes to State objects to support Android. See following diffs.
Reviewed By: mdvacca
Differential Revision: D14663470
fbshipit-source-id: 878f4dc39265991a7b8ff54ca80bdb862f1dd3de
Summary:
In D14571128, we made it so that when a JS object's property was `undefined`, we wouldn't insert that property into the corresponding NSDictionary. Here are two important observations about that diff:
1. ALL JS `null`s were now being converted to `NSNull`, and JS `undefined`s were now being converted to `nil`.
2. If a JS object's property was explicitly `null`, then we'd insert `NSNull` into the corresponding dictionary.
Considering that when a property doesn't exist in a `NSDictionary`, property access returns `nil`, I've made it so that if a JS object's property is either `null` or `undefined`, then we simply do not insert it in the corresponding `NSDictionary`. Also, I've reverted #1 and made it so that `undefined` and `null` always map to the ObjC `nil`.
This shouldn't unfix the problem that D14571128 was trying to fix.
Here's my understanding of the problem that D14571128 was trying to fix (to make sure I'm not breaking something by this diff).
This method was invoked from JS.
```
RCT_EXPORT_METHOD(logEvents:(NSDictionary *)events)
{
RCTAssert(events, @"You should provide events for logger");
[[NSNotificationCenter defaultCenter] postNotificationName:@"FBReactPerfLoggerDidReceiveEventsNotification"
object:nil
userInfo:@{@"FBReactPerfLoggerUserInfoPerfEventsKey" : [events copy]}];
}
```
The above dispatch calls into this method, which appends `events` into `_pendingJSPerfEvents`.
```
- (void)reactPerfLoggerDidReceiveEvents:(NSNotification *)notification
{
NSDictionary *events = notification.userInfo[@"FBReactPerfLoggerUserInfoPerfEventsKey"];
if (events) {
dispatch_async(_eventQueue, ^{
if (self->_sessionData.perfLoggerFlagId != nil) {
if ([self processJSPerfEvents:events]) {
[self reportMetricsIfFinished];
}
} else {
[self->_pendingJSPerfEvents addObject:events];
}
});
}
}
```
Then, in `_processJSPerfEvents`, we do the following (link: https://fburl.com/tr4wr2a7):
```
NSNumber *actionId = events[@"actionId"];
if (actionId) {
self->_sessionData.actionId = actionId;
}
```
So, if `undefined` or `null` was passed in as the `actionId` property of the `events` JS object in `FBReactPerformanceLogger logEvents:`, then we'd default the `NSDictionary` to have `NSNull` in the corresponding property. This is bad because we had this line in FBReactWildePerfLogger (link: https://fburl.com/2nsywl2n): `actionId ? [actionId shortValue] : PerfLoggerActions.SUCCESS`. Essentially, this is the same problem that my diff is trying to fix.
Reviewed By: fkgozali
Differential Revision: D14625287
fbshipit-source-id: c701d4b6172484cee62494256175e8b205b23c73
Summary:
@public
I would like to get rid of implicit conversions between `YGValue` and `CompactValue`, because they don’t come for free.
That’s why I am adding `CompactValue` specific overrides for `YGResolveValue` and `YGValueEqual`, that do explicit casts. Up the commit stack, we will be able mark both `CompactValue(const YGValue&)` and `CompactValue::operator YGValue()` as `explicit`.
Reviewed By: SidharthGuglani
Differential Revision: D14598447
fbshipit-source-id: 75dc15cefb2dddcf8def891c5fb37893cacd9d46
Summary:
We will use it inside `core` module, so we have to decouple it from `view`.
As part of this, I added some comments, changed `const Float &` to just `Float` and put the implementation into `.cpp` file.
Reviewed By: mdvacca
Differential Revision: D14593952
fbshipit-source-id: 80f7746f4fc5b95febc8df9f5a9c0386a6425c88
Summary: This is based on the work done in D8686586. Removed the logger instance from JSIExecutor constructor and installed it into the runtimeInstaller at all call sites.
Reviewed By: mhorowitz
Differential Revision: D14444120
fbshipit-source-id: 0476fda4230c467573ea04102a12101bcdf36c53
Summary: This diff replaces usage of abort() with LOG(FATAL) when a prop-value is not found during parsing of prop values
Reviewed By: fkgozali
Differential Revision: D14591210
fbshipit-source-id: 4a8484ea6bdfec5534122ded43cc24ef80c13c1d
Aditya Kumar
David Vacca
Sidharth Guglani
David Aurelio
Kevin Gozali
Joshua Gross
Valentin Shergin
Rain
Tim Yung
zhongwuzw
Will Holen
Emily Janzer
Ramanpreet Nara
REDMOND\acoates
Dratwas
Michal Sienkiewicz
Eric Lewis
RCiesielczuk
Dmitry Dushkin
Zeyad Salloum
Estevão Lucas
Marc Horowitz
Daniel Andersson
Dhaval Kapil
Yuan Du
