Summary:
When I installed React Native and loaded it up in the emulator, I wasn't really sure what the menu button was. I clicked around through the default emulator for advice but couldn't find it. So, instead this version now tells you directly what the key commands are.
Because it needs to show both<key>ctrl</key> and <key>cmd</key> (depending on dev's OS) I opted to include both and felt like it needed spaces around the `+`. So, I made that consistent everywhere.
## Test Plan
n/a
## Changelog
[Android] [Fixed] - Improves the initial copy for creating a new RN project on android
Pull Request resolved: https://github.com/facebook/react-native/pull/25353
Differential Revision: D15956358
Pulled By: mdvacca
fbshipit-source-id: aa320e30da53e6ba35f879f57740777bdee26618
Summary: This is utility for TurboModule codegen for the purpose of typesafety. It is not used anywhere else at the moment.
Reviewed By: cpojer
Differential Revision: D15929957
fbshipit-source-id: ecf68cc98b78bc5b9c2078492b853a677b625eea
Summary: FBLazyVector is a simple utility to help typesafety/codegen of TurboModule specs. This is not used widely elsewhere at the moment.
Reviewed By: hramos, cpojer
Differential Revision: D15929956
fbshipit-source-id: 17226351738335a74e7b931812a1ca901f47963f
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:
Logging nasty objects can cause RN to lockup as we try to format it nicely. The formatting code has some safegaurds against excessive recursion and some cycles, but it's not failsafe.
This adds a limit on the total number of times format can be called before we start to bail out. In my testing, this limit keeps the format time under ~100ms for huge objects, and logcat and other log readers start truncating it anyway so there is rarely any lost information.
I also considered using wall time, but this seemed a little cleaner. Open to suggestions.
Reviewed By: yungsters
Differential Revision: D15710157
fbshipit-source-id: b50261093270d6fb67b3473432d384ec51b98fd5
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 removes React Transform HMR in favor of the new React Refresh implementation. It should only affect the "Enable Hot Reloading" mode. In further diffs I will remove "React Transform HMR" completely.
This is technically a breaking change for Metro so it'll need a version bump.
Reviewed By: rickhanlonii, rubennorte
Differential Revision: D15903585
fbshipit-source-id: 074380b00868cb31857f599a03799d3584c35d87
Summary:
Prior to this patch the websocket protocol was not being set when a connection
was opened, which could cause client libraries and apps to not work properly.
According to the [whatwg] spec the protocol must be set once the connection is
estabilished.
[whatwg]: https://html.spec.whatwg.org/multipage/web-sockets.html#feedback-from-the-protocol
## Changelog
[Javascript] [Fixed] - Properly set the this.protocol on WebSocket open
[Android] [Fixed] - Send the server chosen protocol to the WebSocket object
[iOS] [Fixed] - Send the server chosen protocol to the WebSocket object
Pull Request resolved: https://github.com/facebook/react-native/pull/25273
Test Plan:
In order to reproduce the issue you **need to install wampy@6.2.1**. Since **wampy@6.2.2** and newer contains a workaround for this react-native bug.
https://www.npmjs.com/package/wampy
```javascript
/**
* Sample React Native App
* https://github.com/facebook/react-native
*
* format
* flow
*/
import React, { Component } from 'react';
import { Platform, StyleSheet, Text, View } from 'react-native';
import Wampy from "wampy";
const instructions = Platform.select({
ios: 'Press Cmd+R to reload,\n' + 'Cmd+D or shake for dev menu',
android:
'Double tap R on your keyboard to reload,\n' +
'Shake or press menu button for dev menu',
});
type Props = {};
export default class App extends Component<Props> {
state = {conState: 'Initializing...'};
componentDidMount() {
const url = "wss://demo.crossbar.io/ws";
const ws = new Wampy(url, {
realm: "crossbardemo",
ws: WebSocket,
debug: true,
onConnect: () => {
console.log("WAMP onConnect");
this.setState({conState: 'Connected'});
},
onClose: () => {
console.log("WAMP onClose");
this.setState({conState: 'Connection closed'});
},
onError: () => {
console.log("WAMP onError");
this.setState({conState: 'Connection Error'});
}
});
}
render() {
return (
<View style={styles.container}>
<Text style={styles.message}>{this.state.conState}</Text>
</View>
);
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
justifyContent: 'center',
alignItems: 'center',
backgroundColor: '#F5FCFF',
},
message: {
fontSize: 20,
color: 'black'
},
});
```
Using the code above one must see the message **WAMP onConnect** on Console and **Connected** in the middle of the screen
Closes https://github.com/facebook/react-native/issues/24796
Differential Revision: D15938870
Pulled By: cpojer
fbshipit-source-id: 10a0a9b40c2a69e484ead37149abc2b1158a4ffc
Summary:
Since React Native ART has been extracted to community module, we can deprecate it in Core. You can find the community module [here](https://github.com/react-native-community/art).
## Changelog
[General] [Deprecate] - Deprecate React Native ART
Pull Request resolved: https://github.com/facebook/react-native/pull/25321
Test Plan:
Deprecation warning prints when user imports ART from react-native core module.
cc. cpojer
Differential Revision: D15938910
Pulled By: cpojer
fbshipit-source-id: d360fab6582c0d6c9064005246a012d2d5391c5c
Summary:
This is a follow up PR to https://github.com/facebook/react-native/issues/24359. There's a good thread in the mentioned PR for more background for why I'm doing this change. Essentially `focusable` makes more sense since it is about whether a view can receive user-initiated focus from a pointer or keyboard.
Pull Request resolved: https://github.com/facebook/react-native/pull/25274
Differential Revision: D15873739
Pulled By: cpojer
fbshipit-source-id: 0f526bb99ecdc68131dfc10200a5d44c2ef75b33
Summary:
Reland https://github.com/facebook/react-native/issues/15611 and added the gcc warning that was different from fb internal config. The original PR missed the static keyword for the `RCTNormalizeAnimatedEventName` function which triggered the gcc warning internally but not with the OSS xcode config.
When calling a prop of type `RCTDirectEventBlock` or `RCTBubblingEventBlock` it uses a completely different code path than events using `[RCTEventDispatcher sendEvent:]` and those were not dispatched to the `RCTEventDispatcherListener`s. We also do some event name normalization which caused issues between the JS and native event names. To fix that I simply remove the parts we normalize from the event key.
## Changelog:
[iOS] [Fixed] - Support events using RCT{Direct|Bubbling}EventBlock
Pull Request resolved: https://github.com/facebook/react-native/pull/25317
Test Plan: Added a Slider (it uses RCTBubblingEventBlock for its onValueChange event) that can control a native animated value in RNTester to reproduce the bug and made sure this diff fixes it.
Differential Revision: D15938856
Pulled By: cpojer
fbshipit-source-id: 7e7a3459e2a2e8b1254a2f1ec8153a159ea73eed
Summary:
This pulls in the latest package updates for Fresh. It doesn't have any user-observable behavior.
The renderer is rebuilt on top of the last cherry-picked sync. I cherry-picked https://github.com/facebook/react/pull/15928 on top of it.
Reviewed By: rickhanlonii
Differential Revision: D15901887
fbshipit-source-id: ccd974f79e4c0a2a8a8cab0d472deeaedf1e3ddd
Summary: We will need to use ES6 exports when we switch this to use the codegen'd view configs. I also need to have a named export from this file.
Reviewed By: rickhanlonii
Differential Revision: D15923789
fbshipit-source-id: 513e27834583b6d021ff06d5d7f116ccdcd27722
Summary:
View needed this wrapper to add a dev time warning about text children. Text children became supported and this warning was removed in https://github.com/facebook/react-native/pull/23195
This check is no longer necessary and we can reduce the overhead and improve the performance of View by removing this.
Reviewed By: rickhanlonii
Differential Revision: D15914658
fbshipit-source-id: 6456a9cb356245fa8104036b2948aa5c5bf39e0f
Summary:
view config RCTStickerViewNativeComponent
had to get one view config in before I left London lol
Reviewed By: rickhanlonii
Differential Revision: D15825774
fbshipit-source-id: 846d9ee1d15f6ec64d88a1af7b72fd863ae10afc
Summary: Trying to mitigate animation-related crashes in T43628589. Clues: all the crashes are off the main thread, and most operations in this class happen explicitly in blocks executed on the main thread. I think there's a category of race conditions caused by animations not being allocated yet when this code runs / being deallocated as it's running. We shouldn't need to add locks if everything just runs on the main thread.
Reviewed By: PeteTheHeat
Differential Revision: D15924310
fbshipit-source-id: d82f5434e53fd394c4a7548d52f59a0f63961779
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:
When a synchronous call from JS to native code throws an error, it doesn't include a useful stack trace from the native side. To improve error attribution, this diff pops the frames in `MessageQueue.js` and `NativeModules.js` from the stack traces of such errors. This uses the `error.framesToPop` convention understood by RN's global error handler.
For now we limit this to errors converted from C++ exceptions in host functions, since those are not likely to ever contain further JavaScript frames at the point where we catch them; if they did, it would violate our assumption that the top two frames of the stack are in the JS bridge code.
Reviewed By: cwdick
Differential Revision: D15805054
fbshipit-source-id: 8c1dd7c81b00b6a88e31473271889af1f88f7263
Summary: Adds a test for synchronous methods (`type === 'sync'`) in NativeModules. This doesn't modify any behaviour.
Reviewed By: amnn
Differential Revision: D15804757
fbshipit-source-id: 4db76dbd0b0b111ed9311d4b7ec35a077c377f01
Summary: Adds a test for promise-returning methods (`type === 'promise'`) in `NativeModules`. This doesn't modify any behaviour.
Reviewed By: cwdick
Differential Revision: D15802452
fbshipit-source-id: 8dc1f862d33742ef4ba355ca36338e0dbabf8edb
Summary:
Types the last 3 members of the `ModuleConfig` tuple (functions, promise method IDs, and sync method IDs) as nullable and immutable arrays. This is in line with how they are used in the code; one debug-only call site had to be fixed to account for nullability.
Also updates the test data in `MessageQueueTestConfig` to explicitly conform to this type.
Reviewed By: amnn
Differential Revision: D15899159
fbshipit-source-id: b6955ba92efc73253de48e2ce7c3034fa91adce3
Summary:
When calling a prop of type `RCTDirectEventBlock` or `RCTBubblingEventBlock` it uses a completely different code path than events using `[RCTEventDispatcher sendEvent:]` and those were not dispatched to the `RCTEventDispatcherListener`s. We also do some event name normalization which caused issues between the JS and native event names. To fix that I simply remove the parts we normalize from the event key.
## Changelog:
[iOS] [Fixed] - Support events using RCT{Direct|Bubbling}EventBlock
Pull Request resolved: https://github.com/facebook/react-native/pull/15611
Test Plan: Added a Slider (it used RCTBubblingEventBlock for it's onValueChange event) that can control a native animated value in RNTester to reproduce the bug and made sure this diff fixes it.
Differential Revision: D15896806
Pulled By: cpojer
fbshipit-source-id: c0ae463f4c3f890062238575e813ed7ab3b7a7e6
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: Requiring legacy native modules fails in bridgeless mode because they use the batched bridge, so we need to check for turbomodules first to avoid crashing. In D15703655 I reversed the order of this check for everyone, but this had some unintended side effects (everyone got turbomodules). This time I'm just using my flag to check for bridgeless mode so we can bail out of legacy native modules instead.
Reviewed By: fkgozali
Differential Revision: D15857106
fbshipit-source-id: 9d33161ae059e7a357f135c82b6865f4d2a57add
Summary:
This adds the Fresh Babel plugin and runtime to React Native dependencies. **They're not actually being used or enabled yet**. This is purely additive and just gets the deps setup out of the way for future diffs.
The `react-refresh` source of truth is in the React repo.
Reviewed By: cpojer
Differential Revision: D15828330
fbshipit-source-id: 67ec2dea8c896477ff8b434445f1730e388ea67a
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 fixes an issue with generated view configs due to react-native-gesture-handler adding events to view which are not in the view config on javascript. These will need removed later when react-native-gesture-handler is updated for the new system
Reviewed By: fkgozali
Differential Revision: D15813596
fbshipit-source-id: 8914c093d9cb03e320406d154bb88abf557a951e
Summary: Developer tools have a lot of dependencies on the bridge, so for now I'm just disabling them in bridgeless mode entirely by guarding everything in `setUpDeveloperTools` with the `RN$Bridgeless` flag. Also consolidating some of the stuff Dan added to `InitializeCore` for hot reloading in here.
Reviewed By: zackargyle
Differential Revision: D15797924
fbshipit-source-id: 360ea81a2844e49f7281eed259fc16a541148ac2
Summary:
It turns out that it's expected in certain cases for `UIManager.getViewManagerConfig` to return null: https://fburl.com/4h4pqtd7
Instead of throwing when you try to call that function, let's log something and return null.
Reviewed By: fkgozali
Differential Revision: D15791367
fbshipit-source-id: 71cf14071d877070b4f8b2d72eaa2f10beac38db
Summary: For bridgeless RN we're not going to use the JSTimers module + Timing native module for timers (e.g. setTimeout, setImmediate, etc.). Instead we're going to install global functions from cpp for each of these, so we can just skip setUpTimers entirely in this case.
Reviewed By: fkgozali
Differential Revision: D15790638
fbshipit-source-id: 1626fe90a27cb8d385cbb700ad932969f708f0cb
Summary:
Not totally sure if this is the best way to handle this. In Venice if a native module is missing I try to log the name of the module, but I noticed that the error I was getting was getting this:
{F161460962}
Presumably this is because importing from NativeModules looks for `__esModule`, but NativeModules uses `module.export`. So it's trying to access that property on my cpp proxy object, which doesn't exist...? Changing TurboModuleProxy to use `require` seems to fix the problem.
Reviewed By: fkgozali
Differential Revision: D15787508
fbshipit-source-id: 4b9df4e3c179117999fe6de6363edbef427a8263
Summary:
Replacing UIManager.js with a shim that redirects to either PaperUIManager (containing old impl) or DummyUIManager, if `global.RN$Bridgeless` is set. The UIManager native module doesn't exist in bridgeless mode, which means requiring UIManager.js currently fatals. This is a bit hacky, but it's a lot easier than implementing a dummy native module to make it happy.
I did have to stub out all the properties in UIManagerJSInterface to appease flow, though...
Reviewed By: yungsters
Differential Revision: D15775582
fbshipit-source-id: 8e2628f75b2242971895583696122760acdad7af