Summary:
Currently there is no way to provide a nonce when using
`ReactDOM.preinit(..., { as: 'script' })`
This PR adds `nonce?: string` as an option
While implementing this PR I added a test to also show you can pass
`integrity`. This test isn't directly related to the nonce change.
DiffTrain build for commit https://github.com/facebook/react/commit/b12bea62d9cfd9a925f28cb2c93daeda3865a64e.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: sammy-SC
Differential Revision: D45416244
Pulled By: tyao1
fbshipit-source-id: f92d66a1d6358c21e52a3b8003d06c662e2fc9fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37197
Changelog: [Internal]
i would like to communicate to OSS that these libraries are not to be used and are undergoing active changes. it seems tricky to enforce this at compile time atm so i think this will be a good first step
we can add stuff later like "what is bridgeless mode" but primary goal is to communicate not to use this
Reviewed By: mdvacca
Differential Revision: D45493984
fbshipit-source-id: 4954068befab71a14899a6bba2069755d17b6a6e
Summary:
This fixes a bug with `use` where if you update a component that's
currently suspended, React will sometimes mistake it for a render phase
update.
This happens because we don't reset `currentlyRenderingFiber` until the
suspended is unwound. And with `use`, that can happen asynchronously,
most commonly when the work loop is suspended during a transition.
The fix is to make sure `currentlyRenderingFiber` is only set when we're
in the middle of rendering, which used to be true until `use` was
introduced.
More specifically this means clearing `currentlyRenderingFiber` when
something throws and setting it again when we resume work.
In many cases, this bug will fail "gracefully" because the update is
still added to the queue; it's not dropped completely. It's also
somewhat rare because it has to be the exact same component that's
currently suspended. But it's still a bug. I wrote a regression test
that shows a sync update failing to interrupt a suspended component.
DiffTrain build for commit https://github.com/facebook/react/commit/18282f881dae106ebf6240aa52c8c02fe7c8d6f2.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: poteto
Differential Revision: D45407314
Pulled By: tyao1
fbshipit-source-id: 1303940cc34db28087563c20a187779a51d133de
Summary:
This hook reads the status of its ancestor form component, if it exists.
```js
const {pending, data, action, method} = useFormStatus();
```
It can be used to implement a loading indicator, for example. You can
think of it as a shortcut for implementing a loading state with the
useTransition hook.
For now, it's only available in the experimental channel. We'll share
docs once its closer to being stable. There are additional APIs that
will ship alongside it.
Internally it's implemented using startTransition + a context object.
That's a good way to think about its behavior, but the actual
implementation details may change in the future.
Because form elements cannot be nested, the implementation in the
reconciler does not bother to keep track of multiple nested "transition
providers". So although it's implemented using generic Fiber config
methods, it does currently make some assumptions based on React DOM's
requirements.
DiffTrain build for commit https://github.com/facebook/react/commit/540bab085d571789f4562565eebfd0db9f36345c.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: poteto
Differential Revision: D45332971
Pulled By: tyao1
fbshipit-source-id: 12e2b5a6c71fc78efb8aedfd1907f65a816cc289
Summary:
When there are multiple async actions at the same time, we entangle them
together because we can't be sure which action an update might be
associated with. (For this, we'd need AsyncContext.) However, if one of
the async actions fails with an error, it should only affect that
action, not all the other actions it may be entangled with.
Resolving each action independently also means they can have independent
pending state types, rather than being limited to an `isPending`
boolean. We'll use this to implement an upcoming form API.
DiffTrain build for commit https://github.com/facebook/react/commit/6eadbe0c4aebf68410bb48147054ee22eec4c20c.
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
Reviewed By: poteto
Differential Revision: D45301261
Pulled By: tyao1
fbshipit-source-id: e571d306be12f184c98ad7c24ff1ec1dbf788056
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37194
`convertObjCObjectToJSIValue` function prototype is declared in `RCTTurboModule.h`. This diff removes its duplicate declaration from `RCTTurboModule.m`.
Changelog: [Interanal]
Reviewed By: cipolleschi
Differential Revision: D45483572
fbshipit-source-id: bc1edae7e08b5345281134ebfe9d0cbdfedcf581
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37148
This should fix https://github.com/facebook/react-native/issue/36945, which is also causing annoyance when doing the releases
## Changelog:
[iOS][Changed] - Use contents of sdks/.hermesversion to let cocoapods recognize Hermes updates.
Reviewed By: cipolleschi
Differential Revision: D45394241
fbshipit-source-id: 972fbee8f954b90f7087bb232f922761c1639e06
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37186
"auto" is not a valid value to go into anything accepting `YGFloatOptional`. Remove the code here which special cases it (though we will produce the same result). Also remove error logging which is not localized/useful, in the theme of having user style inputs be handled gracefully.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D45434650
fbshipit-source-id: e83b3f5d84cf1186c67ca3a546cf2a48b09fc1e8
Summary:
We believe a problem in Bolts is leading to an ANR issue in Fb4a: T152128771
This diff migrates the memory pressure handling path off Bolts tasks.
There is server-side gating, in case we want to disable this fix server-side.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D45461419
fbshipit-source-id: e000a2a8da5f86a0681e6bbd2e058726110d6dea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37117
X-link: https://github.com/facebook/yoga/pull/1265
This deprecates `YGConfigSetUseLegacyStretchBehaviour` and `YGConfigGetUseLegacyStretchBehaviour`and points users to errata APIs instead. Using the C API will fire deprecation warnings, which should create errors in builds with `-Werror`, though they can be ignored if truly needed (like we do with the language bindings which need to expose their own deprecated interface).
Reviewed By: rshest
Differential Revision: D45337198
fbshipit-source-id: 7f069623e38834171f5702382bbf47c37a556a22
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37174
In the future, this will hold TurboModules, as well as legacy/interop modules.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D45404790
fbshipit-source-id: c0f3d597dfd0edc271f2e89c9ddb26e8a5542367
Summary:
ObjCTurboModule::getArgumentTypeName:
1. Only called from JavaScript.
2. Can raise exceptions.
Thread the jsi::Runtime through this method:
1. So that it can throw jsi::JSErrors.
2. To enfore that it be called from JavaScript.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D44887177
fbshipit-source-id: 170399c2919f56d4c15593adf76ec50c061cce69
Summary:
The old and the new native module system perform method argument conversion very differently:
- The TurboModule system converts from JSI Value -> ObjC value. It tries to minimize reliance on RCTConvert.
- The legacy NativeModule system is practically built on top of RCTConvert. It relies on runtime type checking to convert between JSI value -> ObjC value.
So, this diff pulls arg conversion into its own method. That way we can implement argument conversion differently in the TurboModule interop layer.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D44850618
fbshipit-source-id: 811d42ed5a78493df9969c546431a4efdf374c0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37155
Rationale: The interop TurboModule class will need to use this method to convert return ObjC values to JavaScript values.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D44807335
fbshipit-source-id: d44cd1d5effccd8258e034008bd230b299d20451
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37158
This diff sets up a global flag to turn the TurboModule interop on/off.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D45239212
fbshipit-source-id: ca9f6a24663db84eba2cd483d92c5b51cf2af0c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37156
The globals defined using defineReadOnlyGlobal should only ever be defined **at most** once.
So, let's throw an error: in case we accidentally tried to define one of these globals twice (i.e: a mistake I made in D45243456).
NOTE: Redefining the same global twice will throw anyway: you cannot write to a read-only property again. With this diff, the error will be more explicit.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D45286774
fbshipit-source-id: aff48ece2984e0fc4340dcbc80ed102ea989ece7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37157
## Context
NativeAnimatedHelper must be set up in a very particular way:
- On iOS in Bridgeless mode, it must use NativeAnimated**Turbo**Module.
- Everywhere else, it must use NativeAnimatedModule.
## Problem
For some unknown reason, NativeAnimatedModule was getting loaded on D44933587.
## Changes
This diff makes the aformentioned error impossible. It moves the module load gating logic into the two NativeModule spec files.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D45292907
fbshipit-source-id: 771bf64d7b491732e8860cf704bc9c3686980e74
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37169
Reduce visibility of methods that should not be public in ReactHost
changelog: [internal] internal
Reviewed By: philIip
Differential Revision: D45378246
fbshipit-source-id: 681c8fc6e4d67b68ac7604f07b9a031d0aa840b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37152
Those files are unncessary and can be removed from RNTester.
* Proguard file is empty
* Signing config is unnecessary and we can use the debug one also for release.
Changelog:
[Internal] [Changed] - Remove unnecessary files in RN-Tester
Reviewed By: hoxyq
Differential Revision: D45399388
fbshipit-source-id: fd1c6cccaef668e688a699e31045bdc8103ea98e
Summary:
I accidentally turned off New Architecture on RN-Tester while shipping the Fabric Interop. This reverts it.
Changelog:
[Internal] [Changed] - Re-enable newArch on RN-Tester
Reviewed By: cipolleschi
Differential Revision: D45398914
fbshipit-source-id: 2c36f3d0440f147189de644821e1704c00353bac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36967
Changelog: [Internal] - W3CPointerEvents: transform coordinates appropriately for cancel events
This change updates the behavior of pointer cancel events on Android to fire on the correct target. In particular:
1. Transform motion event from child frame into root frame before processing
2. Zero-out coordinates on pointer cancel event in frame of target before dispatching
This is specifically necessary for cancel events due to the way they're propagated between views: we fire a cancel event when a child view starts handling a native gesture (e.g. a scroll view starts being scrolled). However, the native gesture event (MotionEvent) is in the frame of the child view, whereas the rest of the existing pointer event code expects events to be in the frame of the react root view. We don't have to do this conversion for other events since the corresponding MotionEvents are received directly by the root view.
Reviewed By: lunaleaps
Differential Revision: D45064308
fbshipit-source-id: f21d260f6aeb85e5d0efd53a48da6dd1e7b5efbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36959
Changelog: [Internal] - W3CPointerEvents: fix pointercancel test scrollview on Android
On Android the contents of the scrollview were not large enough to allow for scrolling (i.e. they didn't overflow the scroll container). This change sets the height of the content and container explicitly to ensure that the view can be scrolled.
Reviewed By: vincentriemer
Differential Revision: D45064333
fbshipit-source-id: 6aa264d569639bb7d906a3afd887985caa563070
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37122
These are not used anymore.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D45314294
fbshipit-source-id: e4b93e0ebc9ed824ed975ad8486f8f0395605275
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37139
This dependency is unnecessary. React Native already exposes a `api` dependency on
`androidx.swiperefreshlayout:swiperefreshlayout` so every consumer will also get it.
This is just another line in the template we can effectively remove.
Changelog:
[Android] [Changed] - Do not explicitely depend on androidx.swiperefreshlayout:swiperefreshlayout
Reviewed By: cipolleschi
Differential Revision: D45390819
fbshipit-source-id: cce34c6a09100d36ee5eb003bb30323f64f0bb9c
Summary:
This diff adds _missing_ README files for all public RN packages.
#### Changes:
For all public RN packages:
- Add _Missing_ READMEs
Update package.json in all RN packages to add:
- Issues, Bugs urls
- Keywords and Homepage urls to respective pkgs
## Changelog:
[GENERAL][ADDED] - Add missing README files for all public RN packages.
[GENERAL][CHANGED] - Update package.json in all RN packages to add required fields.
Pull Request resolved: https://github.com/facebook/react-native/pull/37090
Test Plan: - `yarn lint && yarn flow && yarn test-ci` --> _should be green_
Reviewed By: cortinico
Differential Revision: D45390861
Pulled By: hoxyq
fbshipit-source-id: 524a92de56a7cb553573d9f54ccf40a998dfd35f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37132
Changelog: [Internal]
The root cause was that one of the custom view managers was returning a read-only map for getExportedCustomDirectEventTypeConstants. React Native merges these maps between view managers, so if the view managers were initialized in a particular order, it will try to merge events into the read-only map and silently crashes.
Reviewed By: rshest
Differential Revision: D45370622
fbshipit-source-id: 7b4b4de372844835d60f81b6700438f56a6b9302
Summary:
`maintainVisibleContentPosition` is broken when using virtualization and the new content pushes visible content outside its "window". This can be reproduced in the example from this diff. When using a large page size it will always push visible content outside of the list "window" which will cause currently visible views to be unmounted so the implementation of `maintainVisibleContentPosition` can't adjust the content inset since the visible views no longer exist.
The first illustration shows the working case, when the new content doesn't push visible content outside the window. The red box represents the window, all views outside the box are not mounted, which means the native implementation of `maintainVisibleContentPosition` has no way to know it exists. In that case the first visible view is https://github.com/facebook/react-native/issues/2, after new content is added https://github.com/facebook/react-native/issues/2 is still inside the window so there's not problem adjusting content offset to maintain position. As you can see Step 1 and 3 result in the same position for all initial views.
The second illustation shows the broken case, when new content is added and pushes the first visible view outside the window. As you can see in step 2 the view https://github.com/facebook/react-native/issues/2 is no longer rendered so there's no way to maintain its position.
#### Illustration 1
#### Illustration 2
To fix `maintainVisibleContentPosition` when using `VirtualizedList` we need to make sure the visible items stay rendered when new items are added at the start of the list.
In order to do that we need to do the following:
- Detect new items that will cause content to be adjusted
- Add cells to render mask so that previously visible cells stay rendered
- Ignore certain updates while scroll metrics are invalid
### Detect new items that will cause content to be adjusted
The goal here is to know that scroll position will be updated natively by the `maintainVisibleContentPosition` implementation. The problem is that the native code uses layout heuristics which are not easily available to JS to do so. In order to approximate the native heuristic we can assume that if new items are added at the start of the list, it will cause `maintainVisibleContentPosition` to be triggered. This simplifies JS logic a lot as we don't have to track visible items. In the worst case if for some reason our JS heuristic is wrong, it will cause extra cells to be rendered until the next scroll event, or content position will not be maintained (what happens all the time currently). I think this is a good compromise between complexity and accuracy.
We need to find how many items have been added before the first one. To do that we save the key of the first item in state `firstItemKey`. When data changes we can find the index of `firstItemKey` in the new data and that will be the amount we need to adjust the window state by.
Note that this means that keys need to be stable, and using index won't work.
### Add cells to render mask so that previously visible cells stay rendered
Once we have the adjusted number we can save this in a new state value `maintainVisibleContentPositionAdjustment` and add the adjusted cells to the render mask.
This state is then cleared when we receive updated scroll metrics, once the native implementation is done adding the new items and adjusting the content offset.
This value is also only set when `maintainVisibleContentPosition` is set so this makes sure this maintains the currently behavior when that prop is not set.
### Ignore certain updates while scroll metrics are invalid
While the `maintainVisibleContentPositionAdjustment` state is set we know that the current scroll metrics are invalid since they will be updated in the native `ScrollView` implementation. In that case we want to prevent certain code from running.
One example is `onStartReached` that will be called incorrectly while we are waiting for updated scroll metrics.
## Changelog
[General] [Fixed] - Fix VirtualizedList with maintainVisibleContentPosition
Pull Request resolved: https://github.com/facebook/react-native/pull/35993
Test Plan:
Added bidirectional paging to RN tester FlatList example. Note that for this to work RN tester need to be run using old architecture on iOS, to use new architecture it requires https://github.com/facebook/react-native/pull/35319
Using debug mode we can see that virtualization is still working properly, and content position is being maintained.
https://user-images.githubusercontent.com/2677334/163294404-e2eeae5b-e079-4dba-8664-ad280c171ae6.mov
Reviewed By: yungsters
Differential Revision: D45294060
Pulled By: NickGerleman
fbshipit-source-id: 8e5228318886aa75da6ae397f74d1801d40295e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37093
This replaces product usages of `YGConfigSetUseLegacyStretchBehaviour` with instead setting `YGErrataAll`, to opt out of future conformance fixes which may impact compatibility.
We need to still audit C/C++ usage for where we should be applying `YGErrataClassic`, port this change to the RN desktop fork, then mark the function as deprecated (taking care to allow deprecated functions in the Yoga bindings to call deprecated C ABI functions without warning).
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D45300631
fbshipit-source-id: 9f94bdbbe7eda091adac016231083b2486c583d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37095
X-link: https://github.com/facebook/yoga/pull/1262
X-link: https://github.com/facebook/litho/pull/942
Now that our own usages are removed, mark this as deprecated to encourage users to move to the errata API. The same will be done to variants of this function on other platforms before releasing, and the functions will be removed after releasing.
Reviewed By: yungsters
Differential Revision: D45300343
fbshipit-source-id: 1ecb2b25021f43a0c97ae6e7976317d28551abea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37094
This searches fbsource for the following strings corresponding to node or config creation using Yoga Java bindings.
1. `YogaNodeFactory.create`
2. `YogaConfigFactory.create`
Apart from benchmarks/tests, this leaves RN Paper, Litho and Native Templates. These are opted into compatibility with current Yoga behavior, using either `YogaErrata.CLASSIC`, or `YogaErrata.ALL` where `UseLegacyStretchBehaviour` is currently set.
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D45299721
fbshipit-source-id: 74da3dfdb8e5d703feeb44cf73bd18a40e2e936f
gnoff
Nick Gerleman
Phillip Pan
eps1lon
acdlite
David Vacca
Pranav Yadav
Dmitry Rykun
tarunrajput
Eric Rozell
Ramanpreet Nara
Nicola Corti
Alex Danoff
Pieter De Baets
Stas Veretennikov
Janic Duplessis
