Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47237
The Xcodeproj gem has been released yesterday to version 1.26.0 and it broke the CI pipeline of react native.
This should fix the issue
## Changelog
[Internal] - Pin Xcodeproj gem to 1.26.0
Reviewed By: blakef
Differential Revision: D65057797
fbshipit-source-id: f4035a1d3c75dd4140eb1646ab2aa0ccb08fb16b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47219
We received reports that textTransform does not correctly match the web behaviour for capitalize, eg. capitalized characters should not be lowercased when using `capitalize`.
Example input: 'hello WORLD', should become 'Hello WORLD'.
Changelog: [General][Fixed] TextTransform: capitalize better reflects the web behaviour
Reviewed By: NickGerleman
Differential Revision: D65023821
fbshipit-source-id: 8ba5fdbd7afb1460193bf82a2f4021c3aff2110a
Summary:
Adds unit tests that directly cover the order in which `LayoutableChildren` iterator goes over the descendant nodes. The covered cases are as follows (nodes with `display: contents` are marked green):
### Single `display: contents` node
```mermaid
flowchart TD
R((R)) --> A((A))
R --> B((B))
R --> C((C))
B --> D((D))
B --> E((E))
style B fill:https://github.com/facebook/yoga/issues/090
```
Correct order: `A, D, E, C`
### Multiple `display: contents` nodes
```mermaid
flowchart TD
R((R)) --> A((A))
R --> B((B))
R --> C((C))
A --> D((D))
A --> E((E))
B --> F((F))
B --> G((G))
C --> H((H))
C --> I((I))
style A fill:https://github.com/facebook/yoga/issues/090
style B fill:https://github.com/facebook/yoga/issues/090
style C fill:https://github.com/facebook/yoga/issues/090
```
Correct order: `D, E, F, G, H, I`
### Nested `display: contents` nodes
```mermaid
flowchart TD
R((R)) --> A((A))
R --> B((B))
R --> C((C))
B --> D((D))
B --> E((E))
E --> F((F))
E --> G((G))
style B fill:https://github.com/facebook/yoga/issues/090
style E fill:https://github.com/facebook/yoga/issues/090
```
Correct order: `A, D, F, G, C`
### Leaf `display: contents` node
```mermaid
flowchart TD
R((R)) --> A((A))
R --> B((B))
R --> C((C))
style B fill:https://github.com/facebook/yoga/issues/090
```
Correct order: `A, C`
### Root `display: contents` node
```mermaid
flowchart TD
R((R)) --> A((A))
R --> B((B))
R --> C((C))
style R fill:https://github.com/facebook/yoga/issues/090
```
Correct order: `A, B, C` - `LayoutableChildren` goes over the children with `display: contents` property, setting it on the root node should have no effect.
Changelog: [Internal]
X-link: https://github.com/facebook/yoga/pull/1731
Reviewed By: joevilches
Differential Revision: D64981779
Pulled By: NickGerleman
fbshipit-source-id: ee39759c663a40f96ad313f1b775d53ab68fb442
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47194
Fixes a case where a node with `display: contents` would not be cleaned up in some cases. This was caused by it being called after some early returns handling different quick paths. This PR moves the call to `cleanupContentsNodesRecursively` earlier so that it's always called.
The problem here wasn't mutating before cloning, but leaving a node marked as dirty after the layout has finished.
The exact case in which I found this was a node with a single `display: contents` child which needs to be a leaf. Then in the parent node [this](b0b842d5e7/yoga/algorithm/CalculateLayout.cpp (L1339)) condition is true, so `cleanupContentsNodesRecursively` doesn't get called and the child node is never visited and cleaned. I assume the same will happen in the other paths with an early return here.
Changelog:
[General][Fixed] - Fix for nodes with `display: contents` not being cleaned in some cases
X-link: https://github.com/facebook/yoga/pull/1729
Reviewed By: rozele
Differential Revision: D64910099
Pulled By: NickGerleman
fbshipit-source-id: 6d56f8fbf687b7ee5af889c0b868406213c9cee8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47167
I couldn't find any usages of this method in javascript.
Removing, so that the native code is easier to read.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64606928
fbshipit-source-id: 1d52d58437370ae3d99e9c44500080687f137191
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47165
The c++ pipeline needs a javascript interface.
We could just re-use exceptions manager (for now).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64779068
fbshipit-source-id: 4e300668a01fa22e194ea9f149ef1d936d5e0834
Summary:
Now, handleError can be called with a JSError that wraps a non-error object!
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64706198
fbshipit-source-id: 562ed7d4e2a13eaef48acfdf3499296462e54166
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45626
I'm deleting CoreFeatures class and all its imports because it was fully replaced by ReactNativeFeatureFlags
Changelog: [Internal][Removed] Delete CoreFeatures class in favor of ReactNativeFeatureFlags
Reviewed By: rubennorte
Differential Revision: D60137380
fbshipit-source-id: 8bf918cdd1ce66e315aa95e1c5a28879445ff9f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47179
In this diff I'm exposing the new parameter (JSBundleLoader) as parameter of DefaultReactHost.
changelog: [Android][Breaking] Added JSBundleLoader as parameter of DefaultReactHost
Reviewed By: cortinico
Differential Revision: D64381501
fbshipit-source-id: dd0d56441802f7db53c67c659bbcae63c4b1b613
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47128
Delete CompositeReactPackage from RN, these classes were deprecated for a long time and they can be deleted now, there are no internal usages
changelog: [Android][Breaking] Deleting deprecated CompositeReactPackage
Reviewed By: cortinico
Differential Revision: D64382211
fbshipit-source-id: d4fdfd51177612a64dde918cd68d6e852ef1b0e2
Summary:
Saw this while going through the remaining warnings of the project. I double checked, and i can't find any other usages left behind, so this is probably the last one
## Changelog:
[INTERNAL] [FIXED] - Switch to using the new sendString method for Websocket
Pull Request resolved: https://github.com/facebook/react-native/pull/47197
Test Plan:
yarn test:
<img width="933" alt="Screenshot 2024-10-25 at 00 55 58" src="https://github.com/user-attachments/assets/dbfebb90-4957-4fc9-8a90-153c03055ac9">
Running the tests in Xcode with `CMD+U` or the objc-test: I could not get it to pass in either the old code or the modified code. I know the test documentation said it needs a WebSocket, but it was a bit too vague , and even turning metro on did not help, so i have no idea how to test it. If anyone can guide me on that one, please let me know
Reviewed By: blakef
Differential Revision: D64934981
Pulled By: cipolleschi
fbshipit-source-id: c6f13d3da5aafe3eed8b99b98f04904fcdcc4115
Summary:
Danger seems to have a bug where it's not transpiling the import of
rnx-kit/rn-changelog-generator. This mitigates the issue to get our
project back on track.
This can be replicated locally by:
```bash
DEBUG="*" DANGER_GITHUB_API_TOKEN=$GITHUB_TOKEN yarn danger pr https://github.com/facebook/react-native/pull/47182
```
You can see it running correctly here when switching to the branch with the fix. **I'm a little concerned that this is still failing on the PR**. Thoughts?
{F1946190275}
Changelog: [internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/47192
Reviewed By: cortinico
Differential Revision: D64924466
Pulled By: blakef
fbshipit-source-id: 68df0521620809effe3a78ce842e043382ad64a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47195
When a user wants to create a Fabric Component i their app (not in a separate library) the app fails to build because:
- The custom component has to inherit from `RCTViewComponentView`
- `RCTViewComponentView` imports `ViewProps.h`
- `ViewProps.h` imports `HostPlatformViewProps.h`
- `HostPlatformViewProps.h` imports `BaseViewProps.h`
- `BaseViewProps.h` imports `YogaStylableProps.h`
which is a Yoga private header and the App has not visibility over it.
It is also not possible to fix this issue with forward declaring the `YogaStylableProps`, because `BaseViewProps` inherit from the yoga's props, so the compiler needs the full declaration of `YogaStylableProps` to work
This needs to be picked in 0.76
## Changelog
[iOS][Fixed] - Give apps access to Yoga headers
Reviewed By: blakef
Differential Revision: D64925222
fbshipit-source-id: e724076bbfb0a678948340dfab2ce609e6509533
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47033
Lastest Folly has updates to fix build errors with LLVM 19 which is also llikely needed for NDK 27
- bf46c8a21f
- also add folly's new dependency fast_float
- update fmt version
Changelog:
[General][Changed] - Bump Folly to 2024.10.14.00
Reviewed By: NickGerleman
Differential Revision: D64372125
fbshipit-source-id: 1a88f1bc2af7bedce96437f2dba5b6e0fe9ea772
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47176
While writing the guide for the New Architecture, we realized that we need to exclude the generation of the Cls function in the RCTThirdPartyFabricComponentsProvider for components defined in the app.
This is needed because a component that is defined in the app will have those function defined in the app project. However, the RCTThirdPartyFabricComponentsProvider is generated in Fabric, inside the Pods project.
The pod project needs to build in isolation from the app and cocoapods then link the app to the pods project. But the compilation of the pods project fails if one of the symbol needed by the pods lives in the app.
By disabling the generation of that function in th RCTThirdPartyFabricComponentsProvider, we can successfully build the app.
The downside is that the user needs to register the component manually, but this is not an issue because if they are writing a component in the app space, they have all the information tomanually register it in the AppDelegate
## Changelog
[iOS][Fixed] - Do not generate the ComponentCls function in the RCTThirdPartyFabricComponentsProvider for components deined in the app.
Reviewed By: cortinico, blakef
Differential Revision: D64739896
fbshipit-source-id: 0eca818ea0198532a611377d14a3ff4c95cb5fe3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47147
By batching sync events if multiple events are dispatched during sync rendering this will reduce the number of re-renders.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D64287526
fbshipit-source-id: a5dc3b643ef1853bef9e38ce8c2f5db75e02214b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47146
This will allows us to batch sync events which leads to better performance.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D64631346
fbshipit-source-id: b82dca150c13bdb7acae6bedb392a93993273988
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47163
In order to adopt react 19's ref-as-prop model, we need to eliminate all the places where they are treated differently. `React.AbstractComponent` is the worst example of this, and we need to eliminate it.
This diff replaces final few in libdefs.
Changelog: [internal]
Reviewed By: alexmckenley
Differential Revision: D64776942
fbshipit-source-id: 5e96c6d4fecb1b6cf539a00aecb10b9b35fc140b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47119
# Changelog:
[General] [Fixed] - Microtasks are now correctly executed after the code evaluation in Console panel of DevTools.
Fixes https://github.com/facebook/react-native/issues/46966.
`runtimeExecutor` which is propagated here, is actually being used by Hermes:
https://www.internalfb.com/code/fbsource/[cba75f2b515a]/xplat/js/react-native-github/packages/react-native/ReactCommon/react/runtime/ReactInstance.cpp?lines=112-113
The issue was that any expression that should be evaluated as part of `Runtime.evaluate` was not going through `RuntimeScheduler`, because specified `runtimeExecutor` was not going through it as well, and it was defined prior to `RuntimeScheduler`. Because of this, `RuntimeScheduler` was not draining out the microtasks queue and basically any scheduled Microtasks were not executed, see T200616136.
With this fix, we create an executor that goes through `RuntimeScheduler`, which is using another executor that makes sure that all scheduled callbacks are only executed after `Inspector` was setup.
It is extremely messy and in the future we should untangle these circular dependencies and try to simplify the approach.
Reviewed By: rubennorte
Differential Revision: D64552372
fbshipit-source-id: 467d37c71a2eb7c940297ce90ca8d68268b1ff33
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47124
With this we start the experiment to analyze the effect of the new `BackgroundDrawable.kt` and `BorderDrawable.kt` classes. This is also essentially a kotlinification of `CSSBackgroundDrawable`
We also start using CompositeBackgroundDrawable as the source of truth for **borderRadius** and **borderInsets**
We are hoping to get neutral results and a general win for code readability.
In general when the FeatureFlag passes we should not generate a CSSBackgroundDrawable at all and just use BackgroundDrawable and BorderDrawable
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63287222
fbshipit-source-id: 7ca98290c2e152b22d09b838e5f0e1cac97b1268
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46745
**Note:** This diff still does nothing yet, it will be enabled on a diff further up the stack. This split is just to simplify reviewing
`CSSBackgroundDrawable` holds the drawing logic for both **Borders** and **Background**. This is not ideal since it results in a huge file which does 2 things.
We now have `CompositeBackgroundDrawable` which allows us to set a different drawable per "layer" on our view.
By splitting up **Border** and **Background** logic we get better modularity and it'll make it easier to implement more `backgroundImage` features without further bloating the `CSSBackgroundDrawable` file
Also, this helps with the kotlinification efforts
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62898246
fbshipit-source-id: 15d1a4ef61f0c757e648c002fc7ef26626d8e3f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46709
**Note:** This diff still does nothing yet, it will be enabled on a diff further up the stack. This split is just to simplify reviewing
`CSSBackgroundDrawable` holds the drawing logic for both **Borders** and **Background**. This is not ideal since it results in a huge file which does 2 things.
We now have `CompositeBackgroundDrawable` which allows us to set a different drawable per "layer" on our view.
By splitting up **Border** and **Background** logic we get better modularity and it'll make it easier to implement more `backgroundImage` features without further bloating the `CSSBackgroundDrawable` file
Also, this helps with the kotlinification efforts
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63137921
fbshipit-source-id: fc459beadfda1832e146e36d74c3d424a28ca905
Summary:
<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please
provide enough information so that others can review your pull request.
The three fields below are mandatory.
Before submitting a pull request, please make sure the following is
done:
1. Fork [the repository](https://github.com/facebook/react) and create
your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch
TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It
supports the same options as `yarn test`.
6. If you need a debugger, run `yarn test --debug --watch TestName`,
open `chrome://inspect`, and press "Inspect".
7. Format your code with
[prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only
check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing:
https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
In order to adopt react 19's ref-as-prop model, Flow needs to eliminate
all the places where they are treated differently.
`React.AbstractComponent` is the worst example of this, and we need to
eliminate it.
This PR eliminates them from the react repo, and only keeps the one that
has 1 argument of props.
## How did you test this change?
yarn flow
DiffTrain build for [45804af18d589fd2c181f3b020f07661c46b73ea](45804af18d)
Reviewed By: jbrown215
Differential Revision: D64725736
Pulled By: SamChou19815
fbshipit-source-id: c9f6f316c95d12a9ae98926faba111395b550ccf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47141
D64152004 fixed a soundness hole in Flow's checking of frozen object types (e.g. try-Flow https://fburl.com/rmct2mf6). This diff suppresses Flow errors that appear when this fix is enabled (`experimental.object_freeze_fix` flag is set).
For most of these cases the result of `Object.freeze()` is assigned to some variable typed as a mutable type. The variable is then passed to a context where its fields can be written to. Thus changing the annotation type to a readonly version would only cause more errors downstream. So, instead, these assignments are suppressed so that the choice of using Object.freeze can be revisited.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D64699992
fbshipit-source-id: 48e4376d4ed3dbda21d32cabe512e6457384994f
Summary:
In order to adopt react 19's ref-as-prop model, we need to eliminate all the places where they are treated differently. `React.AbstractComponent` is the worst example of this, and we need to eliminate it.
This diff replaces 2 more remaining ones in react-native. Now the only remaining one is the one synced from react repo.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D64722899
fbshipit-source-id: 2b2484c385fc5d6c173253f9bee66dfc736368a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47150
In https://github.com/facebook/react/pull/31314, I will change the host component type that will be synced to react-native. Notably, it will expose the issue where all the `HostComponent<mixed>` types are wrong, since it doesn't make sense to write `React.AbstractComponent<mixed>`. This diff fixes the existing usages first in prep for that typing change.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D64722939
fbshipit-source-id: 14e1477090128205d8be8fc7b135a8478f94b790
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47143
In order to adopt react 19's ref-as-prop model, we need to eliminate all the places where they are treated differently. `React.AbstractComponent` is the worst example of this, and we need to eliminate it.
This diff replaces most of the remaining `React.AbstractComponent` in react-native.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D64701145
fbshipit-source-id: c765674fdf59812895c4fae43df97cf8b9d24f05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47121
This class should be internal. I've verified this API is not used in OSS so this is technically breaking but not really affecting anyone in OSS.
Changelog:
[Android] [Breaking] - Stable API - Make AppStateModule internal
Reviewed By: Abbondanzo
Differential Revision: D64598660
fbshipit-source-id: aebc385c741e2e1f352d473db2be87d918f0ef65
