Display uniqueness requirement for name and disable save if not met

[CarolineDenis]

Fixes #4150

[CarolineDenis]

Do we want to keep the warning also on the list behind the dialog or now that we have it in the form we're good?
@grantfitzsimmons

[maxpatiiuk]

this is a good first try, but can you try to improve it:
could you try using the useValidation hook to create a validation error on the name field when there are duplicates?

benefits:

• the error would be connected to the field that caused it - making it even easier to understand how to fix it
• if user tries to submit the form, the invalid field will get focus again and error message will be displayed shown again automatically
• better screen reader/accessibility support

--

as far as having the validation behind this dialog, some thoughts:

• take a look if something in the code would go terribly wrong if name is not unique (i.e terribly wrong means a crash, or loss of data; not terribly wrong is formatter that is used is not the one user was expecting)
• we are adding the UI for editing this, but in the past people might have hand-edited these files, so there could be mistakes that we have to catch an present as soon as possible
• on the other hand, it would be annoying to have to fix all of the mistakes before you can continue on with your work just because some test formatter you are no longer using has a duplicate name
• having the same check in both places is redundant (more code, and also a bit distracting when the error appears in both places)

given that UI is not letting user create new mistakes, that alone is good enough and forcing them to fix previous mistakes may be too forcefull.

[grantfitzsimmons]

Do we want to keep the warning also on the list behind the dialog or now that we have it in the form we're good?

If the error appears in the dialog, we can remove it from behind. Our goal is to prevent the user from closing the dialog until the issue is resolved, right? In that case, we might want to not let the user close the dialog until it's resolved.

[maxpatiiuk]

looks great!

isn't it cool how few lines of code it takes to build a fully-accessible and user-friendly validation, that is also quite robust?

[grantfitzsimmons]

You can bypass this by clicking on the space outside of the dialog

Screen.Recording.2023-11-01.at.9.26.17.AM.mov

[maxpatiiuk]

@grantfitzsimmons

You can bypass this by clicking on the space outside of the dialog

I think forbidding closing the dialog is worse UX than accidentally creating two formatters with the same name and thus seeing wrong one being used on the form

What if user wants to briefly look at something behind the dialog? (i.e some other formatter, or a notification they have just received)

The role of validation in this dialog in my opinion is not bulletproof data integrity, but guiding the user towards right choices (guiding, not holding under the gun)

---

but I am not a user so feel free to pick either way

[CarolineDenis]

@grantfitzsimmons

You can bypass this by clicking on the space outside of the dialog

I think forbidding closing the dialog is worse UX than accidentally creating two formatters with the same name and thus seeing wrong one being used on the form

What if user wants to briefly look at something behind the dialog? (i.e some other formatter, or a notification they have just received)

The role of validation in this dialog in my opinion is not bulletproof data integrity, but guiding the user towards right choices (guiding, not holding under the gun)

but I am not a user so feel free to pick either way

The user could drag the dialog on the side otherwise?

[grantfitzsimmons]

@maxpatiiuk If we disallow saving with duplicate view names, that would be acceptable. Otherwise, it's preferable to require them to resolve the issue before dismissing it.

[CarolineDenis]

@maxpatiiuk If we disallow saving with duplicate view names, that would be acceptable. Otherwise, it's preferable to require them to resolve the issue before dismissing it.

I suggest we keep it like this then and if the user needs to see what's behind, he would move the dialog

[maxpatiiuk]

sounds good, just pointing out that the ability to bypass validation might be a feature and not a bug

[emenslin]

This works and you can no longer close the popup if it has the same name either by using the close button or by clicking out of it. Can still move the popup though if the user did need to see something behind it.