I'd like confirmation from @jameskoster and @mirka but, IIRC, this is not something we want. This prevents users from closing the modal unless all values are valid.

The rationale is that users may run into situations where they can't close the panel. Form example, a form that contains empty values and, once loaded, it couldn't be closed unless the user fills them all. DataForm doesn't handle saving, there's a consumer layer that needs to deal with that, and that'd a better point to handle this logic.

Additionally, even for saving a form, @mirka argued (failed to find the link, sorry), that it'd be better to let values to be submitted and the server respond.

With my current understanding, this would need to be reverted.

This prevents users from closing the modal unless all values are valid.

Isn't the cancel button enough?

Not exactly what I was looking for, but #71412 (comment) may be helpful to understand the rationale.

Thanks for sharing @oandregal! It seems there is tons of context needed behind many things in these parts. Let's revert this.

Nik prepared a revert #73367 (just for context for folks coming to this thread)

Right, I think what we want here is a standard

and type="submit" button pattern. These two pieces are what prevent a form from submitting with invalid fields.

To be clear, we want to keep the submit button enabled so the form element can handle the blocking.

👍

@mirka I understand this is the flow we want for the component that uses DataForm. The case here is a bit different: DataForm is rendering a panel layout, that opens a modal to edit the values. The question is what happens with that modal's save button if some value is invalid.

Or are you saying that we should also use that flow for the modal?

I want to make sure there's clarity on this because my understanding was the opposite (we don't do anything special for the modal, just let user apply the values, and we handle it at the form level as you suggested).

This is surprisingly complex haha. Since the modal doesn't submit the form trapping the user feels a bit intrusive, almost like not allowing them to tab away from an invalid field in the 'regular' layout.

That said, there are a few quirks with this approach. Observe the following video:

"Order" is a number input. There's no indication the letter-based value I input is invalid because of when we validate. Even if we visually indicate invalid fields when the modal is closed (which we should), that wouldn't capture this scenario because the invalid value is stripped meaning the field is no longer invalid. It feels like I was able to successfully set 'abc' as the Order. I suspect we'd need quite a bit of logic to make a flow like this not feel broken.

On the other hand, there are situations where trapping could lead to really awkward experiences. Imagine a form with a required "I agree to terms" checkbox. Once you open the modal it wouldn't be possible to close it until you check the option, effectively forcing the user to agree.

Neither approach seems perfect. It seems a case of choosing the 'safest' one.

Even if we visually indicate invalid fields when the modal is closed (which we should)

Yeah, this is also related to #72321

I'm demonstrating two patterns in #71282:

• Prevent closing on an invalid form, no matter what.
• Prevent closing on an invalid form, only when the user explicitly hits the save button.

What I've been suggesting is the latter ("Validate in modal" story).

@oandregal I discussed this with @jameskoster @jasmussen @fcoveram today, and we agreed on the "validate in modal" pattern in #71282. Some additional subtleties here are to disable shouldCloseOnClickOutside and isDismissable on the modal, to make the cancel intent more explicit.

We also considered disabling shouldCloseOnEsc, but we don't have a strong conviction about this one way or the other, as there are pros and cons. I think we can start by leaving it as is, and see how that works in practice.