Summary: Remove some outdated information and make sure that npmjs shows the builtin TypeScript typings (now that we no longer have clever resolution schemes).
Reviewed By: javache
Differential Revision: D54788636
fbshipit-source-id: 76e7663924189fd68ac62b27730f44213b13ad85
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1593
X-link: https://github.com/facebook/react-native/pull/43417
There was a bug where we did not position absolute nodes correctly if the static node had a different main/cross axis from the containing node. This fixes that. The change is somewhat complicated unfortunately but I tried to add sufficient comments to explain what is happening
Reviewed By: NickGerleman
Differential Revision: D54703955
fbshipit-source-id: 096c643f61d4f9bb3ee6278d675ebd69b57350d7
Summary:
X-link: https://github.com/facebook/react-native/pull/43405
Pull Request resolved: https://github.com/facebook/yoga/pull/1592
Fixes https://github.com/facebook/yoga/issues/1590
Yoga may be built with a high warning level. This is helpful in letting Yoga be used in more places, and finding defects. We currently set these in the internal BUCK build, the CMake reference build, and the Yoga Standalone (not RN) CocoaPods build.
Yoga's reference CMake build and spec are consumed today by users of Yoga, instead of just Yoga developers. Here, it makes more sense to avoid anything that could break compiler-to-compiler compatibility.
We default these to a less intense (`-Wall -Werror`). I kept `/W4`, for pragmatic reasons, and since it is relatively standard for MSVC.
We continue to build with strict flags on Buck build on Clang.
Reviewed By: cortinico
Differential Revision: D54735661
fbshipit-source-id: 130e35ac9dcffa2f7e70e48d18770f1275864e2a
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1585
When used alone, yoga has no visibility over the USE_FRAMEWORKS variable set by React Native.
In this case, there is no other way to know whether the current target that will install the spec is using use_framewors or not. As a failsafe, condition, let's always add the `"$(PODS_TARGET_SRCROOT)"` to the search paths to make sure that archiving won't fail.
Whe used in other context, that should not be a problem: search paths are just directory Xcode uses to find headers that are needed.
Reviewed By: NickGerleman
Differential Revision: D54417386
fbshipit-source-id: aa2ae41c077e4346c0417c73291a37c992a06b58
Summary:
To sanity check that a capture is working as expected when running benchmark
We could maybe even throw here as a bad measure function will throw off the rest of the benchmark.
Reviewed By: NickGerleman
Differential Revision: D53681506
fbshipit-source-id: f5ab7e00e76df0ac899d62c3f6b4535b3780d45d
Summary: A much smaller tree than the previous one. It only has 100 or so nodes
Reviewed By: NickGerleman
Differential Revision: D53632451
fbshipit-source-id: 1268499fa768f3b6673ff8bcedac23cf6d9395ac
Summary: You need to provide the benchmark binary with a path to the captures. This is annoying and there is not a great way to do this in c++ that is cross-plat. So I just made this bash script to ease it. It can do buck and cmake.
Reviewed By: NickGerleman
Differential Revision: D53632438
fbshipit-source-id: 98b0ad52f91f2581e09f787da24f2ec2fff58bf4
Summary:
In addition to all the state that gets set on the node that is easy to serialize - like floats, enums, bools, etc - we also need to serialize measure functions. This is because these functions take a nontrivial amount of time up during layout and we should capture that. Also, they are important to the ability to truly replay layout as it was captured as the results of the measure functions determine many of the steps the layout algorithm takes.
Capturing this is rather tricky however, but I think I found a solution that is relatively simple and non-error prone. Essentially, since we are capturing the entire tree and virtually every input that goes into the flexbox algorithm, we *should* be able to replay layout exactly as it was captured. This means that the order in which measure functions are called *should* be the same. If this is the case, then all we need to do to capture the measure functions is store their input, output, and duration in a big array. During deserialization we just keep track of an index and use that to determine which measure function we should call. That is the premise behind what happens in this diff. In theory the algorithm could change and the capture would be wrong but it is easy enough to recapture again. Additionally we need to dirty the tree so that we get rid of caching which might omit some measure func calls
In order to capture you need to insert a method exposed by CaptureTree.h into the client measure func, which is kind of annoying but not that bad. In future diffs I will put a macro in place to make this even easier.
I also add our first capture! Which is of a large react native desktop app
Reviewed By: NickGerleman
Differential Revision: D53581121
fbshipit-source-id: 876a230208d67f0ecf76844a4f1b80048353aae2
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1575
If we want to replay layouts for benchmark, we should also capture the inputs. This diff does that as well as changing the API in CaptureTree.h. We now expose YGCalculateLayoutWithCapture designed to be a drop-in replacement for YGCalculateLayout. This allows us to have a bit more control on the order of everything and lets us capture measure functions in the next diff much easier.
Reviewed By: NickGerleman
Differential Revision: D53444261
fbshipit-source-id: 616e39153c21e7b472911502b6a717e92c88a4d1
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1573
Noticed a recent stack of commits cause the MVSC builds of benchmark to fail. This was due to forgetting to call `.string()` of a path and trying to escape a character that cannot be escaped.
Reviewed By: philIip
Differential Revision: D53461723
fbshipit-source-id: b6cc034d53b3a61929012965e257a3984c3bff47
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1569
Added a `benchmark` function that takes a path representing a directory to read captures from. This is supplied by the caller due to annoyance with filesystem access in C++. This calls into timing code with <chrono> and prints it out to the console.
Reviewed By: NickGerleman
Differential Revision: D53104632
fbshipit-source-id: fe8bcb0a87198701865fb04193894591d2eff821
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1566
In the previous diffs we serialized the in-memory representation of a node into json. This diff exposes a `generateBenchmark` method that reads from that json executes the proper public Yoga API functions to recreate the same tree. It then calls calculate layout so that we can time that in the next diff.
This diff is really only focusing on the core aspects of a yoga tree like style, children, and calculating layout; there are still more things to add coming up:
* Support for configs, experiments, and errata
* Support for measure functions
* Support for general node state that is not style (like always forming a containing block)
* Actually running all of these benchmarks together
* Tests
Reviewed By: NickGerleman
Differential Revision: D52987588
fbshipit-source-id: 7f7c9ca9956f693be62bc5e3cebdf1aed6f58aec
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1565
This adds a `captureTree` method intended to be injected in somewhere where you would like a JSON representation of a yoga tree. Right now it is very simple and just calls on `nodeToString` to serialize a node into JSON, and then saves that into a file in the given path. Some buck file changes needed to be done as well to use this in other files.
Reviewed By: NickGerleman
Differential Revision: D52972995
fbshipit-source-id: f4e09a815edef92ab959cfc76bacccbce225d940
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1563
X-link: https://github.com/facebook/react-native/pull/42645
We want to be able to capture Yoga trees in production. To do this we need to serialize and deserialize the in-memory representation of a tree. We have a way to turn a tree into html using NodeToString.cpp but that outputs html, which is going to be hard to deserialize. So, I added the [nlohmann json library](https://github.com/nlohmann/json/tree/develop?tab=readme-ov-file) so that we can serialize into JSON instead. Then we need to change the inner workings of NodeToString.cpp to use this library instead of its html.
One of the bigger structural changes I made was standardizing the checks need to append something to the string. What we want is to only add something if it is not the default style. The existing logic does that but bears the burden of knowing what the default of certain styles actually is. This just calls the getter on a new node to obtain that value, which should simplify things a bit.
Reviewed By: NickGerleman
Differential Revision: D52929268
fbshipit-source-id: 06eff1e10061bcb55fcdeb6f3ebe7e95155b4c86
Summary:
X-link: https://github.com/facebook/react-native/pull/42688
Pull Request resolved: https://github.com/facebook/yoga/pull/1567
We are planning on overhauling NodeToString to output JSON instead of HTML for the purposes of better benchmarking and capturing trees in JSON format to benchmark later. This gives us a bit of a headache as we have to revise several build files to ensure this new library works, ensure that it is only included in certain debug builds, and deal with the benchmark <-> internal cross boundary that arises as the benchmark code (which is a separate binary) tries to interact with it.
On top of it all this is really not used at all.
The plan is to rip out this functionality and just put it in a separate binary that one can include if they really want to debug. That means that it cannot exist in the public API, so I am removing it here.
Private internals come next
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D53137544
fbshipit-source-id: 7571d243b914cd9bf09ac2418d9a1b86d1bee64a
Summary:
X-link: https://github.com/facebook/react-native/pull/42411
Pull Request resolved: https://github.com/facebook/yoga/pull/1562
I added a small regression D52605596, where negative border would not be correctly floored. This fixes that, and starts adding tests specifically targeting the computed style API, now decoupled from the yoga node.
Reviewed By: joevilches
Differential Revision: D52930827
fbshipit-source-id: e165dade705a8de54c92d65f3664c9081137788c
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1561
Back when I introduced the inline functions that would get the edge according to the writing direction I swapped some instances of `setLayoutPosition` which wrote to the flexStart edge erroneously. We should basically never read from some inline style and write to the flex edge. This changes them all to use the flex values.
Reviewed By: NickGerleman
Differential Revision: D52921401
fbshipit-source-id: 92b74d652018596134c91827806272ed7418ef6c
Summary:
X-link: https://github.com/facebook/react-native/pull/42131
Pull Request resolved: https://github.com/facebook/yoga/pull/1534
Now that the storage method is a hidden implementation detail, this changes the underlying data structure used to store styles, from `CompactValue` (a customized 32-bit float with tag bits), to `StyleValuePool`.
This new structure operates on 16-bit handles, and a shared small buffer. The vast majority of real-world values can be stored directly in the handle, but we allow arbitrary 32 bit (and soon 64-bit) values to be stored, where the handle then becomes an index into the styles buffer.
This results in a real-world memory usage win, while also letting us store the 64-bit values we are wanting to use for math function support (compared to doubling the storage requirements).
This does seem to make style reads slower, which due to their heavy frequency, does have a performance impact observable by synthetics. In an example laying out a tree of 10,000 nodes, we originally read from `StyleValuePool` 2.4 million times.
This originally resulted in a ~10% regression, but when combined with the changes in the last diff, most style reads become simple bitwise operations on the handle, and we are actually 14% faster than before.
| | Before | After | Δ |
| `sizeof(yoga::Style)` | 208B | 144B | -64B/-31% |
| `sizeof(yoga::Node)` | 640B | 576B | -64B/-10% |
| `sizeof(YogaLayoutableShadowNode) ` | 920B | 856B | -64B/-7% |
| `sizeof(YogaLayoutableShadowNode) + sizeof(YogaStylableProps)` | 1296B | 1168B | -128B/-10% |
| `sizeof(ViewShadowNode)` | 920B | 856B | -64B/-7% |
| `sizeof(ViewShadowNode) + sizeof(ViewShadowNodeProps)` | 2000B | 1872B | -128B/-6% |
| "Huge nested layout" microbenchmark (M1 Ultra) | 11.5ms | 9.9ms | -1.6ms/-14% |
| Quest Store C++ heap usage (avg over 10 runs) | 86.2MB | 84.9MB | -1.3MB/-1.5% |
Reviewed By: joevilches
Differential Revision: D52223122
fbshipit-source-id: 990f4b7e991e8e22d198ce20f7da66d9c6ba637b
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1560
I added these when I was trying to debug the Facepile break removing the row-reverse errata caused. Yoga is doing the right thing, and the tests pass. We didn't have this specific coverage before, so add it.
Reviewed By: joevilches
Differential Revision: D52909633
fbshipit-source-id: d1e8f55bb534d76bd7dfdc46a1e1cc6f0a3ca211
Summary:
X-link: https://github.com/facebook/react-native/pull/42254
Pull Request resolved: https://github.com/facebook/yoga/pull/1550
This change aims to simplify how we resolve edges. This operation happens many, many times, and has gotten complex and slow when paired with StyleValuePool.
This starts reshaping so that `yoga::Style` can resolve a style prop for a given edge. This is closer to the ideal computed style API to avoid recalcing this so many times, but doesn't address that.
This relies on removing the errata related to row-reverse, and cleans up the removal started in the last change.
This has no measurable perf effect under CompactValue, but has a >10% uplift in perf when using StyleValueHandle, where we can trivially check if a handle points to a defined value without resolving it, but only within `yoga::Style` since we don't expose the handle outside of it.
More quantifiably, we go from 2.35 million StyleValuePool reads to 993k. The rest are checks on the handle.
Reviewed By: joevilches
Differential Revision: D52605596
fbshipit-source-id: 0b366963a899e376f99ce3d75cd5f14a25d60cec
Summary:
X-link: https://github.com/facebook/react-native/pull/42314
Pull Request resolved: https://github.com/facebook/yoga/pull/1555
The next diff moves a bunch of methods to `yoga::Style`. This renames the function to be a tad bit shorter, for more readable callsites. It also makes it more consistent with style property getters.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D52803393
fbshipit-source-id: 557df34a9f0fb0ee42ad23b1fda99c1e0eb1d4e3
Summary:
> This PR is based on the proposal in https://github.com/facebook/yoga/issues/1538 inlined below, to integrate yoga with `oss-fuzz`
Hey yoga team,
I've recently become interested in yoga. I'd like to suggest and champion an effort to set up some basic fuzz-testing and combine it with google/oss-fuzz for continuous fuzzing. I'm fully aware that you are very busy people and I don't want to overload your review/maintenance capacity. Is this a bad time to discuss potential security/reliability improvements?
If you're not familiar with fuzzing or oss-fuzz I've included a few brief notes below.
#### **Benefits of Fuzz-Testing**
- **Dynamic Code Testing**: Fuzz-testing challenges systems with unexpected data, aiming to identify vulnerabilities or bugs. It’s akin to an exhaustive stress-test for the code.
- **Detecting Hidden Vulnerabilities**: It can uncover potential weaknesses that may not be evident in routine tests.
- **Continuous and Automated Testing**: With tools like Google’s OSS-Fuzz, fuzz-testing can be automated, running continuously on distributed systems, ensuring daily resilience checks.
#### **Google/oss-fuzz for Continuous Fuzzing**
- **Automated Fuzzing**: OSS-Fuzz undertakes comprehensive fuzz-testing daily on a distributed cluster.
- **Detailed Reporting**: OSS-Fuzz offers exhaustive reports in case of detected anomalies, enabling effective action.
I’d be more than happy to lead the effort in integrating fuzz testing with the yoga and assist in any way required.
#### Prior integrations
There have been a number of previous integrations completed with facebook repositories and google/oss-fuzz including;
- facebook/time
- facebook/zstd
- facebookexperimental/starlark-rust (this was me)
- facebook/proxygen
- facebook/hermes
- facebook/rocksdb
As a proof of concept I created a couple of super simple fuzz harnesses in https://github.com/facebook/yoga/issues/1537.
NOTE: Adding fuzz-testing and integrating with google/oss-fuzz was previously suggested here https://github.com/facebook/yoga/pull/1055 and was rejected. I think I've addressed the concerns raised in the first PR. While the original PR contained what was probably a higher performance fuzzer, the new fuzzer should be easier to integrate and doesn't introduce multiple sources of truth.
Pull Request resolved: https://github.com/facebook/yoga/pull/1537
Reviewed By: yungsters
Differential Revision: D52800366
Pulled By: NickGerleman
fbshipit-source-id: 4957282456f3263e600d13ae6f3e983681bebda6
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1558
X-link: https://github.com/facebook/react-native/pull/42318
AbsolutePositioning -> AbsolutePositioningCatchAll
A bit more clear. This errata is for various issues with positioning absolute nodes. There really isn't a clear description as to what specifically this enables/disables, so I just opted to say "catch all" to indicate that this controls various bugs
Reviewed By: NickGerleman
Differential Revision: D52820117
fbshipit-source-id: 80b77832baf65e68e57ca523c418422dd346ef0f
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1556
X-link: https://github.com/facebook/react-native/pull/42315
Since we aim to ship static to all users of yoga (not just XPR), we need to remove the errata that is gating most of the features. This should be a non breaking change. To ensure that, I added a new errata which, if on, will use the inner size of the containing node as the containing block. This is how it has been for a while and resolving this is risky and time consuming so for the time being we will stick with that.
Reviewed By: NickGerleman
Differential Revision: D52706161
fbshipit-source-id: 30a93f29cb0d97b20b2947eaa21f36cdc78c4961
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1549
X-link: https://github.com/facebook/react-native/pull/42253
This experimental feature is always false, and with the next diff I will be deleting the branch that actually calls into this. Separating this diff out to simplify the review process.
Reviewed By: NickGerleman
Differential Revision: D52705765
fbshipit-source-id: 705f4aa297eae730af9b44753eb01c9dec385dcf
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1553
X-link: https://github.com/facebook/react-native/pull/42274
Separate from `YGConfigSetPrintTreeFlag` we have a public API `YGNodeSetPrintFunc` which sets a function called, if you manually change a constant in source code during debugging.
This is not debug-only, is exposed as part of the public API (without a way to turn it on from the public API), and takes up a pointer per node doing nothing.
I'm not aware of anyone recently using the capability, and the tracing/event related work done since then would be more powerful for this anyway.
Remove the API.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D52767445
fbshipit-source-id: f72927b47cffa4fe6fe886b42f07cc1ba55f141e
Summary:
We technically didn't need to be on the Beta before for NDK 26, but this bumps to the latest, non-prerelease version.
Pull Request resolved: https://github.com/facebook/yoga/pull/1548
Reviewed By: christophpurrer
Differential Revision: D52749378
Pulled By: NickGerleman
fbshipit-source-id: c1940976e6b240aba2af5a2863f189280701ebd3
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1547
X-link: https://github.com/facebook/react-native/pull/42251
Yoga has an odd behavior, where `start`/`end` edges under row-reverse are relative to flex-direction, instead of writing direction.
While Yoga doesn't actually document what this behavior is supposed to be, it goes against CK documentation, historic RN documentation, and the behavior valid on the web. It is also applied inconsistently (e.g. sometimes only on container, sometimes on child). It really is a bug, instead of an intended behavior.
We changed the default behavior for Yoga, but left the existing one behind an errata (so existing fbsource users got old behavior). We have previously seen this behavior show up in product code, including CK when running on FlexLayout.
`row-reverse` is surprisingly uncommon though:
1. Litho has <40 usages
2. RN has ~40 usages in `RKJSModules`,~30 in `arvr/js`, ~6 in `xplat/archon`
3. CK has ~80 usages
4. NT has ~40 usages
There are few enough, mostly simple components, that we can inspect through each of them, looking for signs they will hit the issue (at the potential chance of missing some).
CK accounts for 10/14 usages that I could tell would trigger the issue, since it only exposes start/end edge, and not left/right. It might make sense to make it preserve behavior instead, to reduce risk a bit.
FlexLayout is now separately powering Bloks, which wasn't surveyed, so I didn't touch CK behavior under Bloks.
There could also be other usages in other frameworks/bespoke usages, and this has implications for OSS users. But based on our own usage, of many, many components, this seems rare.
Changelog:
[General][Breaking] - Make `start/end` in styles always refer to writing direction
Reviewed By: pentiumao, joevilches
Differential Revision: D52698130
fbshipit-source-id: 2a9ac47e177469f30dc988d916b6c0ad95d53461
Summary:
Bumps [follow-redirects](https://github.com/follow-redirects/follow-redirects) from 1.15.3 to 1.15.4.
<details>
<summary>Commits</summary>
<ul>
<li><a href="65858205e5"><code>6585820</code></a> Release version 1.15.4 of the npm package.</li>
<li><a href="7a6567e16d"><code>7a6567e</code></a> Disallow bracketed hostnames.</li>
<li><a href="05629af696"><code>05629af</code></a> Prefer native URL instead of deprecated url.parse.</li>
<li><a href="1cba8e85fa"><code>1cba8e8</code></a> Prefer native URL instead of legacy url.resolve.</li>
<li><a href="72bc2a4229"><code>72bc2a4</code></a> Simplify _processResponse error handling.</li>
<li><a href="3d42aecdca"><code>3d42aec</code></a> Add bracket tests.</li>
<li><a href="bcbb096b32"><code>bcbb096</code></a> Do not directly set Error properties.</li>
<li>See full diff in <a href="https://github.com/follow-redirects/follow-redirects/compare/v1.15.3...v1.15.4">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `dependabot rebase` will rebase this PR
- `dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `dependabot merge` will merge this PR after your CI passes on it
- `dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `dependabot cancel merge` will cancel a previously requested merge and block automerging
- `dependabot reopen` will reopen this PR if it is closed
- `dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/facebook/yoga/network/alerts).
</details>
Pull Request resolved: https://github.com/facebook/yoga/pull/1546
Reviewed By: cortinico
Differential Revision: D52689011
Pulled By: NickGerleman
fbshipit-source-id: 3a8b1d0802a03d262660bafd5998bedd8487c5b0
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1542
`YGNodeSetAlwaysFormContainingBlock` -> `YGNodeSetAlwaysFormsContainingBlock`
Started getting tasks telling me github CI was broken. Turns out I was just mispelling this.
Its not a big deal but we really should ensure that stuff will not land if it break github CI...not in our wheelhouse but it seems quite silly that this happens.
Also, a lot of the random files do not have auto complete or code checking which is why I didn't notice this to begin with.
Reviewed By: NickGerleman
Differential Revision: D52632257
fbshipit-source-id: 367ae5766ef9baecf55f7c227ff9fc8dece43af6
Summary:
X-link: https://github.com/facebook/react-native/pull/42191
Pull Request resolved: https://github.com/facebook/yoga/pull/1539
React native supports transforms and if a node has a transform it will [form a containing block for absolute descendants regardless of position type](https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block#identifying_the_containing_block). So we need to pass that information into Yoga to ensure this happens.
The verbiage for the field "alwaysFormsContainingBlock" is very specific. In a vacuum a node cannot simply "form a containing block". It only forms a containing block in reference to a different node. This can be illustrated in a scenario where we have a static node that is a flex container which has 1 absolute child and 1 relative child. This static node will form a containing block for the relative child but not the absolute one. We could just pass the information on rather something has a transform or not but Yoga is not supposed to know about transforms in general. As a result we have a notion of "always" forming a containing block. Since Yoga is a flexbox spec, non-absolute nodes' containing blocks will ways be their parent. If we add something like a transform to a node then that will also apply to absolute nodes - hence we can say the node will **always** form a CB, no matter who is the descendant.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52521160
fbshipit-source-id: bab9319ffddec617f5281823930f2a00cc2967f2
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1533
X-link: https://github.com/facebook/react-native/pull/42031
I have some reservations about some of the conditional setting of trailing position in general, and some of the repeated transformations that neccesitates this, but these functions don't belong in `CalculateLayout.h`. For now, just move these to their own header.
Reviewed By: joevilches
Differential Revision: D52292121
fbshipit-source-id: 4a998a4390a8d045af45f5424adaf049ed635e7a
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1530
Yoga has a shortcut where if a min dimension and max dimension are the same, the value acts as a definite length.
I was curious how browsers handled this.
CSS 2.1 said:
> If the containing block's width depends on this element's width, then the resulting layout is undefined
This is superceded in the CSS box sizing spec. https://www.w3.org/TR/css-sizing-3/#sizing-values
> If, in a particular axis, the containing block’s size depends on the box’s size, see the relevant layout module for special rules on how to resolve percentages. Negative values are invalid.
And later:
https://www.w3.org/TR/css-sizing-3/#cyclic-percentage-contribution
> Sometimes the size of a percentage-sized box’s containing block depends on the intrinsic size contribution of the box itself, creating a cyclic dependency. When calculating the intrinsic size contribution of such a box (including any calculations for a content-based automatic minimum size), a percentage value that resolves against a size in the same axis as the intrinsic size contribution (a cyclic percentage size) is resolved specially:
> If the box is non-replaced, then the entire value of any max size property or preferred size property (width/max-width/height/max-height) specified as an expression containing a percentage (such as 10% or calc(10px + 0%)) that is cyclic is treated for the purpose of calculating the box’s intrinsic size contributions only as that property’s initial value. For example, given a box with width: calc(20px + 50%), its max-content contribution is calculated as if its width were auto. (The percentage is honored as usual, however, during the actual sizing of the box itself; see below.)
> Otherwise, the percentage is resolved against the containing block’s size. (The containing block’s size is not re-resolved based on the resulting size of the box; the contents might thus overflow or underflow the containing block).
So, for the purpose of sizing the parent, the child sized using a percentage does not contribute, but we should be sizing children based on that size.
Yoga does not really work like this right now, but gets the answer right answer for half of these tests.
Reviewed By: yungsters
Differential Revision: D52251601
fbshipit-source-id: 4978b90723130283b00e87bbf49795a4d209174c
