Summary: D16107933 disabled the logs around setup unless they are explicitly enabled and this diff disables all logs from this module entirely unless they are explicitly turned on at the top of the file.
Reviewed By: gaearon
Differential Revision: D16108151
fbshipit-source-id: 355aaf8624fb0778884f25f02d58fe4e1237d686
Summary: This module logs helpful messages in `__DEV__` but it only logs actionable performance logs when the flag on top of the file is enabled. This diff changes those to only log when the toggle on top of the file is enabled as well.
Reviewed By: gaearon
Differential Revision: D16107933
fbshipit-source-id: 7671bc521af984d617a0f5ffc0eacd1aa5674a62
Summary:
Metro symbolication can be expensive in large apps. However, there is no need to symbolicate _runtime stacks from compile errors_. Those are pretty much useless anyway.
This will reduce the workload on Metro workers, and the delays when iterating with Fast Refresh, as the server will be busy much less often.
So I'm special-casing them and not sending the symbolication request anymore.
Reviewed By: rickhanlonii
Differential Revision: D16030087
fbshipit-source-id: 41f83ac01780c0a60cca777014e4ed95c0f3d14b
Summary: If you make a syntax error while there is a redbox while Fast Refresh is on, we should dismiss that redbox. Otherwise there is no way for you to tell why your code is not working.
Reviewed By: rickhanlonii
Differential Revision: D15970337
fbshipit-source-id: 1ca6c9a1b2269d198ae726d3b64e5c51506503db
Summary:
If the error doesn't come in direct response to a user action, I think a redbox is too severe. I think we don't want to associate turning on Fast Refresh with a higher frequency of redboxes. So this downgrades these messages to warnings.
If you manually try to turn it off and on again, we'll still show a redbox to remind why it's not working.
Reviewed By: rickhanlonii, cpojer
Differential Revision: D15958952
fbshipit-source-id: bd144c98e87a9836871391ac583c268dca8009b3
Summary:
We have too many options in the Dev Menu, and they're really hard to pick from. They're also somewhat conflicting. This replaces two menu choices that have a similar purpose (faster iteration cycle) with one.
"Fast Refresh" tries to only update the affected modules, but falls back to doing a full reload if the update can't be handled by the React components.
If for some reason you prefer the "Reload-on-Save" behavior, please:
- Reach out to me so I can learn more about your use case.
- As a workaround, you can add `if (__DEV__) require.Refresh.forceFullRefresh = true` to your app's entry point to always do a full refresh.
Also note that I only removed the user-facing part of "Reload-on-Save". So if you have automation depending on it, that's gonna keep working.
I moved it above Systrace since it's a more generic feature.
As a total aside nit, I renamed "Enable Inspector" and "Disable Inspector" to "Show Inspector" and "Hide Inspector" because... that's what those options do, really.
Reviewed By: rickhanlonii
Differential Revision: D15958697
fbshipit-source-id: 20e856d56f661fe4d39b5ab47d8c44754bf70f67
Summary:
Since we always create `module.hot` objects, the `module.hot` checks were unnecessary. They give a false impression that we're checking for a Hot Reloading mode. However, they're just Flow refinements and always exist in DEV. I made that explicit by throwing early.
Similarly, I removed a `module.hot` check inside `setupReactRefresh`, as it is always truish in DEV.
Finally, I'm adding a new mechanism as an escape hatch. It lets you do:
```
if (__DEV__) {
require.Refresh.forceFullRefresh = true;
}
```
in your entry point and opt into full refreshes on every edit. This sounds similar to "Reload-on-Save". That is because in the next diff, I plan to remove "Reload-on-Save" from user-visible options (but it'll stay for automated workflows).
So this workaround is intended for people who for one reason or another don't want to opt into Hot Reloading as an alternative. We'll need to talk to them and find out why.
Reviewed By: rickhanlonii
Differential Revision: D15958475
fbshipit-source-id: 674187ddf86a4e286dfae28f4182555a8b5d7396
Summary:
As we saw in D15947985, and later traced down to D5623623, the `hot` option isn't used by Metro anymore. The relevant transforms _always_ run in DEV regardless of the option.
Given that, it doesn't make sense that enabling or disabling Hot Reloading forces a full refresh. This significantly raises the usage barrier because **currently, you might have to wait ~20 seconds (on a large app) to just start using Hot Reloading when you're already in the middle of some screen.** So you just end up not using it.
This diff changes enabling/disabling Hot Reloading to be _instant_.
Here's how it works:
1. Now we always send the necessary info to the client via the new `HMRClient.setup()` function. It creates a Metro HMR client instance, but only actually sets up the socket if Hot Reloading is on.
2. The "Enable Hot Reloading" menu no longer forces a reload. Instead, it calls `HMRClient.enable()` which lazily sets up a socket (at most once).
3. The "Disable Hot Reloading" menu also doesn't trigger a refresh now. Instead, it calls `HMRClient.disable()`. We don't actually tear down the socket here because it's a pain to deal with race conditions and such. Instead, we keep the connection — but we _ignore the updates_ that come in while we're disabled.
4. As a result, it is possible to enable and disable it many times during a single session. (Updates while disabled would be ignored — which has a risk of making your running app inconsistent — but I'd argue it's expected and is worth it. You can always save a particular file to force it to update once the mode is on.)
5. In order to support "ignoring" updates, Metro's `HMRClient` (not to be confused with RN's module) now supports a `shouldApplyUpdates` field. The RN module uses it to disable handling updates when the mode is off.
6. In case there is an error that makes hot reloading unavailable (such as the server disconnecting), we surface the error only if the mode is on. If the mode is off, we stash the error message in the `_hmrUnavailableReason` variable, and display it next time you try to enable Hot Reloading.
Reviewed By: rickhanlonii
Differential Revision: D15958160
fbshipit-source-id: 8256fc4d5c2c3f653a78edf13b8515a5671953e4
Summary: The current grey one is very bland, hard to read (no contrast) and often looks like a bug. I've changed it to match the iOS Personal Hotspot colors which look more idiomatic.
Reviewed By: cpojer
Differential Revision: D15941200
fbshipit-source-id: d60a3744c73675b40f42c329c2a44e6b8b0a93dc
Summary:
D10527979 made the "update" message sequence part of initial connection signals. But the HMR client uses this sequence as a signal to show "Hot Reloading..." bar. As a result, we were showing it on every initial load when Hot Reloading is on. This is very confusing.
As a simple fix, I now send an explicit message to mark the end of the first load. I could infer that by first update message but figured this is more explicit and less likely to break. Until we receive `connection-done`, we now don't attempt to show the "Hot Reloading..." bar.
Reviewed By: rubennorte
Differential Revision: D15936085
fbshipit-source-id: b18b6aceea6c47d919b4265e58b21fc44f77b0b3
Summary:
This diff removes an option from the codegen and replaces it with two new options
Removes:
- `isDeprecatedPaperComponentNameRCT`
Adds:
- `paperComponentName`: a better version of the removed option that allows more than just adding RCT
- `paperComponentNameDeprecated`: a new option that allows migrating native code to a new name
```
// Use for components with no current paper rename in progress
// Does not check for new name
paperComponentName?: string,
// Use for components currently being renamed in paper
// Will use new name if it is available and fallback to this name
paperComponentNameDeprecated?: string,
```
For example, Slider uses `paperComponentName: 'RCTSlider'` because it has a different name in fabric but is not currently being migrated to a new name. Because of other work in progress, we don't want to use UIManager check if we don't need to
Reviewed By: shergin
Differential Revision: D15857629
fbshipit-source-id: ca0d3b7dc4a75e00d136ae1f5c84f7423960399d
Summary: For better perf with TurboModule, cache the return value of NativePlatformConstants*.getConstants() in JS so that we avoid going back into native (from JS) for each call. This specific method is called very frequently throughout RN codebase.
Reviewed By: mdvacca
Differential Revision: D15893289
fbshipit-source-id: ce8016ed7d3efb420df93e27dbfa77d7d4f06cf8
Summary: This diff adds the generated view config for View (in DEV)
Reviewed By: ejanzer
Differential Revision: D15780039
fbshipit-source-id: 1ec8ed1b57fd2341552746051980129848cb8e85
Summary: This diff turns on codegen for Slider and Switch
Reviewed By: TheSavior
Differential Revision: D15738544
fbshipit-source-id: a0dfb5b05fd62f28fc3865855986e49598dd5e19
Summary:
This diff adds a testing screen dev route to the facebook app for testing generated view configs
It's not pretty (i have 0 tetra experiance) but it gets the job done
There are three cases handled:
- No generated config �
- Invalid generated config (useful for dev) �
- Valid generated config �
On the description page we:
- Redbox it it's invalid (this could be used to redbox test all host components)
- Show diffs of the view config properties
- List all of the generated config properties
- List all of the native config properties
Using this tool, it's easy to see what the current config on native is, add correct flow types for the generated config, and validate the generated config
Coming later: adding all of the native configs to the list (will probably need filtering)
Reviewed By: cpojer
Differential Revision: D15683033
fbshipit-source-id: 5a566a56bef4f3f0bac3ea581c2e6acb2b9984e3
Summary: `verifyComponentAttributeEquivalence` checks the new JS view configs against what we get from native at runtime (in dev only). This breaks in bridgeless mode because there is no paper UIManager to ask for the viewconfigs from; this diff uses the flag from D15721940 to skip this check.
Reviewed By: fkgozali
Differential Revision: D15722127
fbshipit-source-id: d9227107e0ff7814c34beaae6461bb8232699c94
Summary:
This diff updated the codegen flow types syntax replacing:
```
type Options = {
isDeprecatedPaperComponentNameRCT: true,
};
type ActivityIndicatorNativeType = CodegenNativeComponent<
'ActivityIndicatorView',
NativeProps,
Options,
>;
module.exports = ((requireNativeComponent(
'RCTActivityIndicatorView',
): any): ActivityIndicatorNativeType);
```
with:
```
export default codegenNativeComponent<NativeProps>('ActivityIndicatorView', {
isDeprecatedPaperComponentNameRCT: true,
});
```
This is from Tim's comment in the [View Config Codegen Quip](https://fb.quip.com/jR2aASHad4Se):
> What it CodegenNativeComponent were instead `NativeComponent.fromFlow<T>('…')` that returned `'...'`?
>And the Babel plugin swapped it for NativeComponent.fromSchema('...', {…}) which would both register and return '...'?
I went with `codegenNativeComponent` because it has nice parity with `requireNativeComponent`
I also didn't update the babel output here (we can update that whenever) because I think `registerGeneratedViewConfig` is more clear for what it's doing
Reviewed By: cpojer
Differential Revision: D15602077
fbshipit-source-id: 2d24dc32136ba6d31724f8c929b51417ba625a58
Summary:
This diff updated the format of generated view configs so that they don't need to spread View props into every config, by adding a new registerGeneratedConfig function which will spread them instead
This is a bit of a cleanup of the generated output but is primarily so that the view config babel plugin will not need to rely on object spreading or object.assigns
Reviewed By: TheSavior, cpojer
Differential Revision: D15517199
fbshipit-source-id: 08e575578177bad12d40ee3dcad9381974b6466d
Summary:
Addresses a number of pieces of feedback regarding the debug menu.
- Simplify labels for the debugger actions (e.g. no "remote", no emoji).
- Reorder actions so that modal items are generally lower.
- Changed "Toggle Inspector" to "Show/Hide Inspector".
- Renamed "Live Reloading" to "Reload-on-Save".
- Hide disabled debug items when profiling is enabled.
- Changed "Start Systrace" to "Systrace Unavailable" when debugging.
- Renamed "Change packager location" to "Configure Bundler".
- Revised nomenclature in "Configure Bundler" menu to be clearer.
- Removed extraneous debug menu title.
- Consistently refer to HMR as "Hot Reloading".
Changelog:
[iOS] [Changed] - Cleaned up debug menu.
Reviewed By: axe-fb
Differential Revision: D15548628
fbshipit-source-id: 26b2ddca8280d1f6f8ff904439b403600e98a3b3
Summary:
This is an ESLint plugin that infers whether an import looks like a Haste module name. To keep the linter fast and simple, it does not look in the Haste map. Instead, it looks for uppercase characters in single-name import paths, since npm has disallowed uppercase letters in package names for a long time. There are some false negatives (e.g. "merge" is a Haste module and this linter rule would not pick it up) but those are about 1.1% of the module names in the RN repo, and unit tests and integration tests will fail anyway once Haste is turned off.
You can disable the lint rule on varying granular levels with ESLint's normal disabling/enabling mechanisms.
Also rewrote more Haste imports so that the linter passes (i.e. fixed lint errors as part of this PR).
## Changelog
[General] [Changed] - Add a lint rule to disallow Haste imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25058
Differential Revision: D15515826
Pulled By: cpojer
fbshipit-source-id: d58a3c30dfe0887f8a530e3393af4af5a1ec1cac
Summary: Adding flow types for DeviceInfo module and migrating our codebase over to using `DeviceInfo.getConstants()`
Reviewed By: fkgozali
Differential Revision: D14645744
fbshipit-source-id: e30a060c6dc92938cd1420ba11a1d837c79d1e32
Summary: Rick manually created view config in JS for View; adding some missing attributes/events and using this instead of `requireNativeComponent`
Reviewed By: rickhanlonii
Differential Revision: D15488008
fbshipit-source-id: 48e925ec0ca2aeba9e6cc66edef0b70ee1c94d27
Summary:
This is another step in moving RN towards standard path-based requires, updating more code to use path-based requires. See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
## Changelog
[General] [Changed] - Replace more Haste imports with path-based imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25001
Differential Revision: D15467829
Pulled By: cpojer
fbshipit-source-id: 58c364bb4c1c757689907d5ed0d0f3fac0e22f3f
Summary: Fixes a flow failure in the generated output and adds trailing commas to pass linting
Reviewed By: yungsters
Differential Revision: D15354725
fbshipit-source-id: 1eac27fa753af595a9a2787426b147e5f49a4e1d
Summary: This diff adds a line to the codegen'd view configs which will check that all of the properties in the native view config are also in the JS view config we generate (note that the JS view config may have more properties than one native platform because it includes a union of both platforms)
Reviewed By: TheSavior
Differential Revision: D15278478
fbshipit-source-id: 0fef20c12265b952c69aca4e4c070a7d036db05a
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary: Currently we can't access navigationOptions from measureAppRequire and that breaks fetchRelayQuery logs.
Reviewed By: fkgozali
Differential Revision: D14505525
fbshipit-source-id: 97ae4461ebb0e703633f782323b13b4e4f7c5cb7
Summary:
This PR add tests for several utilities in `Libraries/Utilities`, as a follow-up of #23903.
The following utilities are now tested:
* `clamp.js`
* `binareToBase64.js`
* `DeviceInfo.js`
* `mergeIntoFast.js`
* `PixelRatio.js`
* `infoLog.js`
* `logError.js`
* `warnOnce.js`
* `mapWithSeparator` (added a missing test)
Not applicable, since it only adds tests.
Pull Request resolved: https://github.com/facebook/react-native/pull/23989
Differential Revision: D14502806
Pulled By: cpojer
fbshipit-source-id: e2c3b3a35f4f765d5336b998ab92dba14eeac7bc
Summary:
This function returns a HOC that passes `scopedPerformanceLogger` as a prop to the wrapped component. That HOC
can be used whenever we can't declare `static contextType` as `PerformanceLoggerContext` on a component,
for example because React supports only one React Context per component.
Reviewed By: sahrens
Differential Revision: D14385560
fbshipit-source-id: 41971b4bf499f336c34b9220a3ee97c4ed89498d
Summary:
I was looking at the coverage report of the JavaScript code in the `Libraries` folder, and found some of the modules and functions to be (partially) untested. I believe that adding tests to them would formally capture their behaviour and avoid future regressions. In this PR, I've added some unit tests for 3 utility components.
Perhaps a more general question: Are these kinds of PRs appreciated? I'd be interested in submitting more of them in the future.
Not applicable, since it only adds tests.
Pull Request resolved: https://github.com/facebook/react-native/pull/23903
Differential Revision: D14477601
Pulled By: cpojer
fbshipit-source-id: c0700c5b514cd0df983fecfd91c93fc2bd049f5d
Summary:
@public
This bumps Prettier to v1.16.4
Only format source files were updated.
Reviewed By: mjesun
Differential Revision: D14454893
fbshipit-source-id: 72f9872fe764a79dbf0d9fab9bebb1456b039f2f
Summary:
Initially if a `react-native-web` project were to use a library that required internals `expo/webpack-config` would polyfill those internals. This `Platform.web` was used for cases where `react-native` modules needed other internal `react-native` modules, ex: `Animated/src/AnimatedEvent -> Renderer/shims/ReactNative -> Renderer/oss/ReactNativeRenderer-dev -> Core/InitializeCore -> Devtools/setupDevtools -> WebSocket/WebSocket -> Utilities/Platform`
The consensus is that if any `react-native` library references a `react-native` internal (ex: `react-native/*`), it should continue to throw errors. We've removed the use of internals from all of the Unimodules, `react-navigation`, and `react-native-gesture-handler`. This covers a wide enough area for a lot of projects to get web support.
* Add emitters for libs referencing internals necolas/react-native-web#1275
* Remove monkey patch that bundles RN, libs that use internals will crash instead expo/expo-cli#409
* Remove all unsupported internals and polyfills from the Expo suite expo/expo#3676
* Remove internals from react-native-gesture-handler kmagiera/react-native-gesture-handler#406
* Related #23387
[GENERAL] [REMOVED] - Platform.web.js
Pull Request resolved: https://github.com/facebook/react-native/pull/23830
Differential Revision: D14406145
Pulled By: hramos
fbshipit-source-id: bdda99a334d33f5543fdb954eb80e2e7186f985a
Summary:
I'm changing all callsites to use either global or scoped perf logger explicitly in one diff.
`GlobalPerformanceLogger` is basically a singleton
`scopedPerformanceLogger` is scoped to the React tree by using a React Context
Reviewed By: sahrens
Differential Revision: D14186694
fbshipit-source-id: 062c76eea8fce9d9b531f0eddf153bb79d52f68d
Christoph Nakazawa
Dan Abramov
Panagiotis Vekris
Eli White
Rick Hanlon
Kevin Gozali
Emily Janzer
Tim Yung
Tom Sanderson
James Ide
Wojteg1337
Michał Pierzchała
Eric Lewis
Glenna Buford
Uilque Messias
Alexey Lang
Casper Boone
Georgios Andreadis
Peter van der Zee
Evan Bacon
Alexander Zhang
George Zahariev