Snapshot create confirmation/feedback

[david-crespo]

Really there are two issues, I think. In practice the snapshotting will not be instant (you should probably add a couple of seconds delay to the mock endpoint), so there's the feedback on completion, but I also think there's a general "ok what is happening here, what is being created, what is it called, where does it end up?" that might not be answered by the completion confirmation. Or at least, even if we do give some of that info at completion time, and make it easy, for example, to click through to wherever the snapshot lives, I think the user wants some of that info before they click the button so they can feel confident it's what they want to do.

_Originally posted by @david-crespo in https://github.com/oxidecomputer/console/pull/1204#discussion_r989212083_

[david-crespo]

Lower priority end of MVP list because snapshot creation is a very weird and abrupt experience without this.

[askfongjojo]

I think even an acknowledgement of the request made (including in the message the name of the snapshot being created) will be very helpful. Besides a better user experience, it'll likely help reduce the number of unnecessary retries when user thinks the request has not been received. Currently, repeated snapshot requests may cause sagas to fail as explained in RFD 419.

[david-crespo]

Plopping an extra toast in there when we start is very easy but also terrible. @benjaminleonard @paryhin help!

@@ -95,6 +95,7 @@ export function DisksPage() {
     {
       label: 'Snapshot',
       onActivate() {
+        addToast({ content: 'Creating snapshot', variant: 'info' })
         createSnapshot.mutate({
           query: projectSelector,
           body: {

[david-crespo]

Couple of thoughts after doing #1774. One, obviously whatever we do here should apply to both disks list and instance disks list. Two, I think there are three different stages here that we can give the user feedback about. There's completion, which we already have, but before that there is confirmation prior to initiating the snapshot, and there is a loading/in progress state indicating that the snapshot is happening.

I could go either way on whether we need a confirmation modal — I think the bigger problem is that there's no feedback that anything is happening. But I do lean toward confirmation. It could be a little form in a modal where we show the generated name and give them a chance to change it, for example. Then we could show the loading and done states right in the modal too, like with image upload.

[benjaminleonard]

I could go either way on whether we need a confirmation modal — I think the bigger problem is that there's no feedback that anything is happening. But I do lean toward confirmation. It could be a little form in a modal where we show the generated name and give them a chance to change it, for example. Then we could show the loading and done states right in the modal too, like with image upload.

I came to the same conclusion on using a modal. I can imagine the toast logic getting a little bit awkward, for example how do we handle the lifetime of the creating snapshot toast.

A confirmation modal is more scalable, lets say we have a bulk action in the future that lets you snapshot multiple disks at once, we can reuse the same pattern.

[paryhin]

I think we have toasts with a progress bar? More sophisticated notifications with states may be the answer.

Modal is blocking user from doing anything else. It is ok if the action is fast, but if we envision to use it for bulk actions or something that may take time, we may want to have a less obstructive pattern. If we do go with the modal, ideally we want to let the user close it and continue providing feedback via notifications.

[askfongjojo]

Fixed in #1815