Summary:
In order to make this more flow typed and modern we need to get it off of createReactClass. This change converts the class as is with no intended behavior changes to an ES6 class.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18443018
fbshipit-source-id: 831921976e9de8e965180cdefd1c4a154f04bfea
Summary:
Changes the Fast Refresh message for when metro disconnects to remove "Reload to reconnect.". The most common use case for this happening is when Metro is stopped, and reloading will not reconnect to a stopped metro server.
Long term we should reconnect to Metro automatically and then this message would be followed up with a "Reconnected to Metro" message, never needing a reload.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18527705
fbshipit-source-id: 40768ce1089348b612e9d86638f07169d2a34b67
Summary:
This change is not only more correct, it's also fixes the modal in the the next diff.
It's more accurate because in the previous location, the redbox dismissal was done as a hack in order to hide non-syntax errors so that the syntax error would be visible when it fired. This is unnecessary for LogBox because it always puts syntax errors on top of any other error.
The main motivation for changing this, however, is that this strategy is broken when switching to the Modal component because the Modal component does not work well with quickly unmounting and remounting. With the old strategy, the inspector would flicker and then collapse even though there was a syntax error.
Changelog: [Internal]
Reviewed By: cpojer, gaearon
Differential Revision: D18461431
fbshipit-source-id: e8ed83e3d2b002e5d45cc13dc9533ed841ed5cae
Summary:
Changelog: [Internal]
Reverting the import to the previous local module style since importing from react-native seems to introduce some perf regression. We'll revisit this later in the future.
Reviewed By: yungsters
Differential Revision: D18383893
fbshipit-source-id: f11d46a4545768f39199fd6fd22fcf14905d0a74
Summary:
Adding a handwritten view config for RCTScrollView, to be used in DEV only (for now).
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D18263203
fbshipit-source-id: 975499f030c7caed9851bcde0be42c5058911ad5
Summary:
still some generated files in www that need to land before we can release 0.111 here.
drop-conflicts
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: dsainati1
Differential Revision: D18278838
fbshipit-source-id: b20c3fefb3aab7c5fb614b33d846c7548184f49a
Summary:
When you write platform-specific code using [file extensions](https://facebook.github.io/react-native/docs/platform-specific-code#platform-specific-extensions), you can specify `.ios.js`, `.android.js`, or the catch-all `.native.js` when you are sharing code with a web project.
This `native` shortcut is missing for the `Platform.select` method, and this PR is adding support for that.
## Changelog
[General] [Added] - Platform.select now supports native as an option.
Pull Request resolved: https://github.com/facebook/react-native/pull/26966
Test Plan: Added relevant passing unit tests for Platform module.
Differential Revision: D18323670
Pulled By: cpojer
fbshipit-source-id: 7524c1914beab4f86041dcf8e60875380ebf7e02
Summary:
Changelog: [Internal]
Moved the imports for `TurboModuleRegistry` and `TurboModule` from `react-native`. This was a jscodeshift with the script: P120688078
Reviewed By: yungsters
Differential Revision: D18262538
fbshipit-source-id: 48fac15229c897408928511c5ecbb42f17ec7b42
Summary:
Currently we generate Java ViewManager interfaces and C++ classes for iOS regardless whether the component is supported on platform or it isn't. This adds an option to exclude either iOS to Android in order to avoid this.
Changelog: In codegen it is now possible to exclude one or the other platform
Reviewed By: rickhanlonii
Differential Revision: D18217185
fbshipit-source-id: 1c569b92c92a5b991c96b0abdff6b8ed395e449f
Summary:
This diff adds Fast Refresh support for dismissing LogBox syntax errors. We don't dismiss all errors because once a syntax error is fixed you'll still want to see the covered fatals, errors, and warnings.
If you actually full reload, then it falls back to the native redbox.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278889
fbshipit-source-id: f109ca1d6c34aa3eda6e434deca66f8ce5e02ce0
Summary:
This diff enables the codegen ViewConfig in production, which have been running in Dev mode for 4+ months withouth any issue
Changelog: [Internal]
Reviewed By: rickhanlonii, ejanzer
Differential Revision: D18218546
fbshipit-source-id: cc74a89db1b1f8d9770a0b7dacb2fbfa6fd3a2d7
Summary:
At times, the OS updates the color scheme without any active listener on RN side, e.g. if all RCTRootView's in iOS have been deallocated, no one will tell JS that the color scheme changes. So let's just always ask native side for the latest value.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D18117334
fbshipit-source-id: e8564fb284c5720061592ba72e5b4907e5b48853
Summary:
Some of our NativeModule type specs aren't compatible with our Android codegen and type safety checks - specifically, we don't support `$ReadOnly` in our type checks, and we don't support map types in the codegen. Removing these from a couple of the OSS type specs so we can enable codegen for these modules (eventually).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D17882093
fbshipit-source-id: 6e8669e4be775347199b2b5346bd8d40d7620886
Summary:
If you `console.log` early enough in the initialization sequence, it won't get sent to Metro because `hmrClient` isn't initialized yet. I've added a rolling array to catch at most 100 of those, and send them after we initialize.
Changelog: [General] [Fixed] - Early logs don't get dropped by Metro now
Reviewed By: cpojer
Differential Revision: D17952097
fbshipit-source-id: 964b4735a6a7c3ccd115f44151139d718bf5b26d
Summary:
Fix flow type platform ios get version
## Changelog
[INTERNAL] [FIXED] - Fix flow type platform ios get version
## Test Plan
Pull Request resolved: https://github.com/facebook/react-native/pull/26639
Differential Revision: D17743074
Pulled By: TheSavior
fbshipit-source-id: de97c612dbf615a8ede1905cb158f258c9ce5737
Summary: This diff adds a method to call whenever a fast refresh happens. Right now this is only useful for reporting.
Reviewed By: cpojer
Differential Revision: D17528033
fbshipit-source-id: 17e82abe7a3e2bab6829de5adecda853fe5335c5
Summary:
This diff adds reloadWithReason to the NativeDevSettings and updates the exposed DevSettings.reload method to send to it if it's available (setting an 'uncategorized' reason if one isn't set.
[General][Feature] Update DevSettings.reload to accept a reason
Reviewed By: RSNara
Differential Revision: D17499343
fbshipit-source-id: e8c9724800f93d3b9a5d2a8fe9f689d51947d39b
Summary:
In React Native there are three types of "Native" components.
```
createReactClass with NativeMethodsMixin
```
```
class MyComponent extends ReactNative.NativeComponent
```
```
requireNativeComponent('RCTView')
```
The implementation for how to handle all three of these exists in the React Native Renderer. Refs attached to components created via these methods provide a set of functions such as
```
.measure
.measureInWindow
.measureLayout
.setNativeProps
```
These methods have been used for our core components in the repo to provide a consistent API. Many of the APIs in React Native require a `reactTag` to a host component. This is acquired by calling `findNodeHandle` with any component. `findNodeHandle` works with the first two approaches.
For a lot of our new Fabric APIs, we will require passing a ref to a HostComponent directly instead of relying on `findNodeHandle` to tunnel through the component tree as that behavior isn't safe with React concurrent mode.
The goal of this change is to enable us to differentiate between components created with `requireNativeComponent` and the other types. This will be needed to be able to safely type the new APIs.
For existing components that should support being a host component but need to use some JS behavior in a wrapper, they should use `forwardRef`. The majority of React Native's core components were migrated to use `forwardRef` last year. Components that can't use forwardRef will need to have a method like `getNativeRef()` to get access to the underlying host component ref.
Note, we will need follow up changes as well as changes to the React Renderer in the React repo to fully utilize this new type.
Changelog:
[Internal] Flow type to differentiate between HostComponent and NativeMethodsMixin and NativeComponent
Reviewed By: jbrown215
Differential Revision: D17551089
fbshipit-source-id: 7a30b4bb4323156c0b2465ca41fcd05f4315becf
Summary:
I wanted to configure the RN dev menu without having to write native code. This is pretty useful in a greenfield app since it avoids having to write a custom native module for both platforms (and might enable the feature for expo too).
This ended up a bit more involved than planned since callbacks can only be called once. I needed to convert the `DevSettings` module to a `NativeEventEmitter` and use events when buttons are clicked. This means creating a JS wrapper for it. Currently it does not export all methods, they can be added in follow ups as needed.
## Changelog
[General] [Added] - Export the DevSettings module, add `addMenuItem` method
Pull Request resolved: https://github.com/facebook/react-native/pull/25848
Test Plan:
Tested in an app using the following code.
```js
if (__DEV__) {
DevSettings.addMenuItem('Show Dev Screen', () => {
dispatchNavigationAction(
NavigationActions.navigate({
routeName: 'dev',
}),
);
});
}
```
Added an example in RN tester
![devmenu](https://user-images.githubusercontent.com/2677334/62000297-71624680-b0a1-11e9-8403-bc95c4747f0c.gif)
Differential Revision: D17394916
Pulled By: cpojer
fbshipit-source-id: f9d2c548b09821c594189d1436a27b97cf5a5737
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/26143
A new useColorScheme hook is provided as the preferred way of accessing the user's preferred color scheme (aka Dark Mode).
Changelog:
[General] [Added] - useColorScheme hook
Reviewed By: yungsters
Differential Revision: D16860954
fbshipit-source-id: 8a2b6c2624ed7cf431ab331158bc5456cde1f185
Summary:
Implements the Appearance native module as discussed in https://github.com/react-native-community/discussions-and-proposals/issues/126.
The purpose of the Appearance native module is to expose the user's appearance preferences. It provides a basic get() API that returns the user's preferred color scheme on iOS 13 devices, also known as Dark Mode. It also provides the ability to subscribe to events whenever an appearance preference changes.
The name, "Appearance", was chosen purposefully to allow for future expansion to cover other appearance preferences such as reduced motion, reduced transparency, or high contrast modes.
Changelog:
[iOS] [Added] - The Appearance native module can be used to prepare your app for Dark Mode on iOS 13.
Reviewed By: yungsters
Differential Revision: D16699954
fbshipit-source-id: 03b4cc5d2a1a69f31f3a6d9bece23f6867b774ea
Summary:
https://github.com/facebook/react-native/pull/25990 fixed the `forceUpdate` method to actually update the component, but caused the useEffect to fire on every render, causing continuous updates after dimensions changed (e.g. from rotation).
This reworks things a bit to be a bit simpler and more idiomatic so it's not quite as confusing, and fixes the bugs.
## Changelog
[General] [Fixed] - Fix useWindowDimensions hook firing continuously after dimensions change
Pull Request resolved: https://github.com/facebook/react-native/pull/26008
Test Plan:
Aparently the Mobile Home app supports rotation on iOS now, so replaced it's content with the first `DimensionsExample` and confirmed with logging that `useEffect` fires exactly once, on initial mount, but the view still updates as expected when rotated:
https://pxl.cl/Hfds
Reviewed By: yungsters
Differential Revision: D16765269
Pulled By: sahrens
fbshipit-source-id: ef55d8a470dcfe87aa125d4c426bf01cfe0091a7
Summary:
Need to add explicit type annotations in these areas to unblock types-first architecture for Flow. These are locations the codemod could not automatically handle.
I'll call out areas I need a close eye on in the comments.
Reviewed By: panagosg7
Differential Revision: D16659053
fbshipit-source-id: 167dd2abe093019b128676426374c1c62cf71e7f
Summary: This diff fixes the error message in the codegenNativeComponent fallback
Reviewed By: TheSavior
Differential Revision: D16579775
fbshipit-source-id: 176f81ea91e11f671407a5e5e5b000c4b83f93b2
Summary: ComponentScript uses Dimensions, but doesn't support native modules, so we need to keep the `nativeExtensions` stuff that was dropped in D16525189.
Reviewed By: PeteTheHeat
Differential Revision: D16611233
fbshipit-source-id: c0add40529743e02ab7943814dc9f2188e8e0633
Summary:
Previously codegenNativeCommands was just a hint to the babel transform. This meant that in order to use the codegen'd JS command functions it required having the babel transform turned on.
We aren't ready to turn the transform on for open source so we are adding runtime behavior to the function that will run when it isn't replaced with the transform.
Reviewed By: rickhanlonii
Differential Revision: D16574781
fbshipit-source-id: 583e8857f69ae1695445ee887432d15248dd35a9
Summary:
Original commit changeset: 34a8f8395ca7
The problem with the original commit was the usage of optional chaining. This diff removes the usage of optional chaining with good old fashioned null checks.
Reviewed By: rickhanlonii
Differential Revision: D16593623
fbshipit-source-id: d24cc40c85de9a2e712e5de19e9deb196003ccf2
Summary:
We want to enable codegenNativeCommands to have a runtime fallback that will work if the babel transform is not enabled. For example, in open source until we turn it on everywhere. By listing the supported commands, we can create the necessary functions at runtime to support what we need.
A follow up diff will add that runtime behavior to codegenNativeCommands.
Reviewed By: JoshuaGross
Differential Revision: D16573450
fbshipit-source-id: 189754a567a3a5ccd34629a8dfedf808e6824e82
Summary:
Automatically provides and subscribes to dimension updates - super easy usage:
```
function MyComponent(props: Props) {
const {width, height, scale, fontScale} = useWindowDimensions();
return <Text ...
};
```
Only window for now - it's what people want 99% of the time, so we'll just shovel out a pit of success for them...
There are still cases where `Dimensions` is needed outside of React component render functions, like in GraphQL variables, so we need to keep the existing module.
Reviewed By: zackargyle
Differential Revision: D16525189
fbshipit-source-id: 0a049fb3be8d92888a8a69e3898d337b93422a09
Summary: Symbol is not available in older versions of JSON resulting in crashes in `prettyFormat` because we are using a clowny transform.
Reviewed By: sebmck
Differential Revision: D16501208
fbshipit-source-id: 9952bf4993ae05335707cd386f9aa4bbc14b7564
Summary: Right now we are using `JSON.stringify` which is very lossy with regards to JavaScript data types like functions, `undefined`, NaN and others. This diff switches the logging on the client side to use `prettyFormat` which is part of Jest. It allows to handle much richer log messages.
Reviewed By: gaearon
Differential Revision: D16458775
fbshipit-source-id: e1d2c125eb8357a9508521aa15510cb4f30a7fa9
Summary:
On iOS we don't call `HMRClient.setup()` when Metro is off. So we don't bump into any odd cases.
But on Android, we do call `HMRClient.setup()` even if Metro is off. As a result, we might show a warning about Metro not running to a native engineer who doesn't care (because they don't intend to work on JS).
We could fix this on Android on the native side. And we probably should.
But we can also strengthen it here. The idea is that we should only show warnings about disconnecting from Metro *if we ever managed to successfully connect in the first place*. Otherwise, we can assume that you didn't mean to connect.
If the user is trying to determine the source of the problem, they can still do a full Refresh (on iOS this will show a message about needing Metro, on Android it would show a redbox). So this diff makes the disconnected behavior closer to how it worked before Fast Refresh.
Reviewed By: sahrens
Differential Revision: D16460439
fbshipit-source-id: bf962ff34c25d9734d9668dd583591acacb98253
Summary:
Two changes:
1. If you're connected at startup, and then disconnect, we're supposed to show a yellow box. Looks like we weren't doing it for a few days because the field we were checking has turned into a method.
2. I changed the wording back to remove "Metro" since the packager may be Haul, for example. So I'm just calling it "development server". Does that seem reasonable? I also removed mentions of Fast Refresh since it's not actually relevant to the problem.
Reviewed By: cpojer
Differential Revision: D16459080
fbshipit-source-id: c9c1f19718d522c745e4107a3e7e3a6c63f82642
Summary:
This change switches the sending of log messages to Metro from HTTP over to WebSocket. This is what I should have done from the beginning *however* I only spent very little time on this initially, didn't realize that it would be a popular feature *and* we didn't have a persistent WebSocket connection on the client before that was always on. Together with D16442656 we can finally make this happen!
This change:
* Changes the `fetch` call to `HMRClient.log`
* Removes the middleware and integrates logging with `HmrServer` directly in Metro.
* Simplifies the logging logic as WebSockets guarantee messages are processed in order.
This also fixes an issue makovkastar identified when using the `MessageQueue` spy: because we send messages back and forth over the bridge, using `console.log` within `MessageQueue`'s spy method will actually cause an infinite logging loop. This is the proper solution to that problem instead of hacking around it using custom headers.
Note: in a follow-up we will rename these modules to drop the `HMR` prefix. We have not come up with a better name yet and are open to ideas.
Reviewed By: sebmck
Differential Revision: D16458499
fbshipit-source-id: 4c06acece1fef5234015c877354fb730b155168c
Summary:
Error objects logged as part of the arguments to `console.error` such as from [rejected es6 promises](https://github.com/zloirock/core-js/blob/v2/modules/es6.promise.js#L110) contain the error that the user would want to see as the error object's message, but is not captured by `stringifySafe`. Here we modify it to if the logged value is an error object print the error similar to chrome:
```
const error = new Error('error');
stringifySafe(error); // Error: error
```
Versus the current behavior which does not recognize the error type and instead tries to stringify the it as an object:
```
JSON.stringify(new Error('error')) // "{}"
```
## Changelog
[JavaScript] [Changed] - Add support for stringifying error object messages to safeStringify
Pull Request resolved: https://github.com/facebook/react-native/pull/25723
Test Plan:
Tests:
<img width="802" alt="Screen Shot 2019-07-18 at 8 39 52 PM" src="https://user-images.githubusercontent.com/2192930/61501171-39218080-a99c-11e9-8e87-48ea413b3d01.png">
Lint:
<img width="406" alt="Screen Shot 2019-07-18 at 8 43 35 PM" src="https://user-images.githubusercontent.com/2192930/61501318-dc729580-a99c-11e9-9264-c0232515352c.png">
Differential Revision: D16437956
Pulled By: cpojer
fbshipit-source-id: ca3ce9c98ad585beb29c2bfeb81bbd14b2b1c700
Summary: If there's a redbox at the start, we shouldn't dismiss it. Instead, redboxes should only be dismissed on explicit edits.
Reviewed By: yungsters
Differential Revision: D16421934
fbshipit-source-id: 770c5b5fc85e6b6ce00a4477aa87d6e91b14fc3c
Summary: When turning on Fast Refresh, we might have a compile error in previously saved files. We used to ignore it until a file is saved again, leading to a confusing experience. This changes it so that we remember the last compile error, and show it _either_ when we get it (if Fast Refresh is off), or when we _turn it on_.
Reviewed By: cpojer
Differential Revision: D16359160
fbshipit-source-id: 8dc237563c2a271a23019a32ff85b57de99cfabe