🐾 Add a fast Create Plan page - step 1

[rszwajko]

Implements #801

Initial state

Plan name edited

[yaacov]

nice 👍

added comment in #801 (comment) for separation of #801 into steps

[yaacov]

@rszwajko , can you update the title and description to indicate this is a PR for the first step, "Add fast migration page" may indicate this PR actually adds the complete fast migration form ?

[rszwajko]

@yaacov
Changes in the recent force push:

1. transfer VM objects via context (previously only the IDs)
2. treat context usage as internal implementation and hide it behind useCreateVmMigrationData() hook
3. implement part of the spec provided in this comment
   • [name of source provider]-[short hash]
   • source provider as a resource link with label

Parts not implemented (yet):

1. switch from form-based create page to template-based (similar to edit/details pages) - this requires some more though: first details-like page assumes that the resource is already valid and just maintains this invariant. Second problem is with cross-field dependencies - some user action will invalidate multiple fields i.e. changing the target provider invalidates also the namespace and the mappings.
2. displaying the VMs as a table - this may break the flow we can try to teach to the user - if user can see the same table as on previous screen then why to have a second screen in the first place? why not allow de-selecting and selecting the VMs?

[yaacov]

switch from form-based create page to template-based (similar to edit/details pages

inmplementing the "create and edit" button is the last step, no need to do it now

this requires some more though: first details-like page assumes that the resource is already valid and just maintains this invariant.

yes, it's "create" the plan is valid and created, "and edit" you go to the details/edit page

Second problem is with cross-field dependencies - some user action will invalidate multiple fields i.e. changing the target provider invalidates also the namespace and the mappings.

why will you want to change the target, that is not part of the spec

[yaacov]

displaying the VMs as a table - this may break the flow we can try to teach to the user

that is why it need to be a "lateral" flow, a user will not open the vm list unless they need what to check somthing, "lateral" is somthing outside the regular flow - e.g. a modal or a side pane, the user see it check they didn't make a mistake in the last phase and continue.

if user can see the same table as on previous screen then why to have a second screen in the first place?

they will not open the vm list unless they wnat to check somethig, but if they do want to check, they will not need to leave the create form, the quicly see the list and then close the modal or side pane

why not allow de-selecting and selecting the VMs?

the source, and vm list are the unique featuers of this plan, you should not touch them, if you want to change them, cancel this plan and start a new one with other source and vm list

[yaacov]

Things to finish
a. remove description field (not in "fast create flow")
b. show only "[N] vms selected" (we can leave the side pane with the vm list to later step)
c. remove current target provider and target namespace because they will need hooks to get them, drop down implementation, and some logic to indicate to users that once you choose them you reset the mapings.
we can move the implementation to the next step

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[rszwajko]

@yaacov
implemented most of your suggestions - the detail view for the VMs needs to wait for the next step (unless you want to postpone this one).

as for the discussion above:

this requires some more though: first details-like page assumes that the resource is already valid and just maintains this invariant.
yes, it's "create" the plan is valid and created, "and edit" you go to the details/edit page

just to be clear the plan displayed on the screen won't be valid in all cases

Second problem is with cross-field dependencies - some user action will invalidate multiple fields i.e. changing the target provider invalidates also the namespace and the mappings.
why will you want to change the target, that is not part of the spec

It's part of the spec. You explicitly requested an editable drop down.

regarding VM details representation:

that is why it need to be a "lateral" flow,

OK so displaying table in the standard view is not possible. We could display it in list view (see below). The view is automatic for small spaces.

[yaacov]

lgtm