Summary:
This pre-suppresses the 153 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: mroch
Differential Revision: D28754374
fbshipit-source-id: 1806f53bc7d804644d434583a2dcd6da63d00328
Summary: Changelog: [Fabric][iOS][Fix] Remove use of bridge from Modal by dismissing Modal with visible prop
Reviewed By: sammy-SC
Differential Revision: D28074326
fbshipit-source-id: 0278bfb031db802b59429c553ac62d83838f4cc9
Summary:
Changelog: [Internal]
Static ViewConfigs are not yet available in Fabric. ViewConfigs are generated from Paper view managers.
For a prop to pass through from JS to iOS, props in [RCTModalHostViewNativeComponent.js](dc80b2dcb5/Libraries/Modal/RCTModalHostViewNativeComponent.js) need to match RCT_EXPORT_VIEW_PROPERTY in RCTModalHostViewManager.m.
Reviewed By: sammy-SC
Differential Revision: D27977574
fbshipit-source-id: 9790d93500890a04ffc0fb4d2bcd2de5187f1fc0
Summary:
Changelog:
[Internal][Added] - Use injected Modal if set
Due to Modal uses AppContainer in a dev env, in the StrictMode we'll get warnings about legacy context API usage from inside the AppContainer.
It's a gnarly change to get rid of that legacy context so I'll be following up with additional code change prep steps towards the eventual removal of the legacy context.
Reviewed By: lunaleaps
Differential Revision: D27611218
fbshipit-source-id: f79475845e763527fff9ecfdbf3e581c4666e015
Summary:
ES Modules implicitly enable strict mode. Adding the "use strict" directive is, therefore, not required.
This diff removes all "use strict" directives from ES modules.
Changelog:
[Internal]
Reviewed By: motiz88
Differential Revision: D26172715
fbshipit-source-id: 57957bcbb672c4c3e62b1db633cf425c1c9d6430
Summary:
Adds types to Event Emitters and migrates the most relevant modules using them in `react-native`.
The most relevant file of this diff is `react-native/Libraries/vendor/emitter/__flowtests__/EventEmitter-flowtest.js` with the Flow tests showing and testing the behavior of the new types
Changelog: [Internal] Add types for Event Emitters and subclasses
Reviewed By: motiz88
Differential Revision: D25587936
fbshipit-source-id: feeb09f9ad15d383cdd82deaaaba0d12b94e868b
Summary:
Migrates all usages of `NativeEventEmitter` to `NativeEventEmitter<$FlowFixMe>`.
This prevents having to modify a very large number of files in the same change that adds support for typed events. It adds an unused typed parameter to `NativeEventEmitter` so we can change all usages to add `$FlowFixMe`.
Changelog: [Internal]
Reviewed By: nadiia
Differential Revision: D25575774
fbshipit-source-id: c7979e1502e980401d9c03456282eba333c1606d
Summary:
Fixes: https://github.com/facebook/react-native/issues/29455
Modal's onDismiss is not called on iOS.
This issue occurred the commit bd2b7d6c03 and was fixed the commit 27a3248a3b.
However, the master and stable-0.63 branches do not have this modified commit applied to them.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Modal's onDismiss prop will now be called successfully.
Pull Request resolved: https://github.com/facebook/react-native/pull/29882
Test Plan:
Tested on iOS with this change:
1. Set function Modal's onDismiss prop.
1. Set Modal's visible props is true. (show Modal)
1. Set Modal's visible props is false. (close Modal)
1. The set function in onDismiss is called.
Reviewed By: shergin
Differential Revision: D24648412
Pulled By: hramos
fbshipit-source-id: acf28fef21420117c845d3aed97e47b5dd4e9390
Summary:
In the next react sync we removed the `displayName` from forwardRef and useMemo components ([PR here](https://github.com/facebook/react/pull/18495 )).
This means we need to manually add the displayName in the mock.
Changelog: [General] [Fixed] Fix test renderer mocks to use the displayName more often.
Reviewed By: TheSavior
Differential Revision: D22775470
fbshipit-source-id: 1390dc325e34f7ccea32bbdf1c6a8f6efea3a080
Summary:
Changes dependents of `EmitterSubscription` to instead import the `EventSubscription` type from `EventEmitter.js`.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D22182309
fbshipit-source-id: 575f4c59248ef50182ddb33911f1e6f3ba88ec07
Summary:
Remove usage of the legacy context API in Modal in favor of the new context API. Closes https://github.com/facebook/react-native/issues/28103
Pull Request resolved: https://github.com/facebook/react-native/pull/29002
Test Plan: Run RNTester app and test the Modal example. Also add a `console.warn` to make sure we get the correct context value.
Differential Revision: D21793993
Pulled By: TheSavior
fbshipit-source-id: de2a30cbd46507bfa73a563d2429c5a7f0e320c9
Summary:
I noticed that in ModalHostShadowNode.java (not used in Fabric), there's an assumption that the Modal will have exactly one child on the native side; this child is explicitly specified in Modal.js.
However, in Fabric, these views are flattened and so the Modal will actually have N children - whatever children the product code passes into the Modal.
In *theory* this should be fine, but might be causing issues. Not sure.
This is an experiment and shouldn't be landed until we verify that (1) this actually matters, (2) that it fixes an issue with Modal on iOS or Android.
Changelog: [Internal] Change to make Fabric consistent with non-Fabric Modal
Reviewed By: mdvacca
Differential Revision: D21191822
fbshipit-source-id: 9d65f346387fd056649d4063d70220f637ba8828
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
![Screen Recording 2019-12-26 at 14 05 33](https://user-images.githubusercontent.com/8739/71477208-0ac88c80-27e9-11ea-9342-8631426a9b80.gif)
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:
Changelog: [Internal]
Reverting the import to the previous local module style since importing from react-native seems to introduce some perf regression. We'll revisit this later in the future.
Reviewed By: yungsters
Differential Revision: D18383893
fbshipit-source-id: f11d46a4545768f39199fd6fd22fcf14905d0a74
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:
Changelog: [Internal]
Moved the imports for `TurboModuleRegistry` and `TurboModule` from `react-native`. This was a jscodeshift with the script: P120688078
Reviewed By: yungsters
Differential Revision: D18262538
fbshipit-source-id: 48fac15229c897408928511c5ecbb42f17ec7b42
Summary:
We need to migrate to HostComponent instead of the exported type from codegenNativeComponent which is the same type
Changelog:
[Internal] Migrate NativeComponentType from codegenNativeComponent to HostComponent
Reviewed By: rickhanlonii
Differential Revision: D17563307
fbshipit-source-id: 01c8fea8c67b33bed42ae28ffb8c132be87b9a7a
Summary:
Need to add explicit type annotations in these areas to unblock types-first architecture for Flow. These are locations the codemod could not automatically handle.
I'll call out areas I need a close eye on in the comments.
Reviewed By: panagosg7
Differential Revision: D16659053
fbshipit-source-id: 167dd2abe093019b128676426374c1c62cf71e7f
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: Visible property isn't used by native modal, neither in iOS nor in Android
Reviewed By: osdnk
Differential Revision: D16107927
fbshipit-source-id: 6f8b8db11abc0942f5af3abcc0245bc066da8c6b
Summary:
`WithDefault` appears not to be required to be prefixed with `?` because it's option value per se.
Fixed tests, removed `?` where needed, updated snapshots and review them. Added mechanism fro throwing error when `?WithDefault` found. Add tests for it.
Reviewed By: rubennorte
Differential Revision: D16048463
fbshipit-source-id: f55ed7454aacf0b8c42944a9b5c1037ad1b360fe
Summary:
It appears that `(e: BubblingEvent<T>) = mixed` exists only in given context and it's pointless to keep in this way. It could be simplified to `BubblingEventHandler<T>` without any negative consequences and that's the motivation of this diff.
The only tradeoff of this decision is leaving an opportunity to declare Bubbling/Direct event in the top of the file bc then analysing the code becomes much more difficult. However, it's not used anywhere so it's not a problem now and probably any time.
Also, changes the names to `DirectEventHandler` and `BubblingEventHandler` which are more related to current state. The names were updated in many places in code.
Reviewed By: rubennorte
Differential Revision: D16054571
fbshipit-source-id: 741d075eb46b80bac8eb73a6b30fc0b448cb3902
Summary: These files are no longer needed since all files codegen'd use flow types as the source 🎉
Reviewed By: cpojer
Differential Revision: D15961378
fbshipit-source-id: 510a298b2e97cd78a9a3648cbaa239e8134daa75