Summary:
The [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) is currently open to implement the [PlatformColor proposal](react-native-community/discussions-and-proposals#126). When that PR was imported into Facebooks internal builds it was found that the change to the `processColor()` function to return an opaque type or `number` instead of just `number` breaks internal components.
This PR is a simplification of the PlatformColor PR only changing the return type of `processColor()` from `?number` to `?number | NativeColorType` where `NativeColorType` is just an empty but opaque type. This will allow changes to be made to these internal components but with less risk than the larger PR.
## Changelog
[General] [Changed] - Add NativeColorType opaque type to normalizeColor() ahead of PlatformColor PR
Pull Request resolved: https://github.com/facebook/react-native/pull/28040
Test Plan: Flow checks, Jest test, iOS unit tests, iOS integration tests, and manual testing performed on RNTester for iOS and Android.
Differential Revision: D19860205
Pulled By: TheSavior
fbshipit-source-id: 799662c6621d3974158b375ccccfa136982c43b4
Summary:
This method isn't necessary for the migration to LogBox because we have a YellowBoxDeprecated module instructing users to use LogBox.ignoreLogs (so no old code should be calling LogBox.ignoreWarnings).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19950302
fbshipit-source-id: 4850884e770f812273978b9a205f5b914e5a9d2f
Summary:
This diff replaces YellowBox with YellowBoxDeprecated, adding warnings for using the module directly instead of YellowBox. Also adds a no-op message for unstable_enableLogBox.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19949700
fbshipit-source-id: 269c341a2cedcdb2f7a80947d3239db078238201
Summary:
This diff replaces YellowBox with LogBox so that it can be deprecated and removed.
After this diff, it will no longer be possible to go back to YellowBox and all paths referencing it will be gone.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19949695
fbshipit-source-id: 28a55866e514020bdcc6854aae565cffbbe8af58
Summary:
Make iOS use Commands instead of UIManager.{focus,blur}. This makes these apis compatible with Fabric and paper at the same time.
Changelog:
[Internal] Switch iOS focus/blur calls to use new commands
Reviewed By: mdvacca
Differential Revision: D19458995
fbshipit-source-id: 8c4aacd41941f54a887aeec1a17d9ce0b6878ab1
Summary:
This makes Android dispatch focus/blur through the Fabric view manager when running in Fabric.
Changelog:
[Internal] Switch Android focus/blur calls to use new commands
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19458362
fbshipit-source-id: 23e1d989ec55bc8abff4279e259f4b6c953ac0a3
Summary:
This diff is just here to make it easier for me to work on the stack. It needs to be ripped out of the stack before landing
Changelog:
[Breaking][General] The `target` field of events is now a native component, not a react tag
Reviewed By: mdvacca
Differential Revision: D19458361
fbshipit-source-id: 1d03a58553cf96dc72f6d1323dfb37b1a8cdca75
Summary:
1/4 of https://github.com/facebook/react-native/issues/28103
## Changelog
[JavaScript][Removed] - Remove leftover `Incremental` component.
Pull Request resolved: https://github.com/facebook/react-native/pull/28107
Test Plan: In RNTester `Incremental` component is no longer used so I modified one of existing examples to use it.
Reviewed By: rickhanlonii
Differential Revision: D19960536
Pulled By: TheSavior
fbshipit-source-id: 791bda7138ac23916957577ed5f5c465c5e96299
Summary:
TextInput’s `InputAccessoryView` was using a [deprecated] prop-type as a Flow type, which TheSavior asked me to fix [here](6ba4b28a22 (r37343692)).
## Changelog
[iOS] [Fixed] - Fixes the `InputAccessoryView.backgroundColor` prop’s typing to use `ColorValue`.
Pull Request resolved: https://github.com/facebook/react-native/pull/28105
Test Plan:
Passes:
```bash
yarn flow-check-ios
```
Differential Revision: D19956401
Pulled By: TheSavior
fbshipit-source-id: 0c16f292b0143e83235a23712a0a7a11b8317f4e
Summary:
This diff replaces some YellowBox references with LogBox so we can remove it.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19948126
fbshipit-source-id: b26ad1b78d86a8290f7e08396e4a8314fef7a9f3
Summary:
Migrates internal calls from ignoreWarnings to ignoreLogs so we can remove YellowBox.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19813781
fbshipit-source-id: 16c7b3f2cd38cba1901eccb4d5b9a2396a37ba1b
Summary:
Moves the LogBox images from base64 data to files since base64 is not supported everywhere.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D19879323
fbshipit-source-id: 2dc03eebfc712ed863ed76322e133fcad5b00bb4
Summary:
ChangeLog: [Both] Adds perf markers for `XMLHttpRequest`s
Makes it easier to see JS-based network operations in performance traces.
Reviewed By: zackargyle
Differential Revision: D19903143
fbshipit-source-id: c5ce60163569e003830d8079cb2b580469d5bd5d
Summary:
This class is no longer used by the core and thus can be removed.
It isn't exposed as part of our public API so this is technically not a breaking change, although it may still cause people trouble if they are reaching into internals. It is expected that people will use forwardRef instead of this class.
I will follow up this diff with a removal from the ReactNativeRenderer as well.
Changelog:
[Internal] Remove ReactNative.NativeComponent from React Native
Reviewed By: JoshuaGross
Differential Revision: D19888400
fbshipit-source-id: 78da51e6c0edf9d8706395d376c3bfe75dabda03
Summary:
Resolve React-RCTText warning: `'UIKeyboardTypeASCIICapableNumberPad' is only available on iOS 10.0 or newer`
## Changelog
[iOS] [Fixed] - Resolve React-RCTText Xcode warning
Pull Request resolved: https://github.com/facebook/react-native/pull/28054
Test Plan: Build template, React-RCTText should no longer throw a warning.
Differential Revision: D19887063
Pulled By: hramos
fbshipit-source-id: 3437ee993babd7cdaec259af24526e197acb64bb
Summary: changelog: [General] `console.error` calls, and uncaught exceptions are now displayed in the Metro logs as well
Reviewed By: passy
Differential Revision: D19743075
fbshipit-source-id: a665a06cfc7854ae785af177af8f2478bb1d76b0
Summary:
When `[RCTReconnectingWebSocket stop]` is called and `[RCTReconnectingWebSocket reconnect]` is scheduled afterwards (i.e. connection didn't happen before `[RCTReconnectingWebSocket stop]` being invoked), it will keep reconnecting forever.
Also fixes retain loop in block within `[RCTReconnectingWebSocket reconnect]`. When RCTReconnectingWebSocket is stopped and reference to it set to nil, block in reconnect will still keep self alive and reconnecting forever.
I found this edge case when I tried to stop RCTPackagerConnection after some time, so it doesn't spam with `[] nw_socket_handle_socket_event [C34585.1:1] Socket SO_ERROR [61: Connection refused]` when we don' have Metro running (we have brownfield app, so iOS devs don't need Metro running most of the time).
## Changelog
[iOS] [Fixed] - RCTReconnectingWebSocket is reconnecting infinitely when stopped before getting connected
Pull Request resolved: https://github.com/facebook/react-native/pull/26864
Test Plan:
- Put breakpoint into `[RCTReconnectingWebSocket reconnect]`
- Start sample RN app **without having Metro running**
- Into AppDelegate add something like
```objc
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[RCTPackagerConnection.sharedPackagerConnection stop]
});
```
- After the previous block is dispatched reconnect should not be invoked anymore
Reviewed By: motiz88
Differential Revision: D19767742
Pulled By: rickhanlonii
fbshipit-source-id: dabb2369b06217b961e9d2611257c106d350f70c
Summary:
Right now, people are calling `getInnerViewNode` and `getInnerViewRef` to get the ref of the `View` within `ScrollView`. Instead, this change adds a prop to `ScrollView` to give people direct access to that `View` if they need it.
Previous usage:
```
const myRef = React.createRef<React.ElementRef<typeof ScrollView>>();
<ScrollView ref={myRef} />
const innerViewRef = myRef.current.getInnerViewRef();
innerViewRef.measure();
```
New usage:
```
const myRef = React.createRef<React.ElementRef<typeof View>>();
<ScrollView innerViewRef={myRef} />
// now, myRef.current can be used directly as the ref
myRef.current.measure();
```
Changelog:
[Changed][General] ScrollView: Deprecate getInnerViewNode and getInnerViewRef methods. Use innerViewRef={myRef} prop instead.
Reviewed By: TheSavior
Differential Revision: D19713191
fbshipit-source-id: 3304cb94a253dafb458ef49d6331e0e432693431
Summary:
Added description for rejectResponderTermination prop for the TextInput, which seemed to have been deleted.
Descriptions are taken from https://github.com/facebook/react-native/pull/16755/files
## Changelog
[Internal] [Added] - Add description for rejectResponderTermination prop for TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/28001
Test Plan: This PR only changes comment, which has no effect on actual function.
Differential Revision: D19820886
Pulled By: TheSavior
fbshipit-source-id: 5cbaafcbae0bdbf6932ef9c7c0c1a75cd6d8794e
Summary:
**Resolve/Reject Promise**
* Add onFulfill and onReject to the `PushNotificationIOS.requestPermissions()` Promise
**Replace Apple-deprecated notification method**
* Old: In iOS 10, `UIApplication.registerUserNotificationSettings` was deprecated. Calling this would then call the AppDelegate's lifecycle function `didRegisterUserNotificationSettings`, and then in the AppDelegate, we'd call `RCTPushNotificationManager.didRegisterUserNotificationSettings` to return the user settings.
[registerusernotificationsettings Doc](https://developer.apple.com/documentation/uikit/uiapplication/1622932-registerusernotificationsettings?language=objc)
* New: Replace deprecated function with Apple's recommended `UNUserNotificationCenter.currentNotificationCenter getNotificationSettingsWithCompletionHandler`, which no longer needs the AppDelegate lifecycle method because it directly returns the user's settings in a completion hander.
[requestauthorizationwithoptions Doc](https://developer.apple.com/documentation/usernotifications/unusernotificationcenter/1649527-requestauthorizationwithoptions?language=objc)
**Add Tests**
* Add tests on `PushNotificationIOSExample.js` to test that the onFulfill and onReject are called
* On `PushNotificationIOSExample.js`, instead of asking permission upon page load, ask for permission when the user taps the button "Request Notifications (Should Display Alert)".
* Before, asking for permission multiple times before would result in the RN error "cannot call requestPermissions twice before the first has returned", now you can ask for permission as many times as you want because I've removed the now unused `RCTPromiseResolveBlock`.
**Future**
If this works on device (we have to land this to test push on device), we can delete `RTCPushNotificationManager.didRegisterUserNotificationSettings` which is being called from several apps.
Changelog:
[iOS] [Added] Resolve and reject promise for PushNotificationIOS.requestPermissions
Reviewed By: PeteTheHeat
Differential Revision: D19700061
fbshipit-source-id: 02ba815787efc9047f33ffcdfafe962b134afe6d
Summary:
This prop was deprecated in April 2016 in [this commit](2bb1c263db (diff-931cea019b5e9faceffef4e46f1fff08)), first in 0.26.0
It's been a while, we can remove it now.
Changelog:
[Breaking][General] Modal: Remove support for `aniamted` prop (deprecated in 0.26)
Reviewed By: cpojer
Differential Revision: D19762163
fbshipit-source-id: b6173bba066fc9ad0e786f56a946e2f3fa3d79cc
Summary:
This functionality was deprecated in [this commit](e2bd7db732) on Feb 12th, 2019, originall in 0.59.0
Changelog:
[Breaking][General] Alert: Remove deprecated support for Alert.prompt with type as Callback (deprecated in 0.59)
Reviewed By: cpojer
Differential Revision: D19762618
fbshipit-source-id: a8edb6045bbc57d56e75fd281e602f5370ba1810
Summary:
Deprecations for these props were added in 0.57, June 2018, in this commit: 965adee109 (diff-6ee4e62c750fcd87064f152f53214a05), with warnings added in 9a4fd6b78d (diff-6ee4e62c750fcd87064f152f53214a05)
It has been a couple releases now, so let's clean up the component code and finally remove support.
For instructions on how to migrate off these props, see the commit summary of 965adee109 (diff-6ee4e62c750fcd87064f152f53214a05)
Changelog:
[Breaking][General] Switch: Remove support for thumbTintColor, tintColor, onTintColor props (deprecated in 0.57)
Reviewed By: cpojer
Differential Revision: D19760913
fbshipit-source-id: 8fdcf7af99fecadecf3157c00e6d1cbab8e63268
Summary:
Starting on iOS 13, a View Controller presented modally will have a "bottom sheet" style unless it's explicitly presented full screen.
Before this, modals on iOS were only being dismissed programatically by setting `visible={false}`. However, now that the dismissal can happen on the OS side, we need a callback to be able to update the state.
This PR reuses the `onRequestClose` prop already available for tvOS and Android, and makes it work on iOS for this use case.
Should fix https://github.com/facebook/react-native/issues/26892
## Changelog
[iOS] [Added] - Add support for onRequestClose prop to Modal on iOS 13+
Pull Request resolved: https://github.com/facebook/react-native/pull/27618
Test Plan:
I tested this using the RNTester app with the Modal example:
1. Select any presentation style other than the full screen ones
2. Tap Present and the modal is presented
3. Swipe down on the presented modal until dismissed
4. Tap Present again and a second modal should be presented
Differential Revision: D19235758
Pulled By: shergin
fbshipit-source-id: c0f1d946c77ce8d1baab209eaef7eb64697851df
Summary:
List components aren't host components so checking if the direct component itself's internals isn't sufficient to know if we are in Fabric. For lists, we have to call through some helper functions to get to the host component.
Hopefully we will fix this in the future by making the lists use forwardRef, or by getting rid of the JS Driver altogether, but for now, this is fine (TM).
Changelog: Internal
Reviewed By: mdvacca
Differential Revision: D19731067
fbshipit-source-id: 0e73583c6bf7c10de30e668a390d29718d31b295
Summary:
Bridgeless mode requires all native modules to be turbomodules. The iOS animated module was converted to TM, but reverted due to perf issues. RSNara is looking into it, but it may be an involved fix. As a short term workaround, to unblock release mode testing of bridgeless mode, use `AnimatedMock`.
Changelog: [Internal] Disable animations in bridgeless mode
Reviewed By: RSNara
Differential Revision: D19729827
fbshipit-source-id: e6c4d89258ec23da252c047b4c67c171f7f21c25
Summary:
React is way better than it used to be...
Changelog: [Internal]
Reviewed By: zackargyle, lunaleaps
Differential Revision: D19421772
fbshipit-source-id: db82b68a0c2f31e9ef7e1875fd9e4bf27ef6295a
Summary:
## This diff
- Add a hybird scene tracker that support both native navigation and js navigation
- It also has a filter that bypass loading routes and unrelated routes like log box
- The tracker can provide exactly what surface user is looking at
Changelog: [Internal]
Differential Revision: D19667699
fbshipit-source-id: 600efd05e68bf2702c6c2b1d794e720059f75f81
Summary:
All of our other JS view configs are gated by the `RN$Bridgeless` flag. This one has been behind a DEV flag instead. We've been using it in DEV for a long time now, so it's probably ok to be in prod, but I figured it's better to just be consistent with the rest of the native components, since we only need this for bridgeless.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19669902
fbshipit-source-id: bd28cf84947bfe298efd95ae07e38c2bf4e45091
Summary:
This diff regenerates all Jest inline snapshots (`expect().toMatchInlineSnapshot()`) now that we use Jest 24.9.0 which fixes a longstanding [formatting instability bug](https://github.com/facebook/jest/issues/8424).
This is strictly a formatting change.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D19684238
fbshipit-source-id: 77c1e5fe9d2dfef85dffdcc00056fb439d7d7f84
Summary:
When an asset is outside of the metro project root, it can lead to relative paths like `/assets/../../node_modules/coolpackage/image.png` as the `httpServerLocation`. This can happen for example when using yarn workspaces with hoisted node_modules.
This causes issues when bundling on iOS since we use this path in the filesystem. To avoid this we replace `../` with `_` to preserve the uniqueness of the path while avoiding these kind of problematic relative paths. The same logic is used when bundling assets in the rn-cli.
CLI part of this PR: https://github.com/react-native-community/cli/pull/939
## Changelog
[General] [Fixed] - Fix resolving assets outside of the project root
Pull Request resolved: https://github.com/facebook/react-native/pull/27932
Test Plan: Tested that an asset in a hoisted node_modules package doesn't show up before this patch and does after in a release build.
Differential Revision: D19690587
Pulled By: cpojer
fbshipit-source-id: 8a9c68af04594ce1503a810ecf2e97ef5bfb8004
Summary:
This implement the autoFocus functionality natively instead of calling the focus method from JS on mount. This is needed to properly fix the issue described in https://github.com/facebook/react-native/issues/27217, where when using native navigation (UINavigationController) text input focus needs to happen in the same frame transition starts or it leads to an animation bug in UIKit.
My previous attempt fixed the problem only partially and the bug could still happen since there is no guaranty code executed in useEffect will end up in the same frame as the native view being created and attached.
To fix this I added an autoFocus prop to the native component on iOS and in didAttachToWindow we focus the input if it is set. This makes sure the focus is set in the same frame as the view hierarchy containing the input is created.
## Changelog
[iOS] [Fixed] - Add native support for TextInput autoFocus on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/27803
Test Plan:
- Tested that the UI glitch when transitionning to a screen with an input with autofocus no longer happens in my app.
- Tested that autofocus still works in RNTester
- Made sure that onFocus does get called and TextInputState is updated properly
Differential Revision: D19673369
Pulled By: TheSavior
fbshipit-source-id: 14d8486ac635901622ca667c0e61c75fb446e493
Summary: `requireNativeComponent` redboxes in bridgeless mode because there is no UIManager. This adds a handwritten view config to avoid using UIManager.
Reviewed By: ejanzer
Differential Revision: D19624044
fbshipit-source-id: 5ae68f63068a131a305754003154ee0cf0f1be46
Summary:
In case when Platform is different from Android or iOS, ScrollView initialised RCTScrollView two times, which caused a crash. It looks for me that default option is obsolete and can be united with iOS one to fix this issue.
## Changelog:
[Internal] [Fixed] - Fixed crash during ScrollView initialisation if Platform.OS is not iOS or Android
Reviewed By: ejanzer
Differential Revision: D19623046
fbshipit-source-id: 84f8a46ea24b463aa6aae761f4386ab7e4e95f9b
Summary:
This validate function uses the `UIManager.getViewManagerConfig` API to verify if props are supported. Bridgeless mode doesn't support UIManager APIs.
It seems like these `deprecatedPropType` will be removed eventually, so let's ignore it in bridgeless.
Changelog: [Internal] Ignore deprecatedPropType in bridgeless mode
Reviewed By: ejanzer
Differential Revision: D19603819
fbshipit-source-id: 2c744705be8821cc6a9d8daaac3e652987447e4d
Summary:
Adds build version and an onPress for the build info.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D19334440
fbshipit-source-id: b201b630086179faca31a08c62019a2019cedf4f
Summary:
Can be handy for general animation components, like `FancySuspense`.
ChangeLog:
[General][Added] Export LayoutAnimationConfig flow type
Reviewed By: zackargyle, TheSavior
Differential Revision: D19345668
fbshipit-source-id: 26178d1eb0b6f710f652bf82c8095dec5bf5afbd
Summary:
Introduces `Rect`, an (eventual) replacement for `EdgeInsetsProp`.
This new type is then used in `Pressability` to expand support such that `hitSlop` and `pressRectOffset` can be either a `Rect` or a numeric size.
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D18742616
fbshipit-source-id: 13dd360f68ab804839938fc950fa2f4b25d3ed8c
Summary:
This was all yungsters idea. I blame him. :)
Switching Pressable to be a functional component presents a new challenge. ReactNativeTestTools can no longer find its instance because there is no instance Pressable uses forwardRef.
We need a way to both find a pressable, and then call the onPress callback if the pressable isn't also disabled.
So in DEV (and thus test) we add the pressable config to a secret key on a function passed onto View. The TestTools look for this key on this function, and then can call onPress.
Super hacky, but so is all of ReactNativeTestTools. We aren't proud of this.
Changelog:
[General][Changed]: Added support for Pressable to ReactNativeTestTools.tap
Reviewed By: yungsters
Differential Revision: D18849358
fbshipit-source-id: ea8880ceedfc04cda217ee17ba140475d003172c
Summary:
When building as a framework these headers get automatically added to the framework umbrella header for React-Core. Instead of converting all the React sources to ObjC++ files and still forcing external users that build native source (and link against a framework build) to also compile as ObjC++, this makes the attribution related methods that were added in https://github.com/facebook/react-native/commit/fdcdca4 opt-in to ObjC++ builds.
This is also the reason for the current failure of the CI `test_ios_frameworks` run.
## Changelog
I’m unsure if this change really warrants an entry in the CHANGELOG, as it’s more of an amendment of the (afaik) unreleased [change](https://github.com/facebook/react-native/commit/fdcdca4).
[iOS] [Fixed] - Make framework builds work again by making `RCTImageLoader` C++ requirement opt-in
Pull Request resolved: https://github.com/facebook/react-native/pull/27730
Test Plan:
I tested static and dynamic (framework) builds and ran the test suite.
This change should make the `test_ios_frameworks` CI run _build_ again, ~~but it may still fail overall as in my local testing one of the tests leads to a segfault (which I will try to address separately)~~.
Reviewed By: PeteTheHeat
Differential Revision: D19348846
Pulled By: fkgozali
fbshipit-source-id: 8a74e6f7ad3ddce2cf10b080b9a5d7b399bd5fc0
Summary:
## Context
When a `VirtualizedList` contains a cell which itself contains more than one `VirtualizedList` of the same orientation as the parent list, we log an error if sibling lists in a cell don't have unique `listKey`s (e.g. when the `listKey` prop isn't explicitly set). In release builds, this error does not have a component stack - nor a useful call stack - so it can be hard to track down the true source of the error in complex applications.
## This diff
Here, in addition to the generic error message, we also print the `listKey`, `cellKey` and orientation of each `VirtualizedList` in the hierarchy, from the child list upwards. This is done without significant overhead, by reusing the already-in-place context that `VirtualizedList`s use to manage nesting.
The assumption is that common strategies for deriving `listKey`s and `cellKey`s will make it possible to identify at least some lists in the hierarchy in common cases, and therefore help narrow down the search space even when component stacks are not available.
## Example
(See code in unit test)
```
A VirtualizedList contains a cell which itself contains more than one VirtualizedList of the same orientation as the parent list. You must pass a unique listKey prop to each sibling list.
VirtualizedList trace:
Child (horizontal):
listKey: level2
cellKey: cell0
Parent (horizontal):
listKey: level1
cellKey: cell0
Parent (vertical):
listKey: level0
cellKey: rootList
```
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19600366
fbshipit-source-id: 73f29507ec58a6a3f9b3f6b174a32b21dcd237a1
Summary:
In `XMLHttpRequest`, if the responseType is `Blob`, but the response is an empty string, we return `null` from `XMLHttpRequest.prototype.response()`. Instead, we should return an empty Blob. This is the behaviour on the web. To demonstrate, run the following HTTP server with Node:
## server.js
```
const http = require('http');
const server = http.createServer();
server.on('request', (request, response) => {
if (request.url.includes('img.png')) {
console.log('sending image');
response.end('');
return;
}
response.end('Hello World!');
});
server.listen('9000');
```
Then, open up a web browser to `http://localhost:9000`, and type the following in the console:
```
var oReq = new XMLHttpRequest();
oReq.open('GET', 'http://localhost:9000/img.png', true);
oReq.responseType = 'blob';
oReq.onload = function(oEvent) {
var blob = oReq.response;
console.warn(blob);
};
oReq.onerror = function(error) {
console.warn('Error!');
};
oReq.send();
```
This warns:
```
Blob {size: 0, type: "text/xml"}
```
Changelog:
[Both][Fixed] - [RN][XMLHttpRequest] Transform empty responses into empty Blobs
Reviewed By: sahrens
Differential Revision: D19500607
fbshipit-source-id: ec35e534b32a507c8a94a29e955b7bc4c62902a0
Summary:
When I was testing React Native 0.62-rc.1, I noticed that console was showing a warning for Require Cycle as shown in image below
This is because ScrollResponder was importing `ScrollView` to get the `typeof ScrollView`.
I've made an export for ScrollView type in `ScrollView` so that Require cycle warning will not show up.
## Changelog
[General] [Fixed] - Remove Require cycle warning.
Pull Request resolved: https://github.com/facebook/react-native/pull/27851
Differential Revision: D19577644
Pulled By: cpojer
fbshipit-source-id: 257b9421a91244d69394375102cfbe683326bba2
Summary:
Fixes https://github.com/facebook/react-native/issues/27137
This PR fixes an issue on iOS where RCTTextView height is not calculated as it should for some fonts where font `leading` attributed is not equal to zero, which results in wrong baseline alignment behaviour.
The fix for this is by setting `usesFontLeading` property of `NSLayoutManager` to `NO`, which results is a layout behavior that is similar to `UILabel`
Probably the documentation for `usesFontLeading` describes why UILabel has a different (correct) layout behavior in that case
> // By default, a layout manager will use leading as specified by the font. However, this is not appropriate for most UI text, for which a fixed leading is usually specified by UI layout guidelines. These methods allow the use of the font's leading to be turned off.
## Changelog
[iOS] [Fixed] - Fix RCTTextView layout issue that happens on some font with `leading` attribute not equal to zero, which causes wrong base-alignment layout
Pull Request resolved: https://github.com/facebook/react-native/pull/27195
Test Plan:
Below are the test results before and after the change, and comparing that to native UILabel behavior.
The test is done with using system font and custom font (`GothamNarrow-Medium`) and font size 50
[GothamNarrow-Medium.otf.zip](https://github.com/facebook/react-native/files/3832143/GothamNarrow-Medium.otf.zip)
```js
const App: () => React$Node = () => {
return (
<View style={{flex: 1, margin: 40, flexDirection: 'row', justifyContent: 'center', alignItems: 'baseline'}}>
<View style={{width: 30, height: 30, backgroundColor: 'lightgray'}} />
<Text style={{fontSize: 50, backgroundColor: 'green', fontFamily: 'GothamNarrow-Medium'}}>{'Settings'}</Text>
</View>
);
};
```
-------
### Before the fix
<img width="962" alt="Screenshot 2019-11-11 at 16 53 26" src="https://user-images.githubusercontent.com/5355138/68601049-dd778780-04a3-11ea-879e-cc7b4eb2af95.png">
-----
### After the fix
<img width="944" alt="Screenshot 2019-11-11 at 16 55 11" src="https://user-images.githubusercontent.com/5355138/68601180-1d3e6f00-04a4-11ea-87bc-61c6fa2cdb18.png">
-----
### Using `UILabel`
<img width="805" alt="Screenshot 2019-11-11 at 16 59 28" src="https://user-images.githubusercontent.com/5355138/68601487-b2d9fe80-04a4-11ea-9a0f-c025c7753c24.png">
Differential Revision: D19576556
Pulled By: shergin
fbshipit-source-id: 4eaafdab963c3f53c461884c581e205e6426718a
Summary:
The reason for this change is that it is the primary root that we want people to be using and the naming should reflect that.
#nocancel
build-break
overriding_review_checks_triggers_an_audit_and_retroactive_review
Changelog: [Internal]
Oncall Short Name: fbobjc_sheriff
Differential Revision: D19431128
fbshipit-source-id: c7208e20ed0f5f5eb6c2849428c09a6d4af9b6f3
Summary:
Since migrating to Turbomodules (8fe04cf) the addMenuItem method crashes because the NativeEventListener methods are missing from the codegen flow type. Added the same methods based on what we do in AppState which is another native module that extends NativeEventListener.
## Changelog
[Internal] [Fixed] - Add missing NativeEventListener methods to NativeDevSettings
Pull Request resolved: https://github.com/facebook/react-native/pull/27838
Test Plan:
|Before|After|
|{F226978596}|{F226978628}
Differential Revision: D19518474
Pulled By: PeteTheHeat
fbshipit-source-id: acddba9f18dd558df1d6df78b539689fdfd0062f
Summary:
Noticed the _validateMapping call right now is a no-op, as the traverse method is never invoked. We can only really do validation once we've received a sample of an event, and can then verify the values being extracted indeed correspond with a valid key.
Changelog: [General] [Fixed] - Fix validation of event mappings for AnimatedEvent
Reviewed By: cpojer
Differential Revision: D19498971
fbshipit-source-id: e978dda895498a7e567d5e18b3181b319d88d95c
Summary:
Hand-writing a JS view config for AndroidTextInputNativeComponent.
This diff was generated by adding logging to `getNativeComponentAttributes`. Diff preview: https://our.intern.facebook.com/intern/diff/view-version/96875488/
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19456328
fbshipit-source-id: b2d5abd2fde380be182b95881c335d24481343f1
Summary:
Add Native Commands handlers to TextInput.
It is intentionally done in a way so that it can be easily swapped for codegened implementation once we properly type TextInput.
We also add native commands to view managers for backwards compatibility.
Changelog: [Internal]
Reviewed By: TheSavior, shergin
Differential Revision: D19412026
fbshipit-source-id: 8dc64275cf1da599b1bd5992a41035d51dd4148f
Summary: Changelog: [Fix] Fix status bar color not updating when navigating between two screens with the same status bar color.
Reviewed By: RSNara
Differential Revision: D19439424
fbshipit-source-id: 44388f1f94c87c12102471d72183bb6c152a46b6
Summary:
Re-landing the reverted change:
This removes all callsites that rely on runtime checks to detect the target deployment version. We no longer need to check for iOS 10+ in a few places. Note: for this to compile, the hosting app needs to target iOS 10.0+.
Changelog: [iOS] [Deprecated] - Deprecate iOS 9
Reviewed By: sammy-SC
Differential Revision: D19411136
fbshipit-source-id: ec0a957dc57819f0ee7d138c858209cabe3e5102
Summary:
This removes all callsites that rely on runtime checks to detect the target deployment version. We no longer need to check for iOS 10+ in a few places. Note: for this to compile, the hosting app needs to target iOS 10.0+.
Changelog: [iOS] [Deprecated] - Deprecate iOS 9
Reviewed By: hramos
Differential Revision: D19271321
fbshipit-source-id: 424ad7e2161261d148cb436cc20b4c531a4ba5b7
Summary:
In D15393464, we introduced `NativeHeapCapture`, but it had a few problems:
1. It required `JSCHeapCapture` by doing `TurboModuleRegistry.get<Spec>('HeapCapture')`, when it should have done `TurboModuleRegistry.get<Spec>('JSCHeapCapture')`.
2. It had an additional method `captureHeap`, which didn't exist on the Android NativeModule.
This diff corrects those mistakes.
Changelog:
[Both][Fixed] - Fix JSCHeapCapture
Reviewed By: PeteTheHeat
Differential Revision: D19383511
fbshipit-source-id: 30e69afbcdba673f3f32c16bde4f0342568ab97d
Summary:
Fabric doesn't support setNativeProps, so we are using view commands instead.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18044169
fbshipit-source-id: d5f199b930244d02f174ea8a7ef732e9a8ef2476
Summary:
As a part of the migration from setNativeProps in Fabric and Paper, we are replacing it by view commands in the RefreshControl component on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18475450
fbshipit-source-id: ad89547fada3444f725fd9b00e8482cfc8f4d7fc
Summary:
As a part of the migration from setNativeProps in Fabric and Paper, we are replacing it by view commands in the Checkbox component on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18451749
fbshipit-source-id: 49d786ef3383df95b10260ba2b7f68489ad31789
Summary:
RCTTextInputUtils contains a bunch of conventions and convenience functions that we use in TextInput.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19226658
fbshipit-source-id: df72dcdc052b96b6daef2cc0839235761005d914
Summary:
Bridgeless mode hasn't been able to load random images. I was able to repro this 100% with base64 images. Loading these images hits a particular flow in `RCTImageLoader` which relies on the bridge to access `RCTNetworking`. This diff uses the TM Lookup Delegate as a fallback.
Changelog: [iOS][Internal] Fix error in RCTImageLoader in bridgeless mode
Reviewed By: sammy-SC
Differential Revision: D19331467
fbshipit-source-id: 8239ee258425da4ed8cb9f6dcdcd7f37c162eb19
Summary:
When bridge is nil, RCTBlobManager crashes with `EXC_BAD_ACCESS`.
The fix: instead of using the bridge to find RCTNetworking, use TM lookup delegate.
Changelog: [iOS][Internal] Fix crash in RCTBlobManager in bridgeless mode
Reviewed By: mdvacca
Differential Revision: D19320136
fbshipit-source-id: 49aabb3ce53b2ec620fcc02be1c6c1b44066f440
Summary:
View should reset whether we are inside of a text or not. For example, inline images should only be rendered inside text, but if we have a view inside text, then it should render a regular image, not an inline image.
This logic *should* exist in native instead of in JS, but this is an easier change for now.
I'm sad to have to turn this back into a JS component instead of just being the string 'RCTView' as this will have performance implications on all surfaces, but this is how it always used to be so maybe it's fine.
This example previously crashed, and no longer does:
```
function PlaygroundContent(props: {}) {
return (
<View style={styles.container}>
<Text>
<View style={{width: 10, height: 10}}>
<Image source={fbicon.filled('chevron-down', 10)} />
</View>
</Text>
</View>
);
}
```
Changelog:
[General][Fixed] Fixes bug where <Text><View><Image> would crash.
Reviewed By: JoshuaGross
Differential Revision: D17564510
fbshipit-source-id: 0ecf49b3d466e7adf57a46a7a097dd3798c721a4
Summary:
We're keeping the perf logging flag, but the general instrumentation flag is no longer needed (the use case isn't significant to need separate flag).
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D19304789
fbshipit-source-id: 094f7079283e4f4bf3d546dfd0ae50eb641d562e
Summary:
Hand writing view configs for NativeImageViewComponent so that it'll work in bridgeless mode and won't fall back to the UIManager.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D19217961
fbshipit-source-id: d5a123b35a75ba3e22c57b1dde18a47893681614
Summary:
It can be a pain to debug slow network issues, especially with the iOS simulator which doesn't have a network link conditioner. This makes it really easy and predictable by simply adding a `setTimeout` around calling `sendRequest`.
Changelog:
[General] [Added] - DEBUG_NETWORK_SEND_DELAY can be used to simulate slow network.
Reviewed By: PeteTheHeat
Differential Revision: D19236911
fbshipit-source-id: 14762c7e0c6408a8364aa569c482729a7a1fe740
Summary:
It is time to target SDK version 10.0+.
Changelog: [iOS] [Deprecated] - Deprecating support for iOS/tvOS SDK 9.x, 10.0+ is now required
Reviewed By: mdvacca
Differential Revision: D19265731
fbshipit-source-id: 93b6f9e8f61c5b36ff69e80d3f18256aa96cc2c0
Summary:
Changes the return type of StyleSheet.create to `$ReadOnly<S>`. At runtime, it just freezes the fields in dev mode and is the identity function otherwise. This cause 423 errors due to the wrong props being passed to different styles: P124372727
I went over errors at random with Eli to get confidence in the change.
Changelog:
[General][Fixed] Fix return type of StyleSheet.create
Reviewed By: zackargyle, TheSavior
Differential Revision: D19218817
fbshipit-source-id: b7aa10700f8333372c9f0bd61bfbef371caadf97
Summary:
In https://fb.workplace.com/groups/rn.support/permalink/3132785890103338/?comment_id=3132873900094537 we identified that when Metro restarts but the app keeps the main bundle alive, the next request for a split bundle will always produce an invalid bundle. This is because we rely on module ids being stable while Metro is running and when Metro is restarted, those module ids will likely be assigned to different modules.
The fix applied here simply forces a full reload when downloading (registering) a new split bundle if the connection to Metro disappeared.
Another way to mitigate this is to use stable module ids. That's a more involved change in Metro that I'm not planning on making right now.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D19235555
fbshipit-source-id: b8ff10590655952a2af1379bbf4e930f9eb95c1b
Summary:
This diff removes the findShadowNodeByTag_DEPRECATED method from class UIManagerBinding. This method was created on D17175953 to implement findNodeHandle in Fabric. Recently we decided that we don't need to expose findNodeHandle anymore. This diff cleans up thi code.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19216996
fbshipit-source-id: 07c16aeed28851afc09b0f5d6be338bb4440f813
Summary:
We currently use `UIManager.getViewManagerConfig()` in a few places to check if a view manager exists at runtime; right now these checks fail for Venice because our DummyUIManager returns null. We don't yet have a replacement for this API for Fabric (see T59411524) so for now let's just hard code the view managers that we know exist to return something truthy here. This is hacky, but it works ok for now.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19185957
fbshipit-source-id: e3135b45db4c9ff27fd95362deaa3c1b4340bf48
Summary:
The logic in the method is only relevant if the sourceType is `UIImagePickerControllerSourceTypeCamera`. So we guard it here, to prevent NSInvalidArgumentException.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D19184818
fbshipit-source-id: 5c99dabfaed23629e22fdc888263bd09e8768c88
Summary:
This diff fixes two issues with LogBox in OSS.
Changelog: [Internal]
Reviewed By: mmmulani
Differential Revision: D19165696
fbshipit-source-id: 4dd9c480ea3d2b205f8e65cb32203949b1e32e8a
Summary:
When in debug mode, PlatformConstants doesn't have a `ServerHost` constant. This wasn't captured by `NativePlatformConstants`.
Changelog:
[Android][Fixed] - Make sure ServerHost is optional in NativePlatformConstants.js
Reviewed By: rickhanlonii
Differential Revision: D19091270
fbshipit-source-id: 4b3ac73a4ab6111b3e433ecca01cc769e8cdec6b
Summary:
`node` is passed to us from react devtools. We can call .measure on that directly instead of using findNodeHandle and UIManager. This makes this call compatible with Fabric.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D19152052
fbshipit-source-id: 05ab6d55f3a79221d99289f0341eb25352b96899
Summary:
We currently use `BatchedBridge.registerCallableModule` to call JS from platform code in a bunch of places (e.g. `RCTDeviceEventEmitter.emit()`), including some pretty essential ones - for example, Networking relies on `RCTDeviceEventEmitter` to emit events to JS for network requests and errors. In order to make the migration to bridgeless mode as easy as possible, it'd be best if we didn't have to update all the callsites in JS and platform code, at least for core JS modules like `RCTDeviceEventEmitter`. So we'd like to implement this callable module pattern for bridgeless mode as well.
In this diff, I'm installing a global variable, `RN$registerCallableModule`, which will store the JS module name and factory function in C++. This can then be called from platform code (Java/Obj-C) to invoke a JS function on a module using the existing APIs (`context.getJSModule()` on Android, `enqueueJSCall()` or similar on iOS).
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D18798852
fbshipit-source-id: fbe9eaecaf6f5cab5173beec999d3a933b13375d
Summary:
We will need to operate on instances instead of react tags. This diff passes through the instance instead of the tag.
This does not make the inspector work in Fabric, but it is a necessary refactor in that direction.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D19149647
fbshipit-source-id: 53fa35a2886bf36a146d473a496409dffc114a80
Summary:
Some babel plugins add additional methods to `Function.prototype` (see https://github.com/MatAtBread/fast-async):
```js
Function.prototype.$asyncbind = function $asyncbind(self, catcher) {
...
```
Although undocumented, React Native allows functions to be passed to `StyleSheet.create()` for dynamic styling:
```js
const styles = StyleSheet.create({
animalItem: height => ({ height })
});
```
If there are additional custom methods on `Function.prototype`, React Native's `StyleSheetValidation.validateStyle` will loop through these properties and raise an error because those properties are not valid style keys, because it loops through _all_ properties, including inherited ones.
This PR modifies `StyleSheetValidation.validateStyle` to only loop through the style's own properties, instead of including inherited ones.
## Changelog
[General] [Fixed] - Fix stylesheet validation for functions with custom prototype methods.
Pull Request resolved: https://github.com/facebook/react-native/pull/27264
Test Plan: - Tested that non-function style properties are still validated
Differential Revision: D18694895
Pulled By: hramos
fbshipit-source-id: b36f4a62a435e7b6a689398de3bcc06d6bb14293
Summary:
In https://github.com/facebook/react-native/issues/25427, radex added initial support for running React Native projects on macOS via Catalyst. However, `RCTWebSocket` was disabled for that target because of some compilation issues. This meant that running projects via a connection to the packager wasn't possible: no live reload, and projects must be run in "Release" mode. It also meant making manual changes to Xcode projects deploying to macOS and scattering a number of conditional checks throughout the codebase.
In this change, I've implemented support for `RCTWebSocket` on the macOS target and re-enabled the affected features. Live reload and the inspector now work for macOS targets. Manual modifications of Xcode build settings are no longer necessary for react-native projects running on macOS.
### Limitations
There's no binding which displays the developer menu (since there's no shake event on macOS). We'll probably want to add one, perhaps to the menu bar.
I've chosen not to commit the modifications to RNTester which enable macOS support, since that would imply more "official" support for this target than I suspect you all would like to convey. I'm happy to add those chunks if it would be helpful.
## Changelog
[iOS] [Added] - Added web socket support for macOS (Catalyst), enabling debug builds and live reload
Pull Request resolved: https://github.com/facebook/react-native/pull/27469
Test Plan:
* Open RNTester/RNTester.xcodeproj with Xcode 11.2.1, run it like a normal iOS app -- make sure it compiles and runs correctly (no regression)
* Select "My Mac" as device target, and run. You may need to configure a valid development team to make signing work.
* RNTester should run fine with no additional configuration. Modify a file in RNTester, note that live reload is now working.
* Test the developer inspector. To display the developer menu, you'll need to manually show it; here's an example diff which does that:
```
diff --git a/RNTester/js/RNTesterApp.ios.js b/RNTester/js/RNTesterApp.ios.js
index 8245a68d12..a447ad3b1b 100644
--- a/RNTester/js/RNTesterApp.ios.js
+++ b/RNTester/js/RNTesterApp.ios.js
@@ -19,6 +19,8 @@ const React = require('react');
const SnapshotViewIOS = require('./examples/Snapshot/SnapshotViewIOS.ios');
const URIActionMap = require('./utils/URIActionMap');
+import NativeDevMenu from '../../Libraries/NativeModules/specs/NativeDevMenu';
+
const {
AppRegistry,
AsyncStorage,
@@ -143,6 +145,7 @@ class RNTesterApp extends React.Component<Props, RNTesterNavigationState> {
UNSAFE_componentWillMount() {
BackHandler.addEventListener('hardwareBackPress', this._handleBack);
+ NativeDevMenu.show();
}
componentDidMount() {
```
Reviewed By: sammy-SC
Differential Revision: D18945861
Pulled By: hramos
fbshipit-source-id: edcf02c5803742c89a845a3e5d72bc7dacae839f
Summary:
With a Picker we would like to allow accessibility labels to be passed as a prop for situations where we want go give more detail. For example if we have a number picker that will be used for a timer instead of just saying 3, we might want to say 3 hours.
## Changelog
[General] [Added] - Picker test with an accessibility label prop
[General] [Added] - Support for accessibility Label prop to the Picker component
Pull Request resolved: https://github.com/facebook/react-native/pull/27342
Test Plan: Test plan is testing in RNTester making sure the examples work
Differential Revision: D18770184
Pulled By: hramos
fbshipit-source-id: e6f8ab4a9c50f3fb46342198441ecc71394913d3
Summary:
Added basic hook to enable image instrumentation. The hook passes information to the existing image loader, where instrumentation is done, specific for each app, if any.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19047899
fbshipit-source-id: 6c013806cce98bcf1ea240d696a7ede9697e5cd9
Summary:
The `RCTImageURLLoaderWithAttribution` protocol historically only returns a cancellation block to cancel the url request. But for more complex instrumentation, we may need to associate a requestId for the specific URL request. To do this, the protocol now returns an object that has both the unique ID and the cancellation block, so that instrumentation logic can refer to the ID in the future.
Note that the `RCTImageURLLoader` protocol is unchanged, because the request ID is only relevant for instrumentation purpose.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19047900
fbshipit-source-id: cd029f2470c32fc7bffd674b09a5353fe1dbc80b
Summary:
`RCTImageLoader ` needs loaders & decoders. These can be passed in through init, or looked up at runtime using the bridge. In bridgeless mode, we need to pass them in through init.
This diff just moves the assert to actually protect `_bridge` usage, since there exist other codepaths which don't use the bridge.
Changelog: [iOS][Internal] Move RCTImageLoader asserts to protect bridge usage
Reviewed By: RSNara
Differential Revision: D18990760
fbshipit-source-id: 285008e7b3f473c45381ab472c3d86e5d8e218ae
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:
`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:
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:
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:
We can use the HostComponent type now instead of NativeComponent
Changelog:
[Internal]
Reviewed By: zackargyle, rickhanlonii
Differential Revision: D18871289
fbshipit-source-id: 3c70369c5848dedfc22ca6f6ccbb69d6d60a1330
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:
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:
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:
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:
`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
Summary:
This diff fixes an issue where symbolicated logs were getting stuck in a "pending" state if the timeout occurred before symbolication finished.
Changelog: [Internal]
Reviewed By: sahrens
Differential Revision: D18894154
fbshipit-source-id: ed225962468f67aef40e430aa798f8d426d31027
Summary:
This diff adds a new `unstable_enableLogBox` function to opt-into the new LogBox experience. If LogBox is not enabled early enough, we show an error with instructions.
With this, LogBox can be enabled with:
```
require('react-native').unstable_enableLogBox();
```
Changelog: [General] [Adds] unstable_enableLogBox
Reviewed By: zackargyle, rubennorte
Differential Revision: D18808940
fbshipit-source-id: 4b0234ddc4d1646515bf63110d5b02133780512e
Summary:
Apologies for the large diff, it was difficult to break down.
This diff is a major refactor of LogBox that:
- Separates LogBoxNotification and LogBoxInspector
- Moves them each to their own container
- Updates AppContainer to only render the notification
- Updates the native logbox root to render the inspector
- Adds withSubscription HOC to manage subscribing to LogBoxData
- Simplifies LogBox to export an object instead of a component
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18750011
fbshipit-source-id: 639885d29e55e125892d1c2b6bbf2826f27d78db
Summary:
This diff adds a NativeLogBox module implementation on iOS to manage rendering LogBox the way we render RedBox, except rendering a React Native component instead of a native view.
The strategy here is:
- initialize: will create a hidden window (the way redbox does) and render the LogBox to it
- show: will show the window
- hide: will hide the window
Most of this is copied from the way RedBox works, the difference here is that we eagerly initialize the window with the `initialize` function so that it's warm by the time LogBox needs to render.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D18750008
fbshipit-source-id: 013e55ded55c8572bb08e0219ff4cd0060ebe0da
Summary:
This diff stubs out registering LogBox as a renderable component. In later diffs, we'll render this component on the native side.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18750005
fbshipit-source-id: 4db082ca2104731641d2d10de1ba83a318ab44fb
Summary:
NativeComponent as a type isn't needed now that we have HostComponent
Changelog:
[Internal]
Reviewed By: zackargyle, rickhanlonii
Differential Revision: D18873494
fbshipit-source-id: 5ba3fa25537f8249c80c2303dcdb380e3b6b0ac5
Summary:
Introduced 2 helper functions to toggle image instrumentation/logging (not in this diff) so that gating check is more efficient and easy to access across RN iOS core.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18597208
fbshipit-source-id: 0b22031802ab020b16d6fb63e52461cf80a37ab5
Summary:
This component no longer has any internal callsites and was never exposed in the public API!
Changelog:
[General][Removed] Removing experimental IncrementalPresenter component
Reviewed By: rickhanlonii
Differential Revision: D18828704
fbshipit-source-id: 931254c4328b93b946a7995e7d9d44cb5aeb6a7b
Summary:
Changelog: [Internal] Remove groupCollapsed from list of unsupported polyfills
`console.groupCollapsed` was always replaced with `originalConsole`'s implementation, but
the right behavior is to have it be a proxy (call both `console` and `originalConsole`).
So remove this key from a list of unsupported functions.
Reviewed By: yungsters
Differential Revision: D18820158
fbshipit-source-id: d83cffbc7e7939c2654fad2e0d681da7c3b5196a
Summary:
By depending on react-native, these files can't be flow strict until index.js is flow strict. By depending on the internals directly they can be flow strict as soon as their dependents are flow strict.
Changelog:
[Internal] Refactoring some core file imports to depend on internals directly
Reviewed By: zackargyle
Differential Revision: D18828324
fbshipit-source-id: 2a347c4e234a64edbb3e6f0ef6387ef1ce78badc
Summary:
The flow team is rolling out exact-by-default object types to xplat/js. In order to do that, we need to take all inexact objects `{}` and turn them into explicitly inexact objects `{...}`.
This codemod does not change any type checking behavior. Prettier was run on all of the modified files with `format`.
drop-conflicts
Changelog: [Internal]
Reviewed By: zackargyle
Differential Revision: D18785076
fbshipit-source-id: c89c7fcc9eabe69859c8a488e03185fba5d06f80
Summary:
Code document incorrectly indicates that the `title` property is supported in both iOS and Android.
https://github.com/facebook/react-native/issues/27306
## Changelog
[iOS] [Changed] - Changed doc.
Pull Request resolved: https://github.com/facebook/react-native/pull/27351
Test Plan: NA - Only code comments have been changed.
Differential Revision: D18770026
Pulled By: hramos
fbshipit-source-id: af51c0b08bdf534d5e2c861b10e22d969d6f80f9
Summary:
The following pull-requests adds test for the `processColorArray` function. This ensures that the mapping is respected even in the `processColor` file changes. It also ensures that the mapping follows the basic expected functionality
## Changelog
[General] [Added] - Add test for the `processColorArray` to make sure it maps correctly
Pull Request resolved: https://github.com/facebook/react-native/pull/27344
Test Plan:
- Run `npm run test Libraries/StyleSheet/__tests__/processColorArray-test.js` to ensure tests pass
- Run `npm run lint` to make sure there are no styling conflicts.
<img width="454" alt="Screen Shot 2019-11-26 at 3 24 44 PM" src="https://user-images.githubusercontent.com/31664059/69680816-e8641780-1060-11ea-89ca-336c5534eb16.png">
Differential Revision: D18770069
Pulled By: hramos
fbshipit-source-id: 1a8647931818360b9912dc6fb50c339a91b9d4ea
Summary:
Right now we use `BatchedBridge.registerLazyCallableModule` for all JS modules except for `HMRClient`, which uses `registerCallableModule` instead (takes the module itself instead of a function that returns it). I'm standardizing on `registerLazyCallableModule` so that it will be easier to swap out the implementation later for bridgeless mode.
The only reason I could think why we wouldn't want to do this is if we're relying on some side effect of `require('HMRClient')` when setting up JS, but there don't seem to be any side effects in that module that I can see.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D18798870
fbshipit-source-id: a5c950bdbfd998bb12e4843ee28ece08a26c84bf
Summary:
The former implementations of `TouchableHighlight` used `defaultProps` for `underlayColor`. However, the newly landed implementations use `??` which falls back to the default behavior if the prop is `null`.
This restores the former behavior so that, for example, supplying `underlayColor={null}` to `TouchableHighlight` will not fallback to black. (It probably should always have, but the intention of my rewrite was not to introduce a breaking change.)
Changelog:
[General] [Fixed] - Restore behavior for `underlayColor={null}` in `TouchableHighlight`.
Reviewed By: zackargyle
Differential Revision: D18806494
fbshipit-source-id: 4d33810e2f754f980385d76d81dc0f34006f4337
Summary:
Originally, normalizeColor.js was in Library/Color/ however, I noticed that its tests were in a completely different directly (Library/StyleSheet/__tests__) which was confusing. The other files such as processColor.js, setNormalizedAlphaColor.js had their tests in Library/StyleSheet/__tests__ as well.
## Changelog
[Internal] [Changed] - Moved normalizeColor.js to a more appropriate directory where its tests live.
Pull Request resolved: https://github.com/facebook/react-native/pull/27372
Test Plan: I simply moved a file and changed dependencies. The code should still function as is.
Reviewed By: rickhanlonii, mdvacca
Differential Revision: D18760210
Pulled By: yungsters
fbshipit-source-id: 4c2400acabab35ccbb2533faa5c1d6487c9bf48e
Summary:
## Step 1
I'm going to make every Java NativeModule type-safe and TurboModule-compatible. The first step is to make sure that every type-unsafe NativeModule has a dependency on its spec's codegen target.
## Input
Module -> owner(Module): P123320255
Module -> name(Module): P123320256
Module -> owner(spec(name(Module))): P123320257
### Excluded NativeModules
NativeModules without Specs: P123320644
Java only NativeModules: P123320645
Changelog:
[Internal] - Add buck dependencies for NativeModule specs
Reviewed By: mdvacca
Differential Revision: D18781629
fbshipit-source-id: 89f39017b8224355d9d7b43bf6c162b0957760ee
Summary:
Add a method to get the underlying host component of `FlatList`. Fix flow types in `FlatList` and `VirtualizedList`. Add test cases to test the behavior of the new function in all cases.
Changelog: [General] [Added] - Add getNativeScrollRef method to FlatList component
Reviewed By: TheSavior
Differential Revision: D18302202
fbshipit-source-id: 7005a2bc1dab207434be3f1f4d8fde0b11b3bb4d
Summary:
Changelog:
[iOS] [Fixed] - Slider is now disabled properly on iOS if the disabled prop is set.
Reviewed By: yungsters
Differential Revision: D18758835
fbshipit-source-id: 4850ebf05380f241d49d40107de61fd840049779
Summary:
Fixes a bug where we were skewing some stack traces by sending 1-based column numbers to the Metro symbolication endpoint, which expects them to be 0-based. This is achieved by subtracting 1 from the column numbers we find in textual stack traces, which are almost universally 1-based in current JS engines.
The bug is only noticeable in *some* cases, namely where the column immediately following the correct one is in a different function.
NOTE: The behaviour under Hermes was fixed separately, in a previous commit. This fix applies to other engines (e.g. JSC).
Changelog: [General] [Fixed] - Fix stack traces showing the wrong function name in some cases
Reviewed By: cpojer
Differential Revision: D18628230
fbshipit-source-id: 5677803500e45a41c1005496d19c150526af2d07
Summary:
Makes stack trace parsing return a consistent representation of column numbers when using Hermes, whether we're executing bytecode (in prod) or source code (in dev). This is achieved by creating a new full-fidelity stack trace parser for Hermes.
NOTE: We still use the `stacktrace-parser` package for other engines, so this fix applies only to Hermes and not to JSC - that will be fixed separately in an upcoming diff.
This fixes a bug where we were skewing some stack traces by sending 1-based column numbers to the Metro symbolication endpoint, which expects them to be 0-based. The bug is only noticeable in *some* cases, namely where the column immediately following the correct one is in a different function.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18627930
fbshipit-source-id: abd80846f00f24428670b2c92153564fb4bb2aff
Summary:
This is a more feature-full replacement for `textInputShouldChangeTextInRange:replacementText:` that allows implementing things like limiting text input content length without hacks and compromising the order of events. The new version of the TextInput will rely on that. The existing TextInput will use that as exacly like the previous version (because the new API is a superset of the the old one).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18670792
fbshipit-source-id: 0c434b351dfc8ab42404eb9aea0ede70bedaa9dc
Summary:
In AndroidTextInput, support codegen'd ViewCommands in native and add three commands that will eventually replace usage of setNativeProps on Android.
TextInput will use these commands in a future diff.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D18612150
fbshipit-source-id: 5d427040686e8c5ab504dd845bc8ef863f558c35
Summary:
## Overview
This diff adds handling for syntax errors created using `buildCodeFrameError` which have a slightly different format than syntax errors thrown during transforms.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D18658502
fbshipit-source-id: 0836f2c16cdd57c10ed1e03dc7345d8e1ccf53f3
Summary:
This diff switches LogBox over to use a Modal component so that the log inspector is always full screen.
In order to do that, it needed to add an `internal_excludeLogBox` flag to AppContainer so that it's not recursively rendered as: AppContainer -> LogBox -> Modal -> AppContainer. Not thrilled about the prop but it's necessary for now until this is rendered as it's own root (which we're working on next).
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D18461394
fbshipit-source-id: e1a80dfffbbe6c5467ac6f8d3c445a3280829020
Summary:
Changes `TouchableWithoutFeedback` so that `Props` is no longer exported as a Flow type.
Instead, other modules should use `React.ElementConfig<typeof TouchableWithoutFeedback>`.
Changelog:
[General] [Removed] - TouchableWithoutFeedback no longer exports Props. Use React.ElementConfig, instead.
Reviewed By: zackargyle, TheSavior
Differential Revision: D18718131
fbshipit-source-id: 0bd63123c49564fdab160d5fc8e7f1bf86da1fbe
Summary:
The experimentation code for `Touchable` is no longer necessary. Clean up all the injection points.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18715851
fbshipit-source-id: 15fe59e218d89f222ae2183a1452718e460048cb
Summary:
Launches a new implementation of `TouchableBounce`.
It is implemented using `Pressability` and extends `React.Component`. Notably, `propTypes` no longer exist.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18715856
fbshipit-source-id: df2300600a8f0f07fc669c1e28183a0ef3a6f695
Summary:
Launches a new implementation of `TouchableHighlight`.
It is implemented using `Pressability` and extends `React.Component`. Notably, `propTypes` no longer exist.
Changelog:
[General] [Changed] - TouchableHighlight overhauled as a class without propTypes.
Reviewed By: TheSavior
Differential Revision: D18715854
fbshipit-source-id: d4ea6ebd2ca9aef2af93ffad2fe75a96424514e5
Summary:
Launches a new implementation of `TouchableNativeFeedback`.
It is implemented using `Pressability` and extends `React.Component`. Notably, `propTypes` no longer exist.
Furthermore, `TouchableNativeFeedback` now behaves similar to `TouchableWithoutFeedback` on iOS (instead of rendering an error message).
Changelog:
[General] [Changed] - TouchableNativeFeedback overhauled as a class without propTypes. Also, replaced iOS error renderer.
Reviewed By: TheSavior
Differential Revision: D18715857
fbshipit-source-id: aa42c7547ac94340fde0ef30641cab7eb48ea81b
Summary:
Launches a new implementation of `TouchableOpacity`.
It is implemented using `Pressability` and extends `React.Component`. Notably, `propTypes` no longer exist.
Changelog:
[General] [Changed] - TouchableOpacity overhauled as a class without propTypes.
Reviewed By: TheSavior
Differential Revision: D18715858
fbshipit-source-id: 06ba5fc7eaacdbb7dc12d1564cc5d04e1a991229
Summary:
Launches a new implementation of `TouchableWithoutFeedback`.
It is implemented using `Pressability` and extends `React.Component`. Notably, `propTypes` no longer exist.
Changelog:
[General] [Changed] - TouchableWithoutFeedback overhauled as a class without propTypes.
Reviewed By: TheSavior
Differential Revision: D18715852
fbshipit-source-id: f2eb28e3b8500bfcd8db44fc6bdbc0476193723a
Summary:
Makes `Pressability` available the open source `react-native` repository.
This abstraction is intended to replace `Touchable.Mixin` and enable us to finally stop depending on `createReactClass` (et al).
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18715853
fbshipit-source-id: 21af8652cfb4557c60babd31b2776bcaeaed8447
Summary:
The following accessibility properties was added for view but not for Touchables - importantForAccessibility, accessibilityLiveRegion, accessibilityViewIsModal and accessibilityElementsHidden. This PR is to extend the support for all touchables.
## Changelog
[General] [Added] - Add missing accessibility props on Touchables
Pull Request resolved: https://github.com/facebook/react-native/pull/27293
Test Plan: Tested in RNTester app.
Differential Revision: D18650884
Pulled By: yungsters
fbshipit-source-id: 2172ac55a8c8803d7d923511f43b2598593ea1d2
Summary:
The class `RCTUITextView` is designed to be a home for workarounds. In Fabric we will use it as well, so we need to have all workarounds there.
That's just a move of some code between clases, it does not really affect how the workarounds work.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18607833
fbshipit-source-id: 1ba0e8c5cd928f3bf6fe1d2727325ecfc1dbf684
Summary:
When using `react-native-screen` which uses native view controller animations for navigation `TextInput` with `autoFocus` causes a weird animation glitch.
Removing the requestAnimationFrame will cause the focus command to be sent in the same batch as starting screen transitions which fixes the issue.
It is unclear why the rAF was added in the first place as it was part of the initial RN open source commit. If someone at facebook has more context that would be great to make sure it doesn't cause unintended side effects.
Credits to kmagiera for figuring out this
## Changelog
[General] [Fixed] - Remove requestAnimationFrame when focusing input on mount
Pull Request resolved: https://github.com/facebook/react-native/pull/27217
Test Plan:
- Tested in an app using react-native-screen to make sure the animation glitch is fixed
- Tested in RNTester to make sure it doesn't cause other issues when not using react-native-screens
Before:
After:
Differential Revision: D18666991
Pulled By: TheSavior
fbshipit-source-id: 66664c89e06c9ae65074ddcc4688dc5109fc9c72
Summary:
This removes common whitespace from a code frame to show more code. This is especially useful for heavily intended code that may not even be visible in the small window.
I am not 100% confident I wrote the right code because I'm under time pressure but it seems to work. I'm an intern and it's my last day.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: rickhanlonii
Differential Revision: D18657572
fbshipit-source-id: 6b93999c4482891f2123d67005843ce5db0d2976
Summary:
This vertical bar doesn't really add any value. This diff removes it. At first I tried to use regex but ansi codes make that hard. We can just use the structured data and rely on the fact that the second item is always the one with the vertical bar.
(Note: this ignores all push blocking failures!)
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18656911
fbshipit-source-id: b72d4c93d0008c7da54647d072a4c4eb7646b694
Summary:
This diff adds syntax highlighting to LogBox CodeFrames. It works by turning Ansi codes into "JSON" (it's actually just a JS object but the third-party API uses JSON as terminology) and then turning that into `<Text>` elements.
The syntax theme is called Afterglow and I took it from https://iterm2colorschemes.com/. Happy for anyone who wants to further tweak it! I installed this into iTerm and extracted the colors from there as it has a color picker and the labels directly map to the color classes exposed by the `anser` package.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: rickhanlonii
Differential Revision: D18618897
fbshipit-source-id: 64815619fc482e08b5671f492dabda8c8c0ceca5
Summary:
This diff fixes an exception thrown when using fast refresh when a log is opened.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18656859
fbshipit-source-id: 707f71f627daa172a4f9e02e3ff5d05b6174eb63
Summary:
Adds handling for reference errors so when we throw them in the next diff they're handled as syntax errors.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18644642
fbshipit-source-id: 2b751578c616c27d5b1ec6255aca56063bfd9d16
Summary:
Original commit changeset: d982163fe3f5
Landing the original but with the feature flag disabled. *doh*
Changelog:
[General][Changed] Partial React Sync from 6cff70a74...bb1853f73
Reviewed By: mdvacca
Differential Revision: D18649739
fbshipit-source-id: c9a15f511595fe0ae76dd49db7a7097d1bfa3853
Summary:
Modernizing this code a bit more, converting it to hooks.
Changelog:
[General][Changed] Converted TextInput to use React hooks
[General][Fixed] TextInput now properly sends native the end selection location on change
(Note: this ignores all push blocking failures!)
Reviewed By: JoshuaGross
Differential Revision: D18581712
fbshipit-source-id: 62d6ea8489fa019ddf941c520930365f2c4887d8
Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary:
Changelog: [Internal]
Fixing a red screen on the RN picker.
Looks like the picker gets confused when for unknown reasons a native value is undefined. In that case we stick to the JS value as it is specified in the comment.
https://fb.workplace.com/groups/rn.support/permalink/2997783536936908/
NOTE : Native fix was landed, this add an extra layer on the JS side
Reviewed By: mmmulani
Differential Revision: D18443005
fbshipit-source-id: 9511ac90f2d9e6186c6c0de3b673cc535cdb9fa6
Summary:
This variable is never set and only ever removed
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D18537317
fbshipit-source-id: bbb084e2ea5408fc59ef3853b2ec74bf22afbe21
Summary:
These tests need to be consistent with every test so a helper makes more sense.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D18500439
fbshipit-source-id: de535156d370102bad88e556ad3d2a0d5443e4e2
Summary:
LogBox tends to take a bit of time to open after tapping a log banner. This is very noticeable on Android where it takes multiple seconds.
When looking at React DevTools, the Stack Frame code can be responsible for two thirds of total LogBox rendering time. With this diff, the time is reduced from about 46ms to 25ms, and the total time spent rendering LogBox is reduced by one third.
This diff makes a few micro-optimizations but primarily it gets rid of an unnecessary View and collapses multiple text components into a single one as they are all rendered the same. Note that this also fixes an issue in the case where a line number may be missing but a column was provided. While I can't think of a case where that would actually happen, previously it would print the column (which could be mistaken for the lineNumber in that case) but now it prints the column only if the line Number is also present.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D18613899
fbshipit-source-id: 5c6a3b65b749d5f95058b34ded6cc12531d91c38
Summary:
RCTDevLoadingView wasn't hooked up to the codegen. This diff makes RCTDevLoadingView type-safe and also makes it TurboModule-compatible.
Changelog:
[iOS][Added] - Make RCTDevLoadingView TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D16969764
fbshipit-source-id: 47e6682eea3fc49d3f0448c636b5f616d5bce220
Summary:
This diff makes a few improvements to the call stack / symbolication process:
- Removes button from unsymbolicated stack frames
- Adds a warning message for missing features without symbolication
- Reduces symbolication requests (we were re-requesting stacks when they were pending)
- Speeds up opening unsymbolicated logs (because we were re-requesting them, the components were updating a lot)
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18577288
fbshipit-source-id: 6de322b4755895e2d1599b06100a61e64f7ec023
Summary:
Based on feedback we're going to clear all logs on fast refresh 👍
Changelog: [Internal]
Reviewed By: gaearon
Differential Revision: D18614230
fbshipit-source-id: 119a09e8ffea9d86137583d8da435338833f910c
Summary:
pretty-format library is not available on some JSC which causes the app to crash while trying to log a warning. This change defaults to just stringify the error if formatter is not available. The behavior on platforms where it already works fine isn't changed.
Changelog: Don't crash the app while formatting a warning for console if pretty-format is not available.
Reviewed By: PeteTheHeat
Differential Revision: D18403456
fbshipit-source-id: 73226f1a4e3f38c8d7c4e5ace909dd494e1da298
Summary:
Generating this diff was difficult. We _will_ fix the issues with jscodeshift, but i don't want to block the syntax change on that.
To get this diff, I first codemodded all of xplat to use exact-by-default. Then i turned on implicit-inexact-object:error enforcement to get a list of errors showing places that violated the lint. With that, I used this to generate a list of `sed` commands to add `...`:
```
flow --json | jq '.errors | .[] | .message | .[] | .loc | {source, "line": .end."line", "column": .end."column"} | "\(.column),\(.line),\(.source)"' | sort -n -r | sed 's/"//g' | while read -r line; do echo $line; awk -F',' "{ print \"sed -i '\"\$2\"s/./...&/\"\$1\"' \" \$3 }"; done
```
Then I ran prettier, reverted generated files, and manually fixed up suppressions that got messed up.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D18516431
fbshipit-source-id: 6cf940dce411fb179e7ebaff764bd5113a07989f
Summary:
Changelog: [Internal]
Introduce native command `setNativeRefreshing`, it has the word Native in order to avoid name conflict with setRefreshing in Android implementation. Even this component is iOS only, it would make it easier to merge them in the future.
Introduce `RCTRefreshableProtocol` and make `RCTRefreshControl` and `RCTPullToRefreshViewComponentView` to conform to the protocol so view manager can forward command to both, Paper and Fabric component.
Reviewed By: mmmulani
Differential Revision: D18475804
fbshipit-source-id: 4c19225784efc931b7b8f2d2671cc839bce429bf
Summary:
This diff adds a new API `setAppInfo` to add app version and engine to LogBox and changes the way they're displayed so that they're more subtle and visible for screenshots.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18592992
fbshipit-source-id: 1c57b21fa9dca93029ffc92acf1287f3ee247f4d
Summary:
This is the first diff in the series. It removes Flow types for this feature to verify that we actually do not have any usages. After it lands, we will remove actual support on the native side.
There are several reasons why removing it is a good idea:
* There is no any evidence that this feature is actually useful. That was discussed several times (e.g. see T7936714) during RN lifetime and the overall consensus is: We need something else, something like sync `onChange` event instead of it.
* Supporting the previous point, it's not used (at least inside Facebook). I searched hard and I could find only one place where it's used: in the TextInput Example.
* To deliver more functionality we should lean towards W3C specs, this one is not W3C compliant.
* Supporting this Feature in Fabric is quite challenging, so I want to do it sooner than later.
* This feature was never documented.
Changelog: [Breaking] `<TextInput>::onTextInput` event was removed
Reviewed By: TheSavior
Differential Revision: D18456175
fbshipit-source-id: c7a8ed7a86b33ecc01d45497645fe249556fdf96
Tom Underhill
Rick Hanlon
Eli White
Venits
Eloy Durán
Spencer Ahrens
Adam Ernst
Jason Safaiyeh
Dan Abramov
Josh Leibsly
Michel Weststrate
Lukas Weber
Kacie Bawiec
Jesse Katsumata
Samuel Susla
Paige Sun
Valentin Shergin
Pieter De Baets
Jorge Bernal
Peter Argany
Yuanzhe Bian
Emily Janzer
Moti Zilberman
Janic Duplessis
Mackenzie Mance
Arthur Kushka
Mike Vitousek
Ramanpreet Nara
Ahmed Ibrahim
Nikita Shanin
Kudo Chien
Rajat Gupta
Nat Mote
Kevin Gozali
Jiawei Lv
Nate Stedman
Shubho Sadhu
Oleksandr Melnykov
Christoph Nakazawa
Poyan Nabati
Panagiotis Vekris
Jordan Brown
David Vacca
Jakub
Héctor Ramos
Freeman Latif
Andy Matuschak
Kevin Gonzales
Tim Yung
Jimmy Zhang
Riley Dulin
jeswinsimon
talhaazhar
Isabel B
Andy Huang
Joshua Gross
Sharon Gong
George Zahariev
Lucy Beatriz Gomez
Stepan Furdei
