Summary:
X-link: https://github.com/facebook/react-native/pull/46216
Regarding [issue](https://github.com/facebook/react-native/issues/45817) with incorrect layout when `left` is set to `auto`. This PR introduces handling `auto` whenever inline or flex position is checked to be defined and it fixes above issue.
Changelog:
[General][Fixed] - Fix handling 'auto' checks in absolute layout
## Tests:
I have run the provided unit tests and everything passes.
Pull Request resolved: https://github.com/facebook/yoga/pull/1689
Reviewed By: cipolleschi
Differential Revision: D61737876
Pulled By: NickGerleman
fbshipit-source-id: 531199a91c5e122b930b49725ea567cbb1d592ce
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1599
tsia. Had to add JS api support for set/get direction
Reviewed By: yungsters
Differential Revision: D54778992
fbshipit-source-id: 346152e1d61c80aa524b515e8b30a96fe32fe7c3
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/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:
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:
Pull Request resolved: https://github.com/facebook/yoga/pull/1500
Inspired by the frequent usage of Expo snacks to run RN, to repro Yoga issues, this replaces the Playground port with a new ground up Playground UI. This UI right now is pretty simple, with a JSX editor which creates a Yoga tree, which is then rendered using the WebAssembly variant of Yoga.
There are a lot of ways we can continue to improve this, but this merges the foundation. Subjectively, I find this more useful as a tool to play with Yoga behavior than the GUI.
This also replaces some of the bits of the homepage, and adds a playground entrypoint (though it's pretty identical to the one I've been testing on the home page).
Reviewed By: yungsters
Differential Revision: D51963201
fbshipit-source-id: 1265cb1784151b685686e189d47ecd42cbacdf8f
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1506
In order to build the website, you must build a Yoga binary. This usually requires installing native toolchains.
We have warning messages for these right now, but an even better solution is to just manage the dependencies ourselves. This does that, bringing in specific CMake and Ninja binaries from NPM, and caching a local copy of Emscripten during the build.
A downside is that the CMake packages are chunky, so we add 130MB to node_modules (for a repo total around 350MB). This also delays acquiring Emscripten (which is even chunkier) in CI builds until it is needed, and I added some caching for it as well.
The upside of JS users being able to run and test (inc the website) without installing and managing their own versions of toolchains is a real time-saver though, and is probably worth it.
allow-large-files
Reviewed By: yungsters
Differential Revision: D52013026
fbshipit-source-id: 3d307f751463a21c5e5d5b98b8e9e63db9d3d52e
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1481
X-link: https://github.com/facebook/react-native/pull/41684
Absolute nodes can be laid out by themselves and do not have to care about what is happening to their siblings. Because of this we can make `positionAbsoluteChild` the sole place where we handle this logic. Right now that is scattered around algorithm with many `if (child is absolute)` cases everywhere. This makes implementing position static a lot harder since we are relying on the CB to do all this work, not the parent.
With this change the only time we set position for an absolute node and it matter (i.e. not overwritten) is in `positionAbsoluteChild`
Reviewed By: NickGerleman
Differential Revision: D51290723
fbshipit-source-id: 405d81b1d28826cbb0323dc117c406a44d381dff
Summary:
Fixes https://github.com/facebook/yoga/issues/1417
This dramatically simplifies the matrix of Node vs web, ASM vs WASM, sync vs async compilation, or CommonJS vs ES Modules. We have one variant, using wasm, with ESModule top-level await to do async compilation. Web/node share the same binary, and we base64 encode the WASM into a wrapper JS file for compatibility with Node and bundlers.
This has some downsides, like requiring an environment with top level await, but also has upsides, like a consistent, sync looking API compatible with older Yoga, and mitigating TypeScript issues with package exports and typings resolution.
As part of this work I also removed `ts-node` from the toolchain (at the cost of a couple of config files needing to be vanilla JS).
Pull Request resolved: https://github.com/facebook/yoga/pull/1433
Test Plan:
1. `yarn test`
2. `yarn lint`
3. `yarn tsc`
4. `yarn benchmark`
5. `yarn build` website-next
6. `yarn lint` website-next
7. Locally test website-next
8. Examine package artifact created by GitHub
9. All Automation passes
Reviewed By: yungsters
Differential Revision: D50453324
Pulled By: NickGerleman
fbshipit-source-id: fe1192acc69e57fa69a1ff056dd7b5844d2198d5
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1434
X-link: https://github.com/facebook/react-native/pull/41130
I will use this errata to gate my changes that actually make position: static behave like the web. We have future plans to make position: relative the default again but users could still have declared certain nodes as position: static, so I think this is needed regardless.
Reviewed By: NickGerleman
Differential Revision: D50506915
fbshipit-source-id: b0d9e6883167de6ff002352c9288053324464cb9
Summary:
X-link: https://github.com/facebook/react-native/pull/41019
### Changes made
- Regenerated tests (as some aspect ratio tests seem to be out of date compared to the fixtures)
- Added SpaceEvenly variant to the "Align" enums (via enums.py)
- Implemented `align-content: space-evenly` alignment in CalculateLayout.cpp
- Added generated tests `align-content: space-evenly`
- Updated NumericBitfield test to account for the fact that the Align enum now requires more bits (this bit could do with being reviewed as I am not 100% certain that it's valid to just update the test like this).
### Changes not made
- Any attempt to improve the spec-compliance of content alignment in general (e.g. I think https://github.com/facebook/yoga/pull/1013 probably still needs to happen)
Pull Request resolved: https://github.com/facebook/yoga/pull/1422
Reviewed By: yungsters
Differential Revision: D50305438
Pulled By: NickGerleman
fbshipit-source-id: ef9f6f14220a0db066bc30db8dd690a4a82a0b00
Summary:
This mirrors the clang-format config used by fbsource to Yoga.
They are pretty similar, except for an annoying habit where Yoga's previous forced small functions in headers to be a a single line, so you would get a combination of multiline and single line functions next to each other which are hard to read. That is what motivated this change.
It also enforces header ordering (yay). I don't think we have any side-effect causing headers, so this should be safe.
Reviewed By: yungsters
Differential Revision: D49248994
fbshipit-source-id: 66998395e7c0158ff9d9fb1bee44e8401bdd8f21
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1368
X-link: https://github.com/facebook/react-native/pull/39372
These were marked as deprecated as part of the public Yoga 2.0 release, and were alredy emitting deprecation warnings. Remove them.
Reviewed By: javache
Differential Revision: D49131250
fbshipit-source-id: cc1d4e8b179697b9a11a685f4fc4e9d36e1a26a0
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1369
X-link: https://github.com/facebook/react-native/pull/39370
This fixes const-correctness of callbacks (e.g. not letting a logger function modify nodes during layout). This helps us to continue to fix const-correctness issues inside of Yoga.
This change is breaking to the public API, since it requires a change in signature passed to Yoga.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D49130714
fbshipit-source-id: 4305f8882d89f296e45b78497a51716a0dbb3b2d
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1317
X-link: https://github.com/facebook/react-native/pull/37374
This is edge-casey enough, and I actually broke this in D42282358 without us noticing (I changed height to width of the bottom usage, instead, copy/pasting the value of the top one).
Reviewed By: yungsters
Differential Revision: D45766764
fbshipit-source-id: b600b79b8436534fe48ef2acbfde8ba64068e593
Summary: This is needed to make Webpack happy when bundling Yoga. Webpack assumes this is an ESModule after following it from the package.json export map. We are already importing this via default import.
Reviewed By: GijsWeterings
Differential Revision: D46811190
fbshipit-source-id: 7a074e5d2aa9c0cb4b59e506a0d910762a62dd58
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1284
This makes TypeScript resolution play nicely with export maps, and converts the entrypoints to TypeScript.
We remove the non-export-map fallbacks as well, so the export maps are always followed.
Tests are moved to load yoga from its external export, testing the entrypoints.
This moves the only untyped bit to the binary wrapper, which another diff will move.
Reviewed By: yungsters
Differential Revision: D45713689
fbshipit-source-id: 228e6f2c9d53520230707a81e76c3c35fcd46de5
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1285
Enums are currently exposed to the JS package as constants (e.g. `import {ERRATA_NONE} from 'yoga-layout'`).
This exports enums in the form of `import {Errata} from 'yoga-layout'` then `Errata.None`.
It would be more ergonomic for these to be string union based enums instead, but right now it is a pretty thin wrapper around the native API, we need ordinal values to do things with bit masks, and folks have wanted to serialize them before.
Reviewed By: yungsters
Differential Revision: D45570417
fbshipit-source-id: dbfd330e939051d0c16460a4d2a996f88f98875c
Summary:
This change restructures the package to try to remove the JS build step from the inner loop. Instead, we have a single `src` directory that we babel transform when using, then apply the same transform inline during prepublish.
At the end, we will be publishing a source directory with Babel transformed TS, JS, and TS declarations.
We do a little spring cleaning when doing this. Fixing up some of the folder/file conventions, and removing the non-export-map fallbacks.
We cannot remove the need for a native build.
Reviewed By: yungsters
Differential Revision: D45682153
fbshipit-source-id: ea2dd75c2dd6e3529b1ef6cf6ac6a64a270049a4
