react-native-macos/index.js

783 строки
32 KiB
JavaScript
Исходник Обычный вид История

/**
* Copyright (c) Meta Platforms, Inc. and affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*
* @format
* @flow
*/
'use strict';
// Components
import typeof AccessibilityInfo from './Libraries/Components/AccessibilityInfo/AccessibilityInfo';
import typeof ActivityIndicator from './Libraries/Components/ActivityIndicator/ActivityIndicator';
import typeof Button from './Libraries/Components/Button';
import typeof DrawerLayoutAndroid from './Libraries/Components/DrawerAndroid/DrawerLayoutAndroid';
import typeof FlatList from './Libraries/Lists/FlatList';
import typeof Image from './Libraries/Image/Image';
import typeof ImageBackground from './Libraries/Image/ImageBackground';
import typeof InputAccessoryView from './Libraries/Components/TextInput/InputAccessoryView';
import typeof KeyboardAvoidingView from './Libraries/Components/Keyboard/KeyboardAvoidingView';
import typeof Modal from './Libraries/Modal/Modal';
import typeof Pressable from './Libraries/Components/Pressable/Pressable';
import typeof ProgressBarAndroid from './Libraries/Components/ProgressBarAndroid/ProgressBarAndroid';
import typeof RefreshControl from './Libraries/Components/RefreshControl/RefreshControl';
import typeof SafeAreaView from './Libraries/Components/SafeAreaView/SafeAreaView';
import typeof ScrollView from './Libraries/Components/ScrollView/ScrollView';
import typeof SectionList from './Libraries/Lists/SectionList';
import typeof Slider from './Libraries/Components/Slider/Slider';
import typeof StatusBar from './Libraries/Components/StatusBar/StatusBar';
import typeof Switch from './Libraries/Components/Switch/Switch';
import typeof Text from './Libraries/Text/Text';
import typeof TextInput from './Libraries/Components/TextInput/TextInput';
import typeof Touchable from './Libraries/Components/Touchable/Touchable';
import typeof TouchableHighlight from './Libraries/Components/Touchable/TouchableHighlight';
import typeof TouchableNativeFeedback from './Libraries/Components/Touchable/TouchableNativeFeedback';
import typeof TouchableOpacity from './Libraries/Components/Touchable/TouchableOpacity';
import typeof TouchableWithoutFeedback from './Libraries/Components/Touchable/TouchableWithoutFeedback';
import typeof View from './Libraries/Components/View/View';
import typeof VirtualizedList from './Libraries/Lists/VirtualizedList';
import typeof VirtualizedSectionList from './Libraries/Lists/VirtualizedSectionList';
// APIs
import typeof ActionSheetIOS from './Libraries/ActionSheetIOS/ActionSheetIOS';
import typeof Alert from './Libraries/Alert/Alert';
import typeof Animated from './Libraries/Animated/Animated';
import typeof * as AnimatedModule from './Libraries/Animated/Animated';
import typeof Appearance from './Libraries/Utilities/Appearance';
import typeof AppRegistry from './Libraries/ReactNative/AppRegistry';
import typeof AppState from './Libraries/AppState/AppState';
import typeof BackHandler from './Libraries/Utilities/BackHandler';
import typeof Clipboard from './Libraries/Components/Clipboard/Clipboard';
import typeof DeviceInfo from './Libraries/Utilities/DeviceInfo';
import typeof DevSettings from './Libraries/Utilities/DevSettings';
import typeof Dimensions from './Libraries/Utilities/Dimensions';
import typeof Easing from './Libraries/Animated/Easing';
import typeof ReactNative from './Libraries/Renderer/shims/ReactNative';
import typeof I18nManager from './Libraries/ReactNative/I18nManager';
import typeof InteractionManager from './Libraries/Interaction/InteractionManager';
import typeof Keyboard from './Libraries/Components/Keyboard/Keyboard';
import typeof LayoutAnimation from './Libraries/LayoutAnimation/LayoutAnimation';
import typeof Linking from './Libraries/Linking/Linking';
import typeof LogBox from './Libraries/LogBox/LogBox';
import typeof NativeDialogManagerAndroid from './Libraries/NativeModules/specs/NativeDialogManagerAndroid';
import typeof NativeEventEmitter from './Libraries/EventEmitter/NativeEventEmitter';
import typeof Networking from './Libraries/Network/RCTNetworking';
import typeof PanResponder from './Libraries/Interaction/PanResponder';
import typeof PermissionsAndroid from './Libraries/PermissionsAndroid/PermissionsAndroid';
import typeof PixelRatio from './Libraries/Utilities/PixelRatio';
import typeof PushNotificationIOS from './Libraries/PushNotificationIOS/PushNotificationIOS';
import typeof Settings from './Libraries/Settings/Settings';
import typeof Share from './Libraries/Share/Share';
import typeof StyleSheet from './Libraries/StyleSheet/StyleSheet';
import typeof * as Systrace from './Libraries/Performance/Systrace';
import typeof ToastAndroid from './Libraries/Components/ToastAndroid/ToastAndroid';
import typeof * as TurboModuleRegistry from './Libraries/TurboModule/TurboModuleRegistry';
import typeof UIManager from './Libraries/ReactNative/UIManager';
import typeof useAnimatedValue from './Libraries/Animated/useAnimatedValue';
import typeof useColorScheme from './Libraries/Utilities/useColorScheme';
import typeof useWindowDimensions from './Libraries/Utilities/useWindowDimensions';
import typeof UTFSequence from './Libraries/UTFSequence';
import typeof Vibration from './Libraries/Vibration/Vibration';
import typeof YellowBox from './Libraries/YellowBox/YellowBoxDeprecated';
// Plugins
import typeof {DynamicColorIOS} from './Libraries/StyleSheet/PlatformColorValueTypesIOS';
import typeof NativeModules from './Libraries/BatchedBridge/NativeModules';
import typeof Platform from './Libraries/Utilities/Platform';
PlatformColor implementations for iOS and Android (#27908) Summary: This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester. Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window. The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects. `PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version. The function returns a `ColorValue`. On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`. On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML: XML Resource: `@ [<package_name>:]<resource_type>/<resource_name>` Style reference from current theme: `?[<package_name>:][<resource_type>/]<resource_name>` For example: - `?android:colorError` - `?android:attr/colorError` - `?attr/colorPrimary` - `?colorPrimaryDark` - `android:color/holo_purple` - `color/catalyst_redbox_background` On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes. Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>` Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method. ## Changelog [General] [Added] - Added PlatformColor implementations for iOS and Android Pull Request resolved: https://github.com/facebook/react-native/pull/27908 Test Plan: The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests. <img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png"> In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes: react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors iOS |Light|Dark| |{F229354502}|{F229354515}| Android |Light|Dark| |{F230114392}|{F230114490}| {F230122700} Reviewed By: hramos Differential Revision: D19837753 Pulled By: TheSavior fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
2020-03-03 02:07:50 +03:00
import typeof {PlatformColor} from './Libraries/StyleSheet/PlatformColorValueTypes';
import typeof processColor from './Libraries/StyleSheet/processColor';
import typeof RCTDeviceEventEmitter from './Libraries/EventEmitter/RCTDeviceEventEmitter';
import typeof RCTNativeAppEventEmitter from './Libraries/EventEmitter/RCTNativeAppEventEmitter';
import typeof {RootTagContext} from './Libraries/ReactNative/RootTag';
import type {HostComponent as _HostComponentInternal} from './Libraries/Renderer/shims/ReactNativeTypes';
Add HostComponent to the public API of React Native 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. Reviewed By: rickhanlonii Differential Revision: D17563615 fbshipit-source-id: b9e6042805517d502770fcba37301c2c5b6452b6
2019-09-25 21:42:07 +03:00
export type HostComponent<T> = _HostComponentInternal<T>;
Introduce flow type to differentiate between HostComponent, NativeMethodsMixin, and NativeComponent 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
2019-09-25 20:10:48 +03:00
const invariant = require('invariant');
const warnOnce = require('./Libraries/Utilities/warnOnce');
module.exports = {
// Components
get AccessibilityInfo(): AccessibilityInfo {
return require('./Libraries/Components/AccessibilityInfo/AccessibilityInfo')
.default;
},
get ActivityIndicator(): ActivityIndicator {
return require('./Libraries/Components/ActivityIndicator/ActivityIndicator')
.default;
},
get Button(): Button {
return require('./Libraries/Components/Button');
},
// $FlowFixMe[value-as-type]
get DrawerLayoutAndroid(): DrawerLayoutAndroid {
return require('./Libraries/Components/DrawerAndroid/DrawerLayoutAndroid');
},
get FlatList(): FlatList {
return require('./Libraries/Lists/FlatList');
},
get Image(): Image {
return require('./Libraries/Image/Image');
},
get ImageBackground(): ImageBackground {
return require('./Libraries/Image/ImageBackground');
},
get InputAccessoryView(): InputAccessoryView {
return require('./Libraries/Components/TextInput/InputAccessoryView');
},
get KeyboardAvoidingView(): KeyboardAvoidingView {
return require('./Libraries/Components/Keyboard/KeyboardAvoidingView')
.default;
},
get Modal(): Modal {
return require('./Libraries/Modal/Modal');
},
get Pressable(): Pressable {
return require('./Libraries/Components/Pressable/Pressable').default;
},
// $FlowFixMe[value-as-type]
get ProgressBarAndroid(): ProgressBarAndroid {
warnOnce(
'progress-bar-android-moved',
'ProgressBarAndroid has been extracted from react-native core and will be removed in a future release. ' +
"It can now be installed and imported from '@react-native-community/progress-bar-android' instead of 'react-native'. " +
'See https://github.com/react-native-progress-view/progress-bar-android',
);
return require('./Libraries/Components/ProgressBarAndroid/ProgressBarAndroid');
},
get RefreshControl(): RefreshControl {
return require('./Libraries/Components/RefreshControl/RefreshControl');
},
get SafeAreaView(): SafeAreaView {
return require('./Libraries/Components/SafeAreaView/SafeAreaView').default;
},
get ScrollView(): ScrollView {
return require('./Libraries/Components/ScrollView/ScrollView');
},
get SectionList(): SectionList {
return require('./Libraries/Lists/SectionList').default;
},
get Slider(): Slider {
warnOnce(
'slider-moved',
'Slider has been extracted from react-native core and will be removed in a future release. ' +
"It can now be installed and imported from '@react-native-community/slider' instead of 'react-native'. " +
'See https://github.com/callstack/react-native-slider',
);
return require('./Libraries/Components/Slider/Slider');
},
get StatusBar(): StatusBar {
return require('./Libraries/Components/StatusBar/StatusBar');
},
get Switch(): Switch {
return require('./Libraries/Components/Switch/Switch').default;
},
get Text(): Text {
return require('./Libraries/Text/Text');
},
get TextInput(): TextInput {
return require('./Libraries/Components/TextInput/TextInput');
},
get Touchable(): Touchable {
return require('./Libraries/Components/Touchable/Touchable');
},
get TouchableHighlight(): TouchableHighlight {
return require('./Libraries/Components/Touchable/TouchableHighlight');
},
get TouchableNativeFeedback(): TouchableNativeFeedback {
return require('./Libraries/Components/Touchable/TouchableNativeFeedback');
},
get TouchableOpacity(): TouchableOpacity {
return require('./Libraries/Components/Touchable/TouchableOpacity');
},
get TouchableWithoutFeedback(): TouchableWithoutFeedback {
return require('./Libraries/Components/Touchable/TouchableWithoutFeedback');
},
get View(): View {
return require('./Libraries/Components/View/View');
},
get VirtualizedList(): VirtualizedList {
Ship VirtualizedList_EXPERIMENTAL Summary: `VirtualizedList_EXPERIMENTAL` is a fork of VirtualizedList. It was originally created for the purpose of keyboard/a11y fixes, which required the list to allow rendering discontiguous regions of cells. So, the large part of the refactor is in the data structure used to represent state (now a sparse bitmask), and building out the render function to operate off the bitmask. This structure allows pre-rendering areas where we know focus must be able to be synchronously be moved to. This is exercised on platforms like Windows and macOS which fire view level focus events. The new implementation otherwise aims to preserve near-exact list behavior as previously. Apart from the structure change, the refactor has made the code (subjectively) a lot easier to reason about, and there are now stronger internal invariants than before. The bitmask structure also enables new approaches for nested list stability, and implementing OffScreen. **Why ship it now?** Having two implementations has multiple times prevented other changes to VirtualizedList, so it is incurring a constant engineer cost. At this point, we have a lot of reason to be confident in the maturity of the new list implementation (see the test plan below). So, reconciling the implementations not only unlocks the enhancements of the new list, but unblocks future changes to VirtualizedList. ## Test Plan 1. **Unit tests:** A few dozen unit tests were added to VirtualizedList, validating the regions it renders in response to injected input, across its API surface. Both VirtualizedList implementations must pass the same tests, around expected behavior. 2. **RNTester:** Scenarios in RNTester were manually validated, and all worked as before 3. **New invariants:** I added a lot of internal logic checks and bounds checks as invariant violations, to try to produce signal if any part of the refactor went unexpected in the wild. 4. **MSFT Rollout:** I rolled out the changes as a fork of VirtualizedList at MSFT to a couple of high-usage surfaces using Android, iOS, and Windows on Paper. Some invariant violations were surfaced and fixed, but telemetry showed solid system and scenario health with the change. 5. **Meta import:** Fixed all land-blocking test failures when using the new list. These were confined to updating snapshots, and adding additional checks for invalid input. 6. **Panel apps:** Manually validated top-level surfaces of panel apps in debug/release modes. Fixed a couple of invariant violations and novel usages. Profiled new JS structures against an expensive list with Hermes profiler. 7. **Facebook App Rollout:** After some manual validation of top-level surfaces, the change was rolled out to Facebook for Android and iOS as an experiment. New invariant violations were fixed, and the change has sat in production for several weeks at this point, while measuring impact to metrics like error rate, responsiveness, and impressions. This is the first introduction to all of OSS, and some Meta internal apps. This means there may still be novel usages of VirtualizedList that were not picked up during testing, but I think there has been enough diligence to roll out what has been tested, and forward fix anything unexpected that might still come up. Changelog: [General][Changed] - Ship VirtualizedList_EXPERIMENTAL Reviewed By: javache Differential Revision: D40259791 fbshipit-source-id: 63eee9381d197a1e38ae663b2158436ff135c0e1
2022-10-13 15:04:40 +03:00
return require('./Libraries/Lists/VirtualizedList').default;
},
get VirtualizedSectionList(): VirtualizedSectionList {
return require('./Libraries/Lists/VirtualizedSectionList');
},
// APIs
get ActionSheetIOS(): ActionSheetIOS {
return require('./Libraries/ActionSheetIOS/ActionSheetIOS');
},
get Alert(): Alert {
return require('./Libraries/Alert/Alert');
},
// Include any types exported in the Animated module together with its default export, so
// you can references types such as Animated.Numeric
get Animated(): {...$Diff<AnimatedModule, {default: any}>, ...Animated} {
// $FlowExpectedError[prop-missing]: we only return the default export, all other exports are types
return require('./Libraries/Animated/Animated').default;
},
get Appearance(): Appearance {
return require('./Libraries/Utilities/Appearance');
},
get AppRegistry(): AppRegistry {
return require('./Libraries/ReactNative/AppRegistry');
},
get AppState(): AppState {
return require('./Libraries/AppState/AppState');
},
get BackHandler(): BackHandler {
return require('./Libraries/Utilities/BackHandler');
},
get Clipboard(): Clipboard {
warnOnce(
'clipboard-moved',
'Clipboard has been extracted from react-native core and will be removed in a future release. ' +
"It can now be installed and imported from '@react-native-clipboard/clipboard' instead of 'react-native'. " +
'See https://github.com/react-native-clipboard/clipboard',
);
return require('./Libraries/Components/Clipboard/Clipboard');
},
get DeviceInfo(): DeviceInfo {
return require('./Libraries/Utilities/DeviceInfo');
},
get DevSettings(): DevSettings {
return require('./Libraries/Utilities/DevSettings');
},
get Dimensions(): Dimensions {
return require('./Libraries/Utilities/Dimensions').default;
},
get Easing(): Easing {
return require('./Libraries/Animated/Easing').default;
},
get findNodeHandle(): $PropertyType<ReactNative, 'findNodeHandle'> {
return require('./Libraries/ReactNative/RendererProxy').findNodeHandle;
},
get I18nManager(): I18nManager {
return require('./Libraries/ReactNative/I18nManager');
},
get InteractionManager(): InteractionManager {
return require('./Libraries/Interaction/InteractionManager');
},
get Keyboard(): Keyboard {
return require('./Libraries/Components/Keyboard/Keyboard');
},
get LayoutAnimation(): LayoutAnimation {
return require('./Libraries/LayoutAnimation/LayoutAnimation');
},
get Linking(): Linking {
return require('./Libraries/Linking/Linking');
},
get LogBox(): LogBox {
return require('./Libraries/LogBox/LogBox').default;
},
get NativeDialogManagerAndroid(): NativeDialogManagerAndroid {
return require('./Libraries/NativeModules/specs/NativeDialogManagerAndroid')
.default;
},
get NativeEventEmitter(): NativeEventEmitter {
return require('./Libraries/EventEmitter/NativeEventEmitter').default;
},
Expose RCTNetworking as a public 'Networking' API (#25718) Summary: This PR introduces the `EventSource` web standard as a first-class networking feature in React Native. In the discussion we had in February at https://github.com/react-native-community/discussions-and-proposals/issues/99, cpojer indicated that the RN maintainers would be willing to accept a PR to offer this functionality. The linked discussion goes into detail about why this change must happen in React Native Core as opposed to a community library, but the tl;dr is that `XmlHttpRequest` doesn't let you do streaming in a resource-efficient way, since it holds onto the entire response buffer until the request is complete. When processing a stream that might last for a long time, that's not ideal since there might be a lot of data in that buffer that is now useless to maintain. For more information about EventSource and server-sent events, check out these links: * [EventSource on MDN](https://developer.mozilla.org/en-US/docs/Web/API/EventSource) * [Using server-sent events on MDN](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events) * [WHATWG spec for server-sent events](https://html.spec.whatwg.org/multipage/server-sent-events.html) I've tried as best as I can to satisfy the linked specification so that this is as standard as possible. One of the projects I maintain has an ideal use case for this feature. The SDK for MongoDB Stitch (a backend-as-a-service for the MongoDB database) has the ability to open a "change stream" to watch for changes that happen on a database. However, in our JavaScript SDK, this feature depends on `EventSource`, because the backend service implements the one-way streaming protocol with server-sent events. We know there is demand for this feature because users have requested it: https://github.com/mongodb/stitch-js-sdk/issues/209. If this PR will be accepted, I am happy to update the `Networking` documentation at https://facebook.github.io/react-native/docs/network ## Changelog [JavaScript] [Added] Implements the `EventSource` web standard in `Libraries/Networking` [JavaScript] [Added] Exposes the `EventSource` implementation in `Libraries/Core/setUpXHR.js` Pull Request resolved: https://github.com/facebook/react-native/pull/25718 Test Plan: To test the `EventSource` implementation, I added a comprehensive set of unit tests that cover the basic functionality, as well as edge cases that are laid out in the spec. See `EventSource-test.js` for the cases that the tests handles. For convenience, I've also included the test descriptions as produced by the `jest` test output here. ``` PASS Libraries/Network/__tests__/EventSource-test.js EventSource ✓ should pass along the correct request parameters (527ms) ✓ should transition readyState correctly for successful requests (4ms) ✓ should call onerror function when server responds with an HTTP error (2ms) ✓ should call onerror on non event-stream responses (1ms) ✓ should call onerror function when request times out (1ms) ✓ should call onerror if connection cannot be established (1ms) ✓ should call onopen function when stream is opened (1ms) ✓ should follow HTTP redirects (2ms) ✓ should call onmessage when receiving an unnamed event (2ms) ✓ should handle events with multiple lines of data (1ms) ✓ should call appropriate handler when receiving a named event (1ms) ✓ should receive multiple events (1ms) ✓ should handle messages sent in separate chunks (1ms) ✓ should forward server-sent errors ✓ should ignore comment lines (1ms) ✓ should properly set lastEventId based on server message (1ms) ✓ should properly set reconnect interval based on server message ✓ should handle messages with non-ASCII characters (1ms) ✓ should properly pass along withCredentials option (3ms) ✓ should properly pass along extra headers (1ms) ✓ should properly pass along configured lastEventId (2ms) ✓ should reconnect gracefully and properly pass lastEventId (9ms) ✓ should stop attempting to reconnect after five failed attempts (2ms) ``` As a manual E2E test, I also added streaming support to the Stitch React Native SDK, and tested it with my React Native EventSource implementation, and confirmed that our `EventSource`-based streaming implementation worked with this `EventSource` implementation. * Source code for E2E app test: https://gist.github.com/adamchel/6db456c1a851ed7dd20b54f6db3a6759 * PR for streaming support on our React Native SDK: https://github.com/mongodb/stitch-js-sdk/pull/294 * Very brief video demonstrating E2E functionality: https://youtu.be/-OoIpkAxmcw Differential Revision: D17283890 Pulled By: cpojer fbshipit-source-id: 0e9e079bdb2d795dd0b6fa8a9a9fa1e840245a51
2019-09-11 13:22:09 +03:00
get Networking(): Networking {
return require('./Libraries/Network/RCTNetworking').default;
Expose RCTNetworking as a public 'Networking' API (#25718) Summary: This PR introduces the `EventSource` web standard as a first-class networking feature in React Native. In the discussion we had in February at https://github.com/react-native-community/discussions-and-proposals/issues/99, cpojer indicated that the RN maintainers would be willing to accept a PR to offer this functionality. The linked discussion goes into detail about why this change must happen in React Native Core as opposed to a community library, but the tl;dr is that `XmlHttpRequest` doesn't let you do streaming in a resource-efficient way, since it holds onto the entire response buffer until the request is complete. When processing a stream that might last for a long time, that's not ideal since there might be a lot of data in that buffer that is now useless to maintain. For more information about EventSource and server-sent events, check out these links: * [EventSource on MDN](https://developer.mozilla.org/en-US/docs/Web/API/EventSource) * [Using server-sent events on MDN](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events) * [WHATWG spec for server-sent events](https://html.spec.whatwg.org/multipage/server-sent-events.html) I've tried as best as I can to satisfy the linked specification so that this is as standard as possible. One of the projects I maintain has an ideal use case for this feature. The SDK for MongoDB Stitch (a backend-as-a-service for the MongoDB database) has the ability to open a "change stream" to watch for changes that happen on a database. However, in our JavaScript SDK, this feature depends on `EventSource`, because the backend service implements the one-way streaming protocol with server-sent events. We know there is demand for this feature because users have requested it: https://github.com/mongodb/stitch-js-sdk/issues/209. If this PR will be accepted, I am happy to update the `Networking` documentation at https://facebook.github.io/react-native/docs/network ## Changelog [JavaScript] [Added] Implements the `EventSource` web standard in `Libraries/Networking` [JavaScript] [Added] Exposes the `EventSource` implementation in `Libraries/Core/setUpXHR.js` Pull Request resolved: https://github.com/facebook/react-native/pull/25718 Test Plan: To test the `EventSource` implementation, I added a comprehensive set of unit tests that cover the basic functionality, as well as edge cases that are laid out in the spec. See `EventSource-test.js` for the cases that the tests handles. For convenience, I've also included the test descriptions as produced by the `jest` test output here. ``` PASS Libraries/Network/__tests__/EventSource-test.js EventSource ✓ should pass along the correct request parameters (527ms) ✓ should transition readyState correctly for successful requests (4ms) ✓ should call onerror function when server responds with an HTTP error (2ms) ✓ should call onerror on non event-stream responses (1ms) ✓ should call onerror function when request times out (1ms) ✓ should call onerror if connection cannot be established (1ms) ✓ should call onopen function when stream is opened (1ms) ✓ should follow HTTP redirects (2ms) ✓ should call onmessage when receiving an unnamed event (2ms) ✓ should handle events with multiple lines of data (1ms) ✓ should call appropriate handler when receiving a named event (1ms) ✓ should receive multiple events (1ms) ✓ should handle messages sent in separate chunks (1ms) ✓ should forward server-sent errors ✓ should ignore comment lines (1ms) ✓ should properly set lastEventId based on server message (1ms) ✓ should properly set reconnect interval based on server message ✓ should handle messages with non-ASCII characters (1ms) ✓ should properly pass along withCredentials option (3ms) ✓ should properly pass along extra headers (1ms) ✓ should properly pass along configured lastEventId (2ms) ✓ should reconnect gracefully and properly pass lastEventId (9ms) ✓ should stop attempting to reconnect after five failed attempts (2ms) ``` As a manual E2E test, I also added streaming support to the Stitch React Native SDK, and tested it with my React Native EventSource implementation, and confirmed that our `EventSource`-based streaming implementation worked with this `EventSource` implementation. * Source code for E2E app test: https://gist.github.com/adamchel/6db456c1a851ed7dd20b54f6db3a6759 * PR for streaming support on our React Native SDK: https://github.com/mongodb/stitch-js-sdk/pull/294 * Very brief video demonstrating E2E functionality: https://youtu.be/-OoIpkAxmcw Differential Revision: D17283890 Pulled By: cpojer fbshipit-source-id: 0e9e079bdb2d795dd0b6fa8a9a9fa1e840245a51
2019-09-11 13:22:09 +03:00
},
get PanResponder(): PanResponder {
return require('./Libraries/Interaction/PanResponder');
},
get PermissionsAndroid(): PermissionsAndroid {
return require('./Libraries/PermissionsAndroid/PermissionsAndroid');
},
get PixelRatio(): PixelRatio {
return require('./Libraries/Utilities/PixelRatio').default;
},
get PushNotificationIOS(): PushNotificationIOS {
warnOnce(
'pushNotificationIOS-moved',
'PushNotificationIOS has been extracted from react-native core and will be removed in a future release. ' +
"It can now be installed and imported from '@react-native-community/push-notification-ios' instead of 'react-native'. " +
'See https://github.com/react-native-push-notification-ios/push-notification-ios',
);
return require('./Libraries/PushNotificationIOS/PushNotificationIOS');
},
get Settings(): Settings {
return require('./Libraries/Settings/Settings');
},
get Share(): Share {
return require('./Libraries/Share/Share');
},
get StyleSheet(): StyleSheet {
return require('./Libraries/StyleSheet/StyleSheet');
},
get Systrace(): Systrace {
return require('./Libraries/Performance/Systrace');
},
// $FlowFixMe[value-as-type]
get ToastAndroid(): ToastAndroid {
return require('./Libraries/Components/ToastAndroid/ToastAndroid');
},
get TurboModuleRegistry(): TurboModuleRegistry {
return require('./Libraries/TurboModule/TurboModuleRegistry');
},
get UIManager(): UIManager {
return require('./Libraries/ReactNative/UIManager');
},
get unstable_batchedUpdates(): $PropertyType<
ReactNative,
'unstable_batchedUpdates',
> {
return require('./Libraries/ReactNative/RendererProxy')
.unstable_batchedUpdates;
},
get useAnimatedValue(): useAnimatedValue {
return require('./Libraries/Animated/useAnimatedValue').default;
},
get useColorScheme(): useColorScheme {
return require('./Libraries/Utilities/useColorScheme').default;
},
get useWindowDimensions(): useWindowDimensions {
return require('./Libraries/Utilities/useWindowDimensions').default;
},
get UTFSequence(): UTFSequence {
return require('./Libraries/UTFSequence').default;
},
get Vibration(): Vibration {
return require('./Libraries/Vibration/Vibration');
},
get YellowBox(): YellowBox {
return require('./Libraries/YellowBox/YellowBoxDeprecated');
},
// Plugins
get DeviceEventEmitter(): RCTDeviceEventEmitter {
return require('./Libraries/EventEmitter/RCTDeviceEventEmitter').default;
},
get DynamicColorIOS(): DynamicColorIOS {
return require('./Libraries/StyleSheet/PlatformColorValueTypesIOS')
.DynamicColorIOS;
},
get NativeAppEventEmitter(): RCTNativeAppEventEmitter {
return require('./Libraries/EventEmitter/RCTNativeAppEventEmitter');
},
get NativeModules(): NativeModules {
return require('./Libraries/BatchedBridge/NativeModules');
},
get Platform(): Platform {
return require('./Libraries/Utilities/Platform');
},
PlatformColor implementations for iOS and Android (#27908) Summary: This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester. Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window. The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects. `PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version. The function returns a `ColorValue`. On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`. On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML: XML Resource: `@ [<package_name>:]<resource_type>/<resource_name>` Style reference from current theme: `?[<package_name>:][<resource_type>/]<resource_name>` For example: - `?android:colorError` - `?android:attr/colorError` - `?attr/colorPrimary` - `?colorPrimaryDark` - `android:color/holo_purple` - `color/catalyst_redbox_background` On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes. Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>` Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method. ## Changelog [General] [Added] - Added PlatformColor implementations for iOS and Android Pull Request resolved: https://github.com/facebook/react-native/pull/27908 Test Plan: The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests. <img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png"> In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes: react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors iOS |Light|Dark| |{F229354502}|{F229354515}| Android |Light|Dark| |{F230114392}|{F230114490}| {F230122700} Reviewed By: hramos Differential Revision: D19837753 Pulled By: TheSavior fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
2020-03-03 02:07:50 +03:00
get PlatformColor(): PlatformColor {
return require('./Libraries/StyleSheet/PlatformColorValueTypes')
.PlatformColor;
},
get processColor(): processColor {
return require('./Libraries/StyleSheet/processColor').default;
PlatformColor implementations for iOS and Android (#27908) Summary: This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester. Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window. The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects. `PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version. The function returns a `ColorValue`. On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`. On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML: XML Resource: `@ [<package_name>:]<resource_type>/<resource_name>` Style reference from current theme: `?[<package_name>:][<resource_type>/]<resource_name>` For example: - `?android:colorError` - `?android:attr/colorError` - `?attr/colorPrimary` - `?colorPrimaryDark` - `android:color/holo_purple` - `color/catalyst_redbox_background` On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes. Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>` Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method. ## Changelog [General] [Added] - Added PlatformColor implementations for iOS and Android Pull Request resolved: https://github.com/facebook/react-native/pull/27908 Test Plan: The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests. <img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png"> In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes: react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors iOS |Light|Dark| |{F229354502}|{F229354515}| Android |Light|Dark| |{F230114392}|{F230114490}| {F230122700} Reviewed By: hramos Differential Revision: D19837753 Pulled By: TheSavior fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
2020-03-03 02:07:50 +03:00
},
Introduce flow type to differentiate between HostComponent, NativeMethodsMixin, and NativeComponent 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
2019-09-25 20:10:48 +03:00
get requireNativeComponent(): <T>(
uiViewClassName: string,
) => HostComponent<T> {
return require('./Libraries/ReactNative/requireNativeComponent').default;
},
get RootTagContext(): RootTagContext {
return require('./Libraries/ReactNative/RootTag').RootTagContext;
},
get unstable_enableLogBox(): () => void {
return () =>
console.warn(
'LogBox is enabled by default so there is no need to call unstable_enableLogBox() anymore. This is a no op and will be removed in the next version.',
);
},
// Deprecated Prop Types
get ColorPropType(): $FlowFixMe {
Add back deprecated prop-types Summary: In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely. The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users. Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change. In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it. To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package. Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.** Changelog: [General][Changed] - Add back deprecated PropTypes Reviewed By: yungsters Differential Revision: D40725705 fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
2022-10-27 08:03:19 +03:00
console.error(
'ColorPropType will be removed from React Native, along with all ' +
'other PropTypes. We recommend that you migrate away from PropTypes ' +
'and switch to a type system like TypeScript. If you need to ' +
'continue using ColorPropType, migrate to the ' +
"'deprecated-react-native-prop-types' package.",
);
Add back deprecated prop-types Summary: In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely. The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users. Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change. In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it. To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package. Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.** Changelog: [General][Changed] - Add back deprecated PropTypes Reviewed By: yungsters Differential Revision: D40725705 fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
2022-10-27 08:03:19 +03:00
return require('deprecated-react-native-prop-types').ColorPropType;
},
get EdgeInsetsPropType(): $FlowFixMe {
Add back deprecated prop-types Summary: In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely. The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users. Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change. In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it. To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package. Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.** Changelog: [General][Changed] - Add back deprecated PropTypes Reviewed By: yungsters Differential Revision: D40725705 fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
2022-10-27 08:03:19 +03:00
console.error(
'EdgeInsetsPropType will be removed from React Native, along with all ' +
'other PropTypes. We recommend that you migrate away from PropTypes ' +
'and switch to a type system like TypeScript. If you need to ' +
'continue using EdgeInsetsPropType, migrate to the ' +
"'deprecated-react-native-prop-types' package.",
);
Add back deprecated prop-types Summary: In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely. The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users. Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change. In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it. To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package. Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.** Changelog: [General][Changed] - Add back deprecated PropTypes Reviewed By: yungsters Differential Revision: D40725705 fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
2022-10-27 08:03:19 +03:00
return require('deprecated-react-native-prop-types').EdgeInsetsPropType;
},
get PointPropType(): $FlowFixMe {
Add back deprecated prop-types Summary: In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely. The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users. Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change. In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it. To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package. Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.** Changelog: [General][Changed] - Add back deprecated PropTypes Reviewed By: yungsters Differential Revision: D40725705 fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
2022-10-27 08:03:19 +03:00
console.error(
'PointPropType will be removed from React Native, along with all ' +
'other PropTypes. We recommend that you migrate away from PropTypes ' +
'and switch to a type system like TypeScript. If you need to ' +
'continue using PointPropType, migrate to the ' +
"'deprecated-react-native-prop-types' package.",
);
Add back deprecated prop-types Summary: In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely. The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users. Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change. In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it. To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package. Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.** Changelog: [General][Changed] - Add back deprecated PropTypes Reviewed By: yungsters Differential Revision: D40725705 fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
2022-10-27 08:03:19 +03:00
return require('deprecated-react-native-prop-types').PointPropType;
},
get ViewPropTypes(): $FlowFixMe {
Add back deprecated prop-types Summary: In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely. The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users. Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change. In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it. To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package. Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.** Changelog: [General][Changed] - Add back deprecated PropTypes Reviewed By: yungsters Differential Revision: D40725705 fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
2022-10-27 08:03:19 +03:00
console.error(
'ViewPropTypes will be removed from React Native, along with all ' +
'other PropTypes. We recommend that you migrate away from PropTypes ' +
'and switch to a type system like TypeScript. If you need to ' +
'continue using ViewPropTypes, migrate to the ' +
"'deprecated-react-native-prop-types' package.",
);
Add back deprecated prop-types Summary: In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely. The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users. Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change. In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it. To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package. Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.** Changelog: [General][Changed] - Add back deprecated PropTypes Reviewed By: yungsters Differential Revision: D40725705 fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
2022-10-27 08:03:19 +03:00
return require('deprecated-react-native-prop-types').ViewPropTypes;
},
};
if (__DEV__) {
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access ART. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access ART. */
Object.defineProperty(module.exports, 'ART', {
configurable: true,
get() {
invariant(
false,
'ART has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-community/art' instead of 'react-native'. " +
'See https://github.com/react-native-art/art',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access ListView. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access ListView. */
Object.defineProperty(module.exports, 'ListView', {
configurable: true,
get() {
invariant(
false,
'ListView has been removed from React Native. ' +
'See https://fb.me/nolistview for more information or use ' +
'`deprecated-react-native-listview`.',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access SwipeableListView. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access SwipeableListView. */
Object.defineProperty(module.exports, 'SwipeableListView', {
configurable: true,
get() {
invariant(
false,
'SwipeableListView has been removed from React Native. ' +
'See https://fb.me/nolistview for more information or use ' +
'`deprecated-react-native-swipeable-listview`.',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access WebView. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access WebView. */
Object.defineProperty(module.exports, 'WebView', {
configurable: true,
get() {
invariant(
false,
'WebView has been removed from React Native. ' +
"It can now be installed and imported from 'react-native-webview' instead of 'react-native'. " +
'See https://github.com/react-native-webview/react-native-webview',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access NetInfo. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access NetInfo. */
Object.defineProperty(module.exports, 'NetInfo', {
configurable: true,
get() {
invariant(
false,
'NetInfo has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-community/netinfo' instead of 'react-native'. " +
'See https://github.com/react-native-netinfo/react-native-netinfo',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access CameraRoll. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access CameraRoll. */
Object.defineProperty(module.exports, 'CameraRoll', {
configurable: true,
get() {
invariant(
false,
'CameraRoll has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-community/cameraroll' instead of 'react-native'. " +
'See https://github.com/react-native-cameraroll/react-native-cameraroll',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access ImageStore. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access ImageStore. */
Object.defineProperty(module.exports, 'ImageStore', {
configurable: true,
get() {
invariant(
false,
'ImageStore has been removed from React Native. ' +
'To get a base64-encoded string from a local image use either of the following third-party libraries:' +
"* expo-file-system: `readAsStringAsync(filepath, 'base64')`" +
"* react-native-fs: `readFile(filepath, 'base64')`",
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access ImageEditor. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access ImageEditor. */
Object.defineProperty(module.exports, 'ImageEditor', {
configurable: true,
get() {
invariant(
false,
'ImageEditor has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-community/image-editor' instead of 'react-native'. " +
'See https://github.com/callstack/react-native-image-editor',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access TimePickerAndroid. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access TimePickerAndroid. */
Object.defineProperty(module.exports, 'TimePickerAndroid', {
configurable: true,
get() {
invariant(
false,
'TimePickerAndroid has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-community/datetimepicker' instead of 'react-native'. " +
'See https://github.com/react-native-datetimepicker/datetimepicker',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access ToolbarAndroid. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access ToolbarAndroid. */
Object.defineProperty(module.exports, 'ToolbarAndroid', {
configurable: true,
get() {
invariant(
false,
'ToolbarAndroid has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-community/toolbar-android' instead of 'react-native'. " +
'See https://github.com/react-native-toolbar-android/toolbar-android',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access ViewPagerAndroid. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access ViewPagerAndroid. */
Object.defineProperty(module.exports, 'ViewPagerAndroid', {
configurable: true,
get() {
invariant(
false,
'ViewPagerAndroid has been removed from React Native. ' +
"It can now be installed and imported from 'react-native-pager-view' instead of 'react-native'. " +
'See https://github.com/callstack/react-native-pager-view',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access CheckBox. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access CheckBox. */
Object.defineProperty(module.exports, 'CheckBox', {
configurable: true,
get() {
invariant(
false,
'CheckBox has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-community/checkbox' instead of 'react-native'. " +
'See https://github.com/react-native-checkbox/react-native-checkbox',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access SegmentedControlIOS. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access SegmentedControlIOS. */
Object.defineProperty(module.exports, 'SegmentedControlIOS', {
configurable: true,
get() {
invariant(
false,
'SegmentedControlIOS has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-community/segmented-checkbox' instead of 'react-native'." +
'See https://github.com/react-native-segmented-control/segmented-control',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access StatusBarIOS. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access StatusBarIOS. */
Object.defineProperty(module.exports, 'StatusBarIOS', {
configurable: true,
get() {
invariant(
false,
'StatusBarIOS has been removed from React Native. ' +
'Has been merged with StatusBar. ' +
'See https://reactnative.dev/docs/statusbar',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access PickerIOS. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access PickerIOS. */
Object.defineProperty(module.exports, 'PickerIOS', {
configurable: true,
get() {
invariant(
false,
'PickerIOS has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-picker/picker' instead of 'react-native'. " +
'See https://github.com/react-native-picker/picker',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access Picker. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access Picker. */
Object.defineProperty(module.exports, 'Picker', {
configurable: true,
get() {
invariant(
false,
'Picker has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-picker/picker' instead of 'react-native'. " +
'See https://github.com/react-native-picker/picker',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access DatePickerAndroid. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access DatePickerAndroid. */
Object.defineProperty(module.exports, 'DatePickerAndroid', {
configurable: true,
get() {
invariant(
false,
'DatePickerAndroid has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-community/datetimepicker' instead of 'react-native'. " +
'See https://github.com/react-native-datetimepicker/datetimepicker',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access MaskedViewIOS. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access MaskedViewIOS. */
Object.defineProperty(module.exports, 'MaskedViewIOS', {
configurable: true,
get() {
invariant(
false,
'MaskedViewIOS has been removed from React Native. ' +
"It can now be installed and imported from '@react-native-community/react-native-masked-view' instead of 'react-native'. " +
'See https://github.com/react-native-masked-view/masked-view',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access AsyncStorage. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access AsyncStorage. */
Object.defineProperty(module.exports, 'AsyncStorage', {
configurable: true,
get() {
invariant(
false,
'AsyncStorage has been removed from react-native core. ' +
"It can now be installed and imported from '@react-native-async-storage/async-storage' instead of 'react-native'. " +
'See https://github.com/react-native-async-storage/async-storage',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access ImagePickerIOS. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access ImagePickerIOS. */
Object.defineProperty(module.exports, 'ImagePickerIOS', {
configurable: true,
get() {
invariant(
false,
'ImagePickerIOS has been removed from React Native. ' +
"Please upgrade to use either '@react-native-community/react-native-image-picker' or 'expo-image-picker'. " +
"If you cannot upgrade to a different library, please install the deprecated '@react-native-community/image-picker-ios' package. " +
'See https://github.com/rnc-archive/react-native-image-picker-ios',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access ProgressViewIOS. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access ProgressViewIOS. */
Object.defineProperty(module.exports, 'ProgressViewIOS', {
configurable: true,
get() {
invariant(
false,
'ProgressViewIOS has been removed from react-native core. ' +
"It can now be installed and imported from '@react-native-community/progress-view' instead of 'react-native'. " +
'See https://github.com/react-native-progress-view/progress-view',
);
},
});
/* $FlowFixMe[prop-missing] This is intentional: Flow will error when
* attempting to access DatePickerIOS. */
/* $FlowFixMe[invalid-export] This is intentional: Flow will error when
* attempting to access DatePickerIOS. */
Object.defineProperty(module.exports, 'DatePickerIOS', {
configurable: true,
get() {
invariant(
false,
'DatePickerIOS has been removed from react-native core. ' +
"It can now be installed and imported from '@react-native-community/datetimepicker' instead of 'react-native'. " +
'See https://github.com/react-native-datetimepicker/datetimepicker',
);
},
});
}