Add floating ips to instance create

[charliepark]

Fixes #1979

This PR adds the ability to attach a floating IP (or several) to an instance during the creation process.

There are a few slight differences from the design in Figma …

… namely the dropping of the checkbox, though this brings it into alignment with the "attach disks" flow. Essentially, the button triggers the modal, which allows the user to attach floating IPs. If they remove all of the floating IPs, none will be attached.

[vercel]

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

Name	Status	Preview	Updated (UTC)
console	✅ Ready (Inspect)	Visit Preview	May 24, 2024 11:17pm

[charliepark]

One other visual thing to call out is that the "Attach floating IP" button doesn't have the + icon on it, as none of the other buttons (namely: create new disk and attach existing disk in that form have the + button. I'm open to adding it here, but wanted to call out that it would be distinct from the other buttons.

[charliepark]

Added an empty state for when the project has no floating IPs:

Then, when floating IPs exist and are available to be attached:

Then, when they've been committed to the instance (and will be attached when the instance is created):

[benjaminleonard]

I like that as a pattern. We might want to explain why no floating IPs are found though; either none exist or all the ones that do are already attached to an instance right?

[david-crespo]

We could add/are maybe planning to add a button that lets you create a floating IP right there, and that would cover it. The biggest issue for me is making clear which operations actually create stuff (e.g., floating IP, SSH key) and which are queuing things up to be created as part of instance create (e.g., disks). I wonder if the visual treatment could convey that somehow, or we can just put it in an info box at the top of the forms.

[david-crespo]

Should this be available IPs? You still can't do anything if floating IPs exist but are taken.

[charliepark]

The idea here is that if the list of floating IPs coming in from the API query has 0 items, we show them the empty message; if there are any items in that list at all (attached or not), we show them the Attach floating IP button. That button then is either disabled (no available floating IPs) or enabled (at least one available floating IP). But the disabled message on the button would indicate that no floating IPs are available. Let me know if that didn't make sense, or if there's an alternate flow you would prefer to see there?

[david-crespo]

I think what felt funny to me is that within this form, I'm not sure the distinction between "there are no floating IPs at all" and "there are floating IPs but they're all taken" is meaningful to the user. We are treating it as meaningful by representing those two states differently. Here are all the states:

State	UI representation
no floating IPs at all	empty state like the tables
floating IPs exist but are attached to other instances	disabled attach button
floating IPs exist, none available, 1+ attached to this instance	mini table + disabled attach button
floating IPs available, 1+ attached to this instance	mini table + enabled attach button
floating IPs available, none attached to this instance	enabled attach button

I'm wondering if we should give the first two rows the same representation. This can't matter that much because the user is never going to see both versions next to each other and wonder why they're different, but I'm finding it helpful to think through it.

[charliepark]

If we consolidated them, which of the two treatments feels better to you? Just the disabled button (with no empty state)? That would certainly be less "involved" on an already pretty-lengthy page. Though the empty state does call your eye to it, and for something as foundational as a floating IP, I could see it making sense to have it called out like that.

[david-crespo]

I agree there is something nice about the full empty state almost inviting the user to create one. @benjaminleonard since you weighed in before, what do you think?

[david-crespo]

I just accidentally found an incredible and strange behavior that is probably not caused by anything specific to this PR, and it does it in both FF and Chrome:

1. Go to instance create (preview deploy)
2. Do NOT enter an instance name. scroll down and attach the one available floating IP
3. Hit submit. You get an error because name is empty and it takes you to the name field.
4. Type in any name
5. Press enter

Instead of submitting the form, you just removed the floating IP because the delete button was focused. WTF! Probably an easy fix, but how exciting.

[david-crespo]

I think this is ready to go. Only thing I can think of to add is a couple of lines in the e2e test to test that remove is hooked up.

[charliepark]

Re-running that failing test, as I don't think it's related, but we'll need to look into it if it keeps flaking.

[david-crespo]

That flake was weird — it looked a lot like one I got on the button type branch, where it wasn’t a flake. I noticed another case today where state seemed to be leaking between GH actions runs — a lint rule failed on a branch that should not have that rule on.