Summary:
Android followup for #24745. This adds a jsi object that removes blobs when it is gc'ed. We don't have many modules with native code on Android so I've added the native code directly in the blob package as a separate .so. I used a similar structure as the turbomodule package.
## Changelog
[Android] [Fixed] - [Blob] Release underlying resources when JS instance is GC'ed on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/24767
Differential Revision: D15279651
Pulled By: cpojer
fbshipit-source-id: 2bbdc4bbcbeae8945588ac5e3e895c49e6ac9e1a
Summary:
This commit more clearly defines the mocks RN sets up and uses paths instead of Haste names to define the mocks. The Jest setup script defined mocks for native modules (Obj-C, Java) and mocks for JS modules in the same data structure. This meant that some non-native modules (that is, JS modules) were in the `mockNativeModules` map -- this commit splits them out and mocks them in typical `jest.mock` fashion.
Additionally, the setup script used to mock the modules using the Haste names. As one of the steps toward migrating to standard path-based imports, the setup script now mocks JS modules using paths (native modules don't need a Haste name nor path since they are just entries in `NativeModules`). This gets us closer to being able to remove `hasteImpl`. (Tracking in https://github.com/facebook/react-native/issues/24772.)
Also, this commit removes mocks that are not referenced anywhere in the RN and React repositories (grepped for the names and found no entries outside of the Jest setup scripts).
## Changelog
[General] [Changed] - Explicitly separate mocked native modules from mocked JS modules
Pull Request resolved: https://github.com/facebook/react-native/pull/24809
Differential Revision: D15316882
Pulled By: cpojer
fbshipit-source-id: 039e4e320121bea9580196fe0a091b8b1e8b41bf
Summary:
The original reason for vendoring the fetch polyfill was to remove the default blob response type but this was reverted.
Here's a little history around the fetch polyfill and the blob issue:
- Original commit introducing the vendored polyfill: #19333, the goal was to fix a memory leak because our blob implementation doesn't release resources automatically. Not an ideal fix but since the issue was pretty severe and the infra for a proper fix was not in place.
- This introduced an issue when downloading images using `fetch` which was fixed by #22063 which re-added the default blob content type. However that re-introduced the original fetch memory leak.
- We have better infra now with jsi and I was able to get blob deallocation working, see #24405
Currently the vendored fetch polyfill is useless since it was changed back to the original version. We can just use the npm version again. I also updated to 3.0 which brings better spec compliance and support for cancellation via `AbortController`, https://github.com/github/fetch/releases/tag/v3.0.0.
## Changelog
[General] [Changed] - Remove vendored fetch polyfill, update to whatwg-fetch@3.0
Pull Request resolved: https://github.com/facebook/react-native/pull/24418
Differential Revision: D14932683
Pulled By: cpojer
fbshipit-source-id: 915e3d25978e8b9d7507ed807e7fba45aa88385a
Summary:
Replace the *copy on write* vector with an atomic pointer to a linked list.
This allows to publish without locking a mutex, at the cost of the slower traversal of a linked list (a vector has better locality).
At the moment, the typical use case is to have one subscriber, meaning that the afforementioned slower traversal is not a problem.
Adding subscribers is implemented as atomic *compare and swap.*
Reviewed By: SidharthGuglani
Differential Revision: D15546964
fbshipit-source-id: 41bfa41f1ac6be5c9b6bf4288ea3271ee995877e
Summary:
The previous comparison does not make sense (accessing props by index) - and always returns true. I'm going to assume there was a reason for implementing `shouldComponentUpdate` - although personally I'd just go for PureComponent (even if it may not be 100% accurate). Let me know if PureComponent sounds better.
## Changelog
not needed
Pull Request resolved: https://github.com/facebook/react-native/pull/25097
Differential Revision: D15575079
Pulled By: cpojer
fbshipit-source-id: 49aeb9d2997d3c613fe7a1af4534dff1607d53b4
Summary:
People ask "How do you use `console.log` with React Native?" and there is no good answer. This diff aims to stop people from asking this question.
See https://fb.workplace.com/groups/rn.core/permalink/2372327062999018/ for context.
This logging relies on network requests which can cause logs to show up out-of-order. To reduce the likelihood I queue every log message on the server for a maximum of 200ms. There could be other methods, like using websocket, but that seems more complex than is necessary at least in the beginning.
I considered various throttling strategies because this could be quite chatty and possibly problematic, however I think we can just ship this and iterate based on feedback. On my very underpowered laptop I logged a random number every 10 milliseconds and it didn't cause any issues or slowdown.
Reviewed By: gaearon
Differential Revision: D15559151
fbshipit-source-id: 552001622af0937ae3a37d2bd8c1b96e7ca52020
Summary:
Addresses a number of pieces of feedback regarding the debug menu.
- Simplify labels for the debugger actions (e.g. no "remote", no emoji).
- Reorder actions so that modal items are generally lower.
- Renamed "Live Reloading" to "Reload-on-Save".
- Renamed "Dev Settings" to "Settings".
Changelog:
[Android] [Changed] - Cleaned up debug menu.
Reviewed By: cpojer
Differential Revision: D15553883
fbshipit-source-id: d30e8cd0804e010985c0cf40d443defc7c0710ac
Summary:
Addresses a number of pieces of feedback regarding the debug menu.
- Simplify labels for the debugger actions (e.g. no "remote", no emoji).
- Reorder actions so that modal items are generally lower.
- Changed "Toggle Inspector" to "Show/Hide Inspector".
- Renamed "Live Reloading" to "Reload-on-Save".
- Hide disabled debug items when profiling is enabled.
- Changed "Start Systrace" to "Systrace Unavailable" when debugging.
- Renamed "Change packager location" to "Configure Bundler".
- Revised nomenclature in "Configure Bundler" menu to be clearer.
- Removed extraneous debug menu title.
- Consistently refer to HMR as "Hot Reloading".
Changelog:
[iOS] [Changed] - Cleaned up debug menu.
Reviewed By: axe-fb
Differential Revision: D15548628
fbshipit-source-id: 26b2ddca8280d1f6f8ff904439b403600e98a3b3
Summary: Some modules accessed PermissionsAndroid even in iOS, causing redbox. Let's relax the enforcement, then invariant() on the callsites instead.
Reviewed By: yungsters
Differential Revision: D15572716
fbshipit-source-id: 4a2edea608ab27727e88f0f246ecb9cdcf5a5329
Summary:
part of #24875. Because some of the methods are rewriteable, I dropped the `+` from the signature, this doesn't feel right to me, but I am not sure if the codegen requires that. If it does, it will probably be better to extend the spec and allow those specific methods to be overriden in a UIManager.js interface. Thoughts on that fkgozali or RSNara?
## Changelog
[General] [Added] - Add TM spec for UIManager
Pull Request resolved: https://github.com/facebook/react-native/pull/24902
Reviewed By: hramos
Differential Revision: D15551356
Pulled By: fkgozali
fbshipit-source-id: 076c4ce635aa7ea41e21cbd67c47ecd562fc320d
Summary:
Every call site is either already using `createReactContextInBackground` correctly or guarding the invocation using `hasStartedCreatingInitialContext`. This is an unnecessary and overly complex dance that can be simplified.
This revision simplifies the use of `createReactContextInBackground` by integrating the check. This is not a breaking change.
Reviewed By: zackargyle, mdvacca
Differential Revision: D15566632
fbshipit-source-id: 7b50285c9ac6776d1297d2c9c53dff208851b722
Summary: D15391408 (https://github.com/facebook/react-native/pull/24695) added a new event type with the registration name 'onAccessibilityAction' on Android, using the key 'performAction'. On iOS the same event uses the key 'topAccessibilityAction', which caused a runtime error after I started registering both using the unified JS view config in D15488008. This diff changes Android to use the same name as iOS since the convention is to start with 'top'.
Reviewed By: cpojer
Differential Revision: D15542623
fbshipit-source-id: c339621d2b4d3e1700feb5419ae3e3af8b185ca8
Summary:
Migrate the Circle CI configuration to the 2.1 schema and take advantage of new config reuse features.
I've enabled pipelines in the facebook/react-native Circle CI project, a requirement for Circle CI 2.1 features.
### Overview
* Use executors to provide a common set of execution environments.
* Use commands to provide reusable steps (running yarn with cache, installing Android dependencies, ...)
* Use parametrized commands/jobs to reuse job definitions for `test_js` and `test_js_lts` where the only difference is the version of node provided by the environment.
* Reduce total execution time by [storing the git repo in a cache as opposed to using workspaces](https://circleci.com/blog/persisting-data-in-workflows-when-to-use-caching-artifacts-and-workspaces/)
* Fix various flaky end-to-end test failures related to CocoaPods and the CLI.
* Move `analyze` job to `analysis` workflow and rename to `analyze_pr`
* Rename `test_javascript` as `test_js`.
* Split up end-to-end test job into `test_ios_e2e` and `test_js_e2e`.
## Changelog
[Internal] [Changed] - Migrate to Circle CI 2.1 and fix e2e tests
Pull Request resolved: https://github.com/facebook/react-native/pull/25036
Differential Revision: D15565515
Pulled By: hramos
fbshipit-source-id: cfba2154a9fdc96400cbf778bd5d13e9411ee3f8
Summary:
Updates the CLI version to the latest alpha to fix some issues around init and autolinking. Please port this PR back to `0.60-stable` branch as it fixes an issue with `npx react-native init`.
cc grabbou hramos
## Changelog
[General] [Fix] - Upgrade CLI to latest alpha
Pull Request resolved: https://github.com/facebook/react-native/pull/25094
Differential Revision: D15558082
Pulled By: cpojer
fbshipit-source-id: 60be64fbed996b6667eddc08346b07475dbb5089
Summary:
If you (try to) build React Native for Android without having the NDK properly installed and referenced, you get the following error:
>A problem occurred evaluating project ':ReactAndroid'.
\> Cannot get property 'absolutePath' on null object
This is not an overly helpful diagnostic. This PR results in this message instead:
>ndk-build binary cannot be found, check if you've set $ANDROID_NDK environment variable correctly or if ndk.dir is setup in local.properties
Fixes#25087
## Changelog
[Android] [Fixed] - Show proper error message instead of throwing a NullReferenceException if Gradle cannot find the NDK
Pull Request resolved: https://github.com/facebook/react-native/pull/25088
Differential Revision: D15559271
Pulled By: cpojer
fbshipit-source-id: 35c9a9321af4e4a34bf519144ada48884b48352d
Summary:
This diff fixes the bug of the switch component on Android being stuck in the middle when a user releases their finger whily dragging the thumb.
When a user releases their finger while dragging the thumb, `setChecked` will be called and if `mAllowChange` is set to false, `super.setChecked` is never called. The supper method will actually make sure the thumb will be animated to the correct edge. Without calling the super method, the thumb might stay in the middle of the switch where a user released their finger.
The fix had to be applied both to ReactSwitch and FbReactSwitchCompat.
One more fix had to be made to FbReactSwitchCompat since D5884661 was applied to ReactSwitch, but not to FbReactSwitchCompat:
if (mAllowChange && **isChecked() != checked**) {
...
}
Reviewed By: mdvacca
Differential Revision: D15535611
fbshipit-source-id: 22ca1fe3fa993ae65cbd677bfae2208a02c368d4
Summary:
This is an ESLint plugin that infers whether an import looks like a Haste module name. To keep the linter fast and simple, it does not look in the Haste map. Instead, it looks for uppercase characters in single-name import paths, since npm has disallowed uppercase letters in package names for a long time. There are some false negatives (e.g. "merge" is a Haste module and this linter rule would not pick it up) but those are about 1.1% of the module names in the RN repo, and unit tests and integration tests will fail anyway once Haste is turned off.
You can disable the lint rule on varying granular levels with ESLint's normal disabling/enabling mechanisms.
Also rewrote more Haste imports so that the linter passes (i.e. fixed lint errors as part of this PR).
## Changelog
[General] [Changed] - Add a lint rule to disallow Haste imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25058
Differential Revision: D15515826
Pulled By: cpojer
fbshipit-source-id: d58a3c30dfe0887f8a530e3393af4af5a1ec1cac
Summary: I simply removed them from RN but we should give an actionable error message for people who upgrade from older versions of RN and who may be using these old modules, at least in `__DEV__`.
Reviewed By: rickhanlonii
Differential Revision: D15554863
fbshipit-source-id: 1975d4773581258776d2586ae820677bb14488f6
Summary:
React Native Gesture Handler used to eagerly initialize all of its exports and therefore required a bunch of things from React Native eagerly. When we remove things from RN via the Lean Core project, this leads to failures.
I asked Krzysztof to make a patch release that lazily loads them instead: https://github.com/kmagiera/react-native-gesture-handler/commit/da658c2de2e7135871e27284d9c8c6d323c5d803
Reviewed By: rickhanlonii
Differential Revision: D15554658
fbshipit-source-id: aa4b82e5a3c2c837d160da914f41756d26cd6c07
Summary:
Related #23674, in that PR, we imported background timer support, but it's not sufficient, I think the reason that works is because it enable the `Background Modes` and do some background tasks, for the users who don't enable it, timer would pause immediately before goes into background.
To fix it, we can mark a background task when goes into background, it can keep app active for minutes, try best to support timing when in background.
cc. cpojer .
## Changelog
[iOS] [Fixed] - Timing: Fixes timer when app get into background
Pull Request resolved: https://github.com/facebook/react-native/pull/24649
Differential Revision: D15554451
Pulled By: cpojer
fbshipit-source-id: a33f7afe6b63d1a4fefcb7098459aee0c09145da
Summary:
Part of #24875, adds a spec for Networking. Since `sendRequest` methods are different for both platforms, I had to create 2 spec files as Flow would merge their definitions even when I added `Platform.OS` check
## Changelog
[General] [Added] - TM spec for Networking
Pull Request resolved: https://github.com/facebook/react-native/pull/24892
Reviewed By: RSNara
Differential Revision: D15543067
Pulled By: fkgozali
fbshipit-source-id: 2b91114dfa45e7899bbb139656a30a6fd52e31db
Summary:
part of #24875. I again, am not completely sure how the call site here works- appears settings can be directly accessed?
## Changelog
[General] [Added] - Add TM spec for Settings
Pull Request resolved: https://github.com/facebook/react-native/pull/24879
Reviewed By: RSNara
Differential Revision: D15543012
Pulled By: fkgozali
fbshipit-source-id: a1df3096a2fc5fe8e65d0ed2398912530bd3911a
Summary:
When code depends on a module from fbjs, its types come from the node_modules
directory. This is problematic when Flow is deployed, since we can't codemod the
parts that come from node_modules.
Reviewed By: dsainati1
Differential Revision: D15547035
fbshipit-source-id: 8794a32e0f5786bcdd80eab98344d4bc623fb674
Summary: Adding flow types for DeviceInfo module and migrating our codebase over to using `DeviceInfo.getConstants()`
Reviewed By: fkgozali
Differential Revision: D14645744
fbshipit-source-id: e30a060c6dc92938cd1420ba11a1d837c79d1e32
Summary: Reverting the generated view configs due to a potential issue
Reviewed By: mdvacca
Differential Revision: D15539319
fbshipit-source-id: bddf923dcfda18bd074196f06610fea8bb4561b4
Summary: This unbreaks an issue at FB.
Reviewed By: rickhanlonii
Differential Revision: D15536623
fbshipit-source-id: 2d59542330d2b951908adf8b6c5c41ca4232bb07
Summary:
We want to phase out usage of config pointers on nodes. Setting configs is no longer needed, as a config is unly used during construction.
Here we deprecate the setter, as it is no longer working as it used to (e.g. changing `useWebDefaults` after a node is constructed).
Reviewed By: SidharthGuglani
Differential Revision: D15416474
fbshipit-source-id: a2cc06cad0c5148cecce056ece5f141b3defe9a9
Summary: Create structure of C++ side of mapbuffer project
Reviewed By: shergin
Differential Revision: D15529650
fbshipit-source-id: b563d3fbcfddcf46802ccb202e372233baad123d
Summary:
We currently have two different codepaths for actually rendering a surface with Fabric on iOS and Android: on iOS we use Fabric's `UIManagerBinding.startSurface` to call `AppRegistry.runApplication`, but on Android we don't; instead we use the same codepath as paper, calling `ReactRootView.runApplication`.
This diff does a few different things:
1. Unify iOS and Android by removing the `#ifndef` for Android so that we call `startSurface` for both
2. Pass through the JS module name on Android so that this actually works (it currently passes in an empty string)
3. Remove the call to `ReactRootView.runApplication` for Fabric so that we don't end up doing this twice
4. Copy over some logic that we need from `ReactRootView.runApplication` (make sure that root layout specs get updated, and that content appeared gets logged)
Reviewed By: mdvacca
Differential Revision: D15501666
fbshipit-source-id: 5c96c8cf036261cb99729b1dbdff0f7c09a32d76
Summary:
In Flow v0.99 we are changing function type annotations to be strict about their
static properties. This causes a small issue with the union of a Subcription and
`() => mixed` function type, where the latter is now understood to possibly have
an `unsubscribe` property with a mixed type.
This causes the following refinement check, which appears lower in this file, to
cause an error in the next version of Flow:
```
if (cleanup) {
if (cleanup.unsubscribe) {
cleanup.unsubscribe(); // <-- error here
}
// ...
}
```
In Flow v0.99, because `() => mixed` statics are now checked, Flow sees that
`cleanup.unsubscribe` might be `mixed`, which passes the conditional but could
cause an exception when called.
I also needed to change JestMockFn to have exact statics, because tests
sometimes use a value with that type in place of the cleanup function. That runs
into the `{} <: {+p?: void}` rule, which is an error. `{||} <: {+p?:void}` is
not an error.
Reviewed By: josephsavona
Differential Revision: D15522655
fbshipit-source-id: 2ae3c9016e2b07abaac79827082d2f8743623eb5
Summary: Rick manually created view config in JS for View; adding some missing attributes/events and using this instead of `requireNativeComponent`
Reviewed By: rickhanlonii
Differential Revision: D15488008
fbshipit-source-id: 48e925ec0ca2aeba9e6cc66edef0b70ee1c94d27
Summary:
[Android][Fix] - Fix how we normalize indices
Before, we were incorrectly normalizing indices given pending view deletion in the view hierarchy (namely, using LayoutAnimations)
What we had before (that was wrong):
* Maintained a pendingIndices sparse array for each tag
* For each pendingIndices sparse array we'd keep track of how many views we deleted at each abstract index
* Given an abstract index to delete a view at, we'd consult `pendingIndices` array to sum how many pending deletes we had for indices equal or smaller than and add to abstract index
^ Above algorithm is wrong and you can follow along with the following example to see how.
## The correct approach
Given these operations in this order:
1. {tagsToDelete: [123], indicesToDelete [2]}
2. {tagsToDelete: [124], indicesToDelete [1]}
3. {tagsToDelete: [125], indicesToDelete [2]}
4. {tagsToDelete: [126], indicesToDelete [1]}
The approach we want to be using to calculate normalized indices:
### Step 1: Delete tag 124 at index 2
|Views:|122|123|124|125|126|127|
|Actual Indices:|0|1|2|3|4|5|
|Abstract Indices:|0|1|2|3|4|5|
=> simple, we just mark the view at 2
### Step 2: Delete tag 123 at index 1
View tags and indices:
|Views|122|123|~~124~~|125|126|127|
|Actual indices|0|1|~~2~~|3|4|5|
|Abstract Indices|0|1||2|3|4|
=> again, simple, we can just use the normalized index 1 because no pending deletes affect this operation
### Step 3: Delete tag 126 at index 2
View tags and indices:
|Views|122|~~123~~|~~124~~|125|126|127|
|Actual Indices|0|~~1~~|~~2~~|3|4|5|
|Abstract Indices|0|||1|2|3|
=> Here we want to normalize this index to 4 because we need to account the 2 views that should be skipped
### Step 4: Delete tag 125 at index 1
View tags and indices:
|Views|122|~~123~~|~~124~~|125|~~126~~|127|
|Actual Indices|0|~~1~~|~~2~~|3|~~4~~|5|
|Abstract Indices|0|||1||2|
=> The normalized index should be 3.
This diff updates the function `normalizeIndex` to do the above algorithm by repurposing `pendingIndicesToDelete` to instead be a sparse int array that holds [normalizedIndex]=[tag] pairs
It's required that `pendingIndicesToDelete` is ordered by the normalizedIndex.
Reviewed By: mdvacca
Differential Revision: D15485132
fbshipit-source-id: 43e57dffa807e8ea50fa1650c5dec13a6fded624
Janic Duplessis
James Ide
zhongwuzw
Rubén Norte
David Aurelio
Vojtech Novak
Christoph Nakazawa
Tim Yung
Kevin Gozali
Jarvis Luong
Eric Lewis
Ram N
Emily Janzer
Dan Nguyen
Héctor Ramos
Tom Sanderson
Jean Regisser
Michał Pierzchała
Petter Hesselberg
Oleksandr Melnykov
Johan-dutoit
Wojteg1337
Krzysztof Borowy
Sam Goldman
Rick Hanlon
michalchudziak
Abhinandan Ramaprasath
David Vacca
Luna Wei