feat: Add logic for better bottom SafeArea handling + Enable translucent Android NavBar #57128
Conversation
chrispader
changed the title
|
Unverified commits |
weird thanks, i'll check that |
…apply to more components
chrispader
force-pushed
the
@chrispader/add-flags-for-disabling-bottom-safe-area-spacing
branch
from
76ac324 to
fbb4e37
Compare
|
Hey! I see that you made changes to our Form component. Make sure to update the docs in FORMS.md accordingly. Cheers! |
chrispader
changed the title
|
I have a pretty neat update for handling bottom safe area on screens with keyboards. (cc @kirillzyusko) I've essentially built in a flag into I've also created a flag in An example on the different platforms:
Web and mWeb still work the same: 
|
|
@Expensify/design @shawnborton @dannymcclain what solution for the following problem do you guys prefer in terms of design. 🎨✏️ We want to let scrollable content render all the way until the bottom edge of the screen (right?). Sometimes we have bottom-sticky buttons or elements like on the Does this implementation look good to you? Do you think that there is too much spacing between the gesture-bar/navigation-bar and the button? Should we have some sort of "background fade" at the bottom, where content can still be seen but slightly less noticable? Also, right now when the button is disabled it will be slightly translucent (50% opacity). I don't think this looks good, when there is content below the button. I experimented with the Button and basically impemented a "blending" logic, which we can enable to basically keep the button at 100% opacity, while still getting the lower-opacity color as if it was displayed on the background color. These are screenshots of the differences on Android and iOS for...
Original vs. Edge-to-EdgeAndroid gesture-bar:
Android three-button navigation bar:
Android (with keyboard):
iOS:
Opacity vs fade:Android original opacity vs. blend:
|
|
@Expensify/design @shawnborton @dannymcclain Also, how do we want to handle this "edge-to-edge" layout on web and mWeb? Imo on mWeb we should definitely have the same approach as on mobile, especially important when the keyboard is open. On web i'm not sure what looks better tbh. iOS mWeb with keyboard:
iOS mWeb without keyboard:
Web Original: 
Web Edge-to-Edge: 
Web Edge-to-Edge (scrolled down): 
|
|
|
|
|
|
|
|
|
@mountiny @lakchote
Explanation of Change
Based on the plan laid out in #53186 (comment).
New props
This PR introduces a
enableEdgeToEdgeBottomSafeAreaPaddingprop to many different component (always the same name) that should be removed after all screens have been fully migrated to edge-to-edge bottom safe area handling. There are also some other additional props, that will be kept, since they can be used to enable logic for bottom safe area handling in low-level components on a screen/component level.This PR introduces the following flags/props to these components:
ScreenWrapperenableEdgeToEdgeBottomSafeAreaPadding: Temporary; Used to disableincludeSafeAreaPaddingBottomlogic, renderbottomContentonly when it's set and apply the bottom padding styles correctly.shouldKeyboardOffsetBottomSafeAreaPadding: Explained below. Passed forward toKeyboardAvoidingView.KeyboardAvoidingViewshouldOffsetBottomSafeAreaPadding: Can be used to let theKeyboardAvoidingViewoffset the bottom safe area padding. TheKeyboardAvoidingViewwill basically setkeyboardVerticalOffset={-paddingBottom}, to compensate for the bottom safe area, when the keyboard is open.ModalenableEdgeToEdgeBottomSafeAreaPadding: This disables (extra) bottom safe area in theModal. Once all modals have migrated to handling bottom safe area padding locally, we can remove this prop.ScrollViewaddBottomSafeAreaPadding: Used to trigger theuseContentContainerStyleWithBottomSafeAreaPaddinglogic and applycontentContainerStylewith bottom padding on theSectionListcontentContainerStyle:contentContainerStyleprop can still be used; ifpaddingBottomis set, the padding will be added to the one fromaddBottomSafeAreaPadding.SelectionListaddBottomSafeAreaPadding: This flag will apply the padding incontentContainerStyleof the nestedSectionList, as well as on theFixedFootercomponent, rather than on the container view.shouldFooterContentStickToBottom: Explained below. Passed forward toFixedFooterSectionListaddBottomSafeAreaPadding* Same as inScrollView. TriggersuseContentContainerStyleWithBottomSafeAreaPaddingcontentContainerStyle: Same as inScrollVIew.contentContainerStyleprop can still be usedFormProvider(andFormWrapper)addBottomSafeAreaPadding: This flag gets passed forward toScrollViewand enables padding handling there.shouldSubmitButtonStickToBottom: This flag enables logic which moves theSubmitButtoncomponent out of the scrollable content and places it sticking at the bottom. This is especially useful on screens that have scrollable content, a submit button at the bottom and an input that triggers the keyboard. When the keyboard opens, we still want to see the submit button, e.g. on theWorkspaceInvitePage.FixedFooteraddBottomSafeAreaPadding: If set, the fixed footer will add bottom padding for the safe area inset.shouldStickToBottom: Passed down fromSelectionList. If set, a the footer will stick to the bottom with padding applied bybottom: paddingBottom + styles.pb5.paddingBottom. This works hand in hand with theaddBottomSafeAreaPaddingflag.InteractiveStepWrapper:enableEdgeToEdgeBottomSafeAreaPadding: Used e.g. in workspace screens.Props marked bold props will get removed after the migration, as they are just temporary.
useContentContainerStyleWithBottomSafeAreaPadding: This hooks contains logic around mergingcontentContainerStyleprop (e.g. onScrollViewandSectionList) with additional bottom safe area padding. The style sheet will get flattened and ifpaddingBottomis already set, it will be added to the bottom safe area padding.Follow-up PRs
These are the follow-up PRs that use the flags introduced here:
Fixed Issues
$ #53186
PROPOSAL: #53186 (comment)
Tests
Offline tests
QA Steps
// TODO: These must be filled out, or the issue title must include "[No QA]."
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
MacOS: Desktop