Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38079
This diff fixes the
```
out-of-line definition of constexpr static data member is redundant in C++17 and is deprecated [-Werror,-Wdeprecated]
```
error in `RAMBundleRegistry`
## Changelog:
[internal] - Fix Xcode 15 namespace build errors in `RAMBundleRegistry`.
Reviewed By: javache, cipolleschi
Differential Revision: D46988689
fbshipit-source-id: 5dc34b0f7d6fb266bc379b3639244bf69505aa88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37835
Chrome Dev Tools doesn't correctly display grouped console logs (i.e. console output between a `console.group` and `console.groupEnd`) when timestamps are all zero.
Populate the timestamp field so grouping functions as expected.
Changelog: [General] [Fixed] Fix timestamps and grouped display of console messages within in a `console.group`
Reviewed By: fbmal7
Differential Revision: D46605659
fbshipit-source-id: c5821bfb4807c7f0ce28b7bb95ea08de29caf8a2
Summary:
I added the contentType parameter to Blob.slice like it's in the MDN Web docs.
This PR fixes https://github.com/facebook/react-native/issues/38058
When i slice a Blob for chunked uploads with react native i lost the content type, e.g. "image/jpeg", so the server doesn't know what kind of file he gets. In the docs of MDN the slice method was described with a third contentType parameter which was missing in Metas implementation.
## Changelog:
[GENERAL] [ADDED] added a third parameter "contentType" to method slice of class Blob.
<!-- 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/38078
Test Plan:
I tested it with the unit-tests:
yarn run test Blob-test.js
yarn run v1.22.19
$ jest Blob-test.js
PASS packages/react-native/Libraries/Blob/__tests__/Blob-test.js
Blob
✓ should create empty blob (5 ms)
✓ should create blob from other blobs and strings
✓ should slice a blob (1 ms)
✓ should slice a blob and sets a contentType
✓ should close a blob (4 ms)
My added unit test results "✓ should slice a blob and sets a contentType".
Reviewed By: hoxyq
Differential Revision: D47057162
Pulled By: blakef
fbshipit-source-id: 0931b0b828f81b9b90562ffd51d4111c81034ffc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38075
changelog: [internal]
`SharedFunction<>` is created with nullptr for its internal `std::function`. If called after created with default constructor, it crashes app. It also does not have API to check if its internal function is not nullptr.
With image cancelation, there is a race between when native component calls `imageRequest.cancel()` and when cancelation function is set in `RCTImageManager`.
To fix this, this diff adds a nullptr check inside SharedFunction. So it is always safe to call.
Reviewed By: javache
Differential Revision: D47022957
fbshipit-source-id: 0a04a87cd1ffe6bf3ca2fded38f689f06cc92ca9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38089
This change add a warning if a component is registered in both the New Renderer and in the Interop layer.
This can help users migrating their components once the library has been migrated.
## Changelog:
[iOS][Added] - Add warning to help users migrate away from the interop layer.
Reviewed By: cortinico
Differential Revision: D47053556
fbshipit-source-id: cc2ba09db16aaa370947a77173b6ea6a0acfa519
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38093
In [this issue](https://github.com/facebook/react-native/issues/37905), the community detected a strict assumption in the interop layer for which, given a component `XXXView`, its ViewManager must be called `RCTXXXViewManager`.
That's not the case for some components, for example, `BVLinearGradient`, which View manager is `BVLinearGradientManager` and not `RCTBVLinearGradientManager`.
This diff adds a secondary lookup logic:
1. We look for the `RCTXXXViewManager`.
2. If not found, we look for `XXXViewManager`.
We will assess whether to generalize this logic once and for all or to expand other lookup cases on an example/failure basis as it's not a goal to have a 100% accurate interop layer. The Goal is to cover most use cases.
## Changelog:
[iOS][Added] - Allow to lookup for ViewManager without the RCT prefix in the Interop Layer
Reviewed By: sammy-SC
Differential Revision: D47055969
fbshipit-source-id: 1d31f3f4bc6f1f543edbd157ce04ad9daf23dbc6
Summary:
See: http://blog.nparashuram.com/2019/10/debugging-react-native-ios-apps-with.html
When using direct debugging with JavaScriptCore, Safari Web Inspector doesn't pick up the source map over the network. Instead, as far as I can tell, it expects you to pass the source URL at the time you load your bundle: https://developer.apple.com/documentation/javascriptcore/jscontext/1451384-evaluatescript?language=objc . This leads to a very sub-par developer experience debugging the JSbundle directly. It will however, pick up an inline source map. Therefore, let's add a way to have React Native tell metro to request an inline source map.
I did this by modifying `RCTBundleURLProvider` to have a new query parameter for `inlineSourceMap`, and set to true by default for JSC.
## Changelog:
[IOS] [ADDED] - Added support to inline the source map via RCTBundleURLProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/37878
Test Plan:
I can put a breakpoint in RNTester, via Safari Web Inspector, in human readable code :D
<img width="1728" alt="Screenshot 2023-06-14 at 4 09 03 AM" src="https://github.com/facebook/react-native/assets/6722175/055277fa-d887-4566-9dc6-3ea07a1a60b0">
Reviewed By: motiz88
Differential Revision: D46855418
Pulled By: huntie
fbshipit-source-id: 2134cdbcd0a3e81052d26ed75f83601ae4ddecfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38076
Changelog: [Android][Breaking] Default to ignoring cached Metro bundle when offline
Currently, on Android, if we can't find a Metro server at startup, we try to run the last cached Metro bundle instead of the prebuilt bundle asset in the APK. This is inconsistent with the iOS behaviour, and breaks bundle features that rely on a runtime Metro connection to work correctly - such as HTTP asset loading and lazy bundling (which is the default as of D43600054).
Here we change the default for `ReactInstanceManager`'s `useFallbackBundle` property to `true`, which has the effect of ignoring the cached Metro bundle.
This is a **breaking change** because some developers' workflows might depend on performing a build while connected to a Metro instance, then using the app standalone without access to Metro. This may be exacerbated by the fact that the RN Gradle plugin [skips including a prebuilt bundle in debug builds](https://github.com/facebook/react-native/blob/eaafc260c14674bfbf7ce3a647404c70d546854f/packages/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/TaskConfiguration.kt#L54). This means that, out of the box, debug builds of Android RN apps will only start if connected to Metro. (Contrast with iOS where a "fallback" bundle *is* included out of the box.)
We recommend that developers always connect to a Metro server in development, and perform a release build for standalone use. Alternatively, developers can use `ReactInstanceManager.setUseFallbackBundle(false)` to restore the old behaviour.
Reviewed By: javache, luluwu2032
Differential Revision: D47021957
fbshipit-source-id: 43ce8078ec95f5d65790b56f4d3dfa4f6a4e9023
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38009
This diff reduces dependency of BridgelessReactContext to package only, this way we are removing BridgelessReactContext out of the Stable API, and app developers won't be able to access it directly.
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D46410796
fbshipit-source-id: e887faecdc62b3109bdc7c9616821338e7b66136
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37981
This diff introduces a the test ReactHost.testReload() to verify that reloading of react host works as expected
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D46813814
fbshipit-source-id: 59e23e2f296c81b7ca3decb81e1f53b5871bbff4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37980
In this diff I'm fixing the ReactHostTest.testPreload test that was broken due to concurrency issues between a task submited in bolts that interacted with the UIThread and RobolectricTestRunner blocking on the UI Thread.
I created an utility method to wait for completion of the task
see: https://robolectric.org/blog/2019/06/04/paused-looper/
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D46812085
fbshipit-source-id: 1a8f9de8ef22071e708280720d0384b1562dd56b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37982
ReactHostTest was disabled as part of D44729814, I'm re-enabling it as they pass locally
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D46806278
fbshipit-source-id: 7fa530b4ea5bcacb72253218eded6f9a96e4cdf9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38070
changelog:
[iOS][fix]: Correctly invalidate NSTextStorage when non layout related props change
Fixes: https://github.com/facebook/react-native/issues/37944
Problem:
NSTextStorage was not invalidated if non-layout props were changed. So for example 'color' dynamically changed, it wouldn't get invalidated and font of incorrect color would be rendered on screen.
Reviewed By: javache
Differential Revision: D47019250
fbshipit-source-id: bd5d8e6ee4493791dedbafc64a8b8df48a5681e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38042
Follow-up cleanup from D34379950, now that fbjni has been upgraded. Also synced the internal and external build flags.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D46975010
fbshipit-source-id: 7d2fd215b68bcebbf259e23923fb3fec1ca09f8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38063
I'm cleaning up the ReactApplication code a bit to use a property with custom setter
Moreover I'm also removing the JvmDefault annotation as that is unnecessary as we use
the `-Xjvm-default=all`, plus is deprecated and will be removed soon by Kotlin.
Changelog:
[Internal] [Changed] - Remove unnecessary JvmDefault
Reviewed By: javache
Differential Revision: D47016727
fbshipit-source-id: 8ab1325c6a9d1db2f8290fb89b766e3d93674b0d
Summary:
`testID` which is a valid prop for `<Text>` is also found in the types for `TextStyle`. This pull request removes said property from the styles.
## Changelog:
General Fixed - Remove testID from TextStyle types
Pull Request resolved: https://github.com/facebook/react-native/pull/38053
Test Plan:
```tsx
const styles = StyleSheet.create({
view: {
testID: 'should-error-in-typescript-but-does-not'
}
})
```
`TextStyle` is used to type the `StyleSheet` along with `ViewStyle` and `ImageStyle` which do not contain `testID`.
```tsx
const MyText = <Text testID="already-typed-fine">Hello</Text>
```
`testID` is used to identify components with the mentioned prop. This works for `Text` and will continue to do so, `TextProps` has `testID` added specifically. When using `getByTestId` in jest adding testID to the style already has no effect.
When adding `testID` to a style a warning will already be shown in development: Warning: Failed prop type: Invalid props.style key `testID` supplied to `Text`.
Reviewed By: javache
Differential Revision: D47006787
Pulled By: NickGerleman
fbshipit-source-id: 6993579ee9c173677594f8f3aea499ac8d8ab232
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38038
Changelog: [Internal]
Also un-deprecating the constructors of other Guarded runnables, as an extension of D46685374
Reviewed By: rshest
Differential Revision: D46971220
fbshipit-source-id: cf982f7efe9bcd1ddb7285aa35d836b7c57c4d24
Summary:
When a new version of `fbjni` is released, we can simplify `getName` and `getMessage` calls on throwables.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [CHANGED] - Use new `getCanonicalName` and `getMessage` methods exposed by `fbjni`
Pull Request resolved: https://github.com/facebook/react-native/pull/37879
Test Plan: https://github.com/facebookincubator/fbjni/pull/78
Reviewed By: cortinico
Differential Revision: D46966561
Pulled By: javache
fbshipit-source-id: f30720a30146cf8fe5125336435a1512063c253d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38029
# Changelog:
[Internal] -
A trivial fix - I was looking into some deeper issues with `Image.prefetch`, noticed that code docs were copypasted and incorrect.
Reviewed By: cipolleschi
Differential Revision: D46959350
fbshipit-source-id: 4e4196f9399d91402d9b206c20f2bbd0d1d0eb2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37863
This creates 2 examples for IntersectionObserver in RNTester:
* The first example is just a copy of the example provided by MDN in the documentation page for `IntersectionObserver` (https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API). This example is useful to show how React Native behaves the same way with the same code.
* The second example is a "stress test" for the API: a screen with 500 simultaneous node being observed at the same time with different observers. As we compute the intersections after scroll (after "mounting" the state update with the updated scroll position) in the main thread, this highlights a possible impact on scroll performance.
IntersectionObserver isn't yet enabled by default, so no need to add a changelog entry about this. We'll add one when the API becomes generally available.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D45736845
fbshipit-source-id: 40b6bce39f90e04653504b1033a4edfaa65e93ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37853
This adds a basic implementation of `IntersectionObserver`. This will not be available yet and is only compatible with the new React Native architecture. This shouldn't show up in the changelog until we're ready to enable this in some form.
Changelog: [Internal]
## Context
This implements a basic version of the `IntersectionObserver` API (as defined on the Web) for React Native.
The motivation for this is supporting several use cases that are not possible in React Native at the moment, most importantly:
* Tracking paint times for elements in the screen.
* Tracking precise visibility of elements in the screen outside the context of a `VirtualizedList` (with an even better precision and control).
## Implementation details
This API is implemented as a native module that registers a mount hook in Fabric. Whenever there's a mount (an update to the UI of the host platform) we check for intersections in the shadow tree. The shadow tree contains information about the representation of the UI in a given time (including scroll position), which we use as source of truth for this in a cross-platform fashion. We rely on the fact that scroll position is updated regularly in the shadow tree to provide an up-to-date view into the UI.
**This implementation is completely cross-platform.** The only platform-specific part is the report of mounts in mount hooks from the host platform to Fabric.
This API uses a centralized entity in JS and native to handle registration of observers and dispatch of notifications. The dispatch the notifications for all observers in the same callback so we can easily change the sequencing of events easily (for example, we can change this to use microtasks when they're available in RN).
## Known limitations
* Timestamps are generally accurate for paint (as we report mounts right after they happen in the host platform), but **state updates (like scroll) are reported with a slight delay**.
* In regular rendering, we first update the shadow tree and then mount it (paint), which is generally precise. In state updates, the UI is updated first and then the shadow tree is updated. In this case, we're not correctly reporting the timestamp of the scroll event (which we should be using) but the timestamp of when the update is processed. We'll fix this in a following diff.
* The IntersectionObserver API has a concept of initial notification. This is a mechanism to report the initial state of an observed target. If we start observing a target when it's added to the tree but before it's painted, this initial notification is supposed to provide initial paint time (which is important for performance measurements). This implements some logic to handle that correctly (we check if there is a pending transaction) but it's currently unreliable:
* React Native does not currently block paint on microtasks or layout effects, so setting up an observer in these stages could have race conditions with actual mount. If mount happens before the observation is started, the initial notification doesn't report initial time but observation time. If mount happens after, the initial notification should be fine (except in some cases on Android, see the next point).
* On Android, we have a push model to send mutations to the host platform, we means we consume transactions after commit, not immediately before mount. This breaks this logic and we need to figure out a solution in a following diff.
----
Reviewed By: sammy-SC, rshest
Differential Revision: D45278720
fbshipit-source-id: de350388c6325128f1cf73328779a9d3577a258a
Summary:
Follow up to:
- https://github.com/facebook/react-native/pull/37960
## Changelog:
[INTERNAL] - Update NativeAnimatedNodeTraversalTest to be more idiomatic
Pull Request resolved: https://github.com/facebook/react-native/pull/37970
Test Plan: Will run on CI
Reviewed By: javache, cipolleschi
Differential Revision: D46853581
Pulled By: cortinico
fbshipit-source-id: 73776493163413b045482344b7b1be0635f5aa25