Move IP Pools edit form to view page

[charliepark]

This PR moves the "Edit IP pool" side modal from the IP Pools list page to the individual IP Pool view page. In some ways, this makes more sense with our existing URL schema, as the edit URL is http://localhost:4000/system/networking/ip-pools/:pool/edit, so is conceptually already a child of the pool itself, rather than the list.

We start with an additional actions button in the header …

… which leads to the side modal on the view page …

The delete button is disabled for IP Pools with existing ranges …

… but is enabled for IP Pools that can, in fact, be deleted:

Closes #2353, and if we feel this is a good pattern to replicate, we can roll it out to other resources as well.

[vercel]

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

Name	Status	Preview	Updated (UTC)
console	✅ Ready (Inspect)	Visit Preview	Aug 30, 2024 10:03pm

[david-crespo]

would add a comment explaining why the difference. also the navigate line is the same in both cases, you can just do navigate(pb.ipPool({ pool: _pool.name }))

[charliepark]

I realized that we don't actually need the navigate function when the description has changed; just an onDismiss(). Have added a comment on the first navigate (when name has changed), though.

[david-crespo]

Why the difference in invalidations?

[charliepark]

We can maybe drop the View one; will walk through the various elements of it.

The ipPoolList invalidation is needed because of the presence of the IP pools in the header nav. Without that invalidation, even though the navigate takes us to the new page and the header is correct, the dropdown has old data (this shows ip-pool-1 renamed to ip-pool-updated, without the invalidation:

Adding queryClient.invalidateQueries('ipPoolList') corrects that:

The other invalidation would be useful if the page showed the description (the only form fields in the "Edit IP pool" form are name and description), but since the description is not shown on the IP Pool page, we can actually just remove that invalidation. We'd need to add it back in if we decide down the road to show the description on this page.

[david-crespo]

If so, isn't the ipPoolList invalidation needed regardless of whether the name changed? And on the view one, I think we should always do the corresponding invalidation even if we aren't relying on it directly yet. Leaving out an invalidation was how we got this head-scratcher #2392 (comment).

[charliepark]

Sure, getting the View invalidation back in makes sense, in case we add descriptions in there.

For List, my thought was that it was only needed when the name changed, as the description changing didn't impact that navigation dropdown, so it wouldn't be necessary to invalidate that; every time I manually checked the list page after editing the description it seemed to show the updated description state in the table of IP pools. But perhaps there's an aspect of the List invalidation I'm missing. Will move the it up a level.

[david-crespo]

Ah, I get it! I didn't realize we were already using the perfect route on the list view, which was weird. So we can keep the edit button on the list, and it goes to the same route, but that route now shows the detail view with the form. Very nice. I do like this pattern. I think we should do the same to the other pages in a separate PR.

Looks good, just one change suggested, and the onSuccess thing is still not clear enough on the way.

Something we can look at in a followup is making these real links where possible like I did in #2343 for the settings link. It's more accessible and lets you middle click the links to open in a new tab. The annoying part is that we're using helpers to construct the row actions and the more actions dropdowns, so those need to modified to allow a different kind of item that just has a URL instead of an onActivate callback. I tried that in #2351 and it didn't feel worth it for like 3 links, but now there will be more.

[david-crespo]

wonderful

[david-crespo]

I think this is equivalent since onDismiss just does the same nav.

Suggested change

	queryClient.invalidateQueries('ipPoolList')
	if (pool.name !== _pool.name) {
	// as the pool's name has changed, we need to navigate to an updated URL
	navigate(pb.ipPool({ pool: _pool.name }))
	} else {
	queryClient.invalidateQueries('ipPoolView')
	onDismiss()
	}
	queryClient.invalidateQueries('ipPoolList')
	if (pool.name === _pool.name) {
	queryClient.invalidateQueries('ipPoolView')
	}
	navigate(pb.ipPool({ pool: _pool.name }))

Is the reason for the conditional that you were getting that error flash on nav? Otherwise this would work, wouldn't it?

queryClient.invalidateQueries('ipPoolList')
queryClient.invalidateQueries('ipPoolView')
navigate(pb.ipPool({ pool: _pool.name }))

Or maybe navigate first I guess?