Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48905
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates `Libraries/StyleSheet/processColorArray.js` to use `export` syntax.
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updated View Config codegen (requires an MSDK bump).
- Updates the public API snapshot *(intented breaking change)*
Changelog:
[General][Breaking] - Files inside `Libraries/Text`, `Libraries/Share` and `Libraries/Settings` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: robhogan
Differential Revision: D68564304
fbshipit-source-id: 2fbd058be1a715cccfce4f2a68146118d8ac66ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48807
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates a handful of components in `Libraries/Components` to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Components` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: huntie
Differential Revision: D68436127
fbshipit-source-id: e3496fe69d66932dd4ed82f41d810f3ef1f850f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49003
Changelog: [internal]
I was adding a benchmark for rendering thousands of views and it was surprisingly fast, until I realized I wasn't wrapping the call to `root.render` in `runTask`, which means the benchmark wasn't really doing the rendering, only scheduling a microtask that was never executed.
This is a safety mechanism to prevent those mistakes.
Reviewed By: sammy-SC
Differential Revision: D68771170
fbshipit-source-id: 5bd8e6ba9e1168db2320572c99b3a01ebd6aeeed
Summary:
This is another attempt at fixing the Android HMR client for HTTPS proxied Metro instances. The previous one unintentionally [caused the following error](https://github.com/facebook/react-native/pull/48970#issuecomment-2617047184):
```
java.lang.AssertionError: Method overloading is unsupported: com.facebook.react.devsupport.HMRClient#setup
```
This PR removes the overloading, and only adds the `scheme` property as a parameter to the existing `.setup` method. Aligning with the exact behavior we have on iOS.
The alternative fix, which should NOT be backward breaking (if this is) - is to move this "infer the protocol from the bundle URL" to the JS side of the HMR client. Where we don't just always default to `http`, but instead default to `https IF port === 443, otherwise http`. It's a bit more hacky, but shouldn't cause any other issues. _**Ideally**_, we have the same working behavior on both Android and iOS without workarounds.
<details><summary>Alternative workaround</summary>
See [this change](https://github.com/facebook/react-native/compare/main...byCedric:react-native:patch-2).
<img width="1179" alt="image" src="https://github.com/user-attachments/assets/47c365bc-6df8-43e6-ad7d-5a667e350cd4" />
</details>
See full explanation on https://github.com/facebook/react-native/issues/48970
> We've noticed that the HMR on Android doesn't seem to be connecting when using a HTTPS-proxied Metro instance, where the proxy is hosted through Cloudflare. This is only an issue on Android - not iOS - and likely caused by the HMR Client not being set up properly on Android.
>
>- On Android, we run `.setup('android', <bundleEntryPath>, <proxiedMetroHost>, <proxiedMetroPort>, <hmrEnabled>)` in the [**react/devsupport/DevSupportManagerBase.java**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/DevSupportManagerBase.java#L689-L691) file.
>- On iOS, we run `[self.callableJSModules invokeModule:@"HMRClient" method:@"setup" withArgs:@[ RCTPlatformName, path, host, RCTNullIfNil(port), @(isHotLoadingEnabled), scheme ]];` in the [**React/CoreModules
/RCTDevSettings.mm**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/React/CoreModules/RCTDevSettings.mm#L488-L491) file.
>
>Notice how Android does not pass in the scheme/protocol of the bundle URL, while iOS actually does? Unfortunately, because the default protocol (`http`) mismatches on Android when using HTTPS proxies, we actually try to connect the HMR client over `http` instead of `https` - while still using port 443 - which is rejected by Cloudflare's infrastructure even before we can redirect or mitigate this issue. And the rejection is valid, as we basically try to connect on `http://<host>:443` (the source URL is `https`, so the port is infered as `443`).
>
>This change adds scheme propagation to Android, exactly like we do on iOS for the HMR Client.
## Changelog:
[ANDROID] [FIXED] Pass the bundle URL protocol when setting up HMR client on Android
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/48998
Test Plan:
See full explanation on https://github.com/facebook/react-native/issues/48970
> It's a little bit hard to test this out yourself, since you'd need a HTTPS-based proxy and reject HTTP connections for HTTPS/WSS Websocket requests.
>
>You can set this up through:
>- `bun create expo@latest ./test-app`
>- `cd ./test-app`
>- `touch .env`
>- Set `EXPO_PACKAGER_PROXY_URL=https://<proxied-metro-hostname>` in **.env**
>- Set `REACT_NATIVE_PACKAGER_HOSTNAME=<proxied-metro-hostname>` in **.env**
>- `bun run start`
>
>Setting both these envvars, the bundle URL in the manifest is set to `https://...` - which triggers this HMR issue on Android. You can validate the **.env** setup through:
>
>```bash
>curl "http://localhost:8081" -H "expo-platform: android" | jq .launchAsset.url
>```
>
>This should point the entry bundle URL towards the `EXPO_PACKAGER_PROXY_URL`.
Reviewed By: cortinico
Differential Revision: D68768351
Pulled By: javache
fbshipit-source-id: 49bf1dc60f11b2af6e57177141270632d62ab564
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48940
The PerformanceObserver (marks and measures) example clears it's output each time a new PerformanceObserver event fires, which makes it not particularly useful.
This change makes it so the output is only updated if a non-empty list of performance events is observed.
## Changelog
[Internal]
Reviewed By: rubennorte
Differential Revision: D68634361
fbshipit-source-id: 71b97e1c66aabd090cae63d55c8fa0a425d0c2f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48931
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling
## This diff
- Updates files in Libraries/Inspector to use `export` syntax
- Appends `.default` to requires of the changed files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Inspector` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: robhogan
Differential Revision: D68629285
fbshipit-source-id: ee0904ea5e8f9389aecfb197d05225c88137fb08
Summary:
Currently, the class OkHttpClientProvider is still in Java. Adding some tests before migrating it to Kotlin
## Changelog:
[INTERNAL] - Add OkHttpClientProvider tests
Pull Request resolved: https://github.com/facebook/react-native/pull/48958
Test Plan:
```bash
./gradlew :packages:react-native:ReactAndroid:test -Dtest.single=com.facebook.react.modules.network
```
Reviewed By: javache
Differential Revision: D68706173
Pulled By: cortinico
fbshipit-source-id: 7b4b1cbe17ff39d3775075682dcb8d253892e062
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48995
This change adds an extra parameter to the codegen script that allow our users to trigger codegen for Apps or for Libraries.
When running codegen for Apps, we have to generate some extra files that are not needed by the Libraries. This is causing issues to our library maintainers and this change will provide more flexibility in the DevX of libraries.
The default value is App, so if the new parameter is not passed, nothing will change in the current behavior.
## Changelog:
[iOS][Added] - Add the `source` parameter to generate-codegen-artifacts to avoid generating files not needed by libraries.
Reviewed By: cortinico
Differential Revision: D68765478
fbshipit-source-id: 8030b4472ad4f5058e58b1c91089de5122a4f60a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48934
This class is publicly exposed but effectively unused at all (neither internally, nor externally).
I'm removing it as this should not affect anyone.
Changelog:
[Android] [Breaking] - Removed `RuntimeConfig` class for Hermes which was unused.
Reviewed By: tdn120
Differential Revision: D68631945
fbshipit-source-id: 6a62ccda9e62f4bae650c11bc17a95efc8c88baf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48980
Changelog: [internal]
This will be properly removed soon, but disabling for now to avoid showing up in all PRs.
Reviewed By: cortinico
Differential Revision: D68719573
fbshipit-source-id: 6a631ba2556f1399d0ade52f19b79f5a3212e007
Summary:
Fixes https://github.com/facebook/react-native/issues/37801
This PR fixes the system bars visibility not being in sync as with the activity it is displayed on.
Here I am also taking into account the feedback given in [this PR](https://github.com/facebook/react-native/pull/36854) which was also aiming to address this issue. Unfortunately, I tried in multiple ways to get this to work by simply extending the whole system bars behaviour in the dialog with the activity system bars behaviour but found out that that solution won't work as we [currently clear the flag "FLAG_NOT_FOCUSABLE"](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/modal/ReactModalHostView.kt#L314) and unless we remove that line, extending the behaviour won't work. Removing that line is not an option as it would cause other side effects in the dialog itself.
With the above said, I ended up doing this in a more explicit way, by checking whether the status or navigation bars are hidden in the activity and then hiding then as well in the dialog or otherwise, similar as we are currently doing with the status bars appearance.
## Changelog:
[ANDROID] [FIXED] - Sync Modal system bars visibility with current activity
Pull Request resolved: https://github.com/facebook/react-native/pull/48516
Test Plan:
In order to test this, you need to trigger any method that hides or shows the system bars using `window.insetsController`. Here a very small example of it:
```kt
fun toggleSystemBarsVisibility(shouldHide: Boolean) {
val window = currentActivity?.window
val controller = window?.insetsController
if (shouldHide) {
controller?.hide(WindowInsets.Type.systemBars())
} else {
controller?.show(WindowInsets.Type.systemBars())
}
}
```
You can do this optionally from JS to make testing different cases easier. Below is a screen recording of how the solutions looks like:
<details>
<summary>Screen recording showcasing the solution in the test plan</summary>
https://github.com/user-attachments/assets/c497c1cb-5e65-4f31-98cc-aefd2d7b0339
</details>
Reviewed By: mdvacca, Abbondanzo
Differential Revision: D67906071
Pulled By: alanleedev
fbshipit-source-id: cbb2d15520d7729a9e9eafb5f5efb8d20d796c60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48982
We were missing a conversion to px on the `getOutline()` function of `CompositeBackgroundDrawable` which led to incorrect elevation prop rendering
Changelog: [Android][Fixed] - Elevation prop on android has incorrect border-radius
Reviewed By: NickGerleman
Differential Revision: D68724947
fbshipit-source-id: b3a7a4919bfd7c60fac7c3d6e3ba760e3f74d190
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48054
Web debugging should be fully removed as of recent, so lets remove some of the gunk that was powering it, and checks for that environment.
I did some string searches for the following:
* isAsyncDebugging
* debugRemotely
* isDebuggingRemotely
* isRemoteDebuggingAvailable
* WebSocketExecutor
* JavaJSExecutor
* ProxyJavaScriptExecutor
* RELOAD_APP_EXTRA_JS_PROXY
* getJSBundleURLForRemoteDebugging
* onReloadWithJSDebugger
* setRemoteJSDebugEnabled
* WebsocketJavaScriptExecutor
* createRemoteDebuggerBundleLoader
1. `expo-modules-core` exposes its own `isAsyncDebugging` by checking for `nativeCallSyncHook`, but does not depend on `DebugEnvironment`.
2. `expo-dev-menu` does read `isDebuggingRemotely` from `DevSettings`.
3. Realm does a check in Native using `objc_lookUpClass("RCTWebSocketExecutor")` but will gracefully handle `nil` if it does not exist
4. Some more usages (e.g. `onReloadWithJSDebugger`) in vendored packages of `expo-dev-launcher` for RN 0.74
I created an issue for Expo mentioning both here: https://github.com/expo/expo/issues/33371
Changelog:
[General][Breaking] - Remove some web debugging remnants
Reviewed By: huntie
Differential Revision: D66553934
fbshipit-source-id: deec382b1c8bda393fddb8682aa91b26afd9fbe3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48913
This brings us to parity with normalize-color, and is mostly similar to hsl, with the notable exception there is not a separate alpha variant, and only modern function syntax is supported. Again, I took the math from normalize-color, and sanity tested it against reference function provided by Color Spec.
I'm going to let that cap off color function support for now, and leave the rest as TODO.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68594471
fbshipit-source-id: 95702d576e068655d34e52a714d38e4fd718bbc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48912
The implementation of `hwb()` color functions added in https://github.com/facebook/react-native/pull/34600 is pretty flawed.
`hwb()` color functions do not allow comma delimited values. So most of the examples in the unit test here will fail to parse on web. Like `hsl()`, these should also allow numeric non-hue components (instead of just %), and angle values for hue (instead of just numbers), and this is also missing support for alpha values, though these are less dangerous compared to allowing and encouraging incorrect delimiters.
https://www.w3.org/TR/css-color-4/#the-hwb-notation
These were added for web compat, and the examples fail to parse on web, so I'm opting to just remove this incorrect support before implementing this more correctly in the Fabric CSS parser in next diff. I did not attempt to fix the other issues I discovered with the PR implementation in the last couple diffs, around mixing and matching syntax allowed in legacy/modern, along with allowing inconsistent delimiters.
Changelog:
[General][Breaking] - Remove incorrect hwb() syntax support from normalize-color
Reviewed By: lenaic
Differential Revision: D68591172
fbshipit-source-id: 36d670b096ae9fac4bc24938877ad083d4dd336a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48878
Creates a new `scheduleAnimatedCleanupInMicrotask` feature flag to experiment with deferring the `AnimatedProps` cleanup using the microtask queue.
This is different from the previous approach of deferring invocation of the completion callback, which impacted the timing of composite animations such as `Animated.parallel` and `Animated.sequence`, because we are deferring detaching the `AnimatedNode` graph instead. This will only impact the timing of completion callbacks as a result of invalidating `AnimatedProps` (either by passing in new `AnimatedValue` instances or unmounting the component).
This should minimally impact scheduling and have lower risk of user-visible behavior change because React already provides minimal guarantees around when updates are committed (and effects attached/detached).
This also enables us to significantly simplify the current convoluted dance we do to optimized around reference counting in the AnimatedNode graph.
Changelog:
[General][Changed] - When an Animated component is updated or unmounted, `AnimatedNode` instances will now detach in a microtask instead of synchronously in the commit phase of React. This will cause the completion callback of finished animations to execute after the commit phase instead of during it.
Reviewed By: rickhanlonii
Differential Revision: D68527096
fbshipit-source-id: 99346b8ddbf6a01725376c692b0351be679b9e89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48975
After cutting 0.78-stable, we need to bump the monorepo packages to `0.79.0-main`
## Changelog:
[Internal] - Bump monorepo packages to `0.79.0-main`
Reviewed By: cortinico, huntie
Differential Revision: D68715005
fbshipit-source-id: cb5abbf05e8638683687be8d61d66b3037111572
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48973
changelog: [internal]
This test is broken, let's disable it until it is fixed.
Reviewed By: javache
Differential Revision: D68709385
fbshipit-source-id: f61b287ad7ef921dd26fa290cc7a484d0b550091
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48968
I've noticed we have a lot of `public` and `protected` modifiers for classes that are actually `internal`.
Those are unnecessary as the class itself is `internal` and there is no way to extend the visibility of single fields.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D68707255
fbshipit-source-id: 5b93d01dceba1b5031ac608e58ec898c1a1eaf51
Summary:
We've noticed that the HMR on Android doesn't seem to be connecting when using a HTTPS-proxied Metro instance, where the proxy is hosted through Cloudflare. This is only an issue on Android - not iOS - and likely caused by the HMR Client not being set up properly on Android.
- On Android, we run `.setup('android', <bundleEntryPath>, <proxiedMetroHost>, <proxiedMetroPort>, <hmrEnabled>)` in the [**react/devsupport/DevSupportManagerBase.java**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/DevSupportManagerBase.java#L689-L691) file.
- On iOS, we run `[self.callableJSModules invokeModule:@"HMRClient" method:@"setup" withArgs:@[ RCTPlatformName, path, host, RCTNullIfNil(port), @(isHotLoadingEnabled), scheme ]];` in the [**React/CoreModules
/RCTDevSettings.mm**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/React/CoreModules/RCTDevSettings.mm#L488-L491) file.
Notice how Android does not pass in the scheme/protocol of the bundle URL, while iOS actually does? Unfortunately, because the default protocol (`http`) mismatches on Android when using HTTPS proxies, we actually try to connect the HMR client over `http` instead of `https` - which is rejected by Cloudflare's infrastructure even before we can redirect or mitigate this issue.
This change adds scheme propagation to Android, exactly like we do on iOS for the HMR Client.
## Changelog:
[ANDROID] [FIXED] Pass the bundle URL protocol when setting up HMR client on Android
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/48970
Test Plan: It's a little bit hard to test this out yourself, since you'd need a HTTPS-based proxy and reject HTTP connections for HTTPS/WSS Websocket requests.
Reviewed By: fabriziocucci
Differential Revision: D68711137
Pulled By: javache
fbshipit-source-id: 230c1c91c8189c0a109d20defe085966ac8f5721
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48922
Changelog: [internal]
This is a basic subclass of Event that allows setting custom values (as opposed to `Event` that is meant to be used as a superclass).
Reviewed By: yungsters
Differential Revision: D67804060
fbshipit-source-id: 9e140cc436f8e230f37275a74df23efd4841071b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48962
Changelog: [internal]
We moved away from private fields for `EventTarget` for performance, in favor of normal fields prefixed with underscore, but this would pollute the global scope when we make it extend `EventTarget`.
This refactors the implementation to use symbols for all properties to avoid that problem, leaving only `addEventListener` and `removeEventListener` as regular properties in the prototype.
Performance-wise this is neutral or a slight improvement according to the existing benchmark.
Reviewed By: javache
Differential Revision: D68672215
fbshipit-source-id: b329548efce6059ae2b9f33afa0719e057d3b8ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48918
Changelog: [internal]
Makes the constants read-only and accessible through `Event.prototype` as well.
Reviewed By: yungsters
Differential Revision: D67830012
fbshipit-source-id: 730622a642f08f532cebd4c183d859ccb2ca0641
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48426
Changelog: [internal]
This improves the performance of DOM `Event` interface implementation by migrating away from private fields.
Reviewed By: yungsters
Differential Revision: D67751821
fbshipit-source-id: e58e5a9cbb04e7d91cbc676ec7d1b00fff357e2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48427
Changelog: [internal]
The `ReactNativeElement` class was refactored for performance reasons, and the current implementation does **NOT** call `super()`, and it inlines the parent constructor instead.
When it eventually extends `EventTarget`, things won't work as expected because the existing `EventTarget` implementation has constructor dependencies.
This refactors the current implementation of `EventTarget` to eliminate those constructor side-effects, and eliminates the constructor altogether.
This breaks encapsulation, but it has some positive side-effects on performance:
1. Creating `EventTarget` instances is faster because it has no constructor logic.
2. Improves memory by not creating maps to hold the event listeners if no event listeners are ever added to the target (which is very common).
3. Improves the overall runtime performance of the methods in the class by migrating away from private methods (which are known to be slow on the babel transpiled version we're currently using).
Extra: it also simplifies making window/the global scope implement the EventTarget interface :)
## Benchmark results
Before:
| Latency average (ns) | Latency median (ns) | Samples | Task name | Throughput average (ops/s) | Throughput median (ops/s) |
| ---|--- |--- |--- |---|---|
| 8234.22 ± 0.27% | 8132.00 | 121445 | dispatchEvent, no bubbling, no listeners | 122323 ± 0.02% | 122971 |
| 9001.22 ± 0.41% | 8883.00 | 111097 | dispatchEvent, no bubbling, single listener | 111981 ± 0.02% | 112575 |
| 51777.94 ± 0.58% | 51247.00 | 19314 | dispatchEvent, no bubbling, multiple listeners | 19393 ± 0.04% | 19513 |
| 8256.65 ± 0.29% | 8152.00 | 121115 | dispatchEvent, bubbling, no listeners | 122031 ± 0.02% | 122669 |
| 9064.32 ± 0.44% | 8933.00 | 110323 | dispatchEvent, bubbling, single listener per target | 111265 ± 0.02% | 111944 |
| 51879.66 ± 0.27% | 51447.00 | 19276 | dispatchEvent, bubbling, multiple listeners per target | 19325 ± 0.04% | 19437 |
After:
| Latency average (ns) | Latency median (ns) | Samples | Task name | Throughput average (ops/s) | Throughput median (ops/s)|
| ---------------------|---------------------|---------|--------------------------------------------------------|----------------------------|--------------------------|
| 5664.62 ± 0.50% | 5588.00 | 176535 | dispatchEvent, no bubbling, no listeners | 178219 ± 0.02% | 178955 |
| 7232.86 ± 0.50% | 7131.00 | 138258 | dispatchEvent, no bubbling, single listener | 139540 ± 0.02% | 140233 |
| 50957.51 ± 0.71% | 50336.00 | 19625 | dispatchEvent, no bubbling, multiple listeners | 19751 ± 0.04% | 19866 |
| 5692.36 ± 0.50% | 5618.00 | 175675 | dispatchEvent, bubbling, no listeners | 177315 ± 0.02% | 177999 |
| 7277.82 ± 0.38% | 7181.00 | 137404 | dispatchEvent, bubbling, single listener per target | 138560 ± 0.02% | 139256 |
| 50493.64 ± 0.28% | 50105.00 | 19805 | dispatchEvent, bubbling, multiple listeners per target | 19855 ± 0.04% | 19958 |
Reviewed By: yungsters
Differential Revision: D67758408
fbshipit-source-id: f8da1788251c9e21377de5ab730875bcc7610361
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48431
Changelog: [internal]
Adds a regression test to make sure we implement the correct spec-compliant behavior for a possible bug in ~~the Web spec~~ __Chrome__: https://github.com/whatwg/dom/issues/1346
Edit: the bug is in the Chrome implementation, not in the spec.
Reviewed By: javache
Differential Revision: D67758702
fbshipit-source-id: ecaeacac3bce286e692880f05d70297ba0c2c736
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48429
Changelog: [internal]
This implements a (mostly) spec-compliant version of the [`Event`](https://dom.spec.whatwg.org/#interface-event) and [`EventTarget`](https://dom.spec.whatwg.org/#interface-eventtarget) Web interfaces.
It does not implement legacy methods in either of the interfaces, and ignores the parts of the spec that are related to Web-specific quirks (shadow roots, re-mapping of animation events with webkit prefixes, etc.).
IMPORTANT: This only creates the interfaces and does not expose them externally yet (no `Event` or `EventTarget` in the global scope).
Reviewed By: yungsters
Differential Revision: D67738145
fbshipit-source-id: c86db29821552cc1a1b6e1023cc3a21ae55febd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48965
Running codegen should not be a Cocoapods responsibilities, but it should be something that runs before Cocoapods to ensure that the code is already in the right place.
This change moves the invocation of Codegen to the react-native's core-cli-utils so that frameworks can integrate better with it.
It should also make it easier to migrate away from Cocoapods.
## Changelog:
[iOS][Changed] - Invoke Codegen as part of the Core-cli-utils package
Reviewed By: cortinico
Differential Revision: D68706136
fbshipit-source-id: 548c9ffad62bc561fcc948babaf75de5dad82f86
Iwo Plaza
Ruslan Lesiutin
Dawid Małecki
Rubén Norte
Cedric van Putten
Alex Hunt
Eric Rozell
Mateo Guzmán
VidocqH
Riccardo Cipolleschi
Nicola Corti
CHOIMINSEOK
zhongwuzw
Dmitry Rykun
Jorge Cabiedes Acosta
Pieter De Baets
Nick Gerleman
Christoph Purrer
Tim Yung
Samuel Susla
Håkon Knutzen
Thomas Nardone
Matthew Horan