Summary:
The coefficients in the code were incorrect: the default value of the scale should be 1, not 0.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sahrens
Differential Revision: D19101221
fbshipit-source-id: 3b4c3afc692ddb6bf32bf2344a77ec5ca34a06e4
Summary:
There was a reflective call to a non-existent class. It did, however,
exist in the template, so I copied it over from there and updated
the references accordingly.
Pull Request resolved: https://github.com/facebook/react-native/pull/27482
Test Plan:
Built it and ran it. Works again with the latest Flipper desktop app.
Reviewed By: rickhanlonii
Differential Revision: D18933530
Pulled By: passy
fbshipit-source-id: 4515d7baaad9a9fff9a4b66e1cbf8a75889e6e45
Summary:
Refactors `Pressability` so that updates to the configuration are now explicitly committed using `configure()`.
Previously, the configuration was updated implicitly because `Pressability` accepted a series of functions whose closures capture values (e.g. `this.props`). Although these changes typically happen when component instances are "atomically" updated by React, it is not a guarantee. For example, arbitrary instance variables could be used to configure `Pressability`, and they could be muted at any time.
This change makes updates to the configuration of `Pressability` more predictable.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18742620
fbshipit-source-id: d2e96dd1e3643289daab2177199a29f80d17b0bc
Summary:
Setting `padding` for Yoga node dirties it.
In the previous implementation, we did it for all newly cloned nodes. Now we do it only if State actually changes.
This is important because usually, SafeAreaView is a container node; that means that if some descendant of SafeAreaView changes its state, the recloning of all nodes down to root node will cause dirtying SafeAreaView and cause relayout if the whole subtree.
E.g., if we put ScrollView inside SafeAreaView without the fix, onScroll events will cause Yoga relayout (because ScrollView updates own state on debounced onScroll event).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18987158
fbshipit-source-id: a3130c607c37e54ce813113222cd4a3872c58b6a
Summary:
`selectAll:` does not work for UITextView when it's being called inside UITextView's delegate methods.
This is a bug in UIKit and this quite ugly workaround is only a known solution for it.
Changelog: [Bug][iOS] Fixed bug in implementation of <TextInput>'s selectOnFocus prop
Reviewed By: sammy-SC
Differential Revision: D18966755
fbshipit-source-id: 2ba15fa94570d463a2ea3490331fb879611dc6b8
Summary:
All these NativeModules are now: (1) type-safe, (2) TurboModule-compatible.
**Note:** We still need to update `{Catalyst,Work,Fb4a}TurboModuleManagerDelegate` to understand these TurboModules. I'll most likely write up that diff and stack this one on top of it.
Changelog:
[Android][Added] - Make NativeModules TurboModule-compatible
Reviewed By: mdvacca
Differential Revision: D18888735
fbshipit-source-id: 34df64dc70e3f3a0a0303c049861205f9d3fd2ed
Summary:
For NativeModules that don't need to be accessed from JS, we can just have them implement the TurboModule interface. This is enough to make them be instantiated via the TurboModule system.
Changelog:
[Android][Added] - Make Java only NativeModules TurboModule-compatible
Reviewed By: ejanzer
Differential Revision: D18787789
fbshipit-source-id: d513006ffd736621adbd41146ed6280a60a7437e
Summary:
Fixes https://github.com/facebook/react-native/issues/16067
The issue is due to a race between `onLayout` and `onContentSizeChange`, which in general should be fine because there is no expectation of ordering between the two, and only causes issues with certain configurations.
The bug can be triggered if `initialNumToRender` is smaller than needed to fill past the `onEndReachedThreshold` (say the default, 10, is only 580px tall, but it takes 15 to reach the threshold). This will cause an incrementally render of more items to try and fill the viewport. The problem is that if the `onLayout` comes back before the first `onContentSizeChange`, it will first do the state increment to render 20 items and then the stale `onContentSizeChange` callback from 10 items will fire and we'll think that the content size for 20 items is 580px when in fact it's 1160px (which is past the threshold). If those 20 items are also all of our available data, then we'll call `onEndReached` because we think we've rendered everything and are still within the `onEndReachedThreshold`.
The fundamental problem here is the system getting confused when a stale async `onContentSizeChange` comes in after increasing `state.last`. I wish there was a concrete timeframe, but Fabric will give us more flexibility to do things synchronously so hopefully we can avoid class of issues once that roles out.
The fix here simply adds a check to make sure `contentLength` has been set before adjusting the render window so it's not possible to increase the window size before the initial `onContentSizeChange` callback fires.
For completeness, there are a few user-code workarounds to avoid this issue entirely:
1) Provide the `getItemLayout` prop so the list doesn't have to rely on async layout data (you should do this whenever possible anyway for better perf). e.g. for the original snack example, you can just add `getItemLayout={(d, index) => ({length: 58, offset: 58 * index, index})}` since all the rows are height 58 and the issue will no longer repro. Note this is fragile and must be kept in sync with UI changes, a11y font scaling, etc - a more robust approach could be to render a single representative row offscreen and measure it with `onLayout` then use that value.
2) If `getItemLayout` is not feasible to compute for your UI, increase `initialNumToRender` to cover the `onEndReachedThreshold`.
3) And/or add your own logic to protect against extra calls to `onEndReached` as others have suggested.
Changelog:
[General][Fixed] - Fix sporadic issue with onEndReached called on load when not needed
# Test Plan
Adds a new jest test that fails without this fix and succeeds with it.
Reviewed By: TheSavior
Differential Revision: D18966721
fbshipit-source-id: de05d9f072e24a2faf351e7f5d60578a31def996
Summary:
`Fb4a` and `Workplace` use only one product-specific `ReactPackage`, but `ReactInstanceManager` also installs `CoreModulesPackage` and `DebugCorePackage`. These two packages have NativeModules that got converted to the TurboModule system. So, I've added them to the `Fb4aReactPackagesTest` and `WorkReactPackageTest` to ensure that NativeModule conversions in framework-provided packages are also tested.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D18974083
fbshipit-source-id: a98ec28a882ce51597a068ddecf43f5fbb6bfdc6
Summary:
The NativeModules in DebugCorePackage are now TurboModule-compatible. Therefore, we must make this extend `TurboReactPackage`.
Changelog:
[Internal] - Make DebugCorePackage a TurboReactPackage
Reviewed By: fkgozali
Differential Revision: D18974084
fbshipit-source-id: 648b54fefe7f8952666d5a23a9d81cc6bb167b31
Summary:
We're going to migrate our NativeModules to the TurboModule system soon. Therefore, it's no longer safe to assume that all NativeModules are not TurboModules. Also, it's not a good idea to hard-code this stuff if we can calculate the correct values on the fly.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D18980859
fbshipit-source-id: 399a75a72d7f57998b217502ff79d7d911cc5a1c
Summary:
Remove textColor font and textAlignment in RCTBackedTextInputViewProtocol since they're all wired up in defaultTextAttributes already
Changelog: [iOS] [Removed] Remove three properties: "textColor" "font" "textAlignment" from RCTBackedTextInputViewProtocol, unifying the usage into "defaultTextAttributes".
Reviewed By: PeteTheHeat
Differential Revision: D18954292
fbshipit-source-id: 17fd38a824d035843ae59b1b875dd9c48b3fcc9b
Summary:
Update LogBox on iOS to lazily initialize, using a synchronous RCTSurface, behind RCTSharedApplication checks.
This results in faster of LogBox, without keeping around a long lived window in the background, and only used when LogBox is used.
On Android, we still start the react app in the background but we create a dialog when it's shown and then destroy it when it's hidden. Once we have the sync APIs on android we can update it to use the same strategy.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D18925538
fbshipit-source-id: 1a72c39aa0fc26c8ba657d36c7fa7bc0ae777eb9
Summary:
This PR changes gitignore to ignore prebuilt libs in ReactAndroid as a whole, because we added 64 bit platforms and their files are showing up as changes.
## Changelog
[GENERAL] [Changed] - gitignore ReactAndroid prebuilt libs
Pull Request resolved: https://github.com/facebook/react-native/pull/27487
Test Plan: After ReactAndroid build, you won't see prebuilt lib changes in git.
Differential Revision: D18992774
Pulled By: hramos
fbshipit-source-id: 33d3e01f59945dbc18ae4d9e3e3ac4b0e5b5e764
Summary:
We can use the HostComponent type now instead of NativeComponent
Changelog:
[Internal]
Reviewed By: zackargyle, rickhanlonii
Differential Revision: D18871289
fbshipit-source-id: 3c70369c5848dedfc22ca6f6ccbb69d6d60a1330
Summary:
iOS/UIKit prop `safeAreaInsets` sometimes produces values (and calls `safeAreaInsetsDidChange`) that practically the same but differ just enough to make operator `==` return `false`. That causes an indefinite state update loop and dizzying of the interface.
We do the same in Paper component as well.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18964089
fbshipit-source-id: 4c714d2554fdee0f6e999921f69b95676080b8fa
Summary:
It's nice to have those conversions between NSAttributedString and AttributedTextBox in some utils module because:
An empty string must be stored as an empty C++ string, not like an empty NSAttributedString. That allows deferring this property from the object without accessing Objective-C runtime;
It's nice to hide some tedious Objective-C object wrapping/unwrapping boilerplate.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950430
fbshipit-source-id: 842c202f243da17c47bc5cca9df6722cdcec07c5
Summary:
That will allow building a custom caching table for boxed stings to cache text measurements for them in TextLayoutManager.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950428
fbshipit-source-id: 8ceef29543dc6ed540043e32d65f3295030ae90f
Summary:
We need to use that outside of this file, in Fabric's TextInputComponentView to build `defaultTextAttributes` from C++ text attributes.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950433
fbshipit-source-id: c48155f4340b7e9780c35f86ba5155e54f160be1
Summary:
When we designed the Fabric's event priorities we followed the model "let's assign all priorities to all events as they should theoretically be and create a flag that disables sync execution (because we were unsure that it's stable enough". After some experiments, it's clear that this model is not feasible. We realized that we were often not sure about the exact event priority that should be assigned to a particular event. We also realized that the priorities in web work differently compare to RN. And we are not sure how we should ensure ordering among events in different queues with different priorities.
At the same time, we want to use (or experiment with) sync events for in some cases when we sure about desired behavior and/or where async events make no sense.
This diff deletes the macro that disables sync priorities and explicitly assigns async priorities to events that previously had sync ones.
The actual behavior should not change.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950431
fbshipit-source-id: 4033ef63d4e736075b525a693cd514d7b92d5bb0
Summary:
RCTBackedTextInputViewProtocol is a protocol that describes which capabilities must be exposed for some TextInput-like UIView to be compatible with the rest of TextInput infra. We use that in both implementations. In Classic React Native we use Objective-C runtime mechanisms to call many of those methods (via ViewManager's directives); that masked the problem that the protocol was incomplete.
In Fabric, we call all methods normally, so we need to declare all of them here.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950432
fbshipit-source-id: 3cd5cb57a033f7c43fd5f2c10f9706408e8e6d0c
Summary:
Both RCTUITextField and RCTUITextView must maintain the same public interface that describes all possible features that TextInput needs. That features are declared via `RCTBackedTextInputViewProtocol`.
`scrollEnabled` is a part of this protocol. The idea behind this prop was borrowed from `UIScrollView` class (which `UITextView` extends) and implemented for `RCTUITextField` (yeah, implemented as no-op).
In this diff we change the implementation of this prop to be more consistent with original implementation in UIScrollView:
* Now the name of the getter is now `isScrollEnabled`;
* The object now retains the actual value of the prop (even if it ignores that).
We need all those features for Fabric-compatible implementation.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950426
fbshipit-source-id: 50c399d0fbba1be31750dbe4f235a075f86e8c01
Summary:
We need to expose the `multiline` prop in View Manager class to enable Fabric component to use it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950429
fbshipit-source-id: 69b225b24b4512a1ea21381daacbf868a23ccf6d
Summary:
The general rule that we follow in RN is that the *exported* .h files must have only `<>` includes. That allows to use them outside of the library where they are defined. Those files are already exported technically, but without this change cannot be used as exported.
New Fabric text input implementation uses them, so we need to change those includes to have `<>` style.
Changelog: [Internal] Specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950427
fbshipit-source-id: 96cbe4cac9e28761c123bde8ac70464a0078ee6c
Summary:
RCTAssertJSThread is a specific to RCTCxxBridge assert that ensured that the code is executed on JavaScript thread. It was here from the very beginning. Now we need to remove it.
Reasons:
- The overall concept of limiting the execution of JavaScript code to a single thread is gone. Now we think about this as some queue, not thread. Fabric heavily relies on that and that asserts fires in Fabric.
- The assert is already far from being trivial: it checks for a custom executor, and if it's not nil, it does not fire. We can introduce another special flag for Fabric that will also disable that... but that's pointless. Such kinda asserts should not be complex to be useful.
- This asserts was used only in two places, and both of them are not exposed as public API.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18946388
fbshipit-source-id: 1e5fc732abdcb4bff3cfadcba24f7a433f1a480e
Summary:
The js_coverage step has failed on some recent PRs. While we want to continue collecting coverage data, we are not rejecting PRs that decrease coverage at the moment. Failing a PR in this step sends the wrong message, therefore, we should ignore whenever js_coverage fails.
> The actual coverage failures appear to be issues related to coveralls (the coverage service) failing to map the coverage data to a specific repository, not necessarily due to a decrease in coverage.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/27488
Test Plan: CircleCI.
Differential Revision: D18962339
Pulled By: hramos
fbshipit-source-id: 46cbe32c70ecc01324a703073f390dad0de562f4
Summary:
Same as D18048277 but for Fabric text infra.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: PeteTheHeat
Differential Revision: D18950415
fbshipit-source-id: 09701e261ecb871b3624260a36dd607fdb70e717
Summary:
Google recommends to extend AppCompat widgets, and Android Studio suggests the change. This PR changes ReactEditText to extend AppCompatEditText.
## Changelog
[Android] [Changed] - ReactEditText extends AppCompatEditText
Pull Request resolved: https://github.com/facebook/react-native/pull/27039
Test Plan: CI is green
Reviewed By: mdvacca
Differential Revision: D18196901
Pulled By: hramos
fbshipit-source-id: 1484ae3da1be5776d0431dab3d4bb7ddbe5b8b7c
Summary:
This diff refactors ReactContext to use IllegalStateException instead of RuntimeException when applicable.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18901845
fbshipit-source-id: 51ec36824c8402fa2c17e76c55578be44ec8aa15
Summary:
This diff migrates a couple of events callsites of ReactRootView and ScrollView to be compatible with Bridgeless React mode
Changelog: [internal]
Reviewed By: ejanzer
Differential Revision: D18862857
fbshipit-source-id: f8e0d2d684bfaf84e9c138746507bb7728481b18
Summary:
This diff backports warning filter handling to yellow box. I also backported the skipped warning handling so that ignored patterns do not log to the console, same as LogBox.
Changelog: [Internal]
Reviewed By: gaearon
Differential Revision: D18573288
fbshipit-source-id: 5bf8e86f754adc808313d7ed02f98daaf65de98c
Summary:
These arguments were in the wrong order. It should be x,y,width,height,pageX,pageY. It was x,y,pageX,pageY,width,height.
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D18940318
fbshipit-source-id: ebd757648169b1ffbf33b35dded1d505a1c80974
Summary:
ExceptionManagers are created before the `ReactApplicationContext`. Once we make them all TurboModule-compatible, they'll also subclasses `ReactContextBaseJavaModule`. This means that they'll need to be created with `ReactApplicationContext`. Since one isn't available, we'll have to call `super(null)` in their constructor.
Changelog:
[Android][Changed] - Make ReactApplicationContext nullable as the constructor argument of ReactContextBaseJavaModule
Reviewed By: PeteTheHeat
Differential Revision: D18935950
fbshipit-source-id: a643a10a42cf36a2a2d6fde87795965f16295d43
Summary:
It's possible for us to return no constants from the BlobModule. Therefore, I'm correcting the flow-type.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D18932328
fbshipit-source-id: 2b415d12effd16eda313d5591825c711a20f9ae3
Summary:
Fixes https://github.com/facebook/react-native/issues/26830 by removing version gating around `RCTUserInterfaceStyleDidChangeNotification` sent by `RCTRootView` and observing that notif for `Dimensions` changes.
Also centralizes `RCTUserInterfaceStyleDidChangeNotification` constant definition in new `RCTConstants` file.
Changelog:
[iOS] [Fixed] - `Dimensions` module now updates on initial split screen
Reviewed By: sammy-SC
Differential Revision: D18931098
fbshipit-source-id: e9784be3f544f3b10360fbc2d6ad0324273b1a8f
Summary:
UIScrollView sometimes calls its delegate during its own deallocation and that causes a crash. This change introducing nil-ing the delegate before the deallocation to prevent this.
We already had this implemented in D17924429 but D18752886 broke that. This diff fixes that one more time.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18933934
fbshipit-source-id: 8da22ff4b1fefee712ced25cf0f1c239535554da
Summary:
Outside of __DEV__ the app may still try to use LogBox. We're going to fix that but until we do, if it tries to use LogBox outside of dev render null.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18932666
fbshipit-source-id: ef0f2542a295dc9332cae8b77faed78f8be350fe
Summary:
If redbox flag is disabled, don't initialize LogBox window even if the native module exists. This makes the module noop.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18927309
fbshipit-source-id: 3dc6c08ed537925594cabf77d1142568d47132e9
Summary:
This diff extends the UIManagerHelper class to expose the EventDispatcher associated to a tag / UImanagerType
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862863
fbshipit-source-id: 14ce7a6a33f20a94a6296320924dbe3544eadd85
Summary:
This diff exposes the getJSIModule on the ReactContext class.
This class already has methods to obtain NativeModules and JSModules, it make sense to expose the getJSIModule method too.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862858
fbshipit-source-id: 95fe48c065266060c96fc40a002041ba398b3134
Summary:
This method exposes a method to ReactContext to determine if we are running in Bridgeless mode or not
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18901149
fbshipit-source-id: bdd5ba747381f3bde5f592276b42244ca01ccbb9
Summary:
This diff promotes the UIManagerModule.getEventDispatcher() to the interface UIManager and it implements this method in FabricUIManager class.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862862
fbshipit-source-id: 424f0e601ed1807dbd5d33048daf7dc3bb200dcd
Summary:
`NativeImageEditor` doesn't export any constants. Therefore, `ImageEditingManager` doesn't need a `getConstants()` method. In a subsequent diff (D18888735), I rename all `ReactMethod getConstants()` methods to `Override getTypedExportedConstants()`. This raises an error because the spec for `ImageEditingManager` doesn't contain a `getTypedExportedConstants()` method.
Changelog:
[Internal] - Delete getConstants() from ImageEditingManager
Reviewed By: fkgozali
Differential Revision: D18909419
fbshipit-source-id: 7e4f84f102068aa44bb3d267c66a60c0d0d27404
Summary:
`JSDevSupport.onSuccess` is called in `JSDevSupportModule.getJSHierarchy`:
```
const JSDevSupportModule = {
getJSHierarchy: function(tag: number) {
try {
const {
computeComponentStackForErrorReporting,
} = ReactNative.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED;
const componentStack = computeComponentStackForErrorReporting(tag);
if (!componentStack) {
JSDevSupport.onFailure(
JSDevSupport.ERROR_CODE_VIEW_NOT_FOUND,
"Component stack doesn't exist for tag " + tag,
);
} else {
JSDevSupport.onSuccess(componentStack);
}
} catch (e) {
JSDevSupport.onFailure(JSDevSupport.ERROR_CODE_EXCEPTION, e.message);
}
},
};
```
If you look at the implementation of `computeComponentStackForErrorReporting`, it returns a `string`. The Java NativeModule also accepts a `String` for the argument to `JSDevSupport.onSuccess`. So, I've changed the `NativeJSDevSupport.onSuccess` method signature to match the native implementation (i.e: accept a string).
Changelog:
[General] [Fixed] - Correct argument types of NativeJSDevSupport.onSuccess
Reviewed By: fkgozali
Differential Revision: D18908306
fbshipit-source-id: 1c9a5c6fe5b3a81b25baed520e586ebf7e2514f8
Valentin Shergin
Pascal Hartig
Tim Yung
Ramanpreet Nara
David T. Nguyen
Igor Sugak
Marshall Roch
Spencer Ahrens
Jimmy Zhang
Rick Hanlon
Dulmandakh
brotsky
Eli White
Héctor Ramos
David Vacca
SAEED
Kevin Gozali
