Summary:
Cleans up the implementation of `AndroidPicker` and the Flow types for the native components to almost work with `codegenNativeComponent`.
The remaining blocker is that the `items` prop is an array of objects: https://fburl.com/km8uj8x2
Reviewed By: rickhanlonii
Differential Revision: D15805611
fbshipit-source-id: 34bea83db8dbaaf6eb23b00e73e0c7ce292e8a32
Summary:
Note: iOS only.
This spec file (.h/.mm) was generated via FB internal codegen tool for TurboModule. The tool itself is not yet ready to be opensourced, but at least the generated file is. The output is based on all the Flow types added via https://github.com/facebook/react-native/issues/24875.
This file can be used by each ObjC NativeModule to be TurboModule compliant.
Reviewed By: rickhanlonii
Differential Revision: D15978911
fbshipit-source-id: 9e97495287bc406e0ed0ccf89cf370753b538772
Summary: This util is used for TurboModule codegen system - it's not used anywhere else for now.
Reviewed By: JoshuaGross
Differential Revision: D15971956
fbshipit-source-id: 3cb1c3df7fa96fd51d420abff1fbfd07b18fdae6
Summary:
We should remove all usages of React's legacy context API because it'll be removed from React at some point, it prevents some performance optimizations in updates and can cause conflicts between different context providers (like mixins).
This creates a new Context for `rootTag` (this granularity is intentional) so users that are consuming it via the legacy context API can start migrating away from it.
I didn't create a more generic context (like ReactRootContext, ReactApplicationContext) because having a more granular context makes it easier to track and remove it if we want to, and prevents re-rendering when users only care about certain values.
Reviewed By: rickhanlonii, cpojer
Differential Revision: D14941918
fbshipit-source-id: 7ceea62727d10a591367b7ed7c447309b286758d
Summary:
`DatePickerIOS` and `DatePickerAndroid` have been merged as part of Lean Core. See [repo](https://github.com/react-native-community/react-native-datetimepicker)
## Changelog
[General] [Deprecate] - Warning for `DatePickerIOS` and `DatePickerAndroid`
Pull Request resolved: https://github.com/facebook/react-native/pull/25374
Test Plan: Warning prints when user imports `DatePickerIOS` or `DatePickerAndroid`
Differential Revision: D15983829
Pulled By: cpojer
fbshipit-source-id: dfa35e204bb133a1b8de67c25abaa4338b956901
Summary: The schema for these view commands is lifted wholesale from the schema for TurboModules: P67239314
Reviewed By: rickhanlonii
Differential Revision: D15943109
fbshipit-source-id: a0ccd4e47067b62970218df6a32527c15868c4a5
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: This updates the renderer and Fresh packages to pull in the new error handling behavior. The new feature is that roots that errored on last save get remounted after an edit. This allows much faster iteration in the Fast Refresh mode as you don't need to do a full reload after typos.
Reviewed By: bvaughn
Differential Revision: D15967396
fbshipit-source-id: 96a82e6a4e00a8cb636d7bca037a1a43552a4cd2
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: The onRefresh event is a DirectEvent not a BubblingEvent
Reviewed By: PeteTheHeat
Differential Revision: D15969475
fbshipit-source-id: 049a6ffc74306246e8dbc3acdce5b0b26e849fc7
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: This component is only used in native (there are no JS paths to it). Currently, the schema is being used to generate the native code for this component. Here, we add the codegen types so we still generate the native code when the schemas are removed, but the view config will never be used
Reviewed By: cpojer
Differential Revision: D15960990
fbshipit-source-id: 08fd0155f603e45785520c49a3ea86e30b276f9c
Summary: This was a mismatch with the schema
Reviewed By: cpojer
Differential Revision: D15960977
fbshipit-source-id: 08a56ac404eb5d45c6363e4574bd3d7bacf3ca08
Summary: Renames PullToRefresh to PullToRefreshView to correct a previous mistake so that this matches the Schema file
Reviewed By: cpojer
Differential Revision: D15960975
fbshipit-source-id: 575e526df2efdfa260f3cbbb4b0764998a91ade0
Summary: I think this was just an oversight when adding the flow types (notice that this flag isn't in the schema file, and the interface is required for android)
Reviewed By: TheSavior
Differential Revision: D15960965
fbshipit-source-id: 116b289261fbcaaaff53cd657a91f03dc036fb98
Summary:
The goal of this PR is to improve the pipeline currently used for displaying GIFs / animated images on iOS. It is achieved by not holding all of the decoded frames in memory at the same time, as well as happily releasing existing memory whenever possible. This code is a simplified version of what you would find in SDWebImage (it is nearly 1:1, with unsupported or uneeded things removed). By adopting this API, it also allows classes conforming to RCTImageURLLoader or RCTImageDataDecoder to return any decodable UIImages conforming to RCTAnimatedImage and have improvements to memory consumption. Because RCTAnimatedImage is just a subset of the SDAnimatedImage protocol, it also means that you can use SDWebImage easier with Image directly.
A nice to have would be progressive image loading, but is beyond scope for this PR. It would, however, touch most of these same parts.
## Changelog
[iOS] [Fixed] - Substantially lower chances of crashes from abundant GIF use
Pull Request resolved: https://github.com/facebook/react-native/pull/24822
Test Plan: TBD. (but i am running a version of this in my own app currently)
Reviewed By: shergin
Differential Revision: D15853479
Pulled By: sammy-SC
fbshipit-source-id: 969e0d458da9fa49453aee1dcdf51783c2a45067
Summary:
The current technique we use to draw text uses linear memory, which means that when text is too long the UIView layer is unable to draw it. This causes the issue described [here](https://github.com/facebook/react-native/issues/19453). On an iOS simulator the bug happens at around 500 lines which is quite annoying. It can also happen on a real device but requires a lot more text.
To be more specific the amount of text doesn't actually matter, it is the size of the UIView that we use to draw the text. When we use `[drawRect:]` the view creates a bitmap to send to the gpu to render, if that bitmap is too big it cannot render.
To fix this we can use `CATiledLayer` which will split drawing into smaller parts, that gets executed when the content is about to be visible. This drawing is also async which means the text can seem to appear during scroll. See https://developer.apple.com/documentation/quartzcore/calayer?language=objc.
`CATiledLayer` also adds some overhead that we don't want when rendering small amount of text. To fix this we can use either a regular `CALayer` or a `CATiledLayer` depending on the size of the view containing the text. I picked 1024 as the threshold which is about 1 screen and a half, and is still smaller than the height needed for the bug to occur when using a regular `CALayer` on a iOS simulator.
Also found this which addresses the problem in a similar manner and took some inspiration from the code linked there https://github.com/GitHawkApp/StyledTextKit/issues/14#issuecomment-395234885
Fixes https://github.com/facebook/react-native/issues/19453
## Changelog
[iOS] [Fixed] - Use CALayers to draw text, fixes rendering for long text
Pull Request resolved: https://github.com/facebook/react-native/pull/24387
Test Plan:
- Added the example I was using to verify the fix to RNTester.
- Made sure all other examples are still rendering properly.
- Tested text selection
Reviewed By: shergin
Differential Revision: D15918277
Pulled By: sammy-SC
fbshipit-source-id: c45409a8413e6e3ad272be39ba527a4e8d349e28
Summary:
## Context
Moving SegmentedControlIOS to use a generated view config.
---
It's worth mentioning that even though `RCTSegmentedControlNativeComponent` defines a different event type to that of `RCTView`. We currently do not have 100% type safety for the event types in Paper. In other words, when an event for `onChange` in this case comes from the native side, it could potentially be shaped differently than what was typed in the native component file. This will be addressed in `Fabric`.
```
// RCTSegmentedControlNativeComponent.js
export type Event = $ReadOnly<{|
value: Int32,
selectedSegmentIndex: Int32,
|}>;
...
export type NativeProps = $ReadOnly<{|
...
onChange?: ?(event: BubblingEvent<Event>) => mixed,
|}>
```
This means that in the view config diff, there will be a value of `none` for `bubblingEventTypes`
Reviewed By: rickhanlonii
Differential Revision: D15851692
fbshipit-source-id: 6653fe7a77e46afdd55808aa5a4df813b34d7f70
Summary:
`StatusBarIOS` has been merged with `StatusBar`. See [Implement a StatusBar frame API](https://github.com/facebook/react-native/pull/16478)
## Changelog
[General] [Deprecate] - Warning for `StatusBarIOS`
Pull Request resolved: https://github.com/facebook/react-native/pull/25350
Test Plan: Warning prints when user imports `StatusBarIOS`
Differential Revision: D15963347
Pulled By: cpojer
fbshipit-source-id: 456a7f3ccb245bd89ad322d5a2649e3bf844ba24
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
Tim Yung
Kevin Gozali
Rubén Norte
Luis Miguel Alvarado
Marco Zandonadi
Eli White
Dan Abramov
Rick Hanlon
Eric Lewis
Janic Duplessis
Cameron Bourke
Orta Therox
Chris Blappert
Spencer Ahrens
Christoph Nakazawa
Guilherme Iscaro
Kacper Wiszczuk
Sam Mathias Weggersen
Luna Wei
Joshua Gross
Peter Argany
Moti Zilberman