Summary:
This diff adds `TraceUpdateOverlay` native component to RN `AppContainer.js`. This will enable the overlay when the build is in DEV environment and the DevTools global hook exists. It also closed gap between the JS dev mode and native dev support flag, so that the native component will be available when used by JS.
## Update (2/13/2023)
Instead of the original approach where I put a default value to the devsupport manager flag, I did ui manager check from JS and make sure the native component exists before using it. This is cleaner.
## Problem
Since the `AppContainer` is being used by all RN apps, we need to make sure the native component is registered in UI Manager of the RN app when it's used. Currently, the native component lives in the `DebugCorePackage.java`, which is added to the RN app [when the `DevSupportManager` is used](https://fburl.com/code/muqmqbsa). However, there's no way to tell if an app is using dev support manager in JS, hence there are gaps when the JS code uses `TraceUpdateOverlay`, vs when the native code registered the native component. This issue caused test error in [ReactNativePerfTest](https://fburl.com/testinfra/j24wzh46) from the [previous diff](https://fburl.com/diff/bv9ckhm7), and it actually prevents Flipper from running this properly as shown in this video:
https://pxl.cl/2sqKf
The errors shown in Flipper indicates the RN surface from the plugin is also missing `TraceUpdateOverlay` in its UI Manager:
{F869168865}
## Solution
To fix this issue, we should find a way to expose if the app is using dev support manager in JS. Or we should set to use DevSupportManager whenever it's a dev build as claimed in JS. I will try to find some way to achieve either one of this. I am open to suggestions here for where I should add the native component to. Given that it's used in the AppContainer, and any app could be built in development mode, I don't want to make people to manually add this native component themselves.
## Alternatives
There are some other approaches that could mitigate the issue, but less ideal:
For the test issue
1) Add `setUseDeveloperSupport(true)` to [ReactNativeTestRule.java](https://fburl.com/code/7jaoamdp). That will make the related test pass by using the DevSupportPackages, which has the native component. However, it only fixes tests using that class.
2) Override the package for [ReactNativeTestRule.java](https://fburl.com/code/b4em32fa), or `addPackage` with more packages including the native component. Again this only fixes this test.
3) Add the native component to the [`MainReactPackage`](https://fburl.com/code/nlayho86), which is what I did here in this diff. This would fix more cases as this package is [recommended to be used](https://fburl.com/code/53eweuoh) for all RN app. However, it may not fix all the cases if the RN app didn't manually use it.
4) Add the native component in the [`CoreModulesPackage`](https://fburl.com/code/lfeklztl), which will make all RN apps work, but at the cost of increase package size when this feature is not needed. Or, we could argue that we want to have highlights on trace updates for production build as well?
Changelog:
[Internal] - Enable TraceUpdateOverlay to RN AppContainer
Reviewed By: rubennorte
Differential Revision: D43180893
fbshipit-source-id: a1530cc6e2a9d8c905bdfe5d622d85c4712266f8
Summary:
This fixes some style errors found by dtslint, along with some test cases for StyleSheet.compose() where the recent change made it slightly too permissive when explicit return types are given. I also added runs of the TS tests to a script which runs in sandcastle so we can catch this at diff-submission time in the future.
Changelog:
[General][Fixed] - Fix Errors with TypeScript Tests
Reviewed By: lunaleaps
Differential Revision: D42085257
fbshipit-source-id: 7e6ca49d3c3aef822c61c97ecc07b55b0a949d51
Summary:
These are all documented on the website and seem to likely work in OSS to at least some extent. Add the missing types corresponding to functions exported from AppRegistry.
Changelog:
[General][Fixed] - Add missing types for AppRegistry
Reviewed By: GijsWeterings
Differential Revision: D42036018
fbshipit-source-id: 0728d6c5602a50e50f1eaf7f76c54ab47dcb0124
Summary:
This is exported from the RN entrypoint and documented on the RN website, so we should give types for it.
Changelog:
[General][Fixed] - Add type for RootTagContext
Reviewed By: christophpurrer
Differential Revision: D42040806
fbshipit-source-id: cb8cdf557098ddbe33c143b7ab5d80bda7f80a6e
Summary:
changelog: [internal]
To make migration to the new architecture more straight forward, this change makes `UIManager.measure`, `UIManager.measureInWindow`, `UIManager.measureLayout` and `UIManager.measureLayoutRelativeToParent` functions backwards compatible. Users will not have to make any change to continue using the APIs.
This will make [Migrating .measure*()
](https://reactnative.dev/docs/new-architecture-library-intro#migrating-measure) in the migration guide optional.
Reviewed By: yungsters
Differential Revision: D41613050
fbshipit-source-id: 3c65ced231590243d118fbc120a87b08d5261da0
Summary:
changelog: [internal]
Fix Flow types for UIManager measure functions.
Host platform does not accept null value for reactTag parameter. It errors if null is passed. This moves error closer to developers as Flow can catch it.
Reviewed By: javache
Differential Revision: D41614452
fbshipit-source-id: 2216c195808b8a1aae58c7cb2fa15be8a073e222
Summary:
This was left over from an old codemod.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D41154548
fbshipit-source-id: 0b5fb3e78491b66ebaf13555f80e0265a25dc7d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35169
This reorganizes typing structure a bit.
`Utilities.d.ts` was originally added for utilitiy types but I ended up leaving it a grab bag of types that didn't belong to any individual bit of code. Out of what is in it right now, `Insets` was actually public, and seems to have been imported.
We also run into files around the renderer which are [currently overwritten](e286da25fc/Libraries/Renderer/implementations/ReactNativeRenderer.d.ts) by the React sync script.
Finally, all of the top-level imports of `Utilities` were auto-generated by VS Code, but fail in real apps. I think this is because our tsconfig sets a `baseUrl` to allow resolution from the types folder, so the tooling in the RN repo will use that, but it breaks in real apps that don't have that mapping.
This splits all these up into a couple separate directories that are hopefully easier to reason about, and removes `Omit` which has been a builtin type for quite some time (we were actually already using built-in `Omit`).
Changelog:
[General][Fixed] - Fixup TS Organization
Reviewed By: cipolleschi
Differential Revision: D40932319
fbshipit-source-id: 0b6e3e3eda603885b4dc01dcb9f5233aa546d128
Summary:
This diff adds explicit type arguments to polymorphic function calls that do not constrain their types. This codemod will reduce the error burden that will come in a future version of flow.
This specific diff was generated by running:
```
flow codemod annotate-implicit-instantiations --write .
flow --json --pretty | jq '.errors | .[] | .message | .[] | .loc |.source' | sort | uniq | sed -e 's/"//g' | xargs hg revert
hg st -n | xargs grep "generated" | sed -e 's/:.*//g' | xargs hg revert
arc f
```
So these are the codemod results that introduced no new errors and no generated files.
Changelog: [Internal]
drop-conflicts
Reviewed By: SamChou19815
Differential Revision: D40413074
fbshipit-source-id: 42b52719978f1098169662b503dbcfd8cefdad53
Summary:
changelog: [internal]
Removing listener on detached node leads to a red box, if the said node is `DiffClampAnimatedNode`. This is because calling `AnimatedNode.__getNativeTag()` makes native module call and creates node in native. This node is not completely initialised and red boxes because `[RCTAnimatedNode parentNodes]` is nil when it shouldn't be.
The fix is make sure all listeners are removed before node is destroyed. It is logically correct thing to do. The fix is global, for all components using `DiffClampAnimatedNode`.
Reviewed By: yungsters
Differential Revision: D40381895
fbshipit-source-id: 4f558faf8101b70552f30e6360998e902aacbc83
Summary:
[Changelog]: Internal
integrate the offscreen component when we render an application that is configured to do so
Reviewed By: rubennorte
Differential Revision: D39458472
fbshipit-source-id: 9bd492ca258723cb9cf0b7e4f6c9b0005554e91e
Summary:
It doesn't make sense to have checks for whether we're profiling or not in `__DEV__` blocks, where we shouldn't be profiling in the first case.
We're going to remove the `global.__RCTProfileIsProfiling` flag in favor of a function that checks if we're profiling in real time (as opposed to checking if we're profiling only on startup, which is what that value does). This is just to make that migration easier without having to migrate callsites that are bad practices anyway.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D40095841
fbshipit-source-id: ba6cdf4bef8a4c169c50a974671c21144ccee92b
Summary:
React Native's TS definitions are currently mostly stored in one monolithic file. This change splits the definitions up to correspond to the source files they came from, and are placed next to the source files. I think this should help inform, and make it easy to update the TS declarations when touching the Flow file.
I noticed as part of the change that the typings have not yet removed many APIs that were removed from RN. This is bad, since it means using the removed/non-functional API doesn't cause typechecker errors. Locating typings next to source should prevent that from being able to happen.
The organization here means individual TS declarations can declare what will be in the RN entrypoint, which is a little confusing. Seems like a good potential next refactor, beyond the literal translation I did.
Changelog:
[General][Changed] - Place TS Declarations Alongside Source Files
Reviewed By: lunaleaps, rshest
Differential Revision: D39796598
fbshipit-source-id: b36366466fd1976bdd2d4c8f7a4104a33c457a07
Summary:
This diff updates the documentation for enableCppRenderSystem feature flag
This is a follow up of D38725771 (399907fe4a)
changelog: [internal] internal
Reviewed By: cortinico, makovkastar
Differential Revision: D39558834
fbshipit-source-id: e079ee688a912dfa2670c66e5adf347a902a45e1
Summary:
This diff creates a new Feature Flag to Enable/Disable C++ Render System in JS
Changelog: [Internal] Internal
Reviewed By: sammy-SC
Differential Revision: D38725771
fbshipit-source-id: 3a238781bec427274dbd8f7c045d360135d1803e
Summary:
This diff creates a proxy module to interact with the React Native renderer. The goal of this proxy is to decouple usages of several functions (e.g.: `findNodeHandle`, etc.) from the actual renderer used in an app. This way, we can easily switch between renderers without having to change code depending on it.
This will be useful to remove a specific renderer from an app bundle when it's no longer used (e.g.: Paper on the Facebook App).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D39205975
fbshipit-source-id: 05289c0c3c8cd26d81aa1d2163097c73ec40c6ad
Summary:
Changelog:
[General][Added] - Added an overlay similar to Inspector.js that allows directly selecting elements on RN from React DevTools
This diff updates DevToolsHighlighter into DevToolsOverlay. It now also allows DevTools user to select an element to inspect directly from DevTools.
Depends on https://github.com/facebook/react/pull/25111 to work.
TODOs:
- Currently once an element selected on RN, the inspector toggle isn't turned off automatically.
- Fabric support depends on https://github.com/facebook/react/pull/25118
Reviewed By: lunaruan
Differential Revision: D38815494
fbshipit-source-id: 7e1e3a78f6594960b5dfaec142bafd3ca4b146af
Summary:
Changelog:
[General][Changed] - Copied and refactored the current devtools highlighting code from Inspector into its own module and add to the top level `AppContainer`. The effect is that the highlight stills shows without Inspector opened.
This diff copies the current devtools highlighting logic from Inspector into a module and add to the top level `AppContainer`. The effect is without Inspector opened, the highlight will still show.
## Context
This is the first diff for "Component Tab Automatically Highlight Elements". The idea is to replicate the behavior on Web to RN.
## Behavior
on Web:
- highlight shows whenever an element in the component list is hovered
- Selecting an element doesn't keeps the highlight showing.
on RN (before this diff):
- when RN inspector opens: selecting an element keeps the highlight showing
- when RN inspector closes: stop showing highlihgintg.
on RN(this diff)
- selecting an element keeps the highlight showing
## TODO
- See if highlighting event can be sent on hover, instead of when an element is selected.
Reviewed By: lunaruan
Differential Revision: D38568135
fbshipit-source-id: d168874677d08a9c5526a7f896943579da804565
Summary:
Changelog:
[Internal] Rename AccessibilityInfo.sendAccessibilityEvent_unstable to sendAccessibilityEvent
In Fabric, we want people to use `AccessibilityInfo.sendAccessibilityEvent` instead of `UIManager.sendAccessibilityEvent` for Android. The API is not unstable. There is a test in [AccessibilityExample.js](c940eb0c49/packages/rn-tester/js/examples/Accessibility/AccessibilityExample.js (L959)) in RNTester to confirm that it works.
A search for [`AccessibilityInfo.sendAccessibilityEvent_unstable` in Github](https://github.com/search?q=AccessibilityInfo.sendAccessibilityEvent_unstable&type=Code) shows that it's not being used yet, which makes sense because it's an Fabric API. Therefore it's safe to rename it.
Reviewed By: sammy-SC
Differential Revision: D37901006
fbshipit-source-id: 73f35b09ca8f9337f4d66a431f0a3f815da38249
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
LogBox was using AppRegistry to render on to the screen. Switch LogBox over to using SurfaceRegistry instead.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D37223641
fbshipit-source-id: 59001ad290c1e2c2f14828d38a96f48bd1ab39ca
Summary:
We introduce a few optimizations:
(1) Previous diff: We defer calling any NativeAnimatedModule methods by waiting 1ms before flushing the queue, and debouncing until no flush is requested. Practically, this just means that we'll call NativeAnimatedModule methods N times at once, at the end of a render loop, instead of N times smeared throughout the render loop.
(2) Additionally, instead of calling N methods, we create multi-operation argument buffer and call a single NativeAnimatedModule API, which should essentially throttle NativeAnimatedModule API calls to once-ish per frame. On the native side, this also reduces a lot of overhead associated with scheduling work on the UI thread (we schedule 1 function to run on the UI thread and perform N operations, as opposed to scheduling N functions to run on the UI thread).
TODO:
- implement stubs for iOS
- write gating code so this can be properly tested in VR and in fb4a
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36338606
fbshipit-source-id: 29ac949b53b874683128a76525586c22def3143b
Summary:
Because of the disconnect between the ReactJS render loop and Animated nodes, we don't know when a render loop begins or ends. Historically we haven't cared about that much,
but now for perf reasons we're attempting to batch them. Scheduling a function to execute at the end of the runloop and canceling until nothing interrupts it achieves that.
Impact seems fairly minimal and this should work everywhere (android, ios, etc) but we may want to gate the behavior as it *could* change things in surprising ways.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36338621
fbshipit-source-id: 48e52a1b2e2bcfb3ef13d3abd38d735967356de7
Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Making this change exposes a variety of errors. We can prevent these errors by annotating what we want the type of the empty object to be.
Reduces Xplat error diff to 2.3k
- Announcement: [post](https://fb.workplace.com/groups/flowlang/posts/903386663600331)
- Support group: [Flow Support](https://fb.workplace.com/groups/flow)
drop-conflicts
Format:
```
arc f
```
Sort imports
```
hg l -n | xargs js1 lint --fix --rule 'fb-tools/sort-requires'
```
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D36086696
fbshipit-source-id: 90447279f2e6e38f44189b74ec0297719f7adf58
Summary:
With the new architecture, this diagnostic utility will be helpful to ensure stronger validation of various corner cases at runtime, like handling an early JavaScript exception when loading React Native.
If `global.RN$DiagnosticFlags` is set to a string of comma-separated flags, the util functions will be able to perform additional diagnostics. For now, the accepted flags are:
- `early_js_errors`
- `all`
This is still experimental and may change frequently.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36088407
fbshipit-source-id: 9059d2d081b0f41d049310fb09650416b333ff57
Summary:
Annotate use of `ConcurrentRoot` in React in performance logger.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D34453147
fbshipit-source-id: 813a58ae964e5ae4ddf806a30597ee39d315e800
Summary:
This diff refactors LayoutAnimation to use ReactNativeFeatureFlags.ENABLE_LAYOUT_ANIMATION to enable / disable this feature
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D34349648
fbshipit-source-id: 90d1db6560867e44eeffbf03e5a84edadcdd55f9
Summary:
introduce ReactNativeFeatureFlags file to control FeatureFlags in React Native
changelog: [JS][Added] Create new API to configure FeatureFlags in ReactNative
Reviewed By: JoshuaGross
Differential Revision: D34349458
fbshipit-source-id: 73bb3704fc47e950ee1fcefcfaec1a85dfbcef59
Summary:
Changelog: [Internal]
In the new architecture, when an interop component is being called, log instead of warn/error, since at the moment we expect this to happen often.
Reviewed By: fkgozali
Differential Revision: D34252666
fbshipit-source-id: 971156a1cd9ef9b788f677c49fa2c55bd86ad4fa
Summary:
Changelog: [Internal]
* Rename DummyUIManager to BridgelessUIManager
* Cleanup `RCTVirtualText` & `RCTShimmeringView` since the native changes from T107747313 are already in production, so these two will components always return a viewConfig in prod.
- `console.error` when deprecated Bridge UIManager method are being accessed.
- Make sure new BridgelessUIManager.js has the same method definition as [NativeUIManager.js](https://www.internalfb.com/code/fbsource/[e80c98b816183dcdfde1e81de01ba99aa6e30ed2]/xplat/js/react-native-github/Libraries/ReactNative/NativeUIManager.js?lines=15)
Reviewed By: RSNara
Differential Revision: D34203081
fbshipit-source-id: 99aafc2372b118d0c8cc41f7376e136dabae9bd5