Summary: Add assorted missing includes in `xplat` that would be exposed by future changes.
Reviewed By: ispeters, nlutsenko
Differential Revision: D14213660
fbshipit-source-id: 329f133784015fe20ee99feaec8ef05e117fe3a6
Summary:
This is a back-out of D14214844, we noticed that this regressed TTI for Marketplace You screen running in Fabric
Original commit changeset: b81005f2bf49
Reviewed By: JoshuaGross
Differential Revision: D14247897
fbshipit-source-id: de0cea92b437b2fbcd075f0d6a0066156800e3f0
Summary: Small perf wins for both iOS and Android.
Reviewed By: PeteTheHeat
Differential Revision: D14237532
fbshipit-source-id: 2be114d36adfa6e8540cb8cbca5412782791d8ce
Summary:
In React Native there are several use cases where React State is not the only input that affects the component tree. E.g., in case of a <Modal> component, the screen size directly affects the layout of components inside modal; in the case of uncontrolled <TextInput> component, the text inside the input affects the layout of the surrounding components. `State` is a special (legit!) workaround for all those similar cases. Native part of React Native maintains a special shared object between all nodes of the same family and use that during cloning and commits.
See coming commits to know how to use that.
In the near future State will fully replace LocalData concept but for simplicity they both exist for now.
Reviewed By: mdvacca
Differential Revision: D14217184
fbshipit-source-id: 6e018c5b68208d662462013bce0f4e2733d2f673
Summary:
A couple of small changes:
1. `onEnqueue` was decoupled from `enqueueEvent` for easier and unified overiding in subclasses (other methods will call `onEnqueue` soon);
2. `flushEvents` was decoupled from `onBeat` (we will put more stuff into `onBeat` soon).
Reviewed By: mdvacca
Differential Revision: D14205769
fbshipit-source-id: 574c2b2caaa6432bc7782b2f3bc147fa1fb82bd3
Summary: `LayoutConstraints::clamp` clamps the provided `Size` between the `minimumSize` and `maximumSize` bounds of this `LayoutConstraints`.
Reviewed By: mdvacca
Differential Revision: D14205770
fbshipit-source-id: 4799608cead393451d334e47dd6906255699a1e8
Summary: That's bummer that we have to do it, but it's actually reasonable. Files in `core` and `events` depend on each other creating circular dependencies and other similar hard problem.
Reviewed By: mdvacca
Differential Revision: D14195022
fbshipit-source-id: 96a44ae28631cc9ccd7d7de72a94526f9e0dd12a
Summary:
This diff changes the pre-allocation of Images update the props on the ImageViews during the creation of ShadowNodes instead of during rendering.
The purpose of this change is to optimize TTI.
Reviewed By: shergin
Differential Revision: D14214844
fbshipit-source-id: b81005f2bf494f62f421dc24846e1561e13b9a87
Summary:
Not super clean, but not terrible.
Unfortunately this still relies on the old Paper UIManager calling delegate methods to flush the operations queues. This will work for Marketplace You since Paper will be active, but we need to fix this, along with Animated Events which don't work at all yet.
Random aside: it seems like taps are less responsive in fabric vs. paper, at least on iOS. There is a sporadic delay between the touches event coming in nativly to the JS callback invoking the native module function to start the animation - this will need some debugging.
Reviewed By: shergin
Differential Revision: D14143331
fbshipit-source-id: 63a17eaafa1217d77a532a2716d9f886a96fae59
Summary: It's handy to have all in one file but it also make it hard/impossible to fight with circular dependencies, so I had to slit it.
Reviewed By: mdvacca
Differential Revision: D14188546
fbshipit-source-id: 20809f1ea227c6f8f32922ed5760226248b718e3
Summary:
The previous implementation of the method cloned the root node twice (one time at the very end of the method and one time at the end of loop body).
The new one does it once and a bit more readable.
Reviewed By: mdvacca
Differential Revision: D14187969
fbshipit-source-id: 9859deadd4b041ac115c37108188aab70200c75d
Summary:
RootShadowNode does not have ComponentDescriptor counterpart (because it cannot be created via UIManager) and we used to always clone it manually.
However, apparently, some algorithms (e.g. clone algorithm inside RootShadowNode, which is used by setNativeProps) require valid clone function associated with the node.
So, we implement it.
Reviewed By: JoshuaGross
Differential Revision: D14187762
fbshipit-source-id: a9b6b332a18583217ff0e4f9c15aea0ffb113ba2
Summary:
The ConcreteViewShadowNode was changed to be independend of actual amount of template arguments of ConcreteShadowNode.
We will use it soon.
Reviewed By: JoshuaGross
Differential Revision: D14187761
fbshipit-source-id: b4c8051e2ae3803932713b0c255492466e80d3bd
Summary:
* "rotate" is often used as shorthand for "rotateZ"
** Paper handles this here: diffusion/FBS/browse/master/xplat/js/react-native-github/React/Views/RCTConvert%2BTransform.m$89
* Sometimes react sends a string with units, e.g. "45deg", so we need to convert that to a Float.
** Paper handles this here: diffusion/FBS/browse/master/xplat/js/react-native-github/React/Views/RCTConvert%2BTransform.m$14-27
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D14154173
fbshipit-source-id: 53d7405f26c78bb470d46879309c9697d9985c1c
Summary:
This PR implements the first part of [RFC0004: CocoaPods Support Improvements](353d44f649/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects.
The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are:
* `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies.
* The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`.
*Next steps (not in scope of this PR):*
- Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`.
- Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR)
[iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project
Pull Request resolved: https://github.com/facebook/react-native/pull/23559
Differential Revision: D14179326
Pulled By: cpojer
fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
Summary: Currently xcode fails profile builds since these variables are unused when asserts are disabled.
Reviewed By: PeteTheHeat
Differential Revision: D14160565
fbshipit-source-id: 997352dd148d23c28fa92d4171071c1abbb742f5
Summary: Trivial. If it compiles, it works.
Reviewed By: JoshuaGross
Differential Revision: D14146579
fbshipit-source-id: 6f6895d1634709a5bde012850c5df756171320ab
Summary:
@public
`setBaseLine` was the only place where we used a capitalised *L.* Fixed here.
Reviewed By: SidharthGuglani
Differential Revision: D14152320
fbshipit-source-id: abf54fe7d6088e03775968baa8421c4bf43d6a6e
Summary:
@public
Adds the ability to opt into avoiding global weak JNI refs via `YogaConfig`.
Note that only homogeneous trees are supported, i.e. **mixing weak-ref and non-weak-ref nodes will break!**
Not using JNI refs hopefully will help with avoiding JNI reference table overflows, and will help creating trees on multiple threads, as no lock has to be acquired at any time.
Reviewed By: SidharthGuglani
Differential Revision: D14151037
fbshipit-source-id: 56d94713d39aee080d54be4cb4cdf5e3eccb473a
Summary:
From the git log, we added `__fbRequireBatchedBridge` in this commit 6dc3a83e88, I don't ensure wether I missed something, we actually don't define `__fbRequireBatchedBridge` on `JS` or `Native` side, so `__fbRequireBatchedBridge` getter operation itself would throw exception.
[General] [Fixed] - Remove __fbRequireBatchedBridge call when not get batchedBridge
Pull Request resolved: https://github.com/facebook/react-native/pull/23547
Differential Revision: D14160706
Pulled By: cpojer
fbshipit-source-id: df9180a9a16716a91369249333752316fb6648c5
Summary: Let JS decide if a missing method should be treated as an error, or whether it allows optional methods (e.g. methods that are only for android or for ios).
Reviewed By: JoshuaGross
Differential Revision: D14155799
fbshipit-source-id: 1e298b46a59761cf09e98147da885b1e9a9a675a
Summary:
@public
Context-aware cloning functions are an internal Yoga feature that will be used for Yoga’s JNI code.
It will be possible to specify a context when calculating layout, which will be passed on to cloning functions. This will be a private feature.
Reviewed By: SidharthGuglani
Differential Revision: D14149470
fbshipit-source-id: 1d11106e65f9d872d10f191763da001f8d158a61
Summary:
@public
Limit child cloning to layout calculation. This also allows for mixing shared and owned children.
Rationale:
We do allow for shared children if the caller manages themselves. The single known use case is React Native.
So far, we have cloned children eagerly whenever child lists are mutated, or layout is run. This was to allow for a quick check of the owner of any first child, assuming that either *all* or *no* child of a node are shared.
For Yoga/Java, we want to get rid of global weak JNI refs, and these are also used to invoke clone callbacks. We can achieve that goal by switching to an alternative approach, passing additional data to the layout pass. This additional data has to be passed to any configured cloning callback. Therefore, it is desirable to **only call cloning functions during the layout pass.**
The obvious solution seems to be to not uphold the invariant of the first child determining shared/owned state of all siblings, and allow for a mix of shared and own children.
Reviewed By: shergin
Differential Revision: D14136223
fbshipit-source-id: 34490cfeeb2170c99d6ed1b9bdcbcedb316813af
Summary:
@public
Encapsulates node cloning within `YGConfig`.
This is necessary for allowing for context-aware cloning functions, which will ultimately allow for removal of weak global JNI references.
Reviewed By: shergin
Differential Revision: D14132608
fbshipit-source-id: 0dec114c8e172b1e34a4b7fd146c43f13c151ade
Summary:
This is a re-submit of #23367, which was accidentally over-written in this commit:
0d7faf6f73
This pull request makes this change to `jsi.h`:
* Tweak the call to constructor `Pointer(Runtime::PointerValue* ptr)` in the constructor for `PropNameID`. I am not sure why MSVC wasn't working with the original version, but it compiles after I tweak that.
[General] [Fixed] - Tweaked `jsi.h` to build on MSVC
Pull Request resolved: https://github.com/facebook/react-native/pull/23492
Differential Revision: D14151511
Pulled By: hramos
fbshipit-source-id: 52d726d7b978d321a0343566ee527f2ec25e93f8
Summary: Use the new copyright header format used elsewhere in the React Native repository.
Reviewed By: shergin
Differential Revision: D14091706
fbshipit-source-id: b27b8e6bcdf2f3d9402886dbc6b68c305150b7d5
Summary:
@public
Context-aware print functions are an internal Yoga feature that will be used for Yoga’s JNI code.
It will be possible to specify a context when calculating layout, which will be passed on to baseline and measure functions. This will be a private feature.
Reviewed By: SidharthGuglani
Differential Revision: D14131098
fbshipit-source-id: 7a9da307274ceccba9f7debba581b70c1ebf2c98
Summary:
@public
Removes `YGNodeGetPrintFunc`, and encapsulates node printing within `YGNode`.
This is necessary for allowing for context-aware callback functions, which will ultimately allow for removal of weak global JNI references.
On a side node, the printing logic does not seem to be well thought through: print functions print as a side effect to whatever output they choose. Printing that uses callbacks is printing to different output streams or strings, though.
We need to consolidate Yoga debugging, and make it all more stringent.
Reviewed By: SidharthGuglani
Differential Revision: D14131024
fbshipit-source-id: 68704682dab3e7dfba61930bb03003d7d4723b80
Summary:
publc
Adds the ability to calculate layout with a context pointer set.
The context is passed through to measure and baseline functions of individual nodes.
This will be used to remove the necessity of holding weak global JNI references for each node.
Reviewed By: SidharthGuglani
Differential Revision: D14101426
fbshipit-source-id: 25047e1e44af48feb22ea686285d70803e8961bb
Summary:
@public
Context-aware measure and baseline functions are an internal Yoga feature that will be used for Yoga’s JNI code.
It will be possible to specify a context when calculating layout, which will be passed on to baseline and measure functions. This will be a private feature.
Reviewed By: SidharthGuglani
Differential Revision: D14100509
fbshipit-source-id: acf4a030549b2e38d5ce0cd5dbe837864e5ffd81
Summary:
@public
Stricter encapsulation of baseline and measure callbacks withing `YGNode`.
Instead of invoking these callbacks directly (`node->getBaseline()(...)`), they are invoked via methods on `YGNode` (`node->baseline(...)`).
This change will allow us to add the concept of a *Layout Context,* where measure and baseline functions will be able to receive an additional `void *` argument if configured accordingly. This API will be used internally for Yoga’s JNI bindings, to avoid storing a weak JNI reference for each node, and avoid reference table overflows.
Changed API:
- `YGNodeGetMeasureFunc()` -> `YGNodeHasMeasureFunc()`
- `YGNodeGetBaselineFunc()` -> `YGNodeHasBaselineFunc()`
- `YGNode::getMeasure()` -> `YGNode::hasMeasureFunc()` + `YGNode::measure()`
- `YGNpde::getBaseline()` -> `YGNode::hasBaselineFunc()` + `YGNode::baseline()`
Reviewed By: SidharthGuglani
Differential Revision: D14099550
fbshipit-source-id: 2653ab36acc252a9747986bc88d21dac22d8c91b
Summary:
@public
Context-aware logging functions are an internal Yoga feature that will be used for Yoga’s JNI code.
It will be possible to specify a context when calculating layout, which will be passed on to baseline and measure functions. This will be a private feature.
Reviewed By: SidharthGuglani
Differential Revision: D14123482
fbshipit-source-id: 8ba3b6c493bf79fe09831f22d2b6da44f09e3d95
Summary:
@public
Stricter encapsulation of logging callbacks within `YGConfig`.
Instead of invoking the logging callback directly (`node->logger(...)`), callers now have to go through `YGConfig::log()`.
This change will allow us to add the concept of a *Layout Context,* where logging functions will be able to receive an additional `void *` argument if configured accordingly. This API will be used internally for Yoga’s JNI bindings, to avoid storing a weak JNI reference for each node, and avoid reference table overflows.
Changed API:
- `YGConfig::logger()` -> `YGConfig::log()`
Reviewed By: SidharthGuglani
Differential Revision: D14123483
fbshipit-source-id: 87b8bb7de0e4346b6a41e57a70ac4eb8d79b24af
Summary:
@public
Makes logging implementation internal to Yoga.
Breaking changes: removed `YGLog` and `YGLogWithConfig`.
The upcoming changes to the JNI layer (removal of weak global refs for each node) requires adding additional parameters to the logging functions that will only be available when calculating layout.
Reviewed By: SidharthGuglani
Differential Revision: D14123390
fbshipit-source-id: 468e4a240c190342868ffbb5f8beb92324cdfdd6
Summary:
Some modules may have args with types stricter than just `NSDictionary`. For now, allow these modules to manually define a __turbo__* variant of the same method that receives basic NSDictionary/NSArray typed args. That helper method can do the conversion to the stricter type as necessary. This is only needed during migration phase of TurboModule.
Without this workaround, existing methods may get unrecognized selector errors.
Reviewed By: PeteTheHeat
Differential Revision: D14115981
fbshipit-source-id: ca7fcf497490ef9cce14c3d3444991c50d3cb550
Summary:
This adds a new jsi API prepareJavaScript. This accepts the same
parameters as evaluateJavaScript() but does not evaluate anything; instead
it returns a new object PreparedJavaScript which can itself be evaluated,
via the new API evaluatePreparedJavaScript().
There is a new empty class PreparedJavaScript which may be subclassed by
each Runtime variant to store its particular prepared form.
Reviewed By: mhorowitz
Differential Revision: D10491585
fbshipit-source-id: 702b9e23f2ff03d71a8ab17efb7e154b16dd8e87
Summary:
This changes jsi::evaluateJavaScript() to accept a
const shared_ptr<Buffer> & instead of a unique_ptr<Buffer.
It is reasonable to want to pass the same buffer to evaluateJavaScript()
multiple times. This will also help unify the API with the upcoming
prepareJavaScript() API.
Because shared_ptr has a unique_ptr constructor, this is compatible with
all call sites.
Reviewed By: mhorowitz
Differential Revision: D14001664
fbshipit-source-id: b7a0b7ec578a3fd6a6272241d50067269d2b03e4
Summary:
This changes fix small perf problem in RCTImageManager (and layout!) saving (in my completly non-scientific tests) up to 2 ms.
Maybe that's not much, but it fires during layout (and ShadowNodeTree reconsiliation processes), so it has to be very performant.
Reviewed By: JoshuaGross
Differential Revision: D14072077
fbshipit-source-id: 0baa54584dc3ae6a5f43be13fd152b84801c8539
Summary:
`SharedFunction` implements a pattern of a shared callable object that contains the same executable inside. It's similar to `std::function` with one important difference: when the object is copied, the stored function (and captured values) are shared between instances (not copied).
`SharedFunction` can be stored inside `std::function` because it's callable.
It useful in some scenarios, such as:
* When captured by `std::function` arguments are not copyable;
* When we need to replace the content of the callable later on the go.
We will use it in the coming diffs.
Reviewed By: mdvacca
Differential Revision: D14072078
fbshipit-source-id: 9df4ad2d1b92394e2dfef5c283f35c7c0bd4b500
Summary:
Sometimes, when we deal with ImageRequest and ImageResponseObserverCoordinator we subscribe for status (or access the coordinator) without owning an ImageRequest. In those cases, we have to retain the coordinator explicitly.
For those cases, ImageRequest now exposes `ImageResponseObserverCoordinator` as a `std::shared_ptr`.
Eg, concretely in the code, `completionBlock` and `progressBlock` copied a raw pointer to the observer inside which can lead to a crash when ImageRequest is being deallocated before we received an image data.
Reviewed By: JoshuaGross
Differential Revision: D14072079
fbshipit-source-id: e10120bc05bf685e288f7b3d69092714dcd91d43
Summary:
This diff refactors JNI methods used by the Binding.cpp class in order to use ReadableMap instead of ReadableNativeMap
This will be helpful to provide a different implementation of ReadableMap from C++
Reviewed By: shergin
Differential Revision: D14077762
fbshipit-source-id: 595b0c2d3a2d6070112257b65c1141a8af36f0e1
Summary:
This pull request implements some suggestions made in #23414, namely:
* Rename `ShadowNodeFragment::nullSharedProps()` (and family) to `ShadowNodeFragment::propsPlaceholder()`;
* Introduce similar functions for the rest of members (tag and rootTag);
Later pull requests to remove designated initializers from Fabric (for MSVC support) will use these
I'd like to do the rename of `rootTag` to `surfaceId` as well, but would make sense to do in a separate diff as that would result in a great deal of changes.
[General] [Changed] - Changed naming scheme of `ShadowNodeFragment` placeholders, and added placeholders for remaining members
Pull Request resolved: https://github.com/facebook/react-native/pull/23437
Reviewed By: mdvacca
Differential Revision: D14072007
Pulled By: shergin
fbshipit-source-id: d5bb10a82c16d45955f417a49b503f215c4bc521
Summary:
This pull request removes a constructor in `DebugStringConvertibleItem.h` that was causing this issue in MSVC:
```
DebugStringConvertibleItem.cpp(20): error C2600: 'facebook::react::DebugStringConvertibleItem::DebugStringConvertibleItem': cannot define a compiler-generated special member function (must be declared in the class first)
```
It was likely conflicting with the constructor that has default values for all of its arguments.
[General] [Fixed] - Fixed `DebugStringConvertibleItem` compilation on MSVC
Pull Request resolved: https://github.com/facebook/react-native/pull/23436
Reviewed By: shergin
Differential Revision: D14067760
Pulled By: mdvacca
fbshipit-source-id: 303cf9b3559932c3d06514a1f3a8739d0f6f9dc2
