Proof of concept ideal snackbar results/User release from API Comm

[dumathane]

Proposed Change

Pick an endpoint (preferred name?) to model the proposed snackbar/user release paradigm we are contemplating for app wide distribution. We will need to include in this ticket the long term solution for avoiding 'dismissOnNav' for error snackbar responses described in 9618 (read section 'Can we tinker with our snackbar dismissal code to ignore snackbar dismissals from navigation if the snackbar itself is a failure message?'). After that, move the snackbar presentation and user screen nav to not rely on api response, also described on the above ticket in the 'How can we fix this callback issue?' section. Finally we'll want to demo the branch and invite UX and Accessibility to vet the change.

Questions for vetting meeting:
-should we force a 'sending' screen for arbitrary amounts of time to indicate attempted comms?
-should we indicate to the users in some other way that their request is processing?
-Or is this working version enough?

Why Should We Prioritize?

Will drive how we communicate with API's and display snackbars/processing app-wide.

Coding Time Estimation

3

Testing Considerations

Need to make sure this method does not create any sort of failure to display a snackbar, on success or failure or network issue.
Stacking snackbar sends should also be tested.

Checklist

• Add the relevant team label (Health, global, design system, API, Qa and Release etc.)
• Attach to ticket to the relevant Team Tech Debt Epic epic (old frontend engineering epic is no longer in use as each team is managing their code's technical debt and code upkeep work)

[alexandec]

Another thing to check: what happens if the user presses the button that fires off the request, then presses it again, potentially a few times? If there's no loading screen, it would likely be possible.

[timwright12]

removed the code upkeep label as this is a larger ask and will need UX