Spinner does not cover Dialog about design-system HOT 6 CLOSED

Reviewing the use cases for the current Spinner, it made sense to me why it wouldn't show over a Dialog. So I'm good with that. Thanks!

from design-system.

Hi @dmethvin-gov!

The spinner component that we have in the design system is meant to be flexible and simple enough to use in any context that the application needs—from inside buttons to being a placeholder for content. It would be outside the scope of its design to force it to display above everything else, and in fact we can't for the very reasons you've shown with your example (because browser-made dialogs render above everything else). This is an example of something we'd place in the realm of application responsibility.

But perhaps I'm not understanding the request. What is it you're trying to do exactly? This is not a pattern we've seen used so far in healthcare.gov or medicare.gov or any other apps that we've seen using the design system.

from design-system.

No, you understood correctly. I have a dialog and want a modal spinner to appear when something in the dialog causes it to need to appear. We don't want the user to interact with the dialog while it's in the middle of exchaning data with the server, for example.

I see your point about the spinner though, since the examples show it spinning on a button and in that case it should be contained by the element it's within. So our use case isn't a good match for it. We'll need to create a custom component for it.

from design-system.

Hi @dmethvin-gov 

Before responding, I want to confirm my read on the interaction presented

On submit, the spinner appears over everything on the page in order to disable any interactions on the page until the data status returned changes the state?

this could be the data submitted was a success, or it could be failed- try again.

What you are after is interaction guidance that does not disrupt the flow— is that correct?

from design-system.

@brentschneider Your description sounds accurate. The data submit/fetch are async and there is a central location in the app that manages whether the spinner needs to be shown or not. The user may take actions in the dialog that require remote data. In that case, the data in the dialog may need to be changed and we want to ensure the data user doesn't, for example, start editing a field that a few seconds later will be updated from the server.

from design-system.

Dave, I saw you closed this issue on GH.
Did you want to continue the convo over in the #cms-design-system-team slack?

from design-system.