How to handle mutations triggered modal action

[Mohammer5]

Discussion from slack about

• Where to show loading indicators when using a modal
• Blocking vs non-blocking UI
• Optimistic updates / useSWR

Original conversation from slack:

Jan-Gerke Salomon
I'm adding the last missing tests to the sms config app and now every section has a delete confirmation modal that pops up when you click the delete button.
I was wondering if it'd make sense (UX-wise) to keep showing the delete confirmation dialog and prevent interactions until the delete api request has responded and either close the modal on success or display the error message inside the modal on failure.
What do you guys think about that? (#consistency-across-apps) (cc @joe)

Joe Cooper
It’s a good question! There isn’t a documented approach for this and it does depend on the context. I’m not immediately confident which approach to take here. I’ll have a think about it and get back to you.

Jan-Gerke Salomon
👌

Joe Cooper
Alright, I had a sit and a think about it over a ☕ I’ve come to some draft guidelines that, after review, will be included in the modal usage guidelines.
So, when asking the question “Where to display errors associated with modals?“, I think we can group most situations into two buckets that produce the following guideline:

• If the error or problem is with content inside the modal (for example, an invalid field, an empty required field), show the error inside the modal.
• If the error occurs once a valid modal has been submitted (for example, server-side validation), show the error on the page once the modal has been closed. (edited)
  So, in the case you described above, I would say that displaying an Alert bar of type critical after closing the modal would be appropriate. The modal can be dismissed because all of the content/inputs/actions inside the modal are valid, it’s what happens outside of the modal that produces the error.

Jan-Gerke Salomon
Ah yeah, that makes a lot of sense 👌

Joe Cooper
Thanks for bringing it up, this is a great guideline to include in the docs! 👍

Ismay Wolff
While the delete request is pending wouldn't you guys prefer showing the dialog? To me that felt most natural. That way the user has feedback that something is pending. When the request is sent I set the button to blocked and loading. Then when the request resolves/rejects I remove the modal and refresh the data. (edited)
And for any notifications I'd then also use the alert. (edited)
I've also done it that way because otherwise you'd run the risk of showing incorrect/outdated info. Like, until it's been deleted, do you show or hide the item that has been deleted? (edited)

Joe Cooper
I’d say it depends on the use case here, including the risk of displaying incorrect or outdated info. One option in the use case you describe is to disable the items that are pending delete. That way, the user can still interact with the application, but not with items that have a pending action.

Ismay Wolff
Does get fairly complex that way though
Then you'd have to make sure that your state can't get messed up by ensuring that none of the possible actions can conflict
With a 'blocking' action all you have to consider is what happens in the current action.

Joe Cooper
Yeah, there is the risk of that. In cases where the risk of state problems are high, showing a loading spinner that blocks the modal content is acceptable. Ideally, a user would be able to cancel this blocking action if it is taking a long time, or if they change their mind.

Jan-Gerke Salomon
I think I'd prefer to just cover the section in question with a loading spinner (e. g. cover a table of items with a loading spinner and a transparent background that prevents interaction).
Then the modal can be closed after the action has been clicked (which makes sense to me) & the content that's being deleted can't be interacted with until the request resolved (either successfully or unsuccessfully)
Ideally, a user would be able to cancel this blocking action if it is taking a long time, or if they change their mind.
This is dangerous territory because it gets very complex (what happens if the delete requests succeeded but the user aborts the request before it returns its response)

Ismay Wolff
Yeah, there is the risk of that. In cases where the risk of state problems are high, showing a loading spinner that blocks the modal content is acceptable. Ideally, a user would be able to cancel this blocking action if it is taking a long time, or if they change their mind.
That might be possible. We do have cancelable requests in the app runtime. I've never triggered that on purpose though, so no idea how it'd work in practice. Currently I believe they're canceled on unmount only. (edited)
(what happens if the delete requests succeeded but the user aborts the request before it returns its response)
Yeah, yeah I also wouldn't know.

Jan-Gerke Salomon
I think aborting requests is only a good idea when trying to retrieve information (e. g. in a search input that fires a request after the user enters sth)

Ismay Wolff
Yeah I have no idea tbh

Jan-Gerke Salomon
when interacting with data, aborting requests can cause non-verifiable false-positive/false-negatives (in lack of a better term) because of the nature of async requests
that's off topic though.. What about

think I'd prefer to just cover the section in question with a loading spinner (e. g. cover a table of items with a loading spinner and a transparent background that prevents interaction).
?

Joe Cooper
Yeah that seems like troubled waters. I think the solution @Jan-Gerke Salomon suggests, disabling the entire table, works too. That keeps the rule of “dismiss a modal if its contents are valid” and adds another rule of “disable interface elements that are pending and should not be touched”
That would be the guideline for the use case “what if the modal action affects some visible interface elements?”

Ismay Wolff
I think that with the app platform that gets difficult though

Jan-Gerke Salomon
why so?

Joe Cooper
Sometimes the modal action (a delete, for example) doesn’t affect the interface, and nothing would need to be done unless there was an error.

Ismay Wolff
Well I'm thinking, say you've edited something. You'll have to manually inject the edited data into the app then. Or I guess you could show the outdated data and indicate that it's pending.
But I can imagine that there are complex edge cases here. I'm leaning towards the simple, predictable solution.
Maybe it's doable though. We could try it out somewhere.

Jan-Gerke Salomon
by simple you mean: keep the dialog open until the request is done?

Ismay Wolff
Yeah
That seems the simplest to me from a code perspective
A little bit more synchronous.
I guess maybe SWR could help us out here, but I'm not sure (edited)
I guess what I'm trying to say is that I'd say there's a cost to having the non-blocking ui. We'd need to consider whether that's worth it.

Jan-Gerke Salomon
I guess it depends a bit on how you organize code and on what level you do requests (e. g. if requests are done by the "root view", then it should be fairly straight forward, just a bit more work). If these requests are made by the modal component itself, things get a bit more tricky (but I'd should only be done with modals that contains forms, etc, and then we want to display the error inside anyway)
I guess it's a bit more work to have "having the non-blocking ui", but it should still be fairly trivial work

Ismay Wolff
Yeah you can be smart about the costs, that's true. They're still costs though.
And trivial work in my experience is never as trivial as it seems
But who knows, it would be nice if it were of course, and it might very well be. Still. We have a finite complexity budget, and the question still remains whether this is what we want to spend it on. (edited)

Jan-Gerke Salomon
I'll let you guys decide that. I don't see too many problems with closing the modal and then block just the effected api, feels like we're trying to prepare for something that rarely happens

Ismay Wolff
I agree that it's a nice pattern btw. Just mean to clarify that I feel we shouldn't just establish a pattern without considering the potential extra work that we might take on (at the moment I couldn't say for sure yet, I haven't tested it).

Austin McGee
I guess maybe SWR could help us out here, but I'm not sure
Yes, SWR supports "optimistic updates" which will fire the request and update the value in the cache (delete it in this case) so the UI shows it as removed. Then if the request fails, it rolls back that optimistic update.
This would be super slick to add to app-runtime (i.e. with SWR) but it's a bit complex to do with our complex non-normative data model. Very closely tied to normalized data caching (in-memory and also offline) but it's going to take some thinking.

I don't see too many problems with closing the modal and then block just the effected api, feels like we're trying to prepare for something that rarely happens

While it may be trivial to do this on a case-by-case basis, it's important to keep in mind that this approach would introduce a lot of similar boilerplate code intermingled with other component display logic, so it could significantly increase code complexity and maintenance burden across our entire codebase.
For this reason, I'd be in favor of the blocking modal approach, as it can be done in one place (maybe even a reusable "action modal") and/or use of non-blocking alerts. If we later add optimistic updates to the runtime, we can more easily update the action modal implementation in one place and roll it out to all apps at once.

[cooper-joe]

For clarity, there is an approach included that I think provides the best user experience. However, after following the discussion here, I think it is necessary that the technical implementation be finalized before the user experience guidelines are written up. There is, of course, an ideal solution, but we will provide guidelines for the realistic, working solution. So, once there is a functional spec in place I can write up the design implementation guidelines 👍

[Mohammer5]

I don't see too many problems with closing the modal and then block just the effected api

I thought a bit more about this..

Do we want to block the navigation as well?
We'd always have to remember to use the onError option to display an error in an alert bar, otherwise the error might never be shown when the user navigates somewhere else because the component that would handle the error returned by the hook will unmount (or we disable the navigation too, but that requires a lot more non-trivial work)

We have a finite complexity budget, and the question still remains whether this is what we want to spend it on.

I guess this is a very fair point as well. Regardless of the maintenance burden, I most likely underestimated the cost of this yesterday

---

For this reason, I'd be in favor of the blocking modal approach, as it can be done in one place (maybe even a reusable "action modal") and/or use of non-blocking alerts. If we later add optimistic updates to the runtime, we can more easily update the action modal implementation in one place and roll it out to all apps at once.

I'm on board 👌