Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39353
changelog: [internal]
Increase the wait threshold when waiting for a task in a stub queue to reduce test flakyness.
Reviewed By: makovkastar
Differential Revision: D49093046
fbshipit-source-id: 30d150f421c226587ae9e41786d2d0f95c82dfef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39344
## Changelog:
[iOS][General] - URLs parsed by RCTConvert should be encoded respecting RFC 3986, 1738/1808
in ios 17, NSURLs are encoded respecting RFC 3986 (https://www.ietf.org/rfc/rfc3986.txt) as opposed to RFC 1738/1808 before.
following this, `NSURL`'s parsing algorithm has changed such that if they encounter a reserved character, such as `[`, the parser will percent encode all possible characters in the url, including `%`.
this causes trouble for urls that already have some encoding. for the string `%22[]`, the new parsing algorithm will return the following:
RFC 1738/1808 -> `%22%5B%5D`
RFC 3986 -> `%2522%5B%5D` (invalid encoding)
the solution here is to decode all the percentified encodings in the input string, completely stripping it of the percent encodings, and then re-encoding it. thus, the string will transform as follows:
`%22[]` -> `"[]` -> `%22%5B%5D`
we probably don't need the OS check, but including it just to be safe.
Reviewed By: yungsters
Differential Revision: D49082077
fbshipit-source-id: 21ac1e37c957db3217746f9385f9d7947261794d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39358
This adds a function polyfilling C++ 20's `std::bit_cast`, using `memcpy()` to be safe with strict aliasing rules.
This replaces the conditional code in CompactValue for type punning, an unsafe place in YGJNI where we do it unsafely, and is used in ValuePool. The polyfill can be switched to `std::bit_cast` whenever we adopt C++ 20.
Note that this doesn't actually call into `memcpy()`, as verified by Godbolt. Compilers are aware of the memcpy type punning pattern and optimize it, but it's ugly and confusing to folks who haven't seen it before.
Reviewed By: javache
Differential Revision: D49082997
fbshipit-source-id: b848775a68286bdb11b2a3a95bef8069364ac9b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39205
This diff adds affected layoutable nodes count from Yoga in the telemetry for commit revision. This is used for performance monitoring next to the timestamp information we already have.
Changelog:
[Internal] - Add affected layoutable nodes count information in Fabric commit telemetry.
Reviewed By: rshest
Differential Revision: D48671209
fbshipit-source-id: b054e5dcd465122f01500fb54cba6f6d250cd256
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39330
These tests have been moved to the Hermes repo and shouldn't be used in the React Native repo anymore.
Changelog: [General][Changed] Removed unused Hermes inspector-modern test files
Reviewed By: mattbfb
Differential Revision: D49066703
fbshipit-source-id: a1976f0830e2b54b894417db55c21d1b3f312bfa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39349
This fixes these methods to ignore transforms, as per the spec:
* `offsetLeft`
* `offsetTop`
* `offsetWidth`
* `offsetHeight`
* `clientLeft`
* `clientTop`
* `clientWidth`
* `clientHeight`
`scrollWidth` and `scrollHeight` are the last methods we need to fix, as their fix is more complex than in these cases (in scroll views, the scrollable area is the overflow of all its children with transforms applied, which is an expensive computation we don't currently do, even in host platforms where this behavior doesn't work correctly).
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D49069517
fbshipit-source-id: 3c4b897c904e33514cbeefa8ee317d3c2e4a1280
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39348
We removed this method from the proposal, so we don't need to keep the method around unimplemented.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D49069518
fbshipit-source-id: 5b391954b125a082d7489d166b1c1cd6444cfa1b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39328
This adds a new method in Fabric to get the scroll size for an element, and uses it to implement `scrollWidth` and `scrollHeight` as defined in https://github.com/react-native-community/discussions-and-proposals/pull/607
Scroll size determine how much of the content of a node would move if the node was scrollable. If the content does not overflow the padding box of the node, then this is the same as the `client{Width,Height}` (the size of the node without its borders). If the content would overflow the node, then it would be the size of the content that would be scrollable (in other words, what would "move" when you scrolled).
If the element isn't displayed or it has display: inline, it return 0 in both cases.
These APIs provide rounded integers.
NOTE: The current implementation of `ScrollView` has several known bugs and inconsistencies across platforms (Android vs. iOS) and architectures (Paper vs. Fabric) (e.g.: content showing on top of the border on Android, `overflow: visible` only working on Android but not on iOS, etc.). The data that this API reports is the one that aligns with the Web (with a few limitations), and we'll need to fix the implementation to align with this.
NOTE: transforms are not considered correctly for the sake of this API, but also not applied correctly in any of the native platforms. On Web, the scrollable area is the overflow of all the children **with transforms applied** which isn't honored in RN. We''ll fix the data reported by this API when we also fix the user perceived behavior.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D49058368
fbshipit-source-id: 39a10bf7bddec9afc54f46cc02284d601b6962f3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39325
This diff extracts the logic to compute the content bounds of a shadow node (to compute its overflow insets) to a separate method. The new method is renamed as `getContentBounds` because layout metrics already have a method called `getContentFrame` that has a different meaning (the content box of the node, which excludes border and padding).
As a nice side-effect, we can now avoid executing this logic altogether if the node doesn't have overflow: visible (because we weren't assigning the result anywhere anyway).
NOTE: This method is made public because we need it to compute `scrollWidth` and `scrollHeight` in a following diff.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D49020219
fbshipit-source-id: 7a65abf8523cb1dbcf0f92565fbfc228083a7d21
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38671
Fix a race condition when we unmount and mount a view using FpsView too frequently. In this case, the frame loop callback didn't get a chance to unset the `mShouldStop` flag, causing the old frame loop continues to run unexpectedly.
The fix here guarantees `stop` would queue logic that removes the frame loop callback, and a later `start` would queue logic that attaches a new frame loop callback. Since both of them happens on UI thread, they are in sync.
Changelog:
[Android][Fixed] - Fix a race with FpsView on using FpsDebugFrameCallback.
Reviewed By: hoxyq
Differential Revision: D47849848
fbshipit-source-id: 8c4be40e86be128734bfa3f571fd3a1735976c7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39308
This adds a new method in Fabric to get the border size for an element, and uses it to implement the following methods as defined in https://github.com/react-native-community/discussions-and-proposals/pull/607 :
* `clientLeft`: left border width of the element.
* `clientTop`: top border width of the element.
If the element isn't displayed or it has display: inline, it return 0 in both cases.
These APIs provide rounded integers.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D49009140
fbshipit-source-id: e667059702ca22e2b8e8721209e9c5c2553aa7ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39305
This adds a new method in Fabric to get the inner size for an element (whole size excluding borders, which would be the scrollable size of the element), and uses it to implement the following methods as defined in https://github.com/react-native-community/discussions-and-proposals/pull/607 :
`clientWidth`: width of the element excluding the size of the left and right border.
`clientHeight`: height of the element excluding the size of the top and bottom border.
If the element isn't displayed or it has display: inline, it return `0` in both cases.
These APIs provided rounded integers.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D49008698
fbshipit-source-id: 7c25b8c5ddbba7877ea398398f7a0b755e25d746
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39278
Implements tagName as the name of the component prefixed with `RN:`.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D48951824
fbshipit-source-id: 4a8387adff8ed504423d7ead7b95943bfd77ae8c
Summary:
Fixes a critical networking path used commonly in graphics code, among many other use-cases. It is commonplace to store images within a single binary such as a GLB (see [KHR_binary_glTF](https://github.com/KhronosGroup/glTF/blob/main/extensions/1.0/Khronos/KHR_binary_glTF/README.md#overview)). Base64 encoded glTF can be critically slow in older browsers with an increased size, so it's not a suitable fallback for those targeting multiple platforms. Furthermore, large base64 payloads can cause crash behavior on native when passed via JSI (e.g. `expo-gl`). For textures, this can be several megabytes of high precision data, and a uri from a blob is preferred rather than writing platform-specific workarounds via the filesystem.
A user-land patch I've employed in [pmndrs/react-three-fiber](https://github.com/pmndrs/react-three-fiber), as well as [existing user-land patches](https://github.com/mrousavy/react-native-blob-jsi-helper), is to test the `Blob` constructor with an empty `ArrayBuffer`. `base64-js` is used here since it's already installed with `react-native` for binary utils elsewhere. This is declared as a dependency in the linked library since this is an implementation detail, but will be de-duplicated at install time.
```js
import { fromByteArray } from 'base64-js'
// Patch Blob for ArrayBuffer if unsupported
try {
new Blob([new ArrayBuffer(4)])
} catch (_) {
global.Blob = class extends Blob {
constructor(parts, options) {
super(
parts?.map((part) => {
if (part instanceof ArrayBuffer || ArrayBuffer.isView(part)) {
part = fromByteArray(new Uint8Array(part))
}
return part
}),
options,
)
}
}
}
```
## Changelog:
[INTERNAL] [FIXED] - Implement Blob from ArrayBuffer
Pull Request resolved: https://github.com/facebook/react-native/pull/39276
Test Plan:
Run the following at the project root to selectively test changes:
`jest packages/react-native/Libraries/Blob`
> **Note**: base64 encoding will add an additional ~33% size increase to binary data as part of this PR. This is padded to 4 bytes so a byte length of 4 will encode as 8. Native `ArrayBuffer` support would not have this behavior and remove the overhead of base64 encoding back and forth. This is a growing behavior across the networking stack, such as in `FileReader`.
Reviewed By: NickGerleman
Differential Revision: D48954160
Pulled By: dmytrorykun
fbshipit-source-id: 9d3b984aefe16bad2ee1088140b6e1160df52f55
Summary:
## Summary:
One of the most common diffs we have in React Native macOS is simply extending the `platforms` key Inside every pod spec to include macOS. React Native tvOS does the same to add tvOS. In the future, React Native may support visionOS, at which point we do the same thing again. Let's define a `min_supported_versions` hash that can be overridden at one place that is extensible to more platforms, instead of just specifying `min_ios_version_supported`.
Note: In doing this change, I have set it that `React-Hermes.podspec` doesn't build for macOS anymore. I think this is safe, since anyone using Hermes on macOS was probably using React Native macOS where we already have a diff to add macOS back?
## Changelog:
[IOS] [CHANGED] - Add min_supported_versions helper to cocoa pods scripts
Pull Request resolved: https://github.com/facebook/react-native/pull/39310
Test Plan: CI should pass.
Reviewed By: NickGerleman
Differential Revision: D49014109
Pulled By: dmytrorykun
fbshipit-source-id: d44fc7b750c70cc263a2c89502c022a0db9a4771
Summary:
Experimenting with Accessibility Inspector on iOS I've discovered that while when assigning `accessibilityRole="searchbox"` to a text input results in "Traits" reporting "Search Field" trait. However, when using ARIA-compatible `role="search"` such trait is not assigned, and text input will have an empty trait.
Afaiu this is incorrect as using `role="search"` and `accessibilityRole="searchbox"` should equivalent effect.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
IOS FIXED - `role="searchbox"` now assigns "Search Field" accessibility trait to a view
Pull Request resolved: https://github.com/facebook/react-native/pull/39314
Test Plan: No UI changes, it affects only accessibility.
Reviewed By: NickGerleman
Differential Revision: D49014039
Pulled By: dmytrorykun
fbshipit-source-id: 5fb194e67fbf2ac339d9a746e3ce6aaed2d32558
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39291
X-link: https://github.com/facebook/yoga/pull/1359
This enables clang warnings around potentially unsafe conversions, such as those with mismatched signedness, or ones which may lead to truncation.
This should catch issues in local development which create errors for MSVC (e.g. Dash), who's default `/W3` includes warnings akin to `-Wshorten-64-to-32`.
This full set of warnings here is a tad spammy, but probably more useful than not.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D48954777
fbshipit-source-id: 1ccc07b99d09d1c2d428158149698ffd04025605
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39306
This broke on Android platforms where `ReactFeatureFlags.enableViewRecycling` is enabled, as `setTransform` no longer directly mutates the transform properties, but instead goes through `setTransformProperty`
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D49008194
fbshipit-source-id: 7e5543b8ce79caaaf380f20010bdde69f6e212b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39311
## Changelog:
[Internal] -
Follow up to https://github.com/facebook/react-native/pull/39284 (D48960815), which landed and broke one of the build clauses on CircleCI tests (treating unused parameters as errors, even though they are expected to be unused).
Reviewed By: hoxyq
Differential Revision: D49010472
fbshipit-source-id: 469bf3a9923b85e465d4574e69e9372c16fbc125
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39307
Make it explicit that the second arg for the State update constructor is the old State object, which we use to increment the revision.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D49008431
fbshipit-source-id: 649bdd136a4a6eb25858d8bfb7c41b725e593685
Summary:
We're well past a minimum iOS 10 / macOS 10.11 version. Let's remove these ifdefs that seemed to have been added for backwards compatibility around the use of [ArrayBuffers](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer)
## Changelog:
[IOS] [REMOVED] - Remove redundant ifdefs for ArrayBuffer backwards compatibility
Pull Request resolved: https://github.com/facebook/react-native/pull/39302
Test Plan: CI should pass.
Reviewed By: rshest
Differential Revision: D49007666
Pulled By: javache
fbshipit-source-id: 03ebe303eda45ce043e3c2f9e2a5165ba798b15c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39300
Changelog: [Internal]
`ReactCommon/hermes/inspector` and `ReactCommon/jsinspector` are unused in the React Native repo as of D48897203 and D48966244, respectively. Now that we've removed the last remaining references to them from internal Meta code, we can safely delete them from React Native.
Reviewed By: christophpurrer
Differential Revision: D48983212
fbshipit-source-id: 9a70178b19fb461c00a2304697b647b7bebe74c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39288
Forks `ReactCommon/jsinspector` → `ReactCommon/jsinspector-modern`.
The Gradle, CocoaPods and Buck builds of React Native have been updated to use `jsinspector` everywhere (outside of `ReactCommon/hermes/inspector`, which is itself dead code as of D48897203). The code in `ReactCommon/jsinspector` is thus deprecated and unused in the open source build, and will be deleted in an upcoming diff (likely before the 0.73 cut).
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D48966244
fbshipit-source-id: db81739da83ef9be73690d95d010065e3b3441c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39298
Previously, switches were being announced using Talkback in this order: [state][role][label] but they should be announced as [state][label][role].
Reviewed By: NickGerleman
Differential Revision: D48807314
fbshipit-source-id: e827b9ca6d3b61b5bd2884f0f0ce6ddae00bb7df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39293
This QE is meant to change behavior to not throttle if `scrollEventThrottle` isn't set, but it's actually disabling throttling entirely.
This changes the gating to instead change the initialization path to set `_scrollEventThrottle = 0` when the QE is set.
`_scrollEventThrottle` is already set to zero when the `scrollEventThrottle` prop is removed/set to null, as the default value in ScrollViewProps.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D48968754
fbshipit-source-id: c46c7f5093a60e326267c2e5f2f86dc2d545ac7f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39195
X-link: 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:
Pull Request resolved: https://github.com/facebook/react-native/pull/39262
The use_hermes condition in React core was imprecise as using hermes is the default now. So, if USE_HERMES is not defined, then we are using hermes.
## Changelog:
[iOS][Fixed] - Use the right condition in React-Core for USE_HERMES.
Reviewed By: dmytrorykun
Differential Revision: D48907854
fbshipit-source-id: daeaa1782f23e0ab3992240e70f49ff0b2fd75de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39261
This change allow us to control whether we want to install flipper or not in RNTester using an env var.
This is just a simple quality of life change to speed up local testing.
## Changelog:
[Internal] - Allow to control whether to install Flipper or not from an env variable
Reviewed By: dmytrorykun
Differential Revision: D48907743
fbshipit-source-id: ef0f9362890e2d66be55018622f9b3bf9620bd95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39227
Changelog: [Internal]
1. Adds an `unstable_experiments` option to `createDevMiddleware` in `react-native/dev-middleware`.
2. Adds `enableCustomDebuggerFrontend` (default `false` for now) as an experiment flag controlling whether the new debugger frontend (D48680624, D48682302) is in use. We plan to enable this by default in RN 0.73 after additional testing.
If enabled, the new debugger frontend will only be used for the `/open-debugger` flow
Reviewed By: huntie
Differential Revision: D48602725
fbshipit-source-id: 598865b559478df1f19420daf3633ee6c233362a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39201
X-link: 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
Summary:
X-link: https://github.com/facebook/yoga/pull/1355
Pull Request resolved: https://github.com/facebook/react-native/pull/39198
## This diff
This splits up `Yoga-internal.h` which has become a grab bag. The actual header is left, with the purpose of being a private C ABI for bindings, but everything else is moved to a place more appropriate or removed.
A few notes:
1. `yoga::isUndefined` is replaced with `std::isnan` to avoid a layer of indirection (we will never be able to change its representation anyway). Internal usages of `YGFloatIsUndefined` are also replaced with `std::isnan` since the previous being at a library boundary means I'm not sure it can be inlined/.
2. `leading`, `trailing` arrays are factored into proper functions
3. `Values` is replaced entirely with `std::array`, since most of it was unused.
## 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: D48769241
fbshipit-source-id: 5b8e2192309539e7c133c3b3b29b445b59dd5835
Summary:
This changes Clang format config to enforce left pointer alignment instead of right, in accordance with https://www.internalfb.com/intern/wiki/Cpp/CppStyle/
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: sammy-SC
Differential Revision: D48952040
fbshipit-source-id: 108329b2f11d2041a31dee3334c7801d69a3f1ad
zhongwuzw
Moti Zilberman
troZee
Samuel Susla
Phillip Pan
Nick Gerleman
Xin Chen
Danny Su
Rubén Norte
Pieter De Baets
Cody Bennett
Saad Najmi
Adam Cmiel
Intl Scheduler
Maciej Jastrzębski
generatedunixname89002005325672
Ruslan Shestopalyuk
Vojtech Novak
IzuEneh
Arushi Kesarwani
Fábio Henriques
Carmen Krol
antliann
Riccardo Cipolleschi
Alex Hunt