Summary:
Fixed some typos in the comment.
## Changelog
[Internal] [Fixed] - Fixed typo in the comments
Pull Request resolved: https://github.com/facebook/react-native/pull/28269
Test Plan: Changes are only made in the comments, so test is not necessary.
Reviewed By: cpojer
Differential Revision: D20342637
Pulled By: shergin
fbshipit-source-id: f6e7dd538ee54c43e1570c35e1f8c4502054e328
Summary:
Adds `TextKind` trait to Paragraph and TextInput shadow nodes.
Later on it could cause confusion why they do not have this trait.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D20254008
fbshipit-source-id: 56fb264fa4fe38a5f00f080558cdc7992fd51fea
Summary:
Investigating a crash, I spend half of an hour staring at `__bridge`, `__bridge_retained`, `CFRelease` and etc trying to understand is there a bug or not. Even if I think there was no bug there, it should not be this way. We have a nice abstraction around that madness we should use to make the code obvious.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20260917
fbshipit-source-id: 2b511ebf46a78950c4720e749099134aed1dd890
Summary:
Updating react-native-windows to build with Visual Studio 2019 and the v142 toolset.
## Changelog
[Internal] [Fixed] - Fix MSVC build break in VS 2019
Pull Request resolved: https://github.com/facebook/react-native/pull/28253
Test Plan: No real change, only adding a missing include for `stdexcept`.
Reviewed By: cpojer
Differential Revision: D20321273
Pulled By: shergin
fbshipit-source-id: ffe8b4d3a96ce4ed1db303020d77a806637e88bc
Summary:
Instead of comparing the entire AttributedString, compare just the strings and the TextAttributes of Fragments.
Concretely what I'm seeing is that the Frame of the associated parent ShadowViews are changing very frequently, making it impossible to actually modify the TextInput in some cases. However, we shouldn't forcibly reset the content of the TextInput if the frame of the parent is changing and not the actual child contents.
Changelog: [Internal] Fabric TextInput bug fix
Reviewed By: shergin
Differential Revision: D20319359
fbshipit-source-id: 2f51f521ad76fff9da6f6c8b5e795f03c33e496f
Summary:
As documented in T61647031, Text colors were sometimes not being updated because the ParagraphState was not always updating with a new AttributedString.
Turns out, it's because the equality comparator for Color had not been implemented, and so State was not being set in some cases.
The confusing part is that now color comparisons return true **more often** than before (if you're comparing two smart pointers of opaque data without a custom comparator, in theory I assume they're comparing pointer values and returning false way more often... but maybe my understanding is off). This distracted us for a while in finding an other ~fairly simple solution.
We should keep this in mind if we experience other, similar issues with text attributes not updating.
Changelog: [Internal] Fabric
Reviewed By: mdvacca
Differential Revision: D20300307
fbshipit-source-id: 13d86495f4c4ef8a0219fec66d39a49b4f7e6c2a
Summary:
Someone pointed out in this Github issue: https://github.com/facebook/react-native/issues/27532
that the memory pressure warning from Android was being ignored, when it can easily
be used to start a garbage collection on the JS runtime.
Changelog: [Internal] Add a memory pressure handler for jsi::Runtime
Reviewed By: mhorowitz
Differential Revision: D20072943
fbshipit-source-id: 869a14068aa02bd378e8b26d8c18b76a5d0f7bc0
Summary:
It's not clear why exactly but seems in some cases, for some views the hierarchical relationship between views is required (when it should not be conceptually). Turning this feature off for Android for now.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20292833
fbshipit-source-id: 1aab8468cedeb5c1440a95944be7eca3216e0db0
Summary:
Of course if props aren't changing, rawProps won't have paddings anymore and so padding gets reset.
Also, make sure we pay attention to paddingVertical and paddingHorizontal styles.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20269583
fbshipit-source-id: 2903fd0f7e6178f506109467d9a8f67b6d013a25
Summary:
This adds support for 'returnByValue' in Runtime.evaluate invocations.
If the result of the evaluation can't be serialized to JSON, the results
are undefined.
ChangeLog: [Internal] - Hermes Inspector now supports 'returnByValue' in CDP Runtime.evaluate calls
[Facebook]
This is change was made to support debug completion in VSCode for ReactVR.
Reviewed By: ArchDev
Differential Revision: D19961115
fbshipit-source-id: d20af82b35d6bde88ab74b5c5a4c07415122c142
Summary: Now, following the previous diff, we remove `LayoutableShadowNode::isLayoutOnly()` and change the view flattening algorithm to rely on two new traits. See the previous diff to learn more about how it works.
Reviewed By: sammy-SC
Differential Revision: D20212252
fbshipit-source-id: 87a07e8bb17b2e66e5703f107dc35ca7a8e49634
Summary:
This diff introduces two new `ShadowNodeTrait`s that we will use in the future in the new (slightly tweaked) view-flattening algorithm. (Note: this diff does not enable the new flattening, it's just preparation.)
The idea is that we split the notion of `isLayoutOnlyView` into two traits:
* `FormsView`: `ShadowNode`s with this trait must be represented as `ShadowView`s. Normal "visible" ShadowNodes will have this trait, but "layout only views" in old nomenclature will not.
* `FormsStackingContext`: `ShadowNode`s with this thread not only must be represented as `ShadowView`s but also have to form a "stacking context" which means that their children must be mounted as `ShadowView`'s children.
Our implementation does not exactly follow W3C spec in terms of sets of props that create the stacking context (because of historical reasons and mobile specifics) but ideologically it's the same. We start from the very conservative implementation where only views with background-color and borders do not form stacking context and then we probably extend that to more props.
Most importantly for us now, we will enforce the absence of ``FormsStackingContext` for `ParagraphShadowNode` and the presence of `FormsView` for `TextShadowNode` on Android where it's essential for mounting layer.
Read more about stacking context here: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20212253
fbshipit-source-id: 0fbaee214ce2c5886cb0232843a2a3c7bb20655d
Summary:
Passing `layoutContext` to yoga crashes fb4a-64. Until I have a solution let's back this out.
Original commit changeset: 9df7da4bef8c
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D20246917
fbshipit-source-id: 220744fde9f74e8157fc0714c63639b01152e4ab
Summary:
Now we tweak more props in order to prepare for new flattening algorithm.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20212254
fbshipit-source-id: 7391155072f93046e78fbecf4bb4b42cb1caacdc
Summary:
This is a part of migration staterted in D19390813.
There is no need to have those as const. The whole *Props object is usually const (and when it's not, props should not be too).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20212255
fbshipit-source-id: 87f3d8e7a94c6626bd9b0fc304f75e915dd73d4c
Summary:
Changelog: [Internal]
Use LayoutContext to pass `fontSizeMultiplier` down to ParagrapShadowNode.
Reviewed By: shergin
Differential Revision: D20184596
fbshipit-source-id: 3965a127069a21328ed19cb3f9732f0a2d1c4d58
Summary:
In order to build dynamic text sizing, `LayoutableShadowNode::measure` needs to accept `LayoutContext`
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D20184598
fbshipit-source-id: 8928b59d51948caf3654f40049212a89a91dceb6
Summary:
In order to build dynamic text sizing, we need to pass layoutContext to `yogaNodeMeasureCallbackConnector`
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D20184597
fbshipit-source-id: 9df7da4bef8cbad3bc87d63ed0c5aa5f420dbc11
Summary:
What's changed:
* `end()` now returns the pointer to the imaginary element after the very last one (which is aligned with STL);
* `erase()` now swaps the removing and the last elements and shrinks the size of an array.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19965405
fbshipit-source-id: 92eedf38d55be35a0d9ab6120634b51c8d6e4674
Summary:
Clearing `props` and `state` (which we don't use) allows avoiding retain cycles.
The memory leak was caused by a retain cycle:
AttributedString -> Fragment -> ShadowView -> PharagraphState -> TextLayoutManager -> Cache -> AttributedString.
We don't use `props` and `state` parts of `ShadowView` inside `AttributedString`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20182791
fbshipit-source-id: 2ddc5d53a1cb594e3d1cc39933e8958eb6425389
Summary:
This diff implements serialization and deserialization of text attachments as part of the calculation of layout of text components
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20087251
fbshipit-source-id: dbcbd22f856aadace14343205548154ea80c8464
Summary:
Changelog: [internal]
# Problem
We have node A with N children.
Calling cloning constructor on `YogaLayoutableShadowNode` causes new `yogaNode_` to be created.
However if `fragment.children` is nil in cloning constructor, which basically says children were not changed, then the existing children's `owner` becomes invalid.
# Solution
In the clone constructor, always call `updateYogaChildren`. This updates yoga children with the new `owner`.
Reviewed By: JoshuaGross
Differential Revision: D20139582
fbshipit-source-id: 3932694d4381b601df07dd8a57887ce7c09f1582
Summary:
The sizes of attachments are legit parts of `AttributedString`s identity, so we need to incorporate it into the equality test.
We need that to make measurement cache work correctly with inline views.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20151505
fbshipit-source-id: ae47c24a753eab1e497fcfaa93de557ffb30d874
Summary:
Run clang-format and add .clang-tidy with `clang-diagnostic-*` to several more directories in order to catch any problems.
Changelog:
[Internal]
Reviewed By: shergin
Differential Revision: D19860169
fbshipit-source-id: 7785aab010c8e6945cc6b5c9b68cb8ee0cdbb7fa
Summary:
The PlatformConstants native module exposes the ability to query the React
Native version used to build native code. This is managed on iOS and Android by
a version bumping script, which replaces module code based on a template.
It is currently difficult to accurately determine this version for out-of-tree C++
platforms (I.e. React Native Windows). The version of upstream react-native we resolve to is ultimately
dependent on the version of react-native chosen a peer dependency, which is not
neccesarily constant given a build of react-native-windows.
We could try to hack around this, and make our native build try to reason about
the resolved pacakge for react-native using a lockfile, but a much cleaner
solution is to embed version into C++ code, similar to what is done for Android
and iOS. This change does that, adding a header with React Native version and
updating the build stamping script to write to it.
Usage sample:
```c++
constants["reactNativeVersion"] = folly::dynamic::object();
constants["reactNativeVersion"]["major"] = ReactNativeVersion.Major;
constants["reactNativeVersion"]["minor"] = ReactNativeVersion.Minor;
constants["reactNativeVersion"]["patch"] = ReactNativeVersion.Patch;
```
## Changelog
[General] [Added] - Stamp React Native Version Into C++ Code
Pull Request resolved: https://github.com/facebook/react-native/pull/28036
Test Plan: Validated that the bumping script will accurately update the header, can compile under both MSVC and Clang.
Differential Revision: D19865992
Pulled By: hramos
fbshipit-source-id: 9e0b8e9519015bb62c60b9935a234cd367a1926a
Summary:
Cloning subtrees is not something specific to a RootNode, so it makes sense to have it in ShadowNode. Soon we will use that to clone subtrees inside Paragraph component to implement Inline Views.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20090666
fbshipit-source-id: 0a64ef9bda438cd55d5fd21d3ad83b36221fa89e
Summary:
All logic that is performed on the root node only was moved from `layout` to a separate methods `layoutTree`. That makes the code simpler and allows reusing `layoutTree` in InlineViews feature.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20052025
fbshipit-source-id: 3070a1cca4e322c6d077ede751ea80359c96a600
Summary:
Similar to a previous diff but for `setChildren`.
`YogaLayoutableShadowNode::setChildren()` was renamed to `YogaLayoutableShadowNode::updateYogaChildren()`. Now we don't need to pass an argument to this function because the object is already initialized. The new name also disambiguates this method with `getChildren()` from `ShadowNode` (which does something completely different). The rest of the changes is just type adjustments.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20052031
fbshipit-source-id: 6157cad9b55d4cdd97ce04e1278ac1369bfb96bc
Summary:
`YogaLayoutableShadowNode::setProps()` was renamed to `YogaLayoutableShadowNode::updateYogaProps()`. Now we don't need to pass an argument to this function because the object is already initialized. The new name also disambiguates this method with `getProp()` from `ShadowNode` (which does something completely different).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052018
fbshipit-source-id: 4d9651bb4452408708fa1b36bb5c5c8639f7d1bb
Summary:
How we can finally make `ViewProps` inherit `YogaStylableProps` and remove `dynamic_cast`. This overall change is aligned with D19963353.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052026
fbshipit-source-id: 1066f9a259b50d4672111c9c03a71c2590d59aca
Summary:
Here we delete several constructors that were needed only because `YogaLayoutableShadowNode::yogaStyle` was private (which is not true anymore).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC, mdvacca
Differential Revision: D20052033
fbshipit-source-id: c2afcaf2fdebb65cdcde6c214c8b78aa35d45e91
Summary:
Here we refine the `ShadowNode::BaseTraits` static method. Before this change, ConcreteViewShadowNode<> enforces Layoutable and YogaLayoutable traits. This change moves that responsibility to LayoutableShadowNode and YogaLayoutableShadowNode which makes overall logic more coherent.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052027
fbshipit-source-id: fd25264204b0232b1dbbff6f9dfefd9fbcb146c4
Summary:
Now we can move custom to `YogaLayoutableShadowNode` code from `ConcreteViewShadowNode<>` template to `YogaLayoutableShadowNode` itself reducing the amount of templated code and reduce overall complexity.
Note, here we have to do `dynamic_cast` for now, we will address that in coming diffs.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20052021
fbshipit-source-id: dac5969a97b75e54c7728a1ca8161922bd2245ca
Summary:
The fact that `LayoutableShadowNode` now inherits `ShadowNode` allows us to de-virtualize `getLayoutableChildNodes` and move that to `LayoutableShadowNode`. Less code, less virtual dispatch, less complexity.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052032
fbshipit-source-id: 580e86b5a746028e470788e00027f247bf77126c
Summary:
D19963353 mentioned the infrastructure that re-routes methods calls related to adding and cloning children between YogaLayoutableShadowNode and ShadowNode. `cloneAndReplaceChild` is exactly this. It was implemented as a virtual method that is called from `ConcreteViewShadowNode`. The whole process requires building a list of children of some class and passing that as a list of pointers. Now we don't need it all that because we can call directly and statically. That change will allow us to simplify that infra even more in the future diffs.
With all previous changes, now we can implement `getYogaLayoutableChildren` inside `YogaLayoutableShadowNode` and call that statically. Eventually, that will allow us to remove templated `getChildrenSlice`. Previously the call for that method must be in `ConcreteViewShadowNode`, now it's not true anymore which we will use later to even better goodness.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20052020
fbshipit-source-id: e5c819a4d21b2dbcd08f3439e1783e3a9cba5ef4