Summary:
The callback `dispatchEvent` is called asynchronously on the JavaScript thread, so all data it uses must be copied to the lambda. To work around this constraint we use a shared pointer for the counter.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24598840
fbshipit-source-id: fb5581858d54dc806863caf0c7c4f612ed6046e2
Summary:
Adds an annotation in the performance logger that indicates if the component was rendered using Fabric or not.
Changelog: [internal]
Reviewed By: JoshuaGross, ShikaSD
Differential Revision: D24596131
fbshipit-source-id: 489f3a03f09c5425c870678ed593ee8f16a2d98b
Summary:
This diff cleans up a bunch of code in `symbolicateStackTrace`. According to motiz88 all of it is dead code and I can confirm symbolication does not break with the changes applied.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24585849
fbshipit-source-id: 5b2c76f56dbbbf27449ce1472cdd0271ed230c35
Summary:
Bump Gradle Wrapper to 6.7, to keep tooling on edge. Here are the highlights of this release:
- File system watching is ready for production use
- Declare the version of Java your build requires
- Java 15 support
## Changelog
[Android] [Changed] - Bump Gradle Wrapper to 6.7
Pull Request resolved: https://github.com/facebook/react-native/pull/30200
Test Plan: RNTester builds and runs as expected. Also my apps.
Reviewed By: cpojer
Differential Revision: D24560233
Pulled By: fkgozali
fbshipit-source-id: 0d94b4527b2ee5b28b22478128c25761929fbdc7
Summary:
Android Studio 4.1 release with Android Gradle Plugin 4.1.0, thus I expect developers will update to newer version and expect React Native support. Thus release include many fixes and improvements, see[release notes](https://developer.android.com/studio/releases/gradle-plugin#4-1-0), but most importantly Google released it's API documentation at https://developer.android.com/reference/tools/gradle-api. We lacked the API documentation to develop proper React Gradle Plugin.
## Changelog
[Android] [Changed] - bump Android Gradle Plugin to 4.1.0
Pull Request resolved: https://github.com/facebook/react-native/pull/30201
Test Plan: RNTester builds and runs as expected, also my apps.
Reviewed By: cpojer
Differential Revision: D24560213
Pulled By: fkgozali
fbshipit-source-id: 9cf1e2373f278885b35b4f9176c7ad736ec50f6b
Summary: We support setting the text color in the ReactPicker component, but we don't apply the text color to the little arrow icon that appears next to it. This diff applies the color tint from the picker's primary text color (set with a style prop on the main picker component, *not* the 'color' prop on the Picker.Item) to the background of the picker, which tints the arrow icon.
Reviewed By: makovkastar
Differential Revision: D24480642
fbshipit-source-id: 7ce84d616ae677da8975be9444428392020c57dc
Summary:
Bump Okio to 1.17.5, which includes fixes for many bugs and crashes since current version. Also removed android.enableR8=false from gradle.properties because it's deprecated. And moved FEST_ASSERT_CORE_VERSION from gradle.properties to build.gradle because it's used in single line.
## Changelog
[Android] [Changed] - bump Okio to 1.17.5
Pull Request resolved: https://github.com/facebook/react-native/pull/30204
Test Plan: RNTester builds and runs as expected.
Reviewed By: hramos
Differential Revision: D24560711
Pulled By: fkgozali
fbshipit-source-id: 433075293ca2dc41869dbb272d674625639c8b83
Summary:
When working with RN installed from npm and a regular project structure `$rootDir` won't be at the react-native package root. Instead we can use `$projectRoot` which will always be the ReactAndroid folder.
## Changelog
[Android] [Internal] - Use $projectDir instead of $rootDir for ReactAndroid codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/30220
Test Plan: Test building an app with RN as a regular dep with codegen enabled
Reviewed By: hramos
Differential Revision: D24560634
Pulled By: fkgozali
fbshipit-source-id: 434d32f37e6f9d48a8c562655ceff7249bd056ce
Summary:
Pass the ReactAndroid project build directory as a variable to the ndk build so it can be used instead of assuming that the build directory is under ReactAndroid/build.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/30222
Test Plan: Tested in an app with a custom build directory
Reviewed By: yungsters
Differential Revision: D24560643
Pulled By: fkgozali
fbshipit-source-id: cc65a70582f546ca2e2ca9fb6a2ff03ea70ca9d8
Summary:
The recursive copy statement fixed here behaved differently in MacOS vs Linus (CI), because of the missing dot (.)
The trailing slash on the source directory behaves differently on Mac (BSD) than Linux (GNU):
> If the source_file ends in a /, the contents of the directory are copied rather than the directory itself.
This should fix the CI failure: https://app.circleci.com/pipelines/github/facebook/react-native/6847/workflows/36d59aab-bc4a-4d21-9ce1-a8348e71aea3/jobs/173681
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24560543
fbshipit-source-id: c3ab2c28616b717891bcf5d2ad762340cfb97e3d
Summary:
## Context
We currently run ESLint using `flow-node`. This is a very recent change that was introduced in these two diffs:
- Switch VSCode ESLint plugin using flow-node: D24454702.
- Switch all ESLint scripts to use flow-node: D24379783 (https://github.com/facebook/react-native/commit/ad5802cf916c1cbe3e142385a29810a0d7205c6c).
## Problem
Because `react-native/eslint-plugin-codegen` (written in vanilla JavaScript) requires two files from `react-native-codegen` (written with Flow typings), we force all requires executed while initializing ESLint to compile out Flow types. Issues:
- In the grand scheme of things, this is such a tiny and isolated problem. It shouldn't be the reason why we switch over to using flow node. That's a larger decision that should be discussed outside of this diff.
- On VSCode cold start, in D24454702, I measured that using flow-node adds approximately 320ms to JavaScript file lint time. So, this is just slow.
## Solution
- Switch ESLint back to using regular node:
- Revert the changes to VSCode's ESLint plugin: D24454702
- Revert the changes to the internal ESLint scripts: D24379783 (https://github.com/facebook/react-native/commit/ad5802cf916c1cbe3e142385a29810a0d7205c6c).
- Inside the ESLint plugin, register a temporary require hook to remove Flow types from the NativeModule spec parser, before we require it. We de-register this hook after the requires finish.
## Implementation Notes:
- The `with-babel-register/` is a fork of `babel/register`, except I simplified the implementation based on the assumption that we're using it literally to only compile `react-native-codegen`.
- `with-babel-register/` uses a disk cache, so we only call transformSync when a the input file (1) hasn't been transformed before, or (2) the cache entry was created before the file was last modified.
- I ported over the source-map logic, so that when the NativeModule spec parser throws non-parsing errors, we get the correct stack trace. **Note:** I'm not sure if the source maps will work if there's a babel/register earlier during initialization. However, I don't think this will pose an actual problem, since we don't use a babel/register hook earlier. So, I think we should punt on this investigation.
## Alternative: Why aren't we using babel/register?
Every time you call babel/register, it replaces the last registered hook. We don't want the ESLint plugin to be changing any existing require hooks that people have set up. Abandoned diff with babel/register: D24519349.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D24551549
fbshipit-source-id: bbd7c5be44f74c0e9adbb20fe86e09802410b123
Summary:
This does a few things:
* Remove USE_CODEGEN flag so that TurboModule is enabled by default for RNTester
* Use the codegen output for Java/JNI spec files
* Remove the checked in com.facebook.fbreact.specs Java/JNI files
Changelog: [Changed][Android] RNTester now enables TurboModule by default using codegen.
Reviewed By: RSNara
Differential Revision: D24382083
fbshipit-source-id: 87e3e0581bac3287ef01c1a0deb070c1d7d40f2d
Summary:
The Gradle codegen integration requires the JS CLI to be first built via `yarn run build`. This commit puts that logic in a `build.sh` script, then defines a Gradle task to build it.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24556992
fbshipit-source-id: 7092de7c1126edc157b122f4b2243e55f7188846
Summary:
In D24521951 (https://github.com/facebook/react-native/commit/2ff1d4c041ee662871a84363a3f85a8bc9e857ce) I refactored the JS-side queueing for NativeAnimated API calls, and used randomized IDs for queueing. This could cause bugs or unexpected behavior, and potentially crashes, if there's ever a collision in random numbers generated or
a collision between random number and one of the deterministic numbers generated in createAnimatedComponent.
In this diff I make both of them namespaced with a string, and deterministic, to eliminate any potential collisions. This could also be slightly faster (but not meaningfully) since we're not relying on Math.random.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24553557
fbshipit-source-id: 8b765e21597ad4f8e641453c1f9f90bdf1ee022f
Summary:
To unify with Android, this uses the target off the same BUCK file.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24522269
fbshipit-source-id: 5aa0c08962890b884081faeb1ec801aebec9c2dd
Summary:
This moves all deps on the checked in fbreact/specs files to use the generated output (during build time) instead.
TLDR:
`react_native_target("java/com/facebook/fbreact/specs:FBReactNativeSpec")` ==> `react_native_root_target("Libraries:generated_java_modules-FBReactNativeSpec")`
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24520293
fbshipit-source-id: 3fb34f172f1ab89b7198dfb4fccf605fbc32d660
Summary:
This fixed a bug in the JS Java spec generator. Optional methods were still marked `abstract` before this fix. Instead it should be a normal method with potentially falsy return value.
The JavaPoet version does this correctly already, but there was a minor typo with void return type vs optional.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24524432
fbshipit-source-id: 57a248580a78bc255f34d0492ebe3a4691e66667
Summary:
This defines a separate codegen entrypoint for the entire react-native repo, picking up all JS files under Libraries/ subdir. Buck can then build the codegen library targets. This is a pre-req for removing the checked in Java spec files for NativeModules.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24518569
fbshipit-source-id: 2ece53c7274698e2431a00e590fad213e3a0bece
Summary:
Prepares for production experimentation of a reimplementation of the `Text` component that uses `Pressability` and React Hooks.
After I validate the new experimental implementation of `Text`, I will revert these changes and replace `Text.js` with the new implementation.
Changelog:
[Internal]
Reviewed By: nadiia, kacieb
Differential Revision: D24490569
fbshipit-source-id: 1ee4af72fcbda1b1d283a81c6bdf3fe67aa17e73
Summary:
This small PR fixes few "no-unused-var" issues and and removes two old entries for no longer existing files from the `.eslintignore`.
## Changelog
[Internal] [Fixed] - Lint: fix few "no-unused-var" warnings for imports
Pull Request resolved: https://github.com/facebook/react-native/pull/30157
Test Plan: Successfully run of `yarn lint` script. Warnings count has been reduced from `61` to `58`.
Reviewed By: yungsters
Differential Revision: D24288226
Pulled By: appden
fbshipit-source-id: 06e4ef015a331e3f2eac3b9aa6f757a3764e3ed9
Summary:
We don't currently support object spreads in `ObjectTypeAnnotation`s. This diff adds an explicit error for the case in the parser, so that when people use object spreads in ObjectTypeAnnotations, they get feedback from the linter rule and parser.
Previously, the Linter would crash, and the parser would fail, but the error wouldn't be immediately obvious.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24543650
fbshipit-source-id: 76f389c72f858ee6281c5aff5ce797f3be685096
Summary:
There's no reason for us to have lint ignores for `react-native/codegen/react-native-modules`. This diff removes all such ignores. I'll address any actual problems with the specs in subsequent diffs.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24529238
fbshipit-source-id: bbd2f4fb5dace65d803a8f93bd0d9a1c5a1cfb34
Summary:
- This fix resolves https://github.com/facebook/react-native/issues/29398
- After updating gradle to 6.5+ and android gradle plugin to 4.1.0+(which is recommended in the latest Android Studio 4.1), Running `:app:assembleRelease` or `:app:bundleRelease` will not contain `index.android.bundle` in Apk/AAB. It will be included when the command executed twice.
<img width="949" alt="Screen Shot 2020-10-17 at 11 32 43 PM" src="https://user-images.githubusercontent.com/6277118/96360808-38165c00-10d5-11eb-8b6e-f098517a24c7.png">
- This is caused by the task ordering update introduced in gradle plugin 4.1.0+/gradle 6.5. `mergeResources` task runs before `currentAssetsCopyTask`(copying the bundle asset file to intermediate output directory) which causes generated Apk/AAB not including the bundle file.
- The fix ensures mergeResources task runs after currentAssetsCopyTask
## Changelog
[Android] [Fixed] - Fix App Bundle/Release build missing index.android.bundle with gradle plugin 4.1.0/gradle 6.5
Pull Request resolved: https://github.com/facebook/react-native/pull/30177
Test Plan:
- Reproducible repository https://github.com/tomoima525/android_build_test_rn
- This project is generated with `create-react-native-app` and updated Gradle version to 6.5 and com.android.tools.build:gradle plugin to 4.1
- Run `./gradlew clean :app:assembleRelease` and `./gradlew clean :app:bundleRelease` => reproduces the issue
- After adding the fix above and run `./gradlew clean :app:assembleRelease` and `./gradlew clean :app:bundleRelease` => The issue is resolved
- Also confirmed the build works properly with android gradle plugin `3.5.3` and `gradle 6.2`(the default value of `create-react-native-app`)
Reviewed By: fkgozali
Differential Revision: D24551605
Pulled By: cpojer
fbshipit-source-id: b0effe2c6ea682748af185061af951e2f2bce722
Summary:
Changelog: [internal]
Problem:
`props.transform` gets out of sync with `self.layer.transform`.
To avoid writing out value of transform matrix, in the follow example I will only consider identity matrix and non-identity matrix. It is sufficient to demonstrate the point.
1. View is reused with transform being something besides identity. This causes `props.transform` and `self.layer.transform` to be non-identity.
2. View is taken from pool and animated with transform set to non-identity.
3. React JS props arrive and set `view.props` to identity but `self.layer.transform` stays unchanged because it is managed by native animation. This is the point where `props.transform` and `self.layer.transform` get out of sync.
4. Native animation wants to set transform to identity to finish the animation. But inside `[RCTViewComponentView updateProps:oldProps:]` `self.layer.transform` does not get set because current `view.props` is already identity.
Solution:
After native animation layer calls `[RCTViewComponentView updateProps:oldProps:]`, verify that values were set. If they weren't, set them directly without depending on `[RCTViewComponentView updateProps:oldProps:]`.
Reviewed By: JoshuaGross
Differential Revision: D24538442
fbshipit-source-id: ba8c59c5c9bb751306118bd1c7f0ccd9d0fb7fba
Summary:
Sometimes stopSurface crashes when unmountReactApplication is called under Fabric; knowing the stack trace up to this point might assist in debugging.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24532027
fbshipit-source-id: f350e77fb1a2de52eb146b449f1d2f6e960fa017
Summary:
Ensure the react-native-codegen package is built before the codegen is invoked during RNTester's pod install.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24515852
fbshipit-source-id: eeb1237f601d83a79a5274261c374bb5fc5689eb
Summary:
Changelog: [internal]
Background executor performs unnecessary operations when second `completeRoot` message from React arrives before first `completeRoot` was finished. This produces unnecessary `ShadowViewMutations`.
Mechanism:
Everytime `completeRoot` is received, before the call is dispatched on the background queue, `completeRootEventCounter_DO_NOT_USE_` is incremented.
Inside `ShadowTree::tryCommit` we check if the value has been incremented to determine if another `completeRoot` is queued.
Reviewed By: JoshuaGross
Differential Revision: D24419160
fbshipit-source-id: 11e19026feca01db6c8981b093a691a6b58a006f
Summary:
This moves the test script that generates **all outputs using all generators** to a dedicated "generate-all" CLI. This allows us to use it via Buck, at FB and OSS.
Also renamed the target to be more specific: "rn_codegen" => "generate_all_from_schema"
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24513995
fbshipit-source-id: 8435d3d065718eb1309c1c61fe28fb592787311a
Summary:
Changelog: [internal]
`onScroll` event needs to be fired when scroll view ends the scrolling animation and when scrollTo is called.
This is how Paper does it and client code might depend on it.
Reviewed By: JoshuaGross
Differential Revision: D24527189
fbshipit-source-id: bdec099f16b3d8c97686975a1f769db4d2c0d832
Summary:
Changelog: [internal]
ScrollTo command needs to clamp the value in order to not scroll out of content view of scroll view. Paper does the same thing.
Reviewed By: JoshuaGross
Differential Revision: D24526992
fbshipit-source-id: 47c48ecb01f4ae40791306016dd7847079263128
Summary:
Fabric should be inserting Views into the hierarchy in the correct order based on z-index already, so there should be no reason to enable this mechanism.
At best it's a perf pessimisation and at worst it could be causing consistency issues or crashing (TBD). Most likely this is a noop.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24512203
fbshipit-source-id: b9336240ef8506742bcbd8d08fc8b830f82cdfe2
Summary:
Our NativeModule spec parser parses the TurboModuleRegistry.get<Spec>(...) calls to figure out what the name of the NativeModule is. The parser assumes the argument is a string literal. Therefore, we should lint to validate this case.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24500412
fbshipit-source-id: 5aa5e9255db5a2e0cd86d6dd96e6787caa673fc4
Summary:
TurboModule specs should have exactly one TurboModuleRegistry.get or TurboModuleRegistry.getEnforcing call. When a JS file contains more than one call into TurboModuleRegistry, this lint rule will report an error on all calls.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24499286
fbshipit-source-id: 2c47185165a2a81c4b7b7ad9a7b8458e9aa8c018
Summary:
This diff guts the React Native Modules ESLint rule, and makes it instead call into the NativeModule spec parser. After calling into the parser, the lint rule loops over all collected errors, and reports them.
## Benefits
- There is now one source of truth of what is a "correct" NativeModule spec: The NativeModule spec parser.
- Every change we make to the NativeModule spec parser will reflect in the lint rule. We have a number of changes planned for the NativeModule parser that will change what it means for a NativeModule spec to be correct. These changes now won't have to be duplicated in the ESLint rule.
- The linter will *never* show any false positive errors. If there's an error in the linter, you *need* to fix it. Otherwise, the codegen *will* fail. This is huge. Previously, people were used to ignoring the linter, because it over-reported errors. This behavior won't slide after this stack lands.
NOTE: This will run the NativeModules parser on all our NativeModule specs. We may have to check the specs, or the parser. Therefore, this could take some time to land.
## How does the lint rule work now?
In every JavaScript file, the ESLint rule looks for `CallExpression` AST Nodes. Once it detects a `CallExpression` that corresponds to a `TurboModuleRegistry.get` or `TurboModuleRegistry.getEnforcing` it:
1. Marks the file as a TurboModule spec
2. Validates the `CallExpression` to verify that it is called with the <Spec> type parameters (i.e: like this: TurboModuleRegistry.get<Spec>(...)).
When we're done the visition for the JavaScript file (i.e: in `Program:exit`), if the JavaScript file was a TurboModule spec:
1. Report a lint error if the filename doesn't start with Native.
2. We parse the source using flow-parser, and run the NativeModule spec parser on it. We capture all ParserErrors and report them via ESLint.
## When can I start using this lint rule in VSCode?
I made the ESLint VSCode plugin use flow-node in D24454702. It'll take 3-4 weeks for this change to be shipped to everyone's VSCode. After the update, the linter will automatically start working in VSCode. Until then, we'll only get feedback on Sandcastle/Landcastle for lint rule violations.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24379783
fbshipit-source-id: 222778d8a84d7010eb7b3ad71b34a7fe1f52e509
Summary:
I believe the old method of queueing these operations for Fabric is causing crashes because "connectNode" is on a separate JS queue from setting up nodes.
In hindsight, this seems silly. We must ensure that nodes are created before they're connected, and we weren't doing that?
Using a single queue is conceptually simpler, should be easier to reason about, and should fix some crashes.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24521951
fbshipit-source-id: f6c38ac0023faa28414063d8b96daf32ba95524d
Summary:
I want to see if the child count changes before/after this method execute; that would help pinpoint the cause of these crashes.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24510064
fbshipit-source-id: 11b4baf15bc5e0beb23d65546605b378d84d1b20
Summary:
The method `imageURLLoaderForURL` can be called from multiple threads. This adds a mutex to make sure that _loaders is initialized with a non-nil value only once.
We'll only lock this mutex at one point in time as long as `_loadersProvider()` gives a value, so the mutex doesn't affect performance.
Changelog: [iOS][Fixed] Synchronize RCTImageLoader loaders initialization
Reviewed By: fkgozali
Differential Revision: D24513083
fbshipit-source-id: b89ef8a82729eda508162b01f7fdaa8a291f40d0
Summary:
On October 27, 2020, Node 14 will enter active LTS status, and Node 12 will enter maintenance LTS status at the end of November.
With these upcoming dates in mind, I am bumping the Circle CI NodeLTS executor to use Node 14, and the NodePrevLTS executor to use Node 12.
With these changes, Node 12 will be hereto considered the minimum supported version.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Changed] [JavaScript] - Bump minimum Node version to 12 LTS
Pull Request resolved: https://github.com/facebook/react-native/pull/30237
Test Plan: Circle CI
Reviewed By: PeteTheHeat
Differential Revision: D24513133
Pulled By: hramos
fbshipit-source-id: 2651d954d546e5f7c9e40b54ef3ee976ad9b2d5e
Summary:
With the release of Node 15 on October 20, 2020, the `nvm i node` command started installing Node 15 by default during the Docker setup step on Circle CI. This version of Node now requires user interaction down in `npx envinfo@latest` during the same step.
With these changes, we ensure we automatically accept the installation of any necessary packages.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[CATEGORY] - Internal
Pull Request resolved: https://github.com/facebook/react-native/pull/30235
Test Plan: Circle CI.
Reviewed By: fkgozali
Differential Revision: D24510043
Pulled By: hramos
fbshipit-source-id: bce72fd8ea8b0a4df501f75e48984eca0b10a090