Freeze the Create Instance form when submitting, so the user can't make post-submit edits

[charliepark]

Fixes #1613

In #1613, we see that it's currently possible for a user to edit the Create Instance form after they hit the submit button, and — as the process can sometimes take a bit of time — that this can create confusion in the user about whether last-second edits will be accepted, and, maybe more problematic, a confusing modal appears asking the user if they want to navigate away from the page.

This PR disables the form fields when the user hits the submit button, so edits can't take place. It also disables the tabs that would otherwise allow the user to switch between instance sources (silo vs. project) and switching between the pre-configured sizes for CPU and storage.

One thing I'm not sure about how to elegantly handle is that we have it setting the useState value to isSubmitting when the form is submitted, but there isn't a way to re-set that to false if something blows up in the process. I suspect there's some sort of event that happens when an error is thrown, but am still looking into that.

The only other thing to call out, I think, is that I had to remove a CSS class, which normally affects a selected-but-disabled form field's text color. Note the removal of peer-disabled:text-secondary in the code below.

With that class present (as it is currently), when the form fields are disabled, the selected option looks like this:

By removing the class, the disabled state for the selected option …

… looks more like the normal state for the selected option:

(with the disabled state (top) having slightly thinner outlines)

I believe this is doing what we want, but know there are other situations where removing that class might not be what we want? "Selected but disabled" is a pretty rare situation, though, so I think this class possibly fine to drop.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
console	✅ Ready (Inspect)	Visit Preview	Jan 19, 2024 0:20am

[david-crespo]

Look great overall, thanks for doing this. I also wondered about how to do a setSubmitting(false) at the right time and I wish I had an easy answer for how to do it. First thing that comes to mind is wrapping the mutate in a try/catch and doing it in the catch? Kinda ew, and you might have to change it to await createInstance.mutateAsync(...). Another way would be to use a useEffect that looks for when createInstance.error goes from nothing to something.

[david-crespo]

Very nice! Not as complicated as I expected.

Not sure about the peer-disabled:text-secondary thing. @benjaminleonard?

[david-crespo]

Ooh, there is an isSubmitting on RHF formState. Worth checking if you can use that instead of the explicit state variable before merge. If it doesn't have the desired behavior (e.g., fails to go back to false as desired on submit error).

https://react-hook-form.com/docs/useform/formstate

[david-crespo]

Sorry, never mind on that. It doesn't do what we want. I set the request to take 4 seconds. If you look at the log before and after the 400 comes back, you can see it flips back to false really fast, and then the 4 seconds go by while formState.isSubmitting is false rather than the desired true.

[benjaminleonard]

I think we're okay on the peer-disabled:text-secondary – I'll take a look and can follow up if there's an issue.