-
-
Notifications
You must be signed in to change notification settings - Fork 537
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: move react-native-window-view
to screens package
#1096
Conversation
react-native-window-view
to screens package
@WoLewicki thank you for the great work on this. I think this feature could be a huge addition to React Native iOS in general. I have a few questions:
A big use-case I'm thinking about here is creating custom components like Thanks again! |
Ad 1. as you can see here: https://github.com/software-mansion/react-native-screens/pull/1096/files#diff-174f03b4ee9b6d6719c80e57d200b2057b704709f1b3f83218e31b54819d22d4R6 the Ad 2. as long as the view is not destroyed by React, it should stay in the native view hierarchy, so I think you can think of it as kind of similar thing to Probably the best thing you can do is to test it by yourself 🎉 and see if there are any problems. |
This PR might be an underrated solution to many of my iOS issues...thank you so much @WoLewicki! I will definitely test it. A bit of a naïve question here, what is the best way to test this PR in an app? |
One other question, related to the previous conversation about <>
<App />
<OverlayView interceptTouches={false} shown>
<Notifications /> 👈 this should still intercept touches when it renders
</OverlayView>
</> Ideally, its children can intercept touches, even if the overlay itself doesn't. |
One way of testing is adding this package to your project in As for the behavior you mentioned, I believe it is not possible now due to simple logic enabling/disabling the whole view hierarchy of |
@nandorojo can you check the newest commit? It should make the whole view not intercept touches, but its children should intercept them now. I added the behavior in the example, where the |
Looks good! I'll test it out. Would be great for it to make SDK 43. |
@WoLewicki I tested this. Works very good for me. A much-needed feature |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left two comments inline. Also, I think it'd be good to cleanup draggable/shown parameters as we discussed.
src/index.native.tsx
Outdated
@@ -329,6 +337,14 @@ module.exports = { | |||
|
|||
return ScreensNativeModules.NativeSearchBar; | |||
}, | |||
get OverlayView() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd perhaps change the name to sth like "FullWindowOverlay" to make it cleaner that it does not just overlay the container where its put or the screen under which it is rendered but instead it displays in front of all the content in the window.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WindowOverlay
could work too. A bit simpler to write and remember. But either is fine.
TestsExample/src/Test1096.tsx
Outdated
/> | ||
</View> | ||
</Modal> | ||
<OverlayView style={{position: 'absolute', width: '100%', height: '100%', justifyContent: 'center' }} shown={shown} draggable={draggable} interceptTouches={interceptTouches}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if there are more than one of such components rendered in the tree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They will be rendered on top of each other in the same order as they were added to React
view hierarchy at initialization since this code will be called: https://github.com/software-mansion/react-native-screens/pull/1096/files#diff-4882eafb07e471e6bd8bf6558dca65eacab42001de16e1dc1ca7b23c54ab765fR108 and then the RNWindow
will move all containers to front in order they were added: https://github.com/software-mansion/react-native-screens/pull/1096/files#diff-174f03b4ee9b6d6719c80e57d200b2057b704709f1b3f83218e31b54819d22d4R11
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine for the first iteration. Looking forward to getting full platform compatibility for this one!
Me too, this one is big time! |
@jakob-p what Expo SDK version are you using? Expo SDK 42 comes with FullWindowsOverlay is available from version >=3.7.0 of Cheers |
Im using Expo SDK 42, but tried to upgrade react-native-screens manually to 3.8.0. I'll try it with Expo SDK 43 when its officially released. |
@jacobp100 you can't manually upgrade native dependencies in Expo's managed workflow. It bundles particular versions of 3rd party libraries into one SDK release. See workflow comparison for reference Cheers |
Note: this doesn't work with android yet. const Overlay = Platform.OS === 'ios' ? FullWindowOverlay : View; falling back to a normal It works correctly on ios for Both RN Modals and RNS Modals overlay2.mp4 |
Yeah, I don't think there is a good way to implement something similar on Android, at least I don't have an idea how could it work under the hood. If you have any suggestions or libraries that do something similar, please link it here. |
@WoLewicki I'm not really sure, I'll do some research my self for sure. |
The key difference is that RNS lets you open more than one at a time, in order. RN modal is restricted to only one. |
@nandorojo that is the case on IOS ineed ( which is considered a bug ) , on android you can push multiple RN modals just fine. |
If that's the case, then the normal modal should work fine on Android. I thought that it didn't. It would be useful to have a component that falls back to Modal on non-iOS and matches the same behavior of the RNS overlay view (no animation, etc) so that we don't need to use |
I don't think that would work
|
I think for android replacing the RN |
it's worth noting that on IOS the somehow it removes it completely from the tree. issue-ios-fullscreen.mp4 |
This behavior is a consequence of how |
FWIW I've added an android POC for FullWindowOverlay - see #2421 |
Description
Moved the
WindowView
from https://github.com/WoLewicki/react-native-window-view to this repo and renamed it toRNSFullWindowOverlay
.Changes
Added
RNSFullWindowOverlay
files to JS and iOS files. Removed the necessity of adding changes toAppDelegate.m
by providing an extension ofUIWindow
in the package.Test code and steps to reproduce
Test1096.tsx
Checklist