Twelve confirmations behind a 50 line hook, and not one of them returns a promise

Twelve different components in the Nakodo application utilize a 50-line confirmation dialog hook, but none of them actually fulfill their intended purpose. The hook, named `useConfirm`, allows for creating a single confirmation dialog per component while it is animating out. To open the dialog, the `confirm` function is called with an object containing the question text, description, action button label, whether the action is destructive, and the function to run if the user confirms.

This hook is used in four components, with a total of twelve call sites. Despite its simplicity, the hook has a few issues that make it less than ideal for use. First, the dialog may never resolve a promise, leaving the code after the await statement incomplete. This is problematic when there is cleanup or transitions involved in the process. Secondly, the dialog keeps its text open even after it has been closed, which can cause confusion and an unprofessional appearance.

In order to resolve these issues, the author suggests using the `run` function to keep the Server Action call lexically inside the component that owns the pending state. This way, the click on the confirm button is the start of the transition, rather than a continuation resumed later in the handler. Additionally, the author acknowledges that sequential flows would be more convenient with promises, but in the current implementation there are no sequential flows.

The dialog also keeps its text open after closure, which can cause visual bugs and a poor user experience.