Summary:
X-link: https://github.com/facebook/react-native/pull/41390
Pull Request resolved: https://github.com/facebook/yoga/pull/1460
Yoga passes `MeasureMode`/`YGMeasureMode` to express constraints in how a box should be measured, given definite or indefinite available space.
This is modeled after Android [MeasureSpec](https://developer.android.com/reference/android/view/View.MeasureSpec), with a table above `calculateLayoutImpl()` explaining the CSS terms they map to. This can be confusing when flipping between the spec, and code.
This switches internal usages to the CSS terms, but leaves around `YGMeasureMode` since it is the public API passed to measure functions.
Reviewed By: joevilches
Differential Revision: D51068417
fbshipit-source-id: 0a76266a4e7e0cc39996164607229c3c41de2818
Summary:
X-link: https://github.com/facebook/react-native/pull/41347
Pull Request resolved: https://github.com/facebook/yoga/pull/1453
This follows the previous patterns used for `Gutters` and `Dimension`, where we hide CompactValue array implementation from `yoga::Style` callers.
This allows a single read of a style to only need access to the resolved values of a single edge, vs all edges. This is cheap now because the interface is the representation, but gets expensive if `StyleValuePool` is the actual implementation.
This prevents us from needing to resolve nine dimensions, in order to read a single value like `marginLeft`. Doing this, in the new style, also lets us remove `IdxRef` from the API.
We unroll the structure dependent parts in the props parsing code, for something more verbose, but also a bit clearer.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D50998164
fbshipit-source-id: 248396f9587e29d62cde05ae7512d8194f60c809
Summary:
Pull Request resolved: https://github.com/facebook/yoga/pull/1365
X-link: https://github.com/facebook/react-native/pull/39368
This changes public Yoga API to in more places accept const structures where before they required mutable ones.
`resolveRef` is added as a quick way to resolve overloaded opaque refs for different types which is a bit easier to read than static_casting, and which will propagate const-ness. We also add `YGConfigConstRef`, similar to `YGNodeConstRef`. I was a bit iffy on whether we should add something to make it easier to convert to private interface, but this doesn't seem any easier to misuse than someone who looks at the internals to find the `static_cast`.
This tries to avoid more breaking changes yet, e.g. changing callbacks to require clients do not modify nodes when they are passed for logging. We also don't have const variants for returning child structures which would allow mutation of dependencies of the const object. These would need new names under the public API, since we do not have operator overloading in C.
Reviewed By: rshest
Differential Revision: D49130412
fbshipit-source-id: ee6b31b47f4622031c63dd52d8ac133d21bf29b7
Summary:
X-link: https://github.com/facebook/react-native/pull/39195
Pull Request resolved: https://github.com/facebook/yoga/pull/1352
## This diff
This splits out all of the logic under `YGNodeCalculateLayout` to a couple of different files, does some mechanical renaming, and starts to split up the implementation a tiny bit. After this, core layout functions are all C++ convention and namespaced.
Each new file is marked as a move for the sake of blame history. It means Phabricator has a very inaccurate count of lines removed though.
## This stack
The organization of the C++ internals of Yoga are in need of attention.
1. Some of the C++ internals are namespaced, but others not.
2. Some of the namespaces include `detail`, but are meant to be used outside of the translation unit (FB Clang Tidy rules warn on any usage of these)
2. Most of the files are in a flat hierarchy, except for event tracing in its own folder
3. Some files and functions begin with YG, others don’t
4. Some functions are uppercase, others are not
5. Almost all of the interesting logic is in Yoga.cpp, and the file is too large to reason about
6. There are multiple grab bag files where folks put random functions they need in (Utils, BitUtils, Yoga-Internal.h)
7. There is no clear indication from file structure or type naming what is private vs not
8. Handles like `YGNodeRef` and `YGConfigRef` can be used to access internals just by importing headers
This stack does some much needed spring cleaning:
1. All non-public headers and C++ implementation details are in separate folders from the root level `yoga`. This will give us room to split up logic and add more files without too large a flat hierarchy
3. All private C++ internals are under the `facebook::yoga` namespace. Details namespaces are only ever used within the same header, as they are intended
4. Utils files are split
5. Most C++ internals drop the YG prefix
6. Most C++ internal function names are all lower camel case
7. We start to split up Yoga.cpp
8. Every header beginning with YG or at the top-level directory is public and C only, with the exception of Yoga-Internal.h which has non-public functions for bindings
9. It is not possible to use private APIs without static casting handles to internal classes
This will give us more leeway to continue splitting monolithic files, and consistent guidelines for style in new files as well.
These changes should not be breaking to any project using only public Yoga headers. This includes every usage of Yoga in fbsource except for RN Fabric which is currently tied to internals. This refactor should make that boundary clearer.
Reviewed By: rshest
Differential Revision: D48770478
fbshipit-source-id: 2a74b86441c3352de03ae193c98fc3a3573047ed
Summary:
X-link: https://github.com/facebook/react-native/pull/39201
Pull Request resolved: https://github.com/facebook/yoga/pull/1353
## This diff
This moves and renames `YGAssert`, and removes it from the public API, since external users should not need to call into internal Yoga assert functions, and the current API prevents us from making this a macro later to include the condition in the message.
## This stack
The organization of the C++ internals of Yoga are in need of attention.
1. Some of the C++ internals are namespaced, but others not.
2. Some of the namespaces include `detail`, but are meant to be used outside of the translation unit (FB Clang Tidy rules warn on any usage of these)
2. Most of the files are in a flat hierarchy, except for event tracing in its own folder
3. Some files and functions begin with YG, others don’t
4. Some functions are uppercase, others are not
5. Almost all of the interesting logic is in Yoga.cpp, and the file is too large to reason about
6. There are multiple grab bag files where folks put random functions they need in (Utils, BitUtils, Yoga-Internal.h)
7. There is no clear indication from file structure or type naming what is private vs not
8. Handles like `YGNodeRef` and `YGConfigRef` can be used to access internals just by importing headers
This stack does some much needed spring cleaning:
1. All non-public headers and C++ implementation details are in separate folders from the root level `yoga`. This will give us room to split up logic and add more files without too large a flat hierarchy
3. All private C++ internals are under the `facebook::yoga` namespace. Details namespaces are only ever used within the same header, as they are intended
4. Utils files are split
5. Most C++ internals drop the YG prefix
6. Most C++ internal function names are all lower camel case
7. We start to split up Yoga.cpp
8. Every header beginning with YG or at the top-level directory is public and C only, with the exception of Yoga-Internal.h which has non-public functions for bindings
9. It is not possible to use private APIs without static casting handles to internal classes
This will give us more leeway to continue splitting monolithic files, and consistent guidelines for style in new files as well.
These changes should not be breaking to any project using only public Yoga headers. This includes every usage of Yoga in fbsource except for RN Fabric which is currently tied to internals. This refactor should make that boundary clearer.
Reviewed By: rshest
Differential Revision: D48769809
fbshipit-source-id: b5480ac54781bc01b00c158b07d2d751fac87d37
