Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
This PR only fixes a little typo that I noticed working on the documentation of React Native website taking reference from this source code, and then saw it 😅
## Changelog
[General] [Fixed] - Fixed typo from `inly` to `only` inside `Modal.js` library code.
Pull Request resolved: https://github.com/facebook/react-native/pull/28057
Test Plan: Not needed.
Reviewed By: cpojer
Differential Revision: D20197178
Pulled By: TheSavior
fbshipit-source-id: 372f263a16a2de665ced7c0d3f10e3897777d19f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28058
I'm taking the first step towards supporting iOS 13 UIScene APIs and modernizing React Native not to assume an app only has a single window. See discussion here: https://github.com/facebook/react-native/issues/25181#issuecomment-505612941
The approach I'm taking is to take advantage of `RootTagContext` and passing it to NativeModules so that they can identify correctly which window they refer to. Here I'm just laying groundwork.
- [x] `Alert` and `ActionSheetIOS` take an optional `rootTag` argument that will cause them to appear on the correct window
- [x] `StatusBar` methods also have `rootTag` argument added, but it's not fully hooked up on the native side — this turns out to require some more work, see: https://github.com/facebook/react-native/issues/25181#issuecomment-506690818
- [x] `setNetworkActivityIndicatorVisible` is deprecated in iOS 13
- [x] `RCTPerfMonitor`, `RCTProfile` no longer assume `UIApplicationDelegate` has a `window` property (no longer the best practice) — they now just render on the key window
Next steps: Add VC-based status bar management (if I get the OK on https://github.com/facebook/react-native/issues/25181#issuecomment-506690818 ), add multiple window demo to RNTester, deprecate Dimensions in favor of a layout context, consider adding hook-based APIs for native modules such as Alert that automatically know which rootTag to pass
## Changelog
[Internal] [Changed] - Modernize Modal to use RootTagContext
[iOS] [Changed] - `Alert`, `ActionSheetIOS`, `StatusBar` methods now take an optional `surface` argument (for future iPadOS 13 support)
[iOS] [Changed] - RCTPresentedViewController now takes a nullable `window` arg
[Internal] [Changed] - Do not assume `UIApplicationDelegate` has a `window` property
Pull Request resolved: https://github.com/facebook/react-native/pull/25425
Test Plan:
- Open RNTester and:
- go to Modal and check if it still works
- Alert → see if works
- ACtionSheetIOS → see if it works
- StatusBar → see if it works
- Share → see if it works
Reviewed By: PeteTheHeat
Differential Revision: D16957751
Pulled By: hramos
fbshipit-source-id: ae2a4478e2e7f8d2be3022c9c4861561ec244a26
Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary:
This prop was deprecated in April 2016 in [this commit](2bb1c263db (diff-931cea019b5e9faceffef4e46f1fff08)), first in 0.26.0
It's been a while, we can remove it now.
Changelog:
[Breaking][General] Modal: Remove support for `aniamted` prop (deprecated in 0.26)
Reviewed By: cpojer
Differential Revision: D19762163
fbshipit-source-id: b6173bba066fc9ad0e786f56a946e2f3fa3d79cc
Summary:
Starting on iOS 13, a View Controller presented modally will have a "bottom sheet" style unless it's explicitly presented full screen.
Before this, modals on iOS were only being dismissed programatically by setting `visible={false}`. However, now that the dismissal can happen on the OS side, we need a callback to be able to update the state.
This PR reuses the `onRequestClose` prop already available for tvOS and Android, and makes it work on iOS for this use case.
Should fix https://github.com/facebook/react-native/issues/26892
## Changelog
[iOS] [Added] - Add support for onRequestClose prop to Modal on iOS 13+
Pull Request resolved: https://github.com/facebook/react-native/pull/27618
Test Plan:
I tested this using the RNTester app with the Modal example:
1. Select any presentation style other than the full screen ones
2. Tap Present and the modal is presented
3. Swipe down on the presented modal until dismissed
4. Tap Present again and a second modal should be presented
Differential Revision: D19235758
Pulled By: shergin
fbshipit-source-id: c0f1d946c77ce8d1baab209eaef7eb64697851df
Summary:
Apologies for the large diff, it was difficult to break down.
This diff is a major refactor of LogBox that:
- Separates LogBoxNotification and LogBoxInspector
- Moves them each to their own container
- Updates AppContainer to only render the notification
- Updates the native logbox root to render the inspector
- Adds withSubscription HOC to manage subscribing to LogBoxData
- Simplifies LogBox to export an object instead of a component
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18750011
fbshipit-source-id: 639885d29e55e125892d1c2b6bbf2826f27d78db
Summary:
This diff switches LogBox over to use a Modal component so that the log inspector is always full screen.
In order to do that, it needed to add an `internal_excludeLogBox` flag to AppContainer so that it's not recursively rendered as: AppContainer -> LogBox -> Modal -> AppContainer. Not thrilled about the prop but it's necessary for now until this is rendered as it's own root (which we're working on next).
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D18461394
fbshipit-source-id: e1a80dfffbbe6c5467ac6f8d3c445a3280829020
Summary:
still some generated files in www that need to land before we can release 0.111 here.
drop-conflicts
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: dsainati1
Differential Revision: D18278838
fbshipit-source-id: b20c3fefb3aab7c5fb614b33d846c7548184f49a
Summary:
# Disclaimer:
I might be missing something as the solution I implemented here seems like something that was considered by original author. If this solution isn't good, I have a plan B.
# Problem:
`onDismiss` prop isn't being called once the modal is dismissed, this diff fixes it.
Also I've noticed that `onDismiss` is meant to only work on iOS, why is that? By landing this diff, it'll be called on Android as well so we need to change the docs (https://facebook.github.io/react-native/docs/modal.html#ondismiss).
## Video that shows the problem
Following code is in playground.js P70222409 which just increments number everytime onDismiss is called
{F166303269}
Reviewed By: shergin
Differential Revision: D16109536
fbshipit-source-id: 3fba56f5671912387b217f03b613dffd89614c9d
Summary: This fixes the following warning from appearing when you have a FlatList render a Modal where the content of the Modal also contains a FlatList: https://fburl.com/p953k985. Spencer addressed an issue similar to this in D7863625, but we still get a yellow box due to the fact that `scrollContext` still exists, but `this.context.virtualizedList` is null from this line in Modal.js https://fburl.com/nqc261a1.
Reviewed By: cpojer
Differential Revision: D16160666
fbshipit-source-id: ba222d3eef234f4c8c4c2bddbc71bec27df81e0a
Summary:
returning type of Bubbling and Direct Event should be always void of Promise (if async). Other situations shouldn't be permitted.
Reformated all cases when it the function wasn't void.
Reviewed By: rickhanlonii
Differential Revision: D16165962
fbshipit-source-id: 7c1377c3ed4bd54a431a13e5bcda4f7ec0adf4dc
Summary:
I'd like to use `Modal`’s flow types in my application to make a reusable component.
## Changelog
[JavaScript] [Added] - Exported `Modal`’s types
Pull Request resolved: https://github.com/facebook/react-native/pull/25554
Test Plan: n/a
Differential Revision: D16180231
Pulled By: cpojer
fbshipit-source-id: 9cfd5163a187954783102bfe4d9b4d1dbc8c6e6d
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary:
This diff changes the style of the Modal container style as a pre-requisite to implement Modal on Fabric.
In the current version of React Native the size of the View container is determined at runtime using the size of the screen. The size of this view is set overriding the Widht and Height of this Container View (using the screen size), in Fabric we can not update the size of that view, instead we set the size of the RCTModalHostView to take the size of the whole screen.
Since the RCTModalHostView has an absolute position and it has the size of the screen, making this change should be enough to keep backward compatibility and be able to implement Modal on Fabric
Reviewed By: JoshuaGross
Differential Revision: D15067616
fbshipit-source-id: d7302ef3afc503adfee10e12fb6d0ebd371fb7ed
Summary:
This PR is related to #22990
Changelog:
----------
[iOS] [Changed] - move the call to requireNativeComponent from Modal.js to RCTModalHostViewNativeComponent.js
Pull Request resolved: https://github.com/facebook/react-native/pull/23030
Differential Revision: D13710032
Pulled By: cpojer
fbshipit-source-id: 822284a639f38721442c67ceff98fc99495c31b9
Summary:
Changing the the this.props.visible if to be ` if (!!this.props.visible === false)` . So passing undefined, or other values wont set the modal to be visible. Granting that anything that is not true, will set the modal to null on the render.
I make this this PR, because on the company that im working, we used a lot of RN. At the moment, we arent using anything like flow or TS. But to grant that the modals will only show if they are set visible to true i have changed the if made.
_Pull requests that expand test coverage are more likely to get reviewed. Add a test case whenever possible!_
Pull Request resolved: https://github.com/facebook/react-native/pull/22072
Differential Revision: D12918086
Pulled By: TheSavior
fbshipit-source-id: 8f9c63ac6fd56d83949bb8428ad7c5b7bf805c49
Summary:
Fixes lots of ESLint warnings. Many of them where in PR #20877 by janicduplessis which requested to split the linting fixes from configuration and package changes.
I solved only the issues that I was most certain about but I would love to get hands on all of them with a little bit of input.
Pull Request resolved: https://github.com/facebook/react-native/pull/22062
Differential Revision: D12889447
Pulled By: TheSavior
fbshipit-source-id: 35f7a08104a5b859c860afdde4af2b32c0685c50
Summary:
This PR converts the Prop Types in `Modal` to Flow Types, and fills out the callback types a bit more.
Context Types are left in for now.
Pull Request resolved: https://github.com/facebook/react-native/pull/21279
Reviewed By: yungsters
Differential Revision: D10006795
Pulled By: TheSavior
fbshipit-source-id: ac885f2e5f068b0991009a9b1cbb3886e34941af
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
As we migrate over to static typing solutions for props, we cannot rely on always having `propTypes` available at runtime.
This gets us started on that journey by removing the native prop validation that happens when we require native components.
bypass-lint
Reviewed By: TheSavior
Differential Revision: D7976854
fbshipit-source-id: f3ab579a7f0f8cfb716b0eb7fd4625f8168f3d96
Summary:
`FlatList` (actually `VirtualizedList`) allows recursive nesting of itself for easy and complex composition of lists such that it can support seemless virtualization and VPV events. It does this by only rendering a `ScrollView` for the outermost `VirtualizedList` and simply stacking `View`s for all the internal ones.
However, if a `Modal` is in a `FlatList` and also hosts a `FlatList`, e.g.:
```
<FlatList ListFooterComponent={<Modal><Foo /></Modal>} />
```
Then React context will propogate through to the inner `FlatList` and cause it to render as a plain `View`. Because the `Modal` actually portals the views into a different native hierarchy, one without a `ScrollView`, the `FlatList` won't scroll as expected.
The fix is to wipe out the context - not sure if there is a better way, but this doesn't seem terrible.
Differential Revision: D7863625
fbshipit-source-id: 38f41d72ed32b9f0eb1c9c82893f21d83a83f9ad
Summary:
This PR removes the need for having the `providesModule` tags in all the modules in the repository.
It configures Flow, Jest and Metro to get the module names from the filenames (`Libraries/Animated/src/nodes/AnimatedInterpolation.js` => `AnimatedInterpolation`)
* Checked the Flow configuration by running flow on the project root (no errors):
```
yarn flow
```
* Checked the Jest configuration by running the tests with a clean cache:
```
yarn jest --clearCache && yarn test
```
* Checked the Metro configuration by starting the server with a clean cache and requesting some bundles:
```
yarn run start --reset-cache
curl 'localhost:8081/IntegrationTests/AccessibilityManagerTest.bundle?platform=android'
curl 'localhost:8081/Libraries/Alert/Alert.bundle?platform=ios'
```
[INTERNAL] [FEATURE] [All] - Removed providesModule from all modules and configured tools.
Closes https://github.com/facebook/react-native/pull/18995
Reviewed By: mjesun
Differential Revision: D7729509
Pulled By: rubennorte
fbshipit-source-id: 892f760a05ce1fddb088ff0cd2e97e521fb8e825
Summary:
Hi! I would like to contribute to React Native, and I am just starting out. I forked the repo and found that it has quite a lot of ESLint warnings – many of which were automatically fixable. This PR is simply the result of running `yarn lint --fix` from the root folder.
Most changes are removing trailing spaces from comments.
Haven't really done any manual testing, since I haven't done any code changes manually. `yarn test` runs fine, `yarn flow` runs fine, `yarn prettier` is satisfied.
N/A
[INTERNAL][MINOR][] - Fix ESLint warnings
Closes https://github.com/facebook/react-native/pull/18047
Differential Revision: D7054948
Pulled By: hramos
fbshipit-source-id: d53e692698d1687de5821c3fb5cdb76a5e03b71e
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary: Adds an onDismiss so that navigation events can be chained to the dismissing of a modal.
Reviewed By: sahrens
Differential Revision: D5852953
fbshipit-source-id: a86e36fdd5b0b206c2dd9fa248e2a88da22efa31
Summary:
**Motivation**
On Apple TV, pressing the menu button destroys the native view that backs the `Modal` component, causing an app using this component to get into a broken state. This fix implements `onRequestClose` for tvOS to have the same behavior as it does for the Android back button.
**Test plan**
Manually tested this with the `ModalExample` in the `RNTester` app. See also the test code in issue #15313.
Closes https://github.com/facebook/react-native/pull/15341
Differential Revision: D5651035
Pulled By: shergin
fbshipit-source-id: 54bf66887bbe85940567e63e90b437ac4a8daf9a
Summary:
you don't need curly bracket. `{}`
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/15198
Differential Revision: D5497867
Pulled By: javache
fbshipit-source-id: a09f06aabc6ea16f0b0eec12bf910ffcab804eb0
Summary:
I was using Modal component and I didn't knew what was the default for animationType prop. After reading the code, I saw that it was `none`.
I did not tell that the "default" is `slide` if animated is set to `true`, because it is not a default but an implementation of `animated` prop effect and because of the deprecation of `animated`.
Thanks.
Closes https://github.com/facebook/react-native/pull/13196
Differential Revision: D4795765
Pulled By: hramos
fbshipit-source-id: 25d62ac7eeb20fc5557918c3d75709f44f5d4972
Summary:
When using React Native on Android on top of a game as an overlay, dialog windows sometimes get created with hardware acceleration disabled. This causes the UI to be unresponsive and anything that uses a TextureView stops working. Added a property for the modal view to make sure hardware acceleration flag is enabled when it's set to true.
**Test plan (required)**
set `hardwareAccelerated` property for Modal to force hardware acceleration on dialog windows on Android. Does nothing on iOS.
Closes https://github.com/facebook/react-native/pull/11421
Differential Revision: D4312912
Pulled By: andreicoman11
fbshipit-source-id: 9db6b2eca361421b92b24234b3501b5de0eecea7
Summary:
Following up on fb7fe2d4e8: when <Modal> is used in dev mode, it renders `<AppContainer>` to wrap the children so that the element inspector can show up correctly. In that scenario, we need pass the `rootTag` over the `<AppContainer>` so that the children can read the rootTag correctly. Otherwise, the children of <Modal> will see it as undefined.
With this, AppContainer can then declare `rootTag` as a required prop, as it should have been.
Note that this only affects DEV build because there's no AppContainer wrapping otherwise.
Reviewed By: jingc
Differential Revision: D4204011
fbshipit-source-id: 80edbc8d351d983786e6fc3c68dfa65a71b1ed3c
Michael Bolin
Miguel Bolivar
Logan Daniels
radex
Rachel Nabors
Valentin Shergin
Eli White
Jorge Bernal
Rick Hanlon
Jordan Brown
Pavol Fulop
Samuel Susla
Min ho Kim
Blair Vanderhoof
Michał Osadnik
Cory Reed
Eric Lewis
Abhinandan Ramaprasath
James Ide
David Vacca
nd-02110114
MateusAndrade
Ignacio Olaciregui
empyrical
Héctor Ramos
Tim Yung
Spencer Ahrens
Rubén Norte
Mats Byrkeland
Sophie Alpert
Brian Vaughn
Mehdi Mulani
Caleb Meredith
Douglas Lowder
jooddang
Hank Brekke
Elie Teyssedou
Üstün Ergenoglu
Kevin Gozali
