This repository has been archived by the owner on Jan 12, 2023. It is now read-only.
Bug 1947519: Track migrate/cutover request state locally to the button instead of at the plans page level #537
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1947519
Currently when clicking the Start, Restart or Cutover buttons on a plan, all the action buttons for all plans turn grey while the CR is being created/mutated. This is because there is one query hook at the plans page level for all plans, since we display any errors with these requests at the top of the plans page. This is confusing because greying out all the buttons on unrelated plans looks weird, and because it isn't apparent that the action is working.
This PR factors out a
MigrateOrCutoverButton
component which contains its ownuseCreateMigrationMutation
anduseSetCutoverMutation
hooks, allowing us to track that request state at a per-plan level. To achieve the centralized error container we had before, a React Portal is used which allows the error child of the button component to be rendered at the top of the plans page. Also, instead of greying out the button during the request, it is replaced by a spinner to be more clear that something is happening.Along with #531, this should hopefully clear up any confusion during the transition while a migration is being started.
Although we can't start migrations in mock mode, the spinner behavior and error reporting can still be tested there.