Summary:
Changelog:
[General][Changed] - Refactor pressItem, a RNTester util for list based components to not pass state around.
Reviewed By: nadiia
Differential Revision: D25986318
fbshipit-source-id: d0dd85f783a83f73f83cfb1bd19d144c37af9ef9
Summary:
Changelog:
[General][Changed] - Refactor `renderSmallSwitchOption`, a RNTester util for list based components to not pass state around.
Reviewed By: nadiia
Differential Revision: D25986317
fbshipit-source-id: cbbd71cc1b1bab71ecd007980f2813f7a066b3f2
Summary:
Normally, UIScrollView adjust `contentOffset` inside `setContentSize` to prevent over-scroll. In most cases, it works fine but in a case when the ScrollView is in the middle of user interaction the over-scroll is perfectly acceptable. So, to work around this issue we disable `setContentOffset` when we update `contentSize` and the gesture interaction is in progress.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D26001133
fbshipit-source-id: 19b67289b2c142facd4f516a740180c87f90bc2d
Summary:
This refactors MountingManager into a minimal API that shims into a more fully-featured SurfaceMountingManager. The SurfaceMountingManager keeps track of surface start/stop, surface ID, and surface Context.
This solves a number of issues around (1) race conditions around StopSurface/StartSurface, (2) memory management of Views, (3)
Concrete improvements:
1. Simpler to reason about race conditions around StopSurface/StartSurface.
2. 1:1 relationship between SurfaceId and all Views/tags.
3. When surface is stopped, all descendent Views can be GC'd immediately.
4. Fixed separation of concerns and leaky abstractions: surfaceId/rootTag and Surface Context are now stored and manipulated *only* in SurfaceMountingManager.
5. Simpler StopSurface flow: we simply remove references to all Views, and the Fragment (outside of the scope of this code) removes the RootView. This will trigger GC and we do ~0 work. Previously, we ran a REMOVE and DELETE instruction and kept track of each View in a HashMap. Now we can simply delete the map and move on.
The caveat: NativeAnimated (or other native modules that go through UIManager). APIs like `updateProps` currently uses only the ReactTag and does not store SurfaceId. This is a good argument for moving away from ReactTag, at least in its current incarnation, but: for now this requires that you do a lookup of a ReactTag across N surfaces (worst-case) to determine which Surface a ReactTag is in.
So, to summarize, the "con" of this approach is that now `getSurfaceManagerForViewEnforced` could be slower. It is used in:
* NativeAnimatedModule calls `updateProps` through UIManager
* FabricEventEmitter calls `receiveEvent` on FabricUIManager directly
* On audit, I could find zero native callsites to `sendAccessibilityEvent` through UIManager
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26000781
fbshipit-source-id: 386ae40c4333f8c584e05818c404868dbee6ce73
Summary:
See title. Not used in this diff; see next diff in stack.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26001014
fbshipit-source-id: 475eb265f1c27bd9aff978a49652764a50287e47
Summary:
NativeModule schema targets will now take the form '{library_name}-codegen-modules-schema'.
NOTE: Will launch the necessary diffs to make the same refactor in our component codegen.
Changelog: [Internal]
Differential Revision: D25968071
fbshipit-source-id: 1d7c9f4679e4ae6c26c9a29a74fa7b7ea76460eb
Summary:
IntegtationTestsApp looks for a display name of each component to register it in the AppRegistry, along with show its name in the tests lists. Add the missing display names back to these tests.
## 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
-->
[iOS] [Fixed] - Fix a couple of missing display names in integration test components
Pull Request resolved: https://github.com/facebook/react-native/pull/29902
Test Plan: All integration tests now show up in the list.
Reviewed By: TheSavior
Differential Revision: D25998969
Pulled By: appden
fbshipit-source-id: 45e5544c8df60a67615b75d85195f3080a42a0b8
Summary:
MountingManager keeps a map of tags to Views, and attempts to clean it up by (1) deleting tags when they're explicitly deleted, (2) recursively deleting all Views when the View hierarchy is torn down.
However, there appear to be.... substantial gaps here. In tests, when navigating between screen X -> screen Y -> back to X (triggering a StopSurface), each "StopSurface" resulted in 200-600 Views being leaked (!).
What is causing these leaks? Well, for one, the "dropView" mechanism isn't perfect, so it might be missed Views. Second, Views don't always guarantee that `reactTag == getId()`, so that could result in leaks. Third, View preallocation on Android complicates things: Views can be preallocated and then never even inserted into the View hierarchy, so DELETE mutations could never be issued. Fourth, StopSurface is also complicated on Android (largely because of View preallocatioAndroid (largely because of View preallocation).
So, I introduce a new mechanism: keep a list of all tags for a surface, and remove all tags for a surface when the surface is torn down. This should be fool-proof: it handles preallocation and normal creation; it can handle deletes; and we're guaranteed that tags cannot be added after a surface is stopped.
Is this overly complicating things? Well, hopefully we can simplify all of this in the longterm. But until we get rid of View Preallocation, it seems like we need this mechanism - and View Preallocation might be around for a while, or forever.
Other thoughts: it's possible that using other data-structures could be more efficient, but I'm guessing the perf implications here are marginal (compared to the insane amount of memory leaks we're fixing). It could also simplify things to have a SurfaceMountingManager interface that implies all actions happen on a specific surface, including teardown.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25985409
fbshipit-source-id: f55b533770b1630c6c2a9b7a694d953aa3324428
Summary:
Since `RCTNetworking` overrides init, it requires main queue setup. Native module infra currently throw a yellowbox if a module forgets it.
This diff fixes that.
{F361182429}
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25962402
fbshipit-source-id: d847117cbfe0a191dc1882898711693c6fda68cd
Summary:
Even though CommitHooks, in general, should be implemented as part of the Core and explicitly registered inside the code, sometimes it's handy to pass specify some additional commit hooks during Scheduler initialization (e.g. hooks that are parts of DevEx tools). Now it's possible.
We will use it soon in Timeline feature.
Changelog: [Internal] Fabric-specific internal change.
Differential Revision: D25920577
fbshipit-source-id: 00f33b7b576c9812afd70c364b5cceb3521da16b
Summary:
Today I created a project with RN 0.63 and it failed to **pod install**, and after some investigation I found following error. It's caused by Xcode 12 because it dropped support for 32 bit architectures, but following script sets architecture to armv7 which is 32bit.
This will change architecture to arm64, 64 bit.
```
configure:3727: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.1.sdk conftest.c >&5
clang: error: invalid iOS deployment version 'IPHONEOS_DEPLOYMENT_TARGET=12.0', iOS 10 is the maximum deployment target for 32-bit targets [-Winvalid-ios-deployment-target]
configure:3731: $? = 1
```
## 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
-->
[IOS] [Changed] - fix glog pod install with Xcode 12
Pull Request resolved: https://github.com/facebook/react-native/pull/30372
Test Plan: Create a new project using react-native init, and it'll fail to do pod install. When this change applied, it'll do it successfully.
Reviewed By: fkgozali
Differential Revision: D25957237
Pulled By: PeteTheHeat
fbshipit-source-id: 4ecfaee29da4171fb190352927ec47dbb73fbaa0
Summary:
The old generate-tests mode for checking generics is now defaulted to `false`, and the code path that the setting supports is getting deleted, so .flowconfigs no longer should specify that `generate-tests=false`
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D25958102
fbshipit-source-id: a15926f04bd8cd4337f489cddbb8e385821243bc
Summary:
The current version of Flow fails to report some errors in library definitions. I'm
working on a Flow fix that would surface these errors. In preparation for this, this diff:
* replaces `FbtErrorListener` (missing) with `IFbtErrorListener` in fbt.js
* fixes typos in several files
* suppresses missing names with `[cannot-resolve-name]`
* adds `sourceMapTarget` option in babel-generator
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D25839533
fbshipit-source-id: 947207db9238aa10663616d59080440d2ac6f243
Summary:
Original commit changeset: 3ed8e78e31b0
Backing-out D25938851 (69b3016171) and D25935785 (bdea479a1f). Based on analysis documented in T83141606, I believe this issue should be fixed in JS.
Additionally, this crash actually has nothing to do with (un)flattening or the differ; it is a side-effect of stale ShadowNodes being cloned, which I believe is either UB or a contract violation. Either way, it should probably be fixed either in JS, or in node cloning. So this isn't the right solution for this issue and should be reverted.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25949569
fbshipit-source-id: 8cf1094a767da98fff4430da60d223412e029545
Summary:
This diff changes the type of the SwipeRefreshLayoutManager.size prop from Int to String in Fabric.
The current implementation of this prop allows JS developers to use "int" type when fabric is enables and "int or string" types when using Fabric is disabled.
Since long term we want to only support "string" type for this prop, I'm changing the type of the prop to be String.
After my diff Fabric will start supporting only "string" types, non fabric screens will keep supporting "int or string" values.
**Will this break production?**
No, because there are no usages of RefreshControl.Size prop in fbsource
**What about if someone start using this prop next week?**
IMO It's very unlikely because of the nature of this prop, I will be monitoring next week and if there's an usage it will be detected by flow when trying to land D25933457.
Changelog: [Android][Changed] - RefreshControl.size prop changed its type to string, the valid values are: 'default' and 'large'
Reviewed By: JoshuaGross
Differential Revision: D25933458
fbshipit-source-id: 55067d7405b063f1e8d9bb7a5fd7731f5f168960
Summary:
As a follow up to D25935785 (bdea479a1f), there are more cases where nodes are "recreated" due to unflattening.
This has no impact anywhere (yet) as far as I'm aware, but could fix the same issues as D25935785 (bdea479a1f) (on Android only).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25938851
fbshipit-source-id: 3ed8e78e31b0b911e274ecc395a43bc6cb6d5f9d
Summary:
It is the correct way to deal with the measure function.
I believe it can fix the crash we see with TextInput state update. The crash is probably caused by invalid value of `shadowNodeRawPtr` in `YogaLayoutableShadowNode::yogaNodeCloneCallbackConnector`.
It's hard to reconstruct the full chain of events but I think it's related: Yoga's dirty flag influences cloning, so the improper setting of this flag can misalign "natural" ShadowNode cloning (influenced by changes in the tree) and YGNode-initiated cloning (triggered by layout process).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25937710
fbshipit-source-id: a4e7c9dd8f5e6598fc662f4c6ee8061fd795e20d
Summary:
This implements the `MeasurableYogaNode` trait in `YogaLayoutableShadowNode`. We had this trait from the very beginning but never used it. Now, if the trait is specified, `YogaLayoutableShadowNode` will set the measure function for the node and dirty it during cloning.
Previously, we used (and still use) a dedicated method for setting up the measure function - `YogaLayoutableShadowNode::enableMeasurement()`. The problem with it is that to make it work we have to dirty the Yoga node every time we clone it. And the only proper way to do this in the `YogaLayoutableShadowNode` constructor because if we do it later ancestor nodes could not observe this and react to this. Therefore we have to have a trait for it.
The plan is to use it for TextInput first to fix a crash (see the next diff). After we confirm it works fine, we will replace all the usages of `enableMeasurement` with the new trait.
This diff also renames the other two yoga-related traits (to make them less verbose and look unified), adds more comments, and asserts.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25937711
fbshipit-source-id: fafbd5d62537ac09e02ffbfd56adab6d629d791d
Summary:
Android has some optimizations around view allocation and pre-allocation that, in the case of View Unflattening, can cause "Create" mutations to be skipped.
To make sure that doesn't happen, we add a flag to ShadowViewMutation (in the core) that any platform can consume, that indicates if the mutation is a "recreation" mutation.
It is still a bit unclear why this is needed, in the sense that I would expect props revision to increment if a view is unflattened. However, there is at least one documented reproduction where that is *not* the case. So for now, we'll have a hack pending further investigation.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25935785
fbshipit-source-id: 6fb4f0a6dedba0fe46ba3cd558ac1daa70f671f5
Summary:
MountItem logging was broken in D25841763 (4076293aa1), by adding a field that wasn't logged.
Fixed here.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25934390
fbshipit-source-id: 2db4a809b150ad33ddf886db1db6585889bd7013
Summary:
CommitMode allows customizing the side-effects of commit operations. In `Suspended` mode, the results of commit operations will not be passed down to a MountingCoordinator which will result in skipping the mounting phase completely.
This is one of the core elements of the Pre-rendering infrastructure.
Changelog: [Internal] Fabric-specific internal change.
Differential Revision: D24290773
fbshipit-source-id: c10ec20d13f3131fc632352ef22f4465c9dfb3c2
Summary:
Forgot to delete these snapshot tests in D25915169 (e67fc7cada). They are no longer necessary, because we're deleting the JS TurboModule codegen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25920310
fbshipit-source-id: 66f6fa3fcba5b53210798a204e4f76e4595b3f25
Summary:
This diff refactors the intialization of Fabric in order to avoid loading UIManagerModule as part of the creation of FabricJSIModuleProvider.
One caveat is that now we are not taking into consideration the flag mLazyViewManagersEnabled
master/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/CoreModulesPackage.java177
if (mLazyViewManagersEnabled) {
As a side effect of this diff view managers will be initialized twice if the user has fabric and paper enabled
This diff was originally backed out in D25739854 (4984c1e525) because it produced a couple of bugs:
https://fb.workplace.com/groups/rn.support/permalink/4917641074951135/https://fb.workplace.com/groups/rn.support/permalink/4918163014898941/
These bugs are fixed by D25667987 (2e63147109).
This diff was reverted a couple of times because of the change in the registration of eventDispatcher. That's why I'm gating that behavior change as part of the "StaticViewConfig" QE.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D25858934
fbshipit-source-id: a632799ccac728d4efca44ee685519713b4a7cbb
Summary:
Changelog:
[Internal][Fixed] - Add a default value for the cache breaker value
Reviewed By: fkgozali
Differential Revision: D25907137
fbshipit-source-id: 243346cbc67d1a85519bb469f4d68d61676ba547
Summary:
## Problem
Suppose we have this NativeModule spec, that uses Object literals that contain a property called "id":
```
export interface Spec extends TurboModule {
// Exported methods.
+getConstants: () => {|
id: string,
|};
+getObject: (arg: {id: Object}) => Object;
}
```
For both object literals, we'll generate C++ structs, backed by NSDictionaries. The method in each struct will be named "id_" to avoid a name clash with ObjC's `id` identifier. However, calling that id_ method should still access the "id" property in the corresponding NSDictionary.
## Expected Output
```
inline id<NSObject> JS::NativeSampleTurboModule::SpecGetObjectArg::id_() const
{
id const p = _v[@"id"];
return p;
}
inline JS::NativeSampleTurboModule::Constants::Builder::Builder(const Input i) : _factory(^{
NSMutableDictionary *d = [NSMutableDictionary new];
auto id_ = i.id_.get();
d[@"id"] = id_;
return d;
}) {}
```
## Actual Output
```
inline id<NSObject> JS::NativeSampleTurboModule::SpecGetObjectArg::id_() const
{
id const p = _v[@"id_"]; // <-- HERE!
return p;
}
inline JS::NativeSampleTurboModule::Constants::Builder::Builder(const Input i) : _factory(^{
NSMutableDictionary *d = [NSMutableDictionary new];
auto id_ = i.id_.get();
d[@"id_"] = id_; // <-- HERE!
return d;
}) {}
```
NOTE: This code was generated by running `jf get --version 119805822 && buck build //xplat/js:FBReactNativeSpec_Sample-flow-types-ios --show-output`
This diff fixes this mistake.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25907493
fbshipit-source-id: cb37cbf49db4f871b3f4046f7397a7b1b7df0357
Summary:
Restore the `android_hyphenationFrequency` attribute in the view config for `Text`. This was accidentally dropped by D23708205 (06ce643565) (06ce643565).
Changelog:
[Android][Fixed] - Restore `android_hyphenationFrequency` on `Text`.
Reviewed By: mdvacca
Differential Revision: D25889971
fbshipit-source-id: 622eef618370efdd9a8b060ccd3272e25de218fa