[UI v2] Adds Create or edit dialog for concurrency limit

[devinvillarosa]

1. Adds Switch component using cli
2. Adds Creating or Editing a global concurrent limit using hook logic. (Only manually tested creation)
3. Adds UI for creating a new global concurrent limit

Will add tests when testing for the entire page functionality. Similar to variables.test.tsx. I think our hook tests in hooks/global-concurrent-limits.test.tsx is suffice for now for confidence

Checklist

• This pull request references any related issue by including "closes <link to issue>"
  • If no issue exists and your change is not a small fix, please create an issue first.
• If this pull request adds new functionality, it includes unit tests that cover the changes
• If this pull request removes docs files, it includes redirect settings in mint.json.
• If this pull request adds functions or classes, it includes helpful docstrings.

Related to #15512

[desertaxle]

I had some trouble wrapping my head around this on the first couple of reads. This suggestion I think it a little more clear, but I'm open to alternatives.

Suggested change

	const [openAddOrEditDialog, setOpenAddOrEditDialog] =
	useState<AddOrEditDialogState>({
	open: false,
	});
	const [addOrEditDialogState, addOrEditDialogState] =
	useState<AddOrEditDialogState>({
	open: false,
	limitIdToEdit: undefined
	});

[devinvillarosa]

Based on your comment below here: https://github.com/PrefectHQ/prefect/pull/16248/files#r1873864935, this makes sense.

I was trying to represent the dialog state to:

1. is it open?
2. Should it open with a limit to be edited?

[devinvillarosa]

Updated in latest push.

Simplified it to it just keeps track of it being open.
I removed the selected row logic and will handle it when doing the table

[desertaxle]

We might want to revisit this once the table is created. We should be able to have the table put the full data in a callback, which would negate the need to have a .find call.

[devinvillarosa]

I'll keep an eye out for it, because this approach is to help eliminate duplicate state - which can lead to UX bugs.

eg problem case for duplicating state:

1. UI gets list of data from useSuspenseQuery.
2. UI duplicates selected data into a useState.
3. useSuspenseQuery refetches, and updates its state of that selected data. (from some async event). The UI is now working with stale data.

When using this memoize approach.

1. UI gets list of data from useSuspenseQuery.
2. UI keeps track of the selected data by id via useState.
3. Selected data is found by .find().
4. useSuspenseQuery refetches, and updates its state of that selected data. (from some async event).
5. the selected data that calls .find() is ran because the useMemo dependency has changed from the async event. The UI is now working with the updated data source

Here's a good blog that goes in detail about it: https://blog.webdevsimplified.com/2019-11/never-store-derived-state/

[desertaxle]

That makes sense. I don't think we'll need to worry about stale data from the table because we can directly pass in the data from our query to useTable and retrieve the original data for the row to avoid working with duplicated data.

Plus, since we're using this data in a form, I don't think we want it to change if a new update comes in since that means the form values could change while the user is editing a concurrency limit.

[devinvillarosa]

oh nice, that makes sense

[devinvillarosa]

I'll update that when I implement the table next

[desertaxle]

LGTM!