Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35768
Changelog: [Internal]
This implements native side mechanics for reporting user events timing to JS (PerformanceObserver API).
See the standard for more details: https://www.w3.org/TR/event-timing/
The events are only logged when there are any active subscriptions (via `PerformanceObserver.observe`), also we only log "discrete events" (i.e. no likes of mouse move), so the overhead is non-existing.
There are two main metrics of interest for an event lifecycle:
* Time the event is spent in the queue, i.e. the time between it's created and dispatched
* Time that is spend in the event handler on the JS side (event dispatch), or processing time
Both of these are measured, and the corresponding fields are populated.
Reviewed By: sammy-SC
Differential Revision: D42294947
fbshipit-source-id: 4fd7938c04b942400befa4057d4929fb2763cee1
Summary:
This PR slightly improves the implementation of `dispatchCommand` method of `UIManagerBinding` to use existing variable `shadowNode` instead of calling `shadowNodeFromValue` again.
## Changelog
[INTERNAL] [CHANGED] - Eliminated double call of `shadowNodeFromValue` in `dispatchCommand`
Pull Request resolved: https://github.com/facebook/react-native/pull/35695
Test Plan: Launch RNTester with Fabric enabled and check if `scrollTo` or some other command works properly.
Reviewed By: christophpurrer
Differential Revision: D42233216
Pulled By: robhogan
fbshipit-source-id: db152206060ff599962f47c43fda8ea797f2a8cb
Summary:
[Changelog][Internal]
Both iOS and Android platforms are at this point using the same native implementation of `performanceNow`, based on `std::chrono` (it used to be different some time ago).
This diff unifies the implementations, so it comes from one place in C++ code for all platforms.
The context is that I am developing event timing instrumentation and need a consistent way to get current timestamp from either JS or native (C++) side. The latter is now possible via calling `JSExecutor::performanceNow()`, which is guaranteed to be the same as called from JS.
Reviewed By: christophpurrer
Differential Revision: D42267898
fbshipit-source-id: dcb592f37d6567340ea59faddbf3b6d2b8507d50
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35731
[Changelog][Internal]
The initial intent was to try and use `unique_ptr` instead of `shared_ptr`, however turns out it complicates code more than it's worth it, so I ended up just factoring the repeated complex parts of the corresponding code to make it easier to reason about.
Reviewed By: christophpurrer
Differential Revision: D42265274
fbshipit-source-id: 105f57b449934c2e3227e592a76036ca7f61bc35
Summary:
changelog: [internal]
This is experimental implementation of `setNativeProps` in Fabric.
This diff brings `setNativeProps` to Fabric to make migration easier. I tried to stay as close as possible to Paper's behaviour, with all of its flaws (ready CAUTION section on https://reactnative.dev/docs/direct-manipulation)
State can't be stored in views because on iOS, eventually on Android, views are not the source of truth, shadow tree is. Fabric's implementation keeps state from setNativeProps in shadow node family in very inefficient data structure folly::dynamic. It is always reconciled with new prop updates. The performance cost is only paid in case node has used `setNativeProps` before.
Reviewed By: mdvacca
Differential Revision: D41875413
fbshipit-source-id: 453a5f7612a6f86a4cece269b13bd2ffd0c0e2d1
Summary:
This PR implements `inset` logical properties as requested on https://github.com/facebook/react-native/issues/34425. This implementation includes the addition of the following style properties
- `inset`, equivalent to `top`, `bottom`, `right` and `left`.
- `insetBlock`, equivalent to `top` and `bottom`.
- `insetBlockEnd`, equivalent to `bottom`.
- `insetBlockStart`, equivalent to `top`.
- `insetInline`, equivalent to `right` and `left`.
- `insetInlineEnd`, equivalent to `right` or `left`.
- `insetInlineStart`, equivalent to `right` or `left`.
## Changelog
[GENERAL] [ADDED] - Add Fabric implementation of inset logical properties
Pull Request resolved: https://github.com/facebook/react-native/pull/35692
Test Plan:
1. Open the RNTester app and navigate to the `View` page
2. Test the new style properties through the `Insets` section
<table>
<tr>
<td>Android</td>
<td>iOS</td>
</tr>
<tr>
<td><img src="https://user-images.githubusercontent.com/11707729/208821212-fbbac6ed-09a4-43f4-ba98-dfd2cbabf044.png" alt="1" width="360px" />
</td>
<td>
<img src="https://user-images.githubusercontent.com/11707729/208816997-ef044140-8824-4b1b-a77b-085f18ea9e0e.png" alt="2" width="360px" />
</td>
</tr>
</table>
Reviewed By: NickGerleman
Differential Revision: D42193661
Pulled By: ryancat
fbshipit-source-id: 3db8bcd2c4db0ef4886b9ec49a46424d57362620
Summary:
Many operations on references in JS can modify the referent by
executing additional JS, including operations that we currently mark as
const such as `getProperty`. Because of this, the current distinction
between const and non-const operations on references like `jsi::Object`
is somewhat arbitrary.
A more consistent approach is to mark all operations as const, so that
it is clear that the const-ness applies to the reference and not the
referent. This is analogous to how smart pointers work, since something
like `const shared_ptr<T>` only makes the pointer const, as opposed to
`shared_ptr<const T>`.
This also gives users better guarantees and more flexibility in where
these references may be used.
Changelog:
[General][Changed] - Mark methods on JSI references as const.
Reviewed By: fbmal7
Differential Revision: D41599116
fbshipit-source-id: 40b1537581b09c5a34d0928ee04e7db2b50d26ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35646. Even though the RN code itself does not need `HERMES_ENABLE_DEBUGGER` anymore since the `ifdef`s are gone, the Hermes' headers it includes *do* still need that flag. This is because they were compiled with `HERMES_ENABLE_DEBUGGER` to set true, so that compile flag must match later on when importing the headers.
Changelog:
[Internal][Fixed] - We erroneously deleted usage of the HERMES_ENABLE_DEBUGGER flag, add it back.
Reviewed By: cortinico, mattbfb
Differential Revision: D42041827
fbshipit-source-id: db875f40a067c09aba37ab1b07422157f63b3700
Summary:
Add `uint32_t` as a valid type for communication between C++ and JS via bridging.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42008412
fbshipit-source-id: 2c038e37745782b677d28bcbe4cc030683b74286
Summary:
This is a two step (1/2) fix to a race that could caused a `DELETE`...`CREATE` mutations being sent over to the fabric mounting layer. Such combination was assumed not possible from the differ, yet it happened at least in the existence of layout animation and when certain commits happen while animation is active.
This race condition could cause a view to get deleted at the end of one UI frame, yet the mount instructions generated from animation in the next frame still need to access the deleted view and caused crashes like T112157805. Note that even though such crash is recorded as `RetryableMountingLayerException` and is a soft crash (which only gets logged but not crash in production), the out-of-order mount instructions could lead to illegal view state and make the surface unusable, like what's shown here:
{F820669000}
The diff fixes this issue by removing the `DELETE` [conflict animation](https://fburl.com/code/5ctckvz3) keyframe, as well as the `CREATE` [immediate mutations](https://fburl.com/code/txyomytd) from the layout animation. The Fabric mounting layer assumes no combination of `DELETE...CREATE` in the same frame from differ + [layout animation overrides](https://fburl.com/code/zn17uqch).
Reviewed By: sammy-SC
Differential Revision: D41895427
fbshipit-source-id: d6df02663ba707af6db4a63a325ac776ca54d18e
Summary:
Changelog:
[Android][Changed] - Include the inspector in all build modes, and only turn it off/on at runtime.
Reviewed By: jpporto
Differential Revision: D40248901
fbshipit-source-id: f13c58f631e4617a6f157df8899e128959af450a
Summary:
changelog: Introduce setNativeProps to Fabric
Add support for `setNativeProps` in Fabric for backwards compatibility. It is still recommended to move away from `setNativeProps` because the API will not work with future features.
We can make step [Migrating off setNativeProps](https://reactnative.dev/docs/new-architecture-library-intro#migrating-off-setnativeprops) in migration guide optional.
Reviewed By: yungsters, mdvacca
Differential Revision: D41521523
fbshipit-source-id: 4d9bbd6304b8c5ee24a36b33039ed33ae1fc21f8
Summary:
changelog: [internal]
Add findShadowNodeByTag_DEPRECATED` to Fabric's UIManager.
This API makes it possible to get ShadowNode reference for given native tag.
We will leverage this API to make UIManager.measure* calls backwards compatible in the new architecture.
Reviewed By: yungsters
Differential Revision: D41550734
fbshipit-source-id: a45b6a76634d034eac70603bad8ac60f9135ff24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35525
[Changelog][Internal]
Adds ability to invoke an async JS callback from a C++ native module, as a task with priority.
This will allow native modules to schedule less important calls to JS thread with lower priority. One example use case is feeding collected perf metrics back to JS.
Reviewed By: javache
Differential Revision: D41492849
fbshipit-source-id: 12f738557972dc23398d9bb9a7a01125c79da070
Summary:
Yoga tries to use `std::bit_cast<>()` where it's available and falls back to
`std::memcpy()` everywhere else. Unfortunately, the feature-test macro
(`__cpp_lib_bit_cast`) is only defined if the feature is available *and you have
already included either `<version>` or `<bit>`* (or something else that includes
one of those). Since `CompactValue.h` checks `__cpp_lib_bit_cast` *first*, it's
not defined even if it *would be* defined, leading the header not to
`#include <bit>`, leaving `std::bit_cast<>()` undefined; later, other headers
from the STL are included, leading to `__cpp_lib_bit_cast` *becoming* defined
and causing later code to choose to use the undefind `std::bit_cast<>()`.
This diff fixes the problem by `#include`ing either `<version>` or `<ciso646>`
(depending on availability) before checking any feature-test macros.
Changelog: [Internal]
Reviewed By: smeenai
Differential Revision: D41641205
fbshipit-source-id: 7d7bc5791c902a45302d3707e6cbf21fc0493f0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35506
In our build we had a mixture of `_` and `-` to separate targets.
Dashes don't play well with Gradle + as we expose them now via Prefab,
let's stick to use only underscores
Changelog:
[Internal] [Changed] - Rename target to don't use dashes
Reviewed By: cipolleschi
Differential Revision: D41578938
fbshipit-source-id: 8aa44aa2dc7bf4822b45e5044532837b989817d2
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
This brings back JSIDynamic and JSI together because the current setup is not compatible with iOS frameworks
## Changelog
[iOS][Added] - Bring back JSIDynamic and JSI
Reviewed By: cortinico
Differential Revision: D41557823
fbshipit-source-id: 95eb2fe7df69992861396e41d11cd5182193e1a3
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
The `use_frameworks! :linkage => :static` use to work fine with the Old Architecture.
We modified how the `React-bridging` pod is configured and, now those are broken.
This change make sure to use the right imports for React-bridging.
## Changelog
[iOS][Changed] - Fix imports in React Bridging for Old Arch and frameworks
Reviewed By: christophpurrer, cortinico
Differential Revision: D41551103
fbshipit-source-id: 4416fde92fef11eb801daf2302a57fe52732e4ef
Summary:
This change excludes the `LongLivedObject.h` file from the pod in the ReactCommon library.
The file creates a problem when the `use_frameworks!` option is used in an app because there can't be two files with the same name, despite being in different paths,
within the same framework. Specifically, this `LongLivedObject` is just a redirect to the other one, so it should be safe to exclude this.
## Changelog
[iOS][Fixed] - Exclude redirector to `LongLivedObject.h` from ReactCommon podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/35491
Test Plan: 1. Manually tested in an app from RC2
Reviewed By: cortinico
Differential Revision: D41548985
Pulled By: cipolleschi
fbshipit-source-id: acc57fccdedb344a3aa105f2968645a049392e07
Summary:
This is the last library that we should expose via Prefab.
Thanks to cipolleschi 's work here moving the file to `/ReactCommon/jsc` folder
we can easily expose it to be consumed by third parties.
Changelog:
[Internal] [Changed] - Expose `jscruntime` to be consumed via Prefab
Reviewed By: cipolleschi
Differential Revision: D41534564
fbshipit-source-id: fb4b2d801def8caf71638dcb74eb87f8230984d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35482
This change moves the JSCRuntime.h/cpp into a `jsc` folder.
This change is required for several reasons:
1. on iOS, the new `jsi`, `jsidynamic` and `jsc` setup is breaking the `use_frameworks!` with `:linkage => :static` option with the old architecture. So it is a regression.
2. JSCRuntime is required by some libraries and needs to be exposed as a prefab and the current setup makes it hard to achieve.
allow-large-files
## Changelog:
[General][Changed] - Move JSCRuntime into a separate pod/prefab
Reviewed By: cortinico
Differential Revision: D41533778
fbshipit-source-id: 642240c93a6c124280430d4f196049cb67cb130b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35436
Using std::optional as react-native has been using C++17 for quite some time
changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D41415031
fbshipit-source-id: d786647f64b4f90cf75409109830ae0885460c17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35457
This exposes `hermes-executor` to be consumed via prefab so that
libraries can depend on it and use its symbols if needed (Expo and Reanimated need it).
Changelog:
[Internal] [Changed] - Expose `hermes-executor` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D41520019
fbshipit-source-id: d590a043ea89fdd8ff41b0ed20900c9cf381a1e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35435
This raises the C++ language standard to C++17 which is needed to remove some folly:: dependencies
changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D41482821
fbshipit-source-id: 62af6e95e6e78378112a4ce4e9c3ab7df0587218
Summary:
X-link: https://github.com/facebook/yoga/pull/1176
`Values` is a wrapper to story an array of YGValue's as CompactValues.
From https://github.com/facebook/yoga/issues/1174 we see a warning `Wdeprecated-copy` beacuse a user-defined copy constructor is not present, but a user-defined asignment operator is (the defaulted one). This adds an explicitly defaulted copy contructor which should silence the warning I think.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D41447490
fbshipit-source-id: 8cc8f291cf12014d87cc71c4598bb84fdd6cd930
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35385
In OpenSource builds folly:: types are not always easy to consume.
With butter:: we actually allow consumers to opt-into other/non folly:: types (by providing a custom butter:: implementation).
This change adds a butter::function for that purpose.
It is especially useful for react-native-windows which prefers Mso::Functor over folly::Function.
You can use it by setting those compiler flags:
-DBUTTER_FUNCTION_OVERRIDE_INCLUDE=<functional/functor.h>
-DBUTTER_FUNCTION_OVERRIDE=Mso::Functor
std::function is no option as it is not move-only and we can't wait till 2025 > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0288r9.html
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D41388193
fbshipit-source-id: 56f58b9ddc602aa4b13000031d50de5228b4a16b
Summary:
Fix linter warning when pulling in some code into AR
Changelog: [Internal]
Reviewed By: NickGerleman, mdvacca
Differential Revision: D41269423
fbshipit-source-id: 4305d6c362a51e62b19b4d3590fb0823073dff9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35353
Unfortunately we have 2 different definitions of SystraceSection.h
- xplat/js/react-native-github/ReactCommon/cxxreact/SystraceSection.h
- xplat/js/react-native-github/ReactCommon/react/renderer/debug/SystraceSection.h
The first one is the Old Arch one and the second one is the New Arch one.
As we first step, we unify the implementation
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D41307049
fbshipit-source-id: a9eb854dfcf49f87ad81fd9cc8dbe51648ecd209
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35342
This is a native implementation of the JS shimmed layout-specific properties in https://github.com/facebook/react-native/pull/35316.
There is an experiment splitting the prop splitting codepath in Fabric, so this change effectively has two implementations depending on whether `enablePropIteratorSetter` is enabled.
None of these changes make sense to propagate Yoga. `inlineEnd`, etc are already mapped to `YGEdgeStart` and `YGEdgeEnd`, but RN's mapping used a different name. Then `blockStart`, `blockEnd`, map directly to existing edges in all cases since we don't support a writing mode.
On web, the last value in the style which computes the given dimension is given precedence. E.g. if "left" comes after "start" it will be chosen. Yoga stylesheets are unordered, and precedence for edges is given based on specificity (left > start > horizontal > all).
We give precedence to new renamings (e.g. start to inlineStart), but to preserve consistent behavior, we give precedence to specific edges before overwriting them with flow relative ones (e.g. marginTop has precedence over marginBlockStar).
Changelog:
[General][Added] - Add Fabric implementation of flow-relative padding and margin
Reviewed By: javache
Differential Revision: D41267765
fbshipit-source-id: 896e2ed71fe8bf83aef00b0a9d70fd20b2ce47a7
Summary:
X-link: https://github.com/facebook/yoga/pull/1173
In https://github.com/facebook/react-native/issues/35351 we see incorrect child item height when the flex-wrap is enabled, the cross-axis is to be stretched, and main-axis overflow is caused by gap.
In YGDistributeFreeSpaceSecondPass, if we do not have overflow (determined by flexBasisOverflows), we have stretch cross-alignment, and we reason that nothing can add to main axis dimensions, we know we're a single line and want to take full cross dimensions. and can set YGMeasureModeExactly which uses parent dimensions. Guessing an optimization?
If we do have overflow, then we set YGMeasureModeAtMost to find minimum possible cross-axis dimensions instead.
`flexBasisOverflows` incorporates both computed flex basis, and margin, so it is more generally a flag for whether we will wrap. So we should incorporate gap spacing into it. E.g. it is also used for whether we should the match main axis parent dimension of the overall container. This change does just that, and renames the flag to `mainAxisOverflows`.
We will want to cherry-pick the fix for this into RN 0.71 since we have not yet introduced the community to the incorrect behavior, and we expect a lot of usage of flex-gap.
Changelog:
[General][Fixed] - Fix incorrect height when gap causes main axis to overflow and cross-axis is stretched
Reviewed By: yungsters
Differential Revision: D41311424
fbshipit-source-id: bd0c3b5aac478a56878703b6da84fc3993cc14da
Summary:
a lot of files were depending on Geometry even though they didn't use Vector, this will help with future modularity
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D41127194
fbshipit-source-id: 024519c638a1f0df3fdbfbdd937eac84b9adee6e