Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41815
Our Apps in OSS ends up shipping with too many .so files.
I'm attempting to move several libraries from dynamic to static.
This is a first round of it affecnting only libraries which are not
exposed via prefab and that are not having an OnLoad method
Changelog:
[Internal] [Changed] - Move several libraries to static linking
Reviewed By: NickGerleman
Differential Revision: D51895785
fbshipit-source-id: 1ba2dbbbae6b6c2639ba0e064f1b331b2a157f03
Summary:
Adds changelog for the 0.73.0 release. The changelog was generated using the following command: `npx rnx-kit/rn-changelog-generator --base v0.73.0-rc.4 --compare v0.73.0-rc.8`
## 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
-->
[INTERNAL] [CHANGED] - Add changelog for the 0.73.0 release.
Pull Request resolved: https://github.com/facebook/react-native/pull/41741
Test Plan: Read the changelog 🤞
Reviewed By: rubennorte
Differential Revision: D51892080
Pulled By: huntie
fbshipit-source-id: 191ece6dbb1a65210efb16e13fdab49b55b84145
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41806
Changelog: [Internal]
Adds `isChildPublicInstance` to renderers implementations, which makes it available for usage from `RendererProxy`.
Reviewed By: rubennorte
Differential Revision: D51822905
fbshipit-source-id: 3ac92ead9d31dd3c7e5e7764daf27fe5f0eca942
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41807
Changelog: [Internal]
Follow-up on https://github.com/facebook/react/pull/27783.
React Native is actually using `ReactNativeTypes`, which are synced from
this repo. In order to make `isChildPublicInstance` visible for
renderers inside React Native repository, we need to list it in
`ReactNativeTypes`.
Because of current circular dependency between React Native and React,
it is impossible to actually type it properly:
- Can't import any types in `ReactNativeTypes` from local files, because
it will break React Native, once synced.
- Implementations can't use real types in their definitions, because it
will break these checks:
223db40d5a/packages/react-native-renderer/fabric.js (L12-L13)223db40d5a/packages/react-native-renderer/index.js (L12-L14)
DiffTrain build for commit c29ca23af9.
Test Plan: Sandcastle tests
Reviewed By: kassens
Differential Revision: D51849040
Pulled By: hoxyq
fbshipit-source-id: f75593e44c114289ad4c6fb8b4b37c4c5fd6d3d4
Summary:
Apple will require XCode 15 next year to ship to the app store, and it aligns with how we build and test React Native internally.
XCode 15 and 14.3 add support for a lot of [missing C++ 20 features](https://developer.apple.com/xcode/cpp/#c++20) from earlier versions as well.
Last I was aware, Riccardo was onboard with bumping min supported in 0.74 to XCode 15. This change does a slightly more conservative bump to min 14.3, and main of 15.0 (though we might want to move these before 0.74 comes out).
All of this will get migrated over to GHA soon enough as well, but... formalizing this is the only thing blocking usage of C++ 20 ranges today.
Changelog:
[ios][breaking] - Require XCode >= 14.3
Pull Request resolved: https://github.com/facebook/react-native/pull/41798
Test Plan:
1. CircleCI Passes
2. Can still boot RNTester from XCode with code signing related changes.
Reviewed By: cortinico
Differential Revision: D51840617
Pulled By: NickGerleman
fbshipit-source-id: 58f8951a436eb7c892a00432a8aad0ddd0a49da1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41812
# Changelog:
[Internal]-
This makes sure that unit tests that use okhttp, do consistently use okhttp v4 for both gradle and buck based workflows when running tests.
Reviewed By: christophpurrer
Differential Revision: D51864344
fbshipit-source-id: 7fd80fd1e7e9ccdc5ec75a41c5dd03f9fc2751a0
Summary:
Changelog: [Internal]
This makes a couple objects more exact. Nothing critical, just noticed
this old branch I had created when doing some Flow upgrades in the past.
DiffTrain build for commit f498aa2992.
Reviewed By: hoxyq
Differential Revision: D51824015
Pulled By: kassens
fbshipit-source-id: ecadc98ffb233d6458c65c38150a29ff65a10121
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41811
In this diff I'm extracting binaryCompatibilityValidator configuration into gradle.properties file. The goal is to reuse these properties from BUCK
changelog:[Internal] internal
Reviewed By: cortinico
Differential Revision: D51402033
fbshipit-source-id: 9b585dd07c5c00a39caadac47a2f0d605c5419f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41804
Those 4 tests are Ignored since a while and I haven't found a easy way to re-enable them. I believe we can safely delete them.
Changelog:
[Internal] [Changed] - Remove dead unit tests related to text/layout property settings.
Reviewed By: sammy-SC
Differential Revision: D51848089
fbshipit-source-id: 89880f5402774cb0560ac8fe4ba21e1e44c24889
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41800
I've cleaned up the new issue template:
1. Added Expo to the template selector list
2. Added a short blurb with relevant links at the beginning of every issue template
3. I've added a dedicated field for reproducer and one for extra
4. I've added rendering to the react-native info block
5. I've added another rendered blog for stacktraces.
6. I've added a drop-down item for affected platform
Changelog:
[Internal] [Changed] - Refresh the New Issue template
Reviewed By: GijsWeterings
Differential Revision: D51847659
fbshipit-source-id: 565a2dcab4913825f441e2315ae9b4dd34fd2f4f
Summary:
X-link: https://github.com/facebook/yoga/pull/1494
Pull Request resolved: https://github.com/facebook/react-native/pull/41788
Those tests are currently disabled due to Yoga attempting to do JNI calls.
I've added infra to bypass .so loading during tests, and we should be good to re-enable those tests by now.
Changelog:
[Internal] [Changed] - Re-enabled disabled tests ReactPropForShadowNodeSpecTest and ReactPropForShadowNodeSetterTest
Reviewed By: NickGerleman
Differential Revision: D51814491
fbshipit-source-id: adbbace19c94a0c6d8947f61221fafafd7797ac8
Summary:
X-link: https://github.com/facebook/yoga/pull/1495
Pull Request resolved: https://github.com/facebook/react-native/pull/41794
This is a copy of D51369722 to make it so that it preserves the file history
CalculateLayout.cpp is massive and approaching 3k lines. I added a few large functions dealing with layout of absolute nodes and was thinking it would be nice if that logic was just in its own file so it was more isolated and easier to reason about. So I made AbsoluteLayout.cpp and AbsoluteLayout.h to house this logic. In order for this to work I had to expose calculateLayoutInternal in CalculateLayout.h as layoutAbsoluteChild calls it. This is unideal and I would like to find a better way...
I also make LayoutUtils.h to house misc small helper methods as they are called in AbsoluteLayout.cpp and CalculateLayout.cpp
Reviewed By: NickGerleman
Differential Revision: D51824115
fbshipit-source-id: 9b27449e3c1516492c01e6167a6b2c4568a33807
Summary:
X-link: https://github.com/facebook/yoga/pull/1479
Pull Request resolved: https://github.com/facebook/react-native/pull/41682
There are two ways to get the value of a style for a specific edge right now:
1) From the inline start/end edge which is determined via the writing direction (ltr or rtl), assuming you do not have errata on
2) From the flex start/end edge which is determined via the flex direction (row, row-reverse, column, column-reverse)
There is a weird curiosity in the second case: you can define a style to be on the "start" or "end" edge when writing the stylex/css. The physical edge that this refers to is dependent on the writing direction. So `start` would be `left` in `ltr` and `right` in `rtl`, with `end` the opposite. It is **never** determined via the flex direction. Additionally, `start`/`end` takes precedence over the physical edge it corresponds to in the case both are defined.
So, all of this means that to actually get the value of a style from the flex start/end edges, we need to account for the case that one of these relative edges was defined and would overwrite any physical edge. Since this mapping is solely determined by the writing direction, we need to pass that in to all the flex start/end getters and do that logic. This is done in `flexStartRelativeEdge`/`flexEndRelativeEdge` which was added earlier but for some reason only being used on border.
Reviewed By: NickGerleman
Differential Revision: D51293315
fbshipit-source-id: 26fafff54827134e7c5b10354ff9bfdf67096f5b
Summary:
X-link: https://github.com/facebook/yoga/pull/1473
Pull Request resolved: https://github.com/facebook/react-native/pull/41491
To simplify the logic a bit I introduce a new function called `positionAbsoluteChild`. This function will, eventually, be the **sole function that matters** when determining the layout position of an absolute node. Because [absolute nodes do not participate in flex layout](https://drafts.csswg.org/css-flexbox/#abspos-items), we can determine the position of said node independently of its siblings. The only information we need are the node itself, its parent, and its containing block - which we have all of in `layoutAbsoluteChild`.
Right now, however, this is purely a BE change with no functionality different. There was a big set of if statements at the end of `layoutAbsoluteChild` that would position the node on the main and cross axis for certain cases. The old code had it so that the main and cross axis had basically the same logic but the code was repeated. This puts that logic, as is, in `positionAbsoluteChild` and calls that from `layoutAbsoluteChild`.
I will soon edit this function to actually do what it is envisioned to do (i.e. be the sole place that position is set for absolute nodes).
Reviewed By: NickGerleman
Differential Revision: D51272855
fbshipit-source-id: 68fa1f0e0f4d595faf2af1d9eaceb467382ca406
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41490
X-link: https://github.com/facebook/yoga/pull/1472
This change has most of the logic needed for supporting `position: static`. We do two things here that fix a lot of the broken static test:
1) We pass in the containing node to `layoutAbsoluteChild` and use it to properly position the child in the case that insets are defined.
2) We rewrite the absolute child's position to be relative to it's parent in the event that insets are defined for that child (and thus it is positioned relative to its CB). Yoga's layout position has always be relative to parent, so I feel it is easier to just adjust the coordinates of a node to adhere to that design rather than change the consumers of yoga.
The "hard" part of this algorithm is determining how to iterate the offset from the containing block needed to do this translation described above. That is handled in `layoutAbsoluteDescendants`.
Reviewed By: NickGerleman
Differential Revision: D51224327
fbshipit-source-id: ae6dc54fe2a71bebb4090ba21a0afb0125264cbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41489
X-link: https://github.com/facebook/yoga/pull/1471
If we are going to allow the containing block to layout its absolute descendants and NOT the direct parent then we need to change step 11 which is concerned with setting the trailing position in the case we are row or column reverse. This is the very last step in the function and is positioned that way because it operates on the assumption that all children have their position set by this time. That is no longer a valid assumption if CBs layout their absolute children. In that case the CB also needs to take care of setting the position here.
Because of this problem I moved some things around. It now works like:
* If errata is set, the direct parent will set trailing position for all non absolute children in step 11
* If errata is set the CB will set trailing position of absolute descendants after they are laid out inside of layoutAbsoluteDescendants
Reviewed By: NickGerleman
Differential Revision: D51217291
fbshipit-source-id: a7eea0d3623f9041b73d609a1de2bfb0f0343a26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41488
X-link: https://github.com/facebook/yoga/pull/1470
The way we plan on implementing `position: static` is by changing how we lay out absolutely positioned nodes. Instead of letting their direct parent lay them out we are going to let their containing block handle it. This is useful because by the time the containing block gets to this step it will already know its size, which is needed to ensure that absolute nodes can get the right value with percentage units. Additionally, it means that we can "translate" the position of the absolute nodes to be relative to their parent fairly easily, instead of some second pass that would not be possible with a different design.
This change just gets the core pieces of this process going. It makes it so that containing blocks will layout out absolute descendants that they contain. We also pass in the containing block size to the owner size args for `layoutAbsoluteChild`. This new path will only happen if we have the errata turned off. If there is no positioned ancestor for a given node we just assume the root is. This is not exactly how it works on the web - there is a notion of an initial containing block - but we are not implementing that as of right now.
Reviewed By: NickGerleman
Differential Revision: D51182593
fbshipit-source-id: 88b5730f7f4fec4f33ec64288618e23363091857
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41771
Changelog: [Internal]
Since we are already enforcing C++20 (and 17), we can set the namespace declaration to the C++17 style
Reviewed By: NickGerleman
Differential Revision: D51789991
fbshipit-source-id: 165d7d4e652d60ab200e2355e084010a02f470a4
Summary:
In this diff I'm integrating 'org.jetbrains.kotlinx.binary-compatibility-validator' into RN Android build gradle system.
The tool allows dumping binary API of a JVM part of a Kotlin library that is public in the sense of Kotlin visibilities and ensures that the public binary API wasn't changed in a way that makes this change binary incompatible
More context on https://github.com/Kotlin/binary-compatibility-validator#building-the-project-locally
bypass-github-export-checks
Reviewed By: cortinico
Differential Revision: D51262577
fbshipit-source-id: 1894f4e55a4019e3ce1585e9df12dee69944e5ce
Summary:
When working with Verdaccio (testing the template, releasing packages) - I've stumbled upon a lot of changes in the repo:
![CleanShot 2023-12-04 at 13 14 12@2x](https://github.com/facebook/react-native/assets/52801365/74ce53a2-b885-41f4-9a12-968a8577285e)
## Changelog:
[INTERNAL] [ADDED] - Add verdaccio generated files to .gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/41783
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D51808583
Pulled By: huntie
fbshipit-source-id: fec2a13883590d0c6af179c3804fba9d4235dde2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41767
Changelog: [Internal]
Adds a simple example showing a direct recursive node in a Cxx TM.
Currently we can't auto-generate [the necessary C++ Types](https://reactnative.dev/docs/next/the-new-architecture/cxx-custom-types#struct-generator) - but we can add it later if this scenarios becomes really common.
Direct recursive nodes, can't be value types - it would require infinite memory. Hence they are nullable and managed by a smart pointer.
Reviewed By: rshest
Differential Revision: D51784136
fbshipit-source-id: f6f0710d03583bdf1e6e72ba42d8df7f8ff8d915
Summary:
Was stepping with debugger through the code & noticed few typos.
## 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
-->
[ANDROID] [FIXED] - Typos in `ReactCompoundViewGroup` comments
Pull Request resolved: https://github.com/facebook/react-native/pull/41729
Test Plan: Typos in docs
Reviewed By: cortinico
Differential Revision: D51753447
Pulled By: arushikesarwani94
fbshipit-source-id: b373d67ca8b6c9f22d80ea1ccee98ecc5151b325
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41733
I am currently implementing position: static in Yoga. I have a huge stack of changes that is ready to ship but we are waiting on the default position type to be relative before shipping. The reason being, my changes will affect a whole ton of styles where there is no position set so if we can make static no longer the default we can safely ship this new code. However, this will take a while and keeping up with this stack of diffs though merge conflicts, flakey tests, and general slowness for my IDE is getting annoying. So a solution here is to ship that stack and make it so that no one gets this functionality by changing the strict layout conformance to include the errata that is gating my changes. The end result being that the code can be shipped but will have no affect at the time being.
Right now, because that code is in a different branch and not on prod, this change will do nothing.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51731778
fbshipit-source-id: f0b7fd8559adb19e1658b3ac64fcfc4c5f8ecdf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41739
Refactoring `DefaultReactNativeHost` to use the new way of Fabric initialization through `FabricUIManagerProviderImpl`
Reviewed By: philIip
Differential Revision: D51719555
fbshipit-source-id: bad471a8a273accecb0641ccaa77223534cd45fd
Summary:
iOS?ios?android?Android?
Always making typos when using the local testing script with the platform argument... No more!
## Changelog:
[INTERNAL][ADDED] - Improved E2E local testing script to be more flexible
Pull Request resolved: https://github.com/facebook/react-native/pull/41751
Reviewed By: cortinico
Differential Revision: D51758529
Pulled By: huntie
fbshipit-source-id: d9e633567a59fcfac1057cf1f21714ccef27ebb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41738
Replacing the callsite to `context.getFabricUIManager()` in UIManagerHelper instead of `getJSIModule()`
Fixing the crash by directly making `getFabricUIManager()` of `ReactContext` independent of the assertion.
Reviewed By: philIip
Differential Revision: D51719040
fbshipit-source-id: f9118b16614724a1d6dabe59d5c4d25dd4bdbc73
Summary:
Currently React Native defines `NDEBUG` flag for all pods in Fabric only. This is useful for other libraries, like Reanimated, because they have no easy way of defining their compilation flags (at least none that I know of). Therefore defining `NDEBUG` for both architectures would be beneficial.
## Changelog:
Pick one each for the category and type tags:
[IOS] [CHANGED] - Add `NDEBUG` flag for Release builds for both architectures
Pull Request resolved: https://github.com/facebook/react-native/pull/41715
Test Plan:
Run ruby test suite.
## Notes
For the time being I just copied
`prepare_pod_target_installation_results_mock`
and
`def prepare_installer_for_cpp_flags`
to `utils-test.rb` since I wasn't sure how to handle the installer mock.
Reviewed By: cortinico
Differential Revision: D51708382
Pulled By: cipolleschi
fbshipit-source-id: ff206f8fc151934dbae89aacd1bc69c57b4f28ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41720
We currently go via the UI thread, so we can use AsyncTask to schedule the final bit of async ReactContext destruction. This is a requirement for the AsyncTask API, which is also deprecated. We should figure out a better way to schedule and re-use threads across React Native Android, but until then, we can just create a new Thread here, which is also what we do for instance creation.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51706689
fbshipit-source-id: cf17e20e91b195b956b1701e6d91d563fdba4d15
Summary:
This PR fixes typo in CircleCI config
## 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
-->
[INTERNAL] [FIXED] - Typo in circleci config
Pull Request resolved: https://github.com/facebook/react-native/pull/41727
Test Plan: CI Green
Reviewed By: cipolleschi
Differential Revision: D51748329
Pulled By: cortinico
fbshipit-source-id: 99f54c5b9ec4113205642076c010b748ab6229f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41728
Adding APIs for `getFabricUIManager()` to ReactContext and it's subclasses. This will replace the `getJSIModule()` post JSI module deletion.
Reviewed By: philIip
Differential Revision: D51718430
fbshipit-source-id: c897ab0ee9e755e3fdb3d1e5629177818870f293