Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37108
Move the pulling of transactions to the FabricUIManagerBinding, so we have more flexibility in re-using FabricMountingManager for arbitrary MountingTransaction payloads.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D45312523
fbshipit-source-id: 0aa4edf1ee98bcfc8c7942e9fb8a81ab87842a4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37075
X-link: https://github.com/facebook/yoga/pull/1255
This diff wires up YGErrata to a public API, along with existing functions to set UseLegacyStretchBehaviour.
The `UseLegacyStretchBehaviour` functions will be removed after the world internally is transitioned to `YGConfigSetErrata`. This is intentionally breaking, since most users previously enabling `UseLegacyStretchBehaviour` will want to pick a new appropriate errata setting. Internally, users of the API will be moved to`YGErrataAll`.
The overall change looks like:
1. Clean up YGConfig to use accessors/setters
2. Change up YGconfig internal storage
1. Fabric has a config per ShadowNode, so it makes sense to do some size optimization before adding more (free-form bools to bitfield, `std::array<bool,>` to `std::bitset` since not specialized)
3. Wire accessor/setter of UseLegacyStretchBehaviour to errata while both APIs exist
4. Add errata APIs to C ABI
After this we will need to expose the ABI to more language projections, and (more involved), add usages of the API to internal consumption of Yoga before adding more errata and removing `UseLegacyStretchBehaviour`.
Note that this API representation is similar, but distinct to `YGExperimentalFeature`. I think that API may also have made sense as an enum bitset, like we explicitly want for the new API, but it's not really worth changing the existing API to make that happen.
Reviewed By: rshest
Differential Revision: D45254097
fbshipit-source-id: 5c725ce5a77b25c1356f753d11c468587dbd8ded
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37091
X-link: https://github.com/facebook/yoga/pull/1258
This private constructor was added specifically for Fabric when config setting was deprecated, but that is undeprecated now. Fbsource fabric was moved off of it, and the RN desktop for was in the last diff in the stack, so we can remove it now.
Reviewed By: yungsters
Differential Revision: D45292729
fbshipit-source-id: 87b2a1adaafaf817befe44dbc3ac178af59a6e68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37077
Converts a couple of Yoga config usages in Fabric to public APIs, in preparation for changing the private API.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D45254099
fbshipit-source-id: 0d4511fc31b876bfa12f215b72c7c82c940bf342
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37059
This diff introduces InteropEventEmitter, a re-implementation of RCTEventEmitter that works with Fabric and allows to support events on the Fabric Interop for Android.
Thanks to this, users can keep on calling `getJSModule(RCTEventEmitter.class).receiveEvent(...)` in their legacy ViewManagers and they will be using the EventDispatcher
under the hood to dispatch events.
The logic is enabled only if the `unstable_useFabricInterop` flag is turned on. I've turned this on for the template setup and for RN Tester.
On top of this, this diff takes care also of event name "normalization".
On Fabric, all the events needs to be registered with a "top" prefix. With this diff, we'll be adding the "top" prefix at registration time, if the user hasn't added them.
This allows to use legacy ViewManagers on Fabric without having to ask users to change their event name.
Changelog:
[Android] [Added] - Add support for Events on the Fabric Interop Layer
Reviewed By: mdvacca
Differential Revision: D45144246
fbshipit-source-id: 63d4060153907c05977c976379b90574d1f69866
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37088
changelog: [internal]
This is a race condition. parameters need to be copied out, otherwise they might be changed during read.
Reviewed By: luluwu2032
Differential Revision: D45272086
fbshipit-source-id: 9043762dfaaf61d08e187c0d83f743e991a94ed1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37104
The AppDelegate (and other similar classes) only need to construct the TurboModuleManager for intialization purposes, and should not retain it beyond that. TurboModuleManager retains each of the TurboModule instances and through the new binding mechanism, also JSI pointers, which are invalid beyond the lifetime of the JS context.
Changelog: [iOS] Changed AppDelegate template to avoid retaining TurboModuleManager.
Reviewed By: sammy-SC, cipolleschi
Differential Revision: D45310066
fbshipit-source-id: 4199c9973d832cc07fd32b94f2dcbaa72f4d3920
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37115
X-link: https://github.com/facebook/yoga/pull/1267
This is an existing bitset enum in the API. Use the facility added in the last diff to add flag operators to it, to avoid the need for casting, and to make it clearer in the generated YGEnums.h that it is a bitset.
Reviewed By: rshest
Differential Revision: D45341504
fbshipit-source-id: 0b80588f3e2e167d4c1c722c6d6608408dd617ba
Summary:
X-link: https://github.com/facebook/yoga/pull/1256
Pull Request resolved: https://github.com/facebook/react-native/pull/37076
This adds a `YGErrata` bitset enum matching the API and guarantees described in https://github.com/facebook/yoga/issues/1247.
It is hooked up in later diffs. There are a couple of `YGExperimentalFeature` values that belong here, but keeping the current options means that the default `YGErrataNone` corresponds to existing default behavior, letting us stage the series of changes as:
1. Implement errata API
2. Update internal Yoga users we want to de-risk to `YGErrataClassic` or `YGErrataAll` (if setting `UseLegacyStretchBehaviour`)
3. Add new errata, changing Yoga defaults to be conformant, while letting internal apps opt into compatibility modes pending experimentation.
I also added a macro to let C++ users of Yoga perform bitwise operations on the enum without casting (already available for C users).
Reviewed By: rshest
Differential Revision: D45254098
fbshipit-source-id: d4b61271a8018f548f2d9d8c953db4b121a502d1
Summary:
X-link: https://github.com/facebook/litho/pull/940
X-link: https://github.com/facebook/yoga/pull/1252
Pull Request resolved: https://github.com/facebook/react-native/pull/36993
Fabric relies on the private C++ internals of Yoga. This creates a conundrum in the open source build due to how header creation in Cocoapods works.
1. The default mechanism of specifying public headers needs to include the private headers for them to be made usable by fabric (by default)
2. Cocoapods will roll up all of the public headers when importing a module
https://github.com/facebook/react-native/pull/33381 fixed the Fabric Cocoapods build which ran into this. React Native relies on FlipperKit which relies on YogaKit, which in turn finally imports the Yoga podspec. Because YogaKit may use Swift, we can only expose the public Yoga C ABI.
The first solution in that PR was to allow RN to access Yoga private headers, but this was changed to instead make all Yoga headers public, and to add ifdefs to all of them to no-op when included outside of a C++ environment.
Talking to Kudo, we should be able to change back to the earlier approach in the PR, to instead expose the private headers to only RN. This lets us avoid exposing headers that we ideally wouldn't be, and lets us avoid the messy ifdefs in every Yoga header.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D45139075
fbshipit-source-id: 99152986a578f7aac8324dffe0e18c42a38cc6a5
Summary:
I found a couple scenarios where preloads were issued too aggressively
1. During SSR, if you render a new stylesheet after the preamble flushed
it will flush a preload even if the resource was already preloaded
2. During Client render, if you call `ReactDOM.preload()` it will only
check if a preload exists in the Document before inserting a new one. It
should check for an underlying resource such as a stylesheet link or
script if the preload is for a recognized asset type
DiffTrain build for commit https://github.com/facebook/react/commit/ec5e9c2a75749b0a470b7148738cb85bbb035958.
Reviewed By: kassens
Differential Revision: D45295400
fbshipit-source-id: 6255a2c72d321fdef508d8805b3a5cb807c5c384
Summary:
## Summary
We added some post-processing in the build for RN in #26616 that broke
for users on Windows due to how line endings were handled to the regular
expression to insert some directives in the docblock. This fixes that
problem, reported in #26697 as well.
## How did you test this change?
Verified files are still built correctly on Mac/Linux. Will ask for help
to test on Windows.
DiffTrain build for commit https://github.com/facebook/react/commit/f87e97a0a67fa7cfd7e6f2ec985621c0e825cb23.
Changelog: [Internal]
Reviewed By: kassens
Differential Revision: D45279164
Pulled By: rubennorte
fbshipit-source-id: 5372e8357c99bb09704715b155cb85422ec7886a
Summary:
useMemoCache wasn't previously supported in the DevTools, so any attempt
to inspect a component using the hook would result in a
`dispatcher.useMemoCache is not a function (it is undefined)` error.
DiffTrain build for commit https://github.com/facebook/react/commit/25b99efe0c9c9d593c86829386c86740d409fa8c.
Changelog: [Internal]
Reviewed By: kassens
Differential Revision: D45278799
Pulled By: poteto
fbshipit-source-id: 613b28f9793574cef6fed04211f1fc2d0e600119
Summary:
This is enabled in the canary channels, but because it's relatively
untested, we'll disable it at Meta until they're ready to start trying
it out. It can change some behavior even if you don't intentionally
start using the API.
The reason it's not a dynamic flag is that it affects the external Fizz
runtime, which currently can't read flags at runtime.
DiffTrain build for commit https://github.com/facebook/react/commit/ed545ae3d3478cd82aa498494025cb3a15188e4c.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45278076
Pulled By: kassens
fbshipit-source-id: e9d56912b339384990edd31c4eba5f784fcef932
Summary:
We used to have Event Replaying for any kind of Discrete event where
we'd track any event after hydrateRoot and before the async code/data
has loaded in to hydrate the target. However, this didn't really work
out because code inside event handlers are expected to be able to
synchronously read the state of the world at the time they're invoked.
If we replay discrete events later, the mutable state around them like
selection or form state etc. may have changed.
This limitation doesn't apply to Client Actions:
- They're expected to be async functions that themselves work
asynchronously. They're conceptually also in the "navigation" events
that happen after the "submit" events so they're already not
synchronously even before the first `await`.
- They're expected to operate mostly on the FormData as input which we
can snapshot at the time of the event.
This PR adds a bit of inline script to the Fizz runtime (or external
runtime) to track any early submit events on the page - but only if the
action URL is our placeholder `javascript:` URL. We track a queue of
these on `document.$$reactFormReplay`. Then we replay them in order as
they get hydrated and we get a handle on the Client Action function.
I add the runtime to the `bootstrapScripts` phase in Fizz which is
really technically a little too late, because on a large page, it might
take a while to get to that script even if you have displayed the form.
However, that's also true for external runtime. So there's a very short
window we might miss an event but it's good enough and better than
risking blocking display on this script.
The main thing that makes the replaying difficult to reason about is
that we can have multiple instance of React using this same queue. This
would be very usual but you could have two different Reacts SSR:ing
different parts of the tree and using around the same version. We don't
have any coordinating ids for this. We could stash something on the form
perhaps but given our current structure it's more difficult to get to
the form instance in the commit phase and a naive solution wouldn't
preserve ordering between forms.
This solution isn't 100% guaranteed to preserve ordering between
different React instances neither but should be in order within one
instance which is the common case.
The hard part is that we don't know what instance something will belong
to until it hydrates. So to solve that I keep everything in the original
queue while we wait, so that ordering is preserved until we know which
instance it'll go into. I ended up doing a bunch of clever tricks to
make this work. These could use a lot more tests than I have right now.
Another thing that's tricky is that you can update the action before
it's replayed but we actually want to invoke the old action if that
happens. So we have to extract it even if we can't invoke it right now
just so we get the one that was there during hydration.
DiffTrain build for commit https://github.com/facebook/react/commit/bf449ee74e5e98af3d08c87bb6a9f22a021f3522.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45274088
Pulled By: kassens
fbshipit-source-id: 7e9d96731f0bc72ea5fa3ffc6ce3f4a1dfe80d90
Summary:
We currently use rollup to make an adhoc bundle from the file system
when we're testing an import of an external file.
This doesn't follow all the interception rules that we use in jest and
in our actual builds.
This switches to just using jest require() to load these. This means
that they effectively have to load into the global document so this only
works with global document tests which is all we have now anyway.
DiffTrain build for commit https://github.com/facebook/react/commit/64d6be71224c4241ba8f9d80747d53c0fd6224e7.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45272583
Pulled By: kassens
fbshipit-source-id: bc06743c0997464d0459ecaa1dfefb4d5dc783d0
Summary:
This wires up, but does not yet implement, an experimental hook called
useFormStatus. The hook is imported from React DOM, not React, because
it represents DOM-specific state — its return type includes FormData as
one of its fields. Other renderers that implement similar methods would
use their own renderer-specific types.
The API is prefixed and only available in the experimental channel.
It can only be used from client (browser, SSR) components, not Server
Components.
DiffTrain build for commit https://github.com/facebook/react/commit/919620b2935ca6bb8dfc96204a7cf8754c006240.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45255513
Pulled By: kassens
fbshipit-source-id: 9ba527201889fb25f130eaef385bbb9efa0b92c4
Summary:
This is consistent with what we used to do but not what we want to do.
DiffTrain build for commit https://github.com/facebook/react/commit/9ece58ebaa46f8b5e90a6ad71be4919e1dc9c563.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45253561
Pulled By: kassens
fbshipit-source-id: c739cff3a13d4ddc0569601a018a53ff5cc21c9b
Summary:
This PR proposes the removal of the ability to use remote JS debugging (a.k.a Chrome Debugging) from the DevMenu.
This change has been suggested previously on the contributor's Discord server and it is motivated by the fact that generally speaking, this feature does not work with the new architecture and most of the popular modules these days. The remote JS debugging is basically broken if you use Turbo Modules, Fabric, or sync native module calls.
People tend to assume that if something is part of the dev tools UI, it is going to work reliably. However, when it comes to remote debugging using JSC that's increasingly unlikely to be the case. Having it continue to exist as an option has created some confusion, or at least that's what we've seen within the Expo community.
### How to manually enable remote debugging
If your project depends on remote debugging, you can still enable it manually through the `NativeDevSettings`. E.g.
```jsx
import NativeDevSettings from 'react-native/Libraries/NativeModules/specs/NativeDevSettings';
export default function App() {
return (
<Button
title="Enable remote debugging"
onPress={() => NativeDevSettings.setIsDebuggingRemotely(!true)}
/>
);
}
```
### Next steps
Once this has been released and we are sure that this doesn't cause a lot of problems for people we can remove the ability entirely in a follow-up PR
## Changelog:
[General] [Removed] - Remove remote debugging from the dev menu
Pull Request resolved: https://github.com/facebook/react-native/pull/36754
Test Plan:
Locally run rn-tester using JSC on Android and iOS and open the dev menu
<table>
<tr><th>iOS</th><th>Android</th></tr>
<tr>
<td>
<img src="https://user-images.githubusercontent.com/11707729/229229079-03f98eed-0765-4cc8-b972-0c4ff041b611.png" />
</td>
<td>
<img src="https://user-images.githubusercontent.com/11707729/229229103-b57e8fd2-9aca-4780-8a8f-0fd5b2e53590.png" />
</td>
</tr>
</table>
Reviewed By: christophpurrer
Differential Revision: D45278061
Pulled By: huntie
fbshipit-source-id: 842c33102cd34730c14acece8e318cb263e5c9e5
Summary:
**NOTE**: This is a **BREAKING** change.
TLDR; Enforce minimum Node.js v16 in all RN packages.
This diff **Updates Node.js to v16** across all RN packages.
#### Context:
- For RN development and new project created; bump to node 16 was in https://github.com/facebook/react-native/pull/36217
- Recently `react-native-windows` also; updated node to v16, https://github.com/microsoft/react-native-windows/pull/11500
#### Changes:
- [BREAKING] Update Node.js to v16 across all RN packages under 'packages/' dir
## Changelog:
[GENERAL][BREAKING] - Update Node.js to v16 in all RN packages
Pull Request resolved: https://github.com/facebook/react-native/pull/37073
Test Plan: - `yarn lint && yarn flow && yarn test-ci` --> _should be green_
Reviewed By: cipolleschi
Differential Revision: D45306108
Pulled By: jacdebug
fbshipit-source-id: e3ba7d0151b86a6a0a3d63fb29c2bd887e1ac1e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37069
changelog: [internal]
To create initial C++ state, nothing beside props is needed from `ShadowNodeFragment` and this diff removes it.
It makes creation of state easier as we will no longer need to check if props are nullptr.
Reviewed By: mdvacca
Differential Revision: D45183692
fbshipit-source-id: 81ab8eb3c57f6ff64aaed7c5b395555dce6b60b2
Summary:
[Codegen 94] This PR attempts to extracts the logic of `extendsForProp` function from the following locations :
- `parsers/flow/components/extends.js`
- `parsers/typescript/components/props.js`
since they are the same and move the function to `parsers/parsers-commons.js` as requested on https://github.com/facebook/react-native/issues/34872
## Changelog:
[Internal] [Changed] - Move `extendsForProp` to parser-commons and update usages.
Pull Request resolved: https://github.com/facebook/react-native/pull/37052
Test Plan: Run `yarn jest react-native-codegen` and ensure CI is green
Reviewed By: cipolleschi
Differential Revision: D45225880
Pulled By: rshest
fbshipit-source-id: 45199089746d58d9e9494b28040b34c2a0eb31fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37103
Re backout the fix as there are some edge cases not handled properly internally.
## Changelog:
[iOS][Fixed] - Revert change in URL escaping
Reviewed By: javache, sammy-SC, rshest
Differential Revision: D45309232
fbshipit-source-id: d9f473d1f6409beb1069d9af7e649ee5b1b06d6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37083
`React.ElementConfig<a polymophic type>` will result in unpredictable behavior in Flow due to some types being unresolved. Since the type is already broken in most cases, I use $FlowFixMe as the type for those type arguments that are currently inferred as empty.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D44774275
fbshipit-source-id: bb950379102d41e729593af644d25670d9071ab4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37085
changelog: [internal]
Props and event emitter does not need to use JSI_EXPORT. Therefore we can remove include of jsi.h as well.
Reviewed By: cortinico, rshest
Differential Revision: D45274824
fbshipit-source-id: dd756258767f787e49d86dc31e18ce581f444362
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37087
changelog: [internal]
Surface props can change during life cycle of a surface. This was supported before the new renderer as well. AppRegistry has a corresponding method for this: `AppRegistry.setSurfaceProps`.
To add support for this, we just need to call into `UIManager::setSurfaceProps`.
Reviewed By: rshest
Differential Revision: D45272046
fbshipit-source-id: d138b57d5c83f554839b0db0e6721045b8dc81ef
Summary:
Insert temporary input node to polyfill submitter argument in FormData.
This works for buttons too and fixes a bug where the type attribute
wasn't reset.
I also exclude the submitter if it's a function action. This ensures
that we don't include the generated "name" when the action is a server
action. Conceptually that name doesn't exist.
DiffTrain build for commit https://github.com/facebook/react/commit/5e5342b10059bf90738a8d9171fcf0af9d9d5d51.
Changelog: [Internal]
Reviewed By: kassens
Differential Revision: D45240323
fbshipit-source-id: 3e9a8076942abdc24cf25b9dd9f130727ec3c0fd
Summary:
The Promise as a child case seems buggy. It ends up throwing the Promise
as fatal when used in Sync rendering.
DiffTrain build for commit https://github.com/facebook/react/commit/9c58a0b6475509f9124da578207aa0d3b7364035.
Changelog: [Internal]
Reviewed By: kassens
Differential Revision: D45239545
fbshipit-source-id: 1b377ec87bc3d1bbe07d7fd9f68235629adff764
Summary:
JSON.stringify isn't the right thing here. Luckily this doesn't look to have any security impact.
DiffTrain build for commit https://github.com/facebook/react/commit/9ee796430278c6f6e8acec4f54fd9be7f7868c0d.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45238390
fbshipit-source-id: 04e8ce20ae1b7a86fea538f032bc9dc34d41219c
Summary:
Fizz can emit whatever it wants for the SSR version of these fields when
it's a function action so they might not align with what is in the
previous props. Therefore we need to force them to update if we're
updating to a non-function where they might be relevant again.
DiffTrain build for commit https://github.com/facebook/react/commit/2fa632381839c8732dad9107b90911163b7f2b7a.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45238365
fbshipit-source-id: b75b4779bd3759362d69f96994ba781982f650a0
Summary:
Use the Blob constructor + append with filename instead of File
constructor. Node.js doesn't expose a global File constructor but does
support it in this form.
Queue fields until we get the 'end' event from the previous file. We
rely on previous files being available by the time a field is resolved.
However, since the 'end' event in Readable is fired after two
micro-tasks, these are not resolved in order.
I use a queue of the fields while we're still waiting on files to
finish. This still doesn't resolve files and fields in order relative to
each other but that doesn't matter for our usage.
DiffTrain build for commit https://github.com/facebook/react/commit/a21d1475ffd7225a463f2d0c0c9b732c8dd795eb.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45238341
fbshipit-source-id: d4ce8cf0201a231263c753989267e85f92908b9e
Summary:
Stacked on #26557
Supporting Float methods such as ReactDOM.preload() are challenging for
flight because it does not have an easy means to convey direct
executions in other environments. Because the flight wire format is a
JSON-like serialization that is expected to be rendered it currently
only describes renderable elements. We need a way to convey a function
invocation that gets run in the context of the client environment
whether that is Fizz or Fiber.
Fiber is somewhat straightforward because the HostDispatcher is always
active and we can just have the FlightClient dispatch the serialized
directive.
Fizz is much more challenging becaue the dispatcher is always scoped but
the specific request the dispatch belongs to is not readily available.
Environments that support AsyncLocalStorage (or in the future
AsyncContext) we will use this to be able to resolve directives in Fizz
to the appropriate Request. For other environments directives will be
elided. Right now this is pragmatic and non-breaking because all
directives are opportunistic and non-critical. If this changes in the
future we will need to reconsider how widespread support for async
context tracking is.
For Flight, if AsyncLocalStorage is available Float methods can be
called before and after await points and be expected to work. If
AsyncLocalStorage is not available float methods called in the sync
phase of a component render will be captured but anything after an await
point will be a noop. If a float call is dropped in this manner a DEV
warning should help you realize your code may need to be modified.
This PR also introduces a way for resources (Fizz) and hints (Flight) to
flush even if there is not active task being worked on. This will help
when Float methods are called in between async points within a function
execution but the task is blocked on the entire function finishing.
This PR also introduces deduping of Hints in Flight using the same
resource keys used in Fizz. This will help shrink payload sizes when the
same hint is attempted to emit over and over again
DiffTrain build for commit https://github.com/facebook/react/commit/36e4cbe2e918ec9c8a7abbfda28898c835361fb2.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45238328
fbshipit-source-id: 9b4233def44ffb47a6c4321e01f740586b89fe33
Summary:
In React DOM, we use HostContext to represent the namespace of whatever
is currently rendering — SVG, Math, or HTML. Because there is a fixed
set of possible values, we can switch this to be a number instead. My
motivation is that I want to start tracking additional information in
this type, and I want to pack all of it into a single number instead of
turning it into an object. For better performance.
(In dev, the host context type is already an object that includes
additional information, but that's dev so who cares.)
Technically, before this change, the host context could be any namespace
URI string, but any value other than SVG or Math was treated the same
way. Only SVG and Math have special behavior. So in the new structure,
there are three enum values: SVG, Math, or None, which represents the
HTML namespace as well as all other possible namespaces.
DiffTrain build for commit https://github.com/facebook/react/commit/8f42196892847a3dd1ab4c84eda0c8d52508ecf6.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45238312
fbshipit-source-id: acf5033808ce81c4854ce2b962b4e7f5140e8c0d
Summary:
Errors in form actions are now rethrown during render (#26689), so we
can handle them using an error boundary.
DiffTrain build for commit https://github.com/facebook/react/commit/967d46c76cf9f7f35cf659a6a47c9ad456c685a8.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45238297
fbshipit-source-id: e2db3d9a55671f9f72cf8966e75fe8010e708835
Summary:
This is stable and appears to build w/o problem. I don't see why we
should disallow it.
DiffTrain build for commit https://github.com/facebook/react/commit/5d7ebb4b784cb7e41e28653d89054cfe65637a93.
Changelog: [Internal]
Reviewed By: kassens
Differential Revision: D45238282
Pulled By: gaearon
fbshipit-source-id: c1189aaaf211349a0ad919eaca59dd8e8224e5ac
Summary:
This is the next step toward full support for async form actions.
Errors thrown inside form actions should cause the form to re-render and
throw the error so it can be captured by an error boundary. The behavior
is the same if the `<form />` had an internal useTransition hook, which
is pretty much exactly how we implement it, too.
The first time an action is called, the form's HostComponent is
"upgraded" to become stateful, by lazily mounting a list of hooks. The
rest of the implementation for function components can be shared.
Because the error handling behavior added in this commit is just using
useTransition under-the-hood, it also handles pending states, too.
However, this pending state can't be observed until we add a new hook
for that purpose. I'll add this next.
DiffTrain build for commit https://github.com/facebook/react/commit/fd3fb8e3c5d1c977f4bfa73d715143804c69d4b0.
Changelog: [Internal]
Reviewed By: poteto
Differential Revision: D45238266
Pulled By: kassens
fbshipit-source-id: 93fe8581172522f955278918bf97a0eb54daeeed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37070
This diff fixes an issue where codegened native commands are not able to be triggered, as codegen adds command handling to the delegate. This also brings how receiveCommand is handled into parity with how setProperties is called on the delegate.
Changelog:
[Fixed][Android] - Modify ViewManager.receiveCommand to call into delegate
Reviewed By: javache
Differential Revision: D45236213
fbshipit-source-id: 78f232f288f0a9c5f444e680a9cc49dca1d6af9b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36949
This change is a second attempt at fixing URL encoding and escaping that was already tried [here](https://github.com/facebook/react-native/commit/2b4e1f5ece7d160935b19d4862af8706a44cee59).
We had to roll it back due to some internal tests failing as it looks like Jest is manipulating the URL somehow.
We manage to replicate the issue, which occur when we pre-decode a url even if it is not partially encoded (we were too aggrsssive).
This fix ensure that we pre-decode the urls only if they present some `%` characters.
The problem here was that the e2e tests sends some urls with some `%` symbol which does not belongs to an escape sequence. For example: `anna://launch?height=25%`.
The previous code (v1) was trying to unescape this case. V2 fixes this.
This change should also fix#28508 for good.
## Changelog:
[iOS][Fixed] - Properly escape URLs
Reviewed By: mdvacca
Differential Revision: D45078923
fbshipit-source-id: 010a5c173784f8341a1a08bcbd06a6ad14299c75
Summary:
Cleans up some of the changes to UseWebDefaults that were made in the interest of moving it outside of YGConfig. It still exists in YGConfig, but also exists on the node.
We also assert on null config, or when someone tries to change UseWebDefaults after creating a node (since right now YGStyle does not know the difference between unset vs set explicitly to what would normally be default).
Removes a peculiar constructor which was added to avoid config setting.
Reviewed By: rshest
Differential Revision: D45133644
fbshipit-source-id: 2b5e2baeb826653133df9b1175cf5c194e342e3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37074
I am exploring ways of cleaning up the React Native Jest `setup.js` logic so that we can enable Flow and make it easier to maintain.
This does a few things:
- Create a new Jest test to verify that mocking works as expected (i.e. `jest.mock(X)` and `import ... from 'X'` does the right thing).
- Move the mock implementation for `NativeExceptionsManager` into a `__mocks__` directory that Jest can find automatically.
- Add `flow strict` and fill out the missing implementation details of the `NativeExceptionsManager` mock.
Changelog:
[General][Added] - Added missing methods to `NativeExceptionsManager` mock in Jest
Reviewed By: fkgozali
Differential Revision: D45244175
fbshipit-source-id: 0f4c8f873f93304509b80a13ed52e96265d10a42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37072
Deletes this call to `jest.setMock` for `ErrorUtils`. There is no such manual mock in `__mocks__` adjacent to `ErrorUtils` and this call does nothing.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D45234899
fbshipit-source-id: 51a41061761705e4f55120be0dbb77c6515e6a0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37046
Changes React Native's `jest/setup.js` so that globals (e.g. `__DEV__`, `performance`, `window`) are defined using `Object.defineProperties` instead of using object property assignment.
This makes the setup logic more resilient to Jest environments (e.g. [`jsdom`](https://github.com/jsdom/jsdom/blob/master/lib/jsdom/browser/Window.js#L422-L424)) where the globals are defined without a setter (i.e. `set` is undefined) or without `writable: true`, because object property assignment to such properties throws an error in strict mode.
Changelog:
[General][Changed] - Jest globals are now defined using `Object.defineProperties` instead of object property assignment
Reviewed By: motiz88
Differential Revision: D45202142
fbshipit-source-id: 5511e374ac6ba051ad0c224b902fb6f20960e9be
Pieter De Baets
Nick Gerleman
Nicola Corti
Samuel Susla
Lulu Wu
gnoff
rubennorte (Meta Employee)
poteto (Meta Employee)
acdlite
sebmarkbage
gabrieldonadel
Pranav Yadav
Siddarth Kumar
Riccardo Cipolleschi
Sam Zhou
sophiebits
gaearon (Meta Employee)
Luna Wei
Genki Kondo
tarunrajput
Tim Yung
kassens (Meta Employee)
