Chore/9630-UseDesignSystemSnackbarComponent

[oddballdave]

Description of Change

• Completely removed the old global SnackBar implementation and replaced it with the design system Snackbar component
• Incorporated the use of the Snackbar provider and hook from the design system
• Patched the design system Snackbar to workaround dependency issues with the useEffect hook
• Implemented automatic dismissal of the Snackbar when the user navigates away from the current screen
• Removed SnackbarMessages and switched to using translated text directly
• Modified unit tests to work correctly with the new Snackbar implementation
• Cleaned up unused files, constants, string resources and related portions of the app-level theme

Screenshots/Video

Android (Before)
Android (After)
iOS (Before)
iOS (After)

Testing

• Tested on iOS
• Tested on Android

Reviewer Validations

PR Checklist

Reviewer: Confirm the items below as you review

• PR is connected to issue(s)
• Tests are included to cover this change (when possible)
• No magic strings (All string unions follow the Union -> Constant type pattern)
• No secrets or API keys are checked in
• All imports are absolute (no relative imports)
• New functions and Redux work have proper TSDoc annotations

For QA

Run a build for this branch

[timwright12]

@oddballdave please make sure to not merge until QA has tested and approved. This is a large change, so it will take some time.

[narin]

Looks great for the most part. We'll consider updating the component library to use the patch you created.

Reiterating what we discussed on the call, for Snackbars that need to appear on screens using templates without the nav bar showing such as <FullScreenSubtask /> or <LargePanel />, if a Snackbar is shown and the user isn't immediately navigated back to a screen that has the nav bar showing, the offset option should be included with snackbar.show() to account for the lack of nav bar. This probably would occur mostly with error message Snackbars. You can use theme.dimensions.snackBarBottomOffset as the offset which automatically calculates the correct offset based on OS.

i.e.

snackbar.show(t('secureMessaging.startNewMessage.sent.error')'), { offset: theme.dimensions.snackBarBottomOffset })

[oddballdave]

Looks great for the most part. We'll consider updating the component library to use the patch you created.

Reiterating what we discussed on the call, for Snackbars that need to appear on screens using templates without the nav bar showing such as <FullScreenSubtask /> or <LargePanel />, if a Snackbar is shown and the user isn't immediately navigated back to a screen that has the nav bar showing, the offset option should be included with snackbar.show() to account for the lack of nav bar. This probably would occur mostly with error message Snackbars. You can use theme.dimensions.snackBarBottomOffset as the offset which automatically calculates the correct offset based on OS.

i.e.

snackbar.show(t('secureMessaging.startNewMessage.sent.error')'), { offset: theme.dimensions.snackBarBottomOffset })

I have located and fixed all the Snackbar offsets for screens where there is no bottom navigation bar. As part of this fix and to comply with the Figma design requirements, I made another patch to the Snackbar component to update the navigation bar height (more accurate) and to add a bottom margin to the Snackbar. This seemed like the right place to fix things since we are already accounting for the left/right margins and navigation bar height in the component itself versus relying on the app to provide these properties.

[oddballdave]

All known issues resolved and ready for a re-review. For reference, Jessica Wooden provided this guidance for the Snackbar design.

Here's a visual guide for where the Snackbar should appear on the screen if the nav bar is present or not. The spacing to the left/right and below the snackbar is set to 20.

[TimRoe]

I see the justification for this in another comment:

I made another patch to the Snackbar component to update the navigation bar height (more accurate) and to add a bottom margin to the Snackbar. This seemed like the right place to fix things since we are already accounting for the left/right margins and navigation bar height in the component itself versus relying on the app to provide these properties.

The reason bottom margin was not included in the component is two fold:

1. It's controllable via the offset to whatever an app could want so we just gave a default as apps would need to override it anyway for any special cases--if 20 pixel spacing is desired without a Nav bar, offset can be set to 20
2. Margin makes elements underneath the Snackbar (e.g. a button sticking out partially) no longer pressable within the margined space despite being visible where setting the offset via the library used by the component allows presses outside the bounds of the Snackbar to still occur as desired
   • For full disclosure: when building it, I tried to use margin instead of the library offset functionality since it was simpler, but found it resulted in the bug where you could position it above the Nav bar visually, but none of the Nav bar buttons would be able to be pressed; using the offset functionality, the Nav bar can still be interacted with as meets user expectations

The side margins were deemed acceptable to block presses as, paired with general padding for content, anything peeking should be very minimal.

I technically defer to the app team since we on the design system team long term are not responsible for how apps implement our components, but I'd recommend against patching this in as patches are frail and this is liable to break from future library changes we make to the component when updating while leveraging the offset should not.

[oddballdave]

Thanks for the feedback. Just so we're all on the same page, the left screenshot below is the default location where the Snackbar gets positioned when a bottom navigation bar is present and no offset is specified. There are 4 units of vertical spacing between the top of the navbar and the Snackbar. The right screenshot shows the changes with the patch applied (20 units of vertical spacing). If we can live with the spacing on the left screenshot, then I can remove the patch easily enough. If we want more spacing but no patch, then the app will have to start passing offsets into all Snackbars. Please advise.

[TimRoe]

I think the 4 units spacing is fine, but ultimately seems like a design decision. I believe the position is what it was with the old Snackbar so it'd be maintaining existing functionality and didn't come up during creating it or we'd likely have gone with a different default. As a "floating" element it can appear directly above other content regardless if it's 4 or 20 pixels from the Nav bar--the crux is not blocking the Nav bar so it's usable.

If the increased spacing is determined the way: I think a patch is fair way to go about it, but it would be better to update the default offset to 76 instead of using marginBottom. Longer term, we have done research into global overrides for certain design system parameters and the Snackbar offset definitely would be a good use case--but, in the absence of that yet existing, patching in a different default value seems like a reasonable workaround since when the global override exists then the only code change would be removing the patch and setting the global override in one spot.

Not sure if @Sparowhawk or anyone else on the app side had thoughts since ultimately from the design system side we're just providing recommendations based on how the components were built/designed and consumer apps can do what they want.

[TimRoe]

As a circle back: created a ticket to add a global override for the default Snackbar offset so it's documented as a desired future enhancement.

[TimRoe]

This is somewhat a design decision, but am not sure pixel perfection is necessary here.

Similar to the above of deferring to the app team, but I'd recommend against patching it vs having 4 pixels more in what is already somewhat arbitrary padding for a "floating" element.

[TimRoe]

I think Narin had already suggested it somewhere, but also suggesting having the offset for non-Nav screens set in the app theming instead of having so many hard coded 0's. Make it much easier to change in the future if it's desired vs updating ~25 spots.

[oddballdave]

Agree, I will make this change once we get resolution on the navbar spacing.

[TimRoe]

Approving for my part (still needs app team approval) based on the changes.