Summary:
Changelog:
[internal]
following the recommendation in https://fb.workplace.com/groups/474291069286180/posts/6540719469309946
in order to unit test classes that use SurfaceHandler, we need to be able to mock it somehow - since the class is final we aren't able to do that. in this diff, we convert the function that we need to stub / listen to to a virtual function so we can mock it.
the alternative is to keep this class final, and create another abstract interface that this will extend from. however, this class is quite large and that would have a lot more boilerplate and updation of callsites, so this simpler approach seems better.
Reviewed By: sammy-SC
Differential Revision: D30578928
fbshipit-source-id: 4a63396f049c44753986d15f1ac64332b2a8393a
Summary:
This diff extends the FabricUIManager.getInspectorDataForInstance to return the props of the React Native component associated to the view passed as a parameter.
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D30095406
fbshipit-source-id: 50fdba6636a1f5042dbc113e341c3cb2534a1b04
Summary:
This diff fixes a NullPointer that was being thorwn when hierarchy values are null
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D30095407
fbshipit-source-id: b0a13661b4506cf94eeb5d99923d4c12cba0f972
Summary:
Unfortunately, parsing some props requires stateful context - namely, PlatformColor on Android. We explored several different options but they all seemed inferior to the approach of using ContextContainer, and most would require using global state.
By introducing this change everywhere as early as possible, we can avoid later pain. It is likely that some prop, on some platform, will require this mechanism. We'll be ready for it!
Because we can pass a constref of the ContextContainer through to all props and because the context and context data is never retained by prop parsers, perf and memory hit should be ~0.
This diff contains core changes only. Leaf changes to all props structs and conversions files will be in next diff(s).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29838789
fbshipit-source-id: f5090e7f02eb6e8fbe0ef4dd201e7d12104a3e3c
Summary:
This diff exposes a new API in FabricUIManager called getInspectorDataForInstance. The goal of this method is to return React metadata for a Native view.
This data will be used from partner teams to build tools that uses React metadata in RN
Data returned from React: P429701924
changelog: [internal] internal
allow-large-files
Reviewed By: JoshuaGross
Differential Revision: D29747864
fbshipit-source-id: 8cb55573be08cb530f7e3c83eed8b4fcf43e7781
Summary:
This diff exposes a new struct InspectorData that will be used by FabricUIManager.getInspectorDataForInstance to return metadata of stacktraces.
See next diffs of the stack
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29764995
fbshipit-source-id: 6a2ab819623e379795e59002be0e4d40ac73b9a6
Summary:
I'm hunting down the source of a perf regression on a screen and think that having these systrace sections could be handy for this and future investigations.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D29802969
fbshipit-source-id: f4030261da8888ddeb32ae41b9cf2b25af6a5583
Summary:
Changelog: [internal]
Remove `RuntimeScheduler` from `SchedulerToolbox` and all of its uses.
`RuntimeScheduler` needs to be allocated before `Scheduler` and therefore its presence in the toolbox is redundant.
Reviewed By: JoshuaGross
Differential Revision: D29134769
fbshipit-source-id: fa00c5dcc4b565d6941e6d742c6aefade37b31c4
Summary:
PreAllocation currently always happens at revision 0 (after ShadowNode creation), and all CREATE mutations are triggered for ShadowNodes at revision 1 or higher (since CREATE mutations are generated by the differ, it means that all ShadowNodes have revision 1 or higher when CompleteRoot is called). This means that between PreAllocation and CREATE, we /always/ expect at least one clone.
It is possible for a node to be "non-view-forming" at revision 0, causing view preallocation to be skipped, and "view-forming" at revision 1 (causing the CREATE mutation to be thrown away, since all CREATE mutations of revision 0 or 1 are thrown away). This causes a crash. It is extremely marginal, but there are repros in the wild.
Thus, I'm introducing one new UIManager and Scheduler delegate method that allows the mounting layer to be notified of clones. If a clone from rev 0->1 results in a node going from non-view-forming to view-forming, we can preallocate then, as well.
This resolves this crash, and allows us to keep experimenting safely with this View PreAllocation optimization. I believe all edge-cases are accounted for.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D29043426
fbshipit-source-id: dff11d3140ded1cbb02a5518a3aeb52dc812cc50
Summary:
The new C++ Differ has been validated on Android and iOS. Delete the old code path.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28904330
fbshipit-source-id: 2e0d8682f6b2a79f9758ed8b7b92809060835815
Summary:
Changelog: [internal]
Add an option to make all measure calls asynchronous.
Reviewed By: JoshuaGross
Differential Revision: D28934444
fbshipit-source-id: 57a320b03add0182b4646b13ed4b692b899ddea3
Summary:
Changelog: [internal]
Introduces synchronous access to the runtime from RuntimeScheduler.
At the moment, this is not used anywhere.
In case RuntimeScheduler isn't defined (controlled by MC), falls back to RuntimeExecutor.
Reviewed By: mdvacca
Differential Revision: D28024380
fbshipit-source-id: 90be36dd390202540ed51940a4396040f043cd90
Summary:
Changelog: [internal]
Pulling out event queue processing to its separate class. We will be adding more logic there so it makes sense to separate it for simplicity and testability purposes.
Alternative names that came to mind: `EventsProcessor`, `EventsDispatcher`.
Reviewed By: JoshuaGross
Differential Revision: D28572283
fbshipit-source-id: 1cb2459f616b9995f66da80d50c401e68002da7f
Summary:
Changelog: [internal]
My suggestion is to simplify event dispatching to only two options, synchronous and asynchronous.
Why?
- Fabric has only been using one queue, `AsynchronousBatched`.
- Batching happens even on `AsynchronousUnbatched`. It just batches events until JS thread starts processing them instead of waiting for the main run loop.
- It will make it easier to reason about the code in the future once we start utilising different priorities for Concurrent Mode.
Reviewed By: JoshuaGross
Differential Revision: D28603472
fbshipit-source-id: 14e3a9c15a012c550dc16a044c31d722051a2bdc
Summary:
Changelog: [internal]
Extend LeakChecker so it is available on Android (or any other platform as it is completely in C++ now).
Reviewed By: JoshuaGross
Differential Revision: D28600243
fbshipit-source-id: c77a003e3ffc6171e61c998508c9f34f10bb65ca
Summary:
While we are still waiting for Android results, we can safely ship this on iOS.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28542478
fbshipit-source-id: 2673cc4bea0edbc7e4211be7bfec9779205d721b
Summary:
Changelog: [internal]
This diff moves all calls to RuntimeExecutor to RuntimeScheduler. The calls are still immediately dispatched. Timing of events will not change.
The goal of this diff is to prepare infrastructure for Concurrent Mode.
Reviewed By: JoshuaGross
Differential Revision: D27937665
fbshipit-source-id: 434d78c95ccf23d8da41186d0dae91bff4eda384
Summary:
Changelog: [internal]
Current implementation of `AsynchronousEventBeat` dispatches lambdas through `RuntimeExecutor` regardless if it has done so previously.
So if `AsynchronousEventBeat::induce` is called 30 times, it will dispatch 30 lambdas.
In `AsynchronousEventBeatV2`, we make sure only single lambda is dispatched to `RuntimeExecutor` at a time.
Reviewed By: mdvacca
Differential Revision: D27940300
fbshipit-source-id: 2bad25c86315c1712b4a1da8c1d4702734cec70f
Summary:
Changes in following diffs will be gated by this feature flag.
The differ in the new file is copied from the current stable implementation and will not be modified until it's deleted.
Changelog: [Internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D27775698
fbshipit-source-id: 03d9518ffd2b1f25712386c56a38bd2b4d839fc2
Summary:
Changelog: [internal]
Add minimal implementation of schedule task. More features and proper scheduling will be added later.
Reviewed By: mdvacca
Differential Revision: D27622138
fbshipit-source-id: b2e4623d38e7217290a6a3c59ccc10a1c13e3a4f
Summary:
This diff extends startSurface and setSurfaceProps methods with the new parameter called displayMode
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D27669847
fbshipit-source-id: c2ddb690ca897e46e00f07b491b91bb2bc8e847d
Summary:
This diff moves DisplayMode out of SurfaceHandler, this is necessary in order to use it from react/uimanager package
changelog: [internal] internal
Reviewed By: ShikaSD
Differential Revision: D27669846
fbshipit-source-id: 274869d8f2907b1b159f51240440acece09a746f
Summary:
This diff updates initial props when DisplayMode changes in Fabric. This method will be called during pre-rendering.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27607586
fbshipit-source-id: 7625943d57a786d6dfe30dd893e27704f51826d2
Summary:
Changelog: [internal]
Add config flags for RuntimeScheduler. Even with the flags, React will not be using it. Further changes on React side will be required.
Reviewed By: mdvacca
Differential Revision: D27616916
fbshipit-source-id: 296a040c2b6dd936dd9582e937e6db75e28f31a4
Summary:
Changelog: [internal[
Introducing RuntimeScheduler. A coordinator of work between native and React.
Reviewed By: mdvacca
Differential Revision: D27616818
fbshipit-source-id: e90d3d9ca8907be99e61f69e62e83cece8155050
Summary:
~Scheduler and ~SurfaceHandler both contain react_native_asserts that trip whenever we reload React Native with Fabric enabled. These asserts trip because of a memory leak in Fabric. These asserts do not run in production. We should fix the memory leak before re-enabling these assertions.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27481220
fbshipit-source-id: 15c3d46f7efab9ed67a70714efe44b74b0acd385
Summary:
Changing back the values of DisplayMode, visible is the default value, it should be 0
changelog: [internal] internal
Reviewed By: ShikaSD
Differential Revision: D27596595
fbshipit-source-id: e5a17e22dc04d380f584bbb816106ab7d3388875
Summary:
Changelog: [Internal] enable support for C++ 17.
C++ 17 in React Native targets.
Short and comprehensive list of C++ features:
https://github.com/AnthonyCalandra/modern-cpp-features#c17-language-features
Reviewed By: JoshuaGross
Differential Revision: D27431145
fbshipit-source-id: e8da6fe9d70e9b7343a8caec21cdbeb043478575
Summary:
In the previous diff, we moved the destruction of a ShadowTree object from `UIManager::stopSurface` method. And the next logical step is to align `UIManager::startSurface` method with the symmetrical approach. Now `stopSurface` accepts a unique pointer to a ShadowTree and `stopSurface` returns it back to the caller; this way we can avoid returning a raw pointer from `startSurface`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D27010533
fbshipit-source-id: b9211fb7e67763cc190d6b8c86cb866d20c6693d
Summary:
Changelog: [internal]
Introducing LeakChecker. A tool that checks if all native components have been cleaned up when surface is stopped.
**Known shortcomings**:
- LeakChecker is only enabled in debug builds and the existence of leaks is logged to console.
- For now, Leak Checker looks at N-1 screen. This is intentional as there is a known limitation of React that doesn't free up all shadow nodes when surface is stopped. Because of this, the use of LeakChecker is not intuitive and I'll work with React team to try to work around this.
- It doesn't help locating the leak, it only informs that leak is present. I'll be looking into ways to help locate the leak.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D26727461
fbshipit-source-id: 8350190b99f24642f8e15a3c2e1d79cfaa810d3d
Summary:
The non-Fabric API has a `blockNativeResponder` param in setJSResponder. Make sure to pass that along in Fabric.
On Android this allows us to respect the flag and do the same thing non-Fabric was doing if `blockNativeResponder` is false. It's not clear yet what the impact is on iOS.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27058806
fbshipit-source-id: aa5074fa46191d78f5292a93d9040ab4bb58ca66
Summary:
As part of stoping a Surface, we have to commit an empty shadow node tree. And to avoid a deadlock we have to do it not under a `linkMutex_`. To do so, we need to move the part that commits an empty tree from UIManager to SurfaceHandler. And this diff does exactly this.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D27010535
fbshipit-source-id: 60cc79b1c81d7340b550e78653737d2cc5bec24d
Summary:
Changelog: [Internal]
Updates `ReactSurface` to use `SurfaceHandler` internally.
This removes most of the internal state in `ReactSurface` and propagates all the calls to the `SurfaceHandler`.
`FabricUIManager` now uses `SurfaceHandler` to start/stop the surface.
SurfaceId is still used for view operations. SurfaceId is also now mutable to play better with existing Android infra.
Reviewed By: shergin, mdvacca
Differential Revision: D26112992
fbshipit-source-id: 52e6860084d739381317035dc3011956d452063c
Summary:
For better cross-platform consistency, migrate usages of NDEBUG to REACT_NATIVE_DEBUG. See flags.h for explanation.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D26695253
fbshipit-source-id: b0ff02416ab208dfd71f71c2b3d83009f40be0a9
Summary:
Changelog: [Internal]
Adds react_debug dependency in Android.mk where it was missing
Reviewed By: mdvacca
Differential Revision: D26617400
fbshipit-source-id: 5ac799269b106eadd881d30490ac34bd2134a9b7
Summary:
See react_native_assert.{h,cpp}. Because of the BUCK+Android issue where NDEBUG is always defined, we use react_native_assert instead of assert to enable xplat asserts in debug/dev mode.
This migrates most of the codebase, but probably not 100%. The goal is to increase assertion coverage on Android, not to get to 100% (yet).
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D26562866
fbshipit-source-id: a7bf2055b973e1d3650ed8d68a6d02d556604af9
Summary:
Building ReactAndroid from source on Windows has recently hit the limitation of maximum path lengths.
At build time, during the `:ReactAndroid:buildReactNdkLib` task, the linker tries to access several of the intermediate binaries located deep in the tmp folder hierarchy, eg.
```
D:\r\ReactAndroid\build\tmp\buildReactNdkLib/local/armeabi-v7a/objs/react_render_components_progressbar/D_/r/ReactAndroid/__/ReactCommon/react/renderer/components/progressbar/android/react/renderer/components/progressbar/AndroidProgressBarMeasurementsManager.o
```
**Suggested fix:** for modules such as `react_render_components_progressbar` and `react_render_components_picker`, rename them to `rrc_progressbar` etc.
**NOTE**: this assumes that the fix from https://github.com/facebook/react-native/issues/30535 is in place. This regression happened while https://github.com/facebook/react-native/issues/30535 has been pending checkin.
**Other mitigations I've tried:**
- setting [`LOCAL_SHORT_COMMANDS`](https://developer.android.com/ndk/guides/android_mk#local_short_commands) for the problematic modules or `APP_SHORT_COMMANDS` for the root project. Turns out those commands don't work on the NDK version RN requires, but even after manually applying a [patch ](https://android-review.googlesource.com/c/platform/ndk/+/1126440) to my local copy of the NDK, these flags had no effect.
- moving the repo directory higher in the file system tree, and using short directory names `D:\r\...` was not enough
- creating virtual drive letters for specific long paths with the [`sust`](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/subst#examples) command is not workable, since they depend on the source folder structure, and get partly generated by the build system, which I can't plug into
- just enabling long path support on Windows is not enough, since the compiler toolchain doesn't support them.
## 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
-->
[Android] [Fixed] - Fix source build on Windows machines vol. 2
Pull Request resolved: https://github.com/facebook/react-native/pull/30776
Test Plan:
Run `.\gradlew installArchives`
Before:
Now:
Differential Revision: D26194286
Pulled By: mdvacca
fbshipit-source-id: 778b5a0515148e2ace19e7902f74301831ebed94
Summary:
We still have usages of "fbsource//tools/build_defs/apple:flag_defs.bzl" in react-native-github. But this should get us closer towards not using the fbsource cell. Hopefully, this is enough to unbreak the test_docker CircleCI build.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D26289304
fbshipit-source-id: 1c6464bb84df4f82f8a797321a73a1ed324e319a
Summary:
This is a Fabric-compliant implementation of `JSResponder` feature. To make it work e2e we also need to update FabricRenderer in React repository. But before we can do this, we need to ship the native changes.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D24630027
fbshipit-source-id: 70c30e1250b554d83862956b536714704093072f
Summary:
The diff implements a way to use `SurfaceHandler` without using `SurfaceHandler` directly for testing and transitioning purposes. If a boolean flag is enabled all calls related to surface management will be redirected to an appropriate `SurfaceHandler` via `SurfaceManager`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D26125955
fbshipit-source-id: 8760c237d486897ea0c32867c921d445a7f24edc
Samuel Susla
Phillip Pan
David Vacca
Joshua Gross
Ramanpreet Nara
Valentin Shergin
Andrei Shikov
Igor Klemenski
