Inset the full screen modal used for workspaces on large devices#3887
Conversation
|
Should we set the overlay background color to the one used in the Figma design or leave it as |
|
I think we should already have a color variable for the correct overlay color. If you launch an attachment modal from a chat, you should see what I mean. |
|
Done! I had to create a new component to customize the background color. Let me know what you think about the changes. |
|
Mind sharing a screenshot? |
|
I'm not sure if this is a blocker, but interacting with the backdrop won't dismiss this modal. |
marcaaron
left a comment
There was a problem hiding this comment.
Mostly LGTM! But did have some questions
|
|
||
| if (!props.isSmallScreenWidth) { | ||
| return ( | ||
| <View style={styles.navigationSceneFullScreenWrapper}> |
There was a problem hiding this comment.
Could we change only the styles passed to sceneContainerStyle? Why is the additional View necessary? Asking mostly because it would make this logic a bit cleaner without having to create the content variable, but not a blocker.
There was a problem hiding this comment.
That's what I tried first, and I found that the sceneContainerStyle targets a different UI component.
Adding the View wrapper was necessary because it was the only way to wrap the Drawer and the Screen contents and apply the rounded corners to them.
There was a problem hiding this comment.
Got it. Does having the extra View around everything else cause issues as well? Something like
<View style={props.isSmallScreenWidth ? styles.navigationSceneFullScreenWrapper : undefined}>
... other stuffThere was a problem hiding this comment.
Also no worries if there is no way to keep all the JSX together. I think it's just easier to parse without the content variable.
| * @returns {Object} | ||
| */ | ||
| function getNavigationDrawerStyle(windowWidth, windowHeight, isSmallScreenWidth) { | ||
| function getNavigationDrawerStyle(isSmallScreenWidth) { |
There was a problem hiding this comment.
Out of curiosity, is this change just clean up or were the non relative width/height causing some issue?
There was a problem hiding this comment.
Yep, the non-relative values were causing issues after I added the spacing around the modal (essentially, the modal wasn't respecting the parent's right and bottom padding), so I ended up making all the sizes relative to fix the issue.
An alternative to this was subtracting spacing size * 2 from the absolute values, but that was a worse solution IMO.
There was a problem hiding this comment.
Yep, the non-relative values were causing issues after I added the spacing around the modal (essentially, the modal wasn't respecting the parent's right and bottom padding), so I ended up making all the sizes relative to fix the issue.
Got it, thanks. I think maybe in this case it would be good to add that context in a comment since a future change could undo that and the reasoning for these values is not very clear.
An alternative to this was subtracting spacing size * 2 from the absolute values, but that was a worse solution IMO.
That does sound more complicated.
| left: 0, | ||
| width: '100%', | ||
| height: '100%', | ||
| opacity: 0.5, |
There was a problem hiding this comment.
This style should be moved into styles.js. We have standardized on avoiding inline styles and there is some more explanation here.
|
We could use a Touchable inside the CardOverlay to handle these interactions. However, the visible surface of the overlay is tiny (20px per side), so it may not add that much value. Have we considered adding support for the |
I'll defer to @shawnborton on this one. I see your point about the small surface, but also can see an argument where the universal expected behavior for a backdrop behind a modal (however small) would be to dismiss the modal. No strong feelings on it though :)
|
marcaaron
left a comment
There was a problem hiding this comment.
Code changes look good, but I think this PR is introducing a regression as the height expands much larger than the screen size. See video:
2021-07-07_07-14-21.mp4
|
|
||
| if (!props.isSmallScreenWidth) { | ||
| return ( | ||
| <View style={styles.navigationSceneFullScreenWrapper}> |
There was a problem hiding this comment.
Got it. Does having the extra View around everything else cause issues as well? Something like
<View style={props.isSmallScreenWidth ? styles.navigationSceneFullScreenWrapper : undefined}>
... other stuff|
|
||
| if (!props.isSmallScreenWidth) { | ||
| return ( | ||
| <View style={styles.navigationSceneFullScreenWrapper}> |
There was a problem hiding this comment.
Also no worries if there is no way to keep all the JSX together. I think it's just easier to parse without the content variable.
| * @returns {Object} | ||
| */ | ||
| function getNavigationDrawerStyle(windowWidth, windowHeight, isSmallScreenWidth) { | ||
| function getNavigationDrawerStyle(isSmallScreenWidth) { |
There was a problem hiding this comment.
Yep, the non-relative values were causing issues after I added the spacing around the modal (essentially, the modal wasn't respecting the parent's right and bottom padding), so I ended up making all the sizes relative to fix the issue.
Got it, thanks. I think maybe in this case it would be good to add that context in a comment since a future change could undo that and the reasoning for these values is not very clear.
An alternative to this was subtracting spacing size * 2 from the absolute values, but that was a worse solution IMO.
That does sound more complicated.
|
I don't feel strongly about the outside area being clickable. I agree with Marc though that it is expected behavior, but I could live without it here. I feel like the |
|
I'll pick this back after coming back from OOO 😄 |
joelbettner
left a comment
There was a problem hiding this comment.
Left one comment. Other than that it LGTM.
| ...commonModalScreenOptions, | ||
| cardStyle: {...styles.fullscreenCard}, | ||
| cardStyle: { | ||
| ...styles.fullscreenCard, |
There was a problem hiding this comment.
Since styles.cardOverlay is being added below and has the following styles:
cardOverlay: {
backgroundColor: themeColors.modalBackdrop,
position: 'absolute',
top: 0,
left: 0,
width: '100%',
height: '100%',
opacity: 0.5,
}and styles.fullscreenCard has the following styles:
fullscreenCard: {
position: 'absolute',
left: 0,
top: 0,
width: '100%',
height: '100%',
}why do we need to add ...styles.fullscreenCard here? Won't all these styles be included in cardOverlay?
There was a problem hiding this comment.
The cardOverlay is for the backdrop of the modal, and the fullscreenCard is for the content that appears on top of the backdrop. These styles are for two different components, hence the need for the two different styles.
There was a problem hiding this comment.
I was just wondering if the styles would be inherited. In any case, if the cardOverlay component might be used elsewhere, it makes sense to pass the styles along and not rely on inheritence.
| cardOverlayEnabled: false, | ||
| cardOverlayEnabled: !this.props.isSmallScreenWidth, | ||
| isFullScreenModal: true, | ||
| cardOverlay: CardOverlay, |
There was a problem hiding this comment.
Sould it make more sense just to have
cardOverlay: <View style={styles.cardOverlay} />,Why have an entirely different file for something that is only used in this one place?
There was a problem hiding this comment.
We could move it to the AuthScreen but, we would still need to pass it as cardOverlay: CardOverlay. I think it's best to leave it as a separate file just in case we need to use it for another modal.
|
I just fixed the bug @marcaaron mentioned for the Reports screen. I still need to test other screens similar to the Reports one to see if there are similar regressions. |
|
Let us know when it's ready for another review 👍 |
|
Ready for review! |
|
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
|
I'm not sure if this PR was blocked on me (sorry, if so) but it has conflicts now. |
|
Conflicts fixed. If you could review @marcaaron |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by @marcaaron in version: 1.0.83-2 🚀
|

cc @marcaaron
Details
Added the expected spacing around the full-screen modals without modifying too many things.
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/169135
Tests / QA Steps
Using a large screen (like the web version or the desktop app):
Using a small screen (mobile version):
Tested On
Screenshots
Web
Mobile Web
Desktop
iOS
Android