feat(package actions): Update Enable/Disable RAI Withdraw UI to use ConfirmationModal #200
Conversation
| if (toggleSucceeded) { | ||
| // Clear actions for package from cache | ||
| qc.invalidateQueries(["actions", id]).then(() => { | ||
| setAwaitingNav(true); // Triggers LoadingSpinner | ||
| // Debounce back nav to give the data pipeline time to update | ||
| setTimeout(() => { | ||
| // Go back to package details and render success alert | ||
| navigate(`/details?id=${id}`, { | ||
| state: { | ||
| callout: { | ||
| heading: `Formal RAI Response Withdraw action has been ${ACTION_WORD.toLowerCase()}d`, | ||
| body: `You have successfully ${ACTION_WORD.toLowerCase()}d the Formal RAI Response Withdraw action for the State.`, | ||
| }, | ||
| }, | ||
| }); | ||
| }, 2000); | ||
| }); | ||
| } |
There was a problem hiding this comment.
do we not want to invalidate this query. just want to make sure we arent loosing functionality.
There was a problem hiding this comment.
When testing it without this, it seemed to work just fine. We thought we'd have to invalidate the cached item and then redirect, but the real sauce was just that 2-second debounce on navigating...something the modal definitely handles through requiring interaction. Upon the details page re-loading, the actions updated 👍🏼
|
hey @kevinhaube Our deploy workflow has this thing where if you put a namespace in your branch (idk what the term is, but like you have 'fix/') the workflow won't kick off. This is an inadvertent win to some degree, as it skips dependabot branches and i think forks. |
|
Closing and handling via #204 |
Purpose
This PR gets rid of our debounced reload on the ToggleRAIResponseWithdraw form page and replaces it with a ConfirmationModal.
Linked Issues to Close
N/A
Approach
N/A
Assorted Notes/Considerations/Learning
N/A