Await for confirm method results

[excid3]

The browser's confirm is synchronous and waits for a boolean. This is really convenient, but makes it painful to implement a custom confirm modal in Boostrap, Tailwind, etc.

This PR adds await so a custom confirm can return a promise that waits until the user confirms or cancels the operation.

The overridden confirm method simply needs to return a Promise that resolves to true or `false.

Turbo.setConfirmMethod(() => {
  return new Promise((resolve, reject) => {
    // show modal
    // on confirm, resolve(true)
    // on cancel, resolve(false)
  })
})

Closes #522

Example of it in action:
https://user-images.githubusercontent.com/67093/151271318-5034bbff-6b24-462f-89f7-8e6e3f8d0466.mp4

[excid3]

Tests are failing because main has failing tests.

[seanpdoyle]

Switching to an assumption that FormSubmission.confirmMethod is a promise, what happens when a user-provided Promise set by Turbo.setConfirmMethod throws an exception?

Before the await, the async start() (the method that wraps these lines) would have to deal with the exception.

After adding the await, is that exception swallowed?

[excid3]

Throwing an error in the promise raises the Uncaught (in promise) error in the start() method of FormSubmission:

turbo/src/core/drive/form_submission.ts

Line 122 in 201f8b3

return this.fetchRequest.perform()

It doesn't swallow the exception.

[seanpdoyle]

That's good. In that case, should the default function also be translated into a Promise?

turbo/src/core/drive/form_submission.ts

Lines 53 to 55 in 201f8b3

	static confirmMethod(message: string, element: HTMLFormElement):boolean {
	return confirm(message)
	}

static confirmMethod(message: string, element: HTMLFormElement): Promise<boolean> {
  return Promise.resolve(confirm(message))
} 

[excid3]

It didn't affect the default method, but we could.

Would we also want to change this to expect a Promise too?

export function setConfirmMethod(confirmMethod: (message: string, element: HTMLFormElement)=>Promise<boolean>) {
  FormSubmission.confirmMethod = confirmMethod
}

[kstratis]

Great work @excid3! Thank you!
Seems there are a couple of "duplicate" commits though - Could you please have a look?

[excid3]

@kstratis I botched the rebase from main on accident. 😅

[tabishiqbal]

any update on this? @excid3

[MatheusRich]

Is there anything actionable here? How can we move this forward?

cc @dhh

[excid3]

@dhh fixed this, so it's ready for review now. 👍

[excid3]

Tests that are failing are the same ones in main.

[thewatts]

@excid3 congrats on the merge!

Does this mean that you're going to have a GoRails episode on implementing a custom confirm modal? 😇

[ivorpad]

@thewatts https://gorails.com/episodes/custom-hotwire-turbo-confirm-modals

[thewatts]

@ivorpad YESSSSSSS! Thank you!

( And many thanks to you as well, @excid3 ! )

[rapcal]

@excid3 how would you go about i18n buttons rendered in insertConfirmModal?

[excid3]

@rapcal Lots of options.

You could pass the text as extra data attributes on the element with the data-turbo-confirm, like data: { turbo_confirm_ok: I18n.t("ok"), turbo_confirm_cancel: I18n.t("cancel") } and then use those when rendering your modal HTML.

Or have Rails render the HTML for the dialog ahead of time like we do in the screencast linked here. #525 (comment)

[rapcal]

@rapcal Lots of options.

You could pass the text as extra data attributes on the element with the data-turbo-confirm, like data: { turbo_confirm_ok: I18n.t("ok"), turbo_confirm_cancel: I18n.t("cancel") } and then use those when rendering your modal HTML.

Or have Rails render the HTML for the dialog ahead of time like we do in the screencast linked here. #525 (comment)

Thanks, Chris!