Summary:
Because we use the `PromiseWrapper` struct, we need to explicitly manage its lifecycle to ensure that it doesn't clear before the promise methods are invoked by the ObjC Runtime. This `PromiseWrapper` struct is unnecessary. We could just not have it and create the CallbackWrappers for resolve and reject within the `createPromise` function. Therefore, I moved all the logic from `PromiseWrapper` to the `RCTTurboModule::createPromise` function.
In the next diff, I'm going to keep a track of all the CallbackWrappers we create in instances of RCTTurboModule, and `destroy()` them in the destructor of RCTTurboModule. This should make sure that all `jsi::Function`s are released before we delete the `jsi::Runtime`, which should prevent Marketplace from crashing when we hit CMD + R. See: https://fb.workplace.com/groups/rn.support/permalink/2761112713937326/.
Reviewed By: fkgozali
Differential Revision: D17208729
fbshipit-source-id: ce80c9c01088f0e3dc47c7c29397b7a197d699ce
Summary:
Removed unused file YogaNodeJNIPhantomRefs.java as this was causing oss build failures because of an import.
````:yoga:compileDebugJavaWithJavac/home/travis/build/facebook/yoga/java/com/facebook/yoga/YogaNodeJNIPhantomRefs.java:9: error: package com.facebook.jni does not exist
import com.facebook.jni.DestructorThread;
^
/home/travis/build/facebook/yoga/java/com/facebook/yoga/YogaNodeJNIPhantomRefs.java:30: error: package DestructorThread does not exist
new DestructorThread.Destructor(node) {
^
2 errors
FAILED
Reviewed By: pasqualeanatriello
Differential Revision: D17257330
fbshipit-source-id: 98b0c5d5b7dcd94bee559b58194c13b07f47723d
Summary:
Migrates ARTSurfaceView to Fabric,
This diff only migrates the necessary minimum for RCTVideo component to work. Other ART components are
ARTNode, ARTGroup, ARTRenderable, ARTShape and ARTText.
Reviewed By: mdvacca
Differential Revision: D17181298
fbshipit-source-id: c2656bbcaefde25e37a9e05a64d2691bc2343b67
Summary:
Fix a simple error where `types[index]` was being accessed after it was cleared, instead of before.
## Changelog
[iOS] [Fixed] - never call deleteTimer for setImmediate and requestIdleCallback
Pull Request resolved: https://github.com/facebook/react-native/pull/26113
Test Plan: None
Differential Revision: D17314489
Pulled By: cpojer
fbshipit-source-id: 74715f0f7cc2d5cee3b97a67313c5e96e9d6c555
Summary:
iOS13 status bar has now 3 styles
UIStatusBarStyleDefault, UIStatusBarStyleLightContent, UIStatusBarStyleDarkContent
UIStatusBarStyleDefault now acts as an automatic style which will set it’s value dynamically based on the the userinterfacestyle(One of the traits) of the viewcontroller that controls the status bar appearance.
## Changelog
[iOS] [Fixed] - iOS13 new status bar style UIStatusBarStyleDarkContent
Pull Request resolved: https://github.com/facebook/react-native/pull/26294
Differential Revision: D17314054
Pulled By: cpojer
fbshipit-source-id: ea109e729bb551dff314bc00a056860a8febb0e9
Summary:
Fix a bug where `CACurrentMediaTime` was being used to calculate the elapsed frame time, even though it's not comparable to `NSDate.timeIntervalSince1970` time.
## Changelog
[iOS] [Fixed] - callIdleCallbacks deadline calculation
Pull Request resolved: https://github.com/facebook/react-native/pull/26114
Test Plan: None
Differential Revision: D17314125
Pulled By: cpojer
fbshipit-source-id: 5061a3954371df2134f0c77dc260228668abe747
Summary:
When doing RN init from scratch for 0.61, I noticed pod install was failing. This was because "Yoga.podspec" was mis-spelled to "yoga.podspec" in the yoga ReactCommon folder. Thus, `pod install` was failing
```
[!] No podspec found for `Yoga` in `../node_modules/react-native/ReactCommon/yoga
```
## Changelog
[iOS] [Fixed] - Fix Yoga.podspec case sensitivity
Pull Request resolved: https://github.com/facebook/react-native/pull/26360
Test Plan: `pod install` now runs successfully with a clean build of master.
Differential Revision: D17314027
Pulled By: cpojer
fbshipit-source-id: 8db2ac4dd9295afcc0e074c842dcda71b7b3b668
Summary:
This PR introduces the `EventSource` web standard as a first-class networking feature in React Native. In the discussion we had in February at https://github.com/react-native-community/discussions-and-proposals/issues/99, cpojer indicated that the RN maintainers would be willing to accept a PR to offer this functionality.
The linked discussion goes into detail about why this change must happen in React Native Core as opposed to a community library, but the tl;dr is that `XmlHttpRequest` doesn't let you do streaming in a resource-efficient way, since it holds onto the entire response buffer until the request is complete. When processing a stream that might last for a long time, that's not ideal since there might be a lot of data in that buffer that is now useless to maintain.
For more information about EventSource and server-sent events, check out these links:
* [EventSource on MDN](https://developer.mozilla.org/en-US/docs/Web/API/EventSource)
* [Using server-sent events on MDN](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events)
* [WHATWG spec for server-sent events](https://html.spec.whatwg.org/multipage/server-sent-events.html)
I've tried as best as I can to satisfy the linked specification so that this is as standard as possible.
One of the projects I maintain has an ideal use case for this feature. The SDK for MongoDB Stitch (a backend-as-a-service for the MongoDB database) has the ability to open a "change stream" to watch for changes that happen on a database. However, in our JavaScript SDK, this feature depends on `EventSource`, because the backend service implements the one-way streaming protocol with server-sent events. We know there is demand for this feature because users have requested it: https://github.com/mongodb/stitch-js-sdk/issues/209.
If this PR will be accepted, I am happy to update the `Networking` documentation at https://facebook.github.io/react-native/docs/network
## Changelog
[JavaScript] [Added] Implements the `EventSource` web standard in `Libraries/Networking`
[JavaScript] [Added] Exposes the `EventSource` implementation in `Libraries/Core/setUpXHR.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/25718
Test Plan:
To test the `EventSource` implementation, I added a comprehensive set of unit tests that cover the basic functionality, as well as edge cases that are laid out in the spec. See `EventSource-test.js` for the cases that the tests handles. For convenience, I've also included the test descriptions as produced by the `jest` test output here.
```
PASS Libraries/Network/__tests__/EventSource-test.js
EventSource
✓ should pass along the correct request parameters (527ms)
✓ should transition readyState correctly for successful requests (4ms)
✓ should call onerror function when server responds with an HTTP error (2ms)
✓ should call onerror on non event-stream responses (1ms)
✓ should call onerror function when request times out (1ms)
✓ should call onerror if connection cannot be established (1ms)
✓ should call onopen function when stream is opened (1ms)
✓ should follow HTTP redirects (2ms)
✓ should call onmessage when receiving an unnamed event (2ms)
✓ should handle events with multiple lines of data (1ms)
✓ should call appropriate handler when receiving a named event (1ms)
✓ should receive multiple events (1ms)
✓ should handle messages sent in separate chunks (1ms)
✓ should forward server-sent errors
✓ should ignore comment lines (1ms)
✓ should properly set lastEventId based on server message (1ms)
✓ should properly set reconnect interval based on server message
✓ should handle messages with non-ASCII characters (1ms)
✓ should properly pass along withCredentials option (3ms)
✓ should properly pass along extra headers (1ms)
✓ should properly pass along configured lastEventId (2ms)
✓ should reconnect gracefully and properly pass lastEventId (9ms)
✓ should stop attempting to reconnect after five failed attempts (2ms)
```
As a manual E2E test, I also added streaming support to the Stitch React Native SDK, and tested it with my React Native EventSource implementation, and confirmed that our `EventSource`-based streaming implementation worked with this `EventSource` implementation.
* Source code for E2E app test: https://gist.github.com/adamchel/6db456c1a851ed7dd20b54f6db3a6759
* PR for streaming support on our React Native SDK: https://github.com/mongodb/stitch-js-sdk/pull/294
* Very brief video demonstrating E2E functionality: https://youtu.be/-OoIpkAxmcw
Differential Revision: D17283890
Pulled By: cpojer
fbshipit-source-id: 0e9e079bdb2d795dd0b6fa8a9a9fa1e840245a51
Summary: Previously, the `_scheduler` method in `RCTSurfacePresenter` was implemented as a lazy getter. The only problem with that is that Scheduler instance might be (re)created in the middle of the hot-reloading process (e.g. external request to relayout some Surface might trigger that). Since it does not make any sense to create an empty Scheduler during the reloading process, now the Scheduler creation only happens in constructor and right after the VM is reloaded.
Reviewed By: JoshuaGross
Differential Revision: D17299441
fbshipit-source-id: 273451bbb03e8cdf532131adfdf3bc60c34e997e
Summary:
Remove cxx from iOS project, because we have the corresponding implementation in iOS. Otherwise, it would break the logical handling of iOS part.
## Changelog
[iOS] [Fixed] - Remove cxx from iOS project
Pull Request resolved: https://github.com/facebook/react-native/pull/25392
Test Plan: Fabric enabled Tester can work like loading image.
Reviewed By: mdvacca
Differential Revision: D17285463
Pulled By: shergin
fbshipit-source-id: b414406578dcce51f3b54fd06941225efc560e7f
Summary:
Bump eslint-plugin-relay version to 1.3.11 on fbsource
`js1 upgrade dependency --package eslint-plugin-relay@1.3.11`
And enable lint rule for checking second argument on relay hooks
Reviewed By: jstejada
Differential Revision: D17261273
fbshipit-source-id: 1d898535079ba5b7a7ee0d179e6e68f6a5e2bd46
Summary:
I noticed two syntax errors in code gen while using it. This fixes them.
One of them is missing semicolon, the other one is name mismatch.
Reviewed By: TheSavior
Differential Revision: D17226188
fbshipit-source-id: 880dbf4c9b22efa7754de6413d01c04e7abbe411
Summary:
This bypasses setNativeProps and causes all animations to go through the mounting layer in Fabric only. Resubmit of D17201061
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D17246910
fbshipit-source-id: 88effbaa9b04b277b07cd14427c59e464549ad4a
Summary:
The code is moved from the destructor a separate method that we now call in the Scheduler::stopSurface.
That makes the code more readable and resilient to possible races and ownership-related changes.
Reviewed By: JoshuaGross
Differential Revision: D17272294
fbshipit-source-id: 948d76d074577beb3dda6defdf09261b5c8abb98
Summary:
MountingCoordinator is a borderline between Core and Mounting. Some of Core design constraints are impossible/impractical to enforce on Mounting layer, so we have to handle all of those cases in `MountingCoordinator`.
One of the constrains is that all ShadowNodes implicitly depend on associated ComponentDescriptor instances without retaining them (retaining is expensive and creates a retain cycle).
The problem is that the Mounting layer can call `MountingCoordinator::pull()` at any moment (even after the whole Core is already destroyed). To prevent this, the owner of a `MountingCoordinator` on the Core side calls `revoke()` right before being deallocated (right before the moment the owner cannot guarantee the constraint).
Reviewed By: JoshuaGross
Differential Revision: D17272295
fbshipit-source-id: ba8b02eab8f84cce68aa65c1ad36950cd2498049
Summary:
Collapse many Remove/Delete mount items into a single batched item.
Since a delete is always preceded by a remove mountitem, we can batch these into one instruction. Since deletes tend to come in large blocks, it might make sense to batch many into a single instruction.
Reviewed By: mdvacca
Differential Revision: D17254631
fbshipit-source-id: abfd54cdb0bbb9a4c0880ec8e8bbd681367aecd4
Summary: Retain reference to reactNativeConfig to allow feature checks within core. This also rearranges the members of Binding to make them private instead of public.
Reviewed By: mdvacca
Differential Revision: D17275344
fbshipit-source-id: 67ad00aeebd3534a45a6ea8a28e14b7fcd9eb2e5
Summary: We were using an alias_ref which is like a raw pointer (not managed/retained); as it turns out, everywhere (?) else we accept an alias_ref we convert it to a global_ref (see Binding.cpp, JMessageQueueThread). We've just gotten lucky to not have already hit use-after-free errors.
Reviewed By: mdvacca
Differential Revision: D17275200
fbshipit-source-id: 581a51da36e96c353ed1117e9e0f428e65d36d69
Summary:
Log every item in a BatchMountItem. There's a lot of useful debug information being hidden there currently.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D17254629
fbshipit-source-id: c72f0aa8506059da5225ebead24d3f8ead5bdebd
Summary: This indicator is not to be used globally, only to some folks. For now prefix it with (FB-ONLY) since it's only used internally at FB.
Reviewed By: PeteTheHeat
Differential Revision: D17266514
fbshipit-source-id: f22411c26f5f412a1a3da9666f57cffabd2cc017
Summary: Now that `ImageURISource` is a proper type, `nativeImageSource`'s return type should simply use that instead of being an untyped `Object`.
Reviewed By: cpojer
Differential Revision: D17246527
fbshipit-source-id: 6ec0c80a93b8794e6c243154875e3560ddacbc59
Summary: Whenever we invoke a method, we convert JS arguments into JNI objects. These JNI objects are all local references that need to be manually destroyed after the method call happens. Therefore, I'm using `JniLocalScope` to automatically do this whenever the stack is cleared after the call to `JavaTurboModule::invokeJavaMethod`. This should hopefully get rid of the JNI table overflow we're seeing in T52817336.
Reviewed By: mdvacca
Differential Revision: D17244061
fbshipit-source-id: 92ca78cdb23ad8dfe2425db46e086c10c9662fe2
Summary:
We're trying to build react-native on Windows (part of the Microsoft\react-native-windows project) with MSVC compiler with WITH_FBSYSTRACE set to true (to route the traces to ETW). This change is to fix a compilation error due to the non standard usage of ATOMIC_VAR_INIT macro called with no parameters. It's not absolutely clear to me the objective of this macro in the standard at all (to be used in c context ?), and which compiler does support this parameterless version (gcc?).
Also, I'm more inclined towards changing the statement to just "std::atomic_uint_least32_t m_systraceCookie{};". Please confirm.
## Changelog
[General] [Fixed] - Removing the non-standard usage of ATOMIC_VAR_INIT macro from code with systrace enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/26238
Test Plan: Build verification should suffice as there is no semantic change introduced by this change.
Differential Revision: D17259213
Pulled By: cpojer
fbshipit-source-id: 9fe44f9220f18399a58f94f0f01d5fa93e6458e0
Summary:
Fixes typos in code comments about CocoaPods’s `use_frameworks!`.
## Changelog
[Internal] [Fixed] - Fix typos in comments about `use_frameworks!`
Pull Request resolved: https://github.com/facebook/react-native/pull/26381
Test Plan: Considering this only changes code comments, I don’t think this pull request needs a test plan.
Differential Revision: D17258856
Pulled By: cpojer
fbshipit-source-id: fd9a7253ef9744685c233ebbec7df9eea50a8d28
Summary:
Pods directory showed up as untracked files after running `pod install`
in the `RNTester` directory. With this small change to `.gitignore`, it
will no longer show up.
## Changelog
Small repo-level change, no changelog needed (?)
Pull Request resolved: https://github.com/facebook/react-native/pull/26265
Test Plan:
Run `pod install` in `/RNTester`, verify that "Pods" no longer show up
as untracked files in `git status`.
Differential Revision: D17259103
Pulled By: cpojer
fbshipit-source-id: 72a3774bcb48c88c2c6629bf452ddb0cbc32f581
Summary:
The new podspec includes all .h and .m files, `RCTInputAccessoryViewContent` was missing a tvOS guard.
## Changelog
[iOS] [Fixed] - Restore RCTText tvOS pod compatibility
Pull Request resolved: https://github.com/facebook/react-native/pull/26332
Test Plan: Build RCTText for tvOS
Differential Revision: D17258958
Pulled By: cpojer
fbshipit-source-id: 5e7408680133aa3ec111552d1413a928193945a7
Summary:
Has explained in https://github.com/facebook/react-native/issues/26233, current template is incorrect & can create error, like having require() of png that are considered as `string` instead of `number. This can probably hide tons of similar mistakes.
The change in this PR should resolve the previous behavior (& for example, some places in previous version of the flowconfig have the full path like here 35300147ca/template/_flowconfig (L61))
Closes https://github.com/facebook/react-native/issues/26233
## Changelog
```
[General] [Fixed] Fix incorrect `module.name_mapper` in template .flowconfig
```
Alternatively, message could be
```
[General] [Internal] Fix incorrect `module.name_mapper` in template .flowconfig
```
As it hasn't this "bug" hasn't been released in a public stable release. You decide
Pull Request resolved: https://github.com/facebook/react-native/pull/26330
Test Plan: I just tested this in my project, thymikee might be able to confirm & approve this PR.
Differential Revision: D17258891
Pulled By: cpojer
fbshipit-source-id: 3904ffbc6f076ee0e435311249d694b8604fc7b8
Summary:
This is a cherry-pick of the fix on 0.61-stable that fixes an issue with CircleCI.
fafc58b62d
Pull Request resolved: https://github.com/facebook/react-native/pull/26329
Differential Revision: D17258952
Pulled By: cpojer
fbshipit-source-id: 5116a143b582ab4835d7a53f4037a7b7e749f3a8
Summary:
The `dependencies` section in the `build.gradle` Android template contains this line:
implementation "com.facebook.react:react-native:+" // From node_modules
It causes the following Gradle Lint warning:
> Avoid using '+' in version numbers, can lead to unpredictable or unrepeatable builds
In this case, as the `// From node_modules` comment suggests, the version is _not_ determined by Gradle but by the version specified in `package.json` - Using "+" is completely fine and intentional.
Therefore it can safely be ignored, which is what the added `//noinspection` comment does.
## Changelog
[Android] [Fixed] - Skip lint check for dynamic react-native version
Pull Request resolved: https://github.com/facebook/react-native/pull/26222
Test Plan: Projects generated with the new template no longer cause the warning anymore.
Differential Revision: D17091476
Pulled By: osdnk
fbshipit-source-id: 910b4ecf22ccd11cade9427af68087ffcce8bc8e
Summary:
Original commit changeset: 91eb08181f82
Original diff: D16940181
The original commit removed the gating logic to enable the "fix" to T48583301. However, v236 was burned, and v237+ no longer had this gating, making it impossible to measure the impact of the fix.
This diff reverted the original gating removal until we confirm the fix in prod. Note: this is to be picked to RC v238 (but will have merge conflict for sure, will send a separate diff for the branch).
Reviewed By: mmmulani
Differential Revision: D17251340
fbshipit-source-id: 359ac54aeb9c9e728c2735c688346a1f79ed2189
Summary: Looks like some of the imports went missing when merging. Found this when testing this again.
Reviewed By: mdvacca
Differential Revision: D17200737
fbshipit-source-id: ded39493786d4999317c5e29be270e5990601b06
Summary: Same as prior diff, but Android.
Reviewed By: JoshuaGross
Differential Revision: D17005308
fbshipit-source-id: 1ac815a232dceaf918e14b045e04aed53a00ae47
Summary: This bypasses setNativeProps and causes all Fabric animations to go through the mounting layer.
Reviewed By: mdvacca
Differential Revision: D17201061
fbshipit-source-id: c43b59913d8240860e5269e73e1c0ec10ec8e717
Summary: When you return null or [NSNull null] from a TurboModule method, we should just return null to JS.
Reviewed By: fkgozali
Differential Revision: D17141170
fbshipit-source-id: a73410b7a4a765750a8dd9c4e904046ffe1c0fc1
Summary: Implements the new `reportException` method in the iOS version of `ExceptionsManager`.
Reviewed By: sammy-SC
Differential Revision: D17226365
fbshipit-source-id: baa81424399175eaf8fc0835d4df01897e7fa468
Summary:
Refines the condition for ignoring updates to an already-open redbox on iOS.
Previously we would only update the stack trace if the message string in the update was exactly the same as in the initial redbox. With this diff we rely on the `exceptionId` parameter instead, and only fall back to string comparison if it's omitted (i.e. for non-JS uses of redbox on iOS).
NOTE: `exceptionId` is part of the existing ExceptionsManager API and is already supported on Android.
Reviewed By: sammy-SC
Differential Revision: D17226179
fbshipit-source-id: 5940110bf4e4358a8a1b3477e8d2cf8b224dd9f8
Summary: Enables the use_framework! support for the Flipper for RN
Reviewed By: jknoxville
Differential Revision: D17206811
fbshipit-source-id: ec1408083655044e1c10d4b7d3b0a6844b15511b
Summary: We still include this info in real reports. We also still print the root tag when the app starts. This just removes the redbox "extra data" logging to console. It's noisy, especially on smaller apps in open source that only have one root tag and always empty props.
Reviewed By: cpojer
Differential Revision: D17226903
fbshipit-source-id: a702daaf3a02600fbe9038c46d294c3392953239
Summary: This diff adds support for generating native code for arrays of arrays of objects
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D16936272
fbshipit-source-id: 1543f8c1d5d9d4db28e4c7841ff7184ca0e417b3
Ramanpreet Nara
Sidharth Guglani
Samuel Susla
jainkuniya
Alec Larson
gaodeng
jeswinsimon
Siddhant Soni
Hassan Bazzi
Adam Chelminski
Valentin Shergin
zhongwuzw
Tianyu Yao
Janic Duplessis
Joshua Gross
Kevin Gozali
Tim Yung
Anandraj
Jakob Krigovsky
Frieder Bluemle
Benoit Dion
Max Thirouin
Mike Grabowski
Eli White
Ram N
David Vacca
gengjiawen
Nat Mote
Moti Zilberman
Pritesh Nandgaonkar
Dan Abramov
Rick Hanlon
