Skip to content

Conversation

sbrow
Copy link

@sbrow sbrow commented Jul 15, 2025

Description

This PR closes issue #3376, and allows users to create custom hx-prompt dialogs in exactly the same way we make hx-confirm dialogs.

To do this, all I had to do was update the input type of issueRequest() to accept a string|false value rather than boolean.

Corresponding issue: #3376

Testing

I tested this with a custom Alpine.js modal, and it worked as expected. If I get traction on this, I will provide a full, working example (for hx-confirm and hx-prompt.

Please explain how you tested this change manually, and, if applicable, what new tests you added. If you're making a change to just the website, you can omit this section.

Checklist

  • I have read the contribution guidelines
  • I have targeted this PR against the correct branch (master for website changes, dev for
    source changes)
  • This is either a bugfix, a documentation update, or a new feature that has been explicitly
    approved via an issue
  • I ran the test suite locally (npm run test) and verified that it succeeded
    (Having trouble testing, running on nixos).

@sbrow sbrow changed the title Patch 2 Allow custom hx-prompt dialogs Jul 15, 2025
src/htmx.js Outdated
if (confirmed === undefined) {
const issueRequest = function(skipConfirmation) {
return issueAjaxRequest(verb, path, elt, event, etc, !!skipConfirmation)
return issueAjaxRequest(verb, path, elt, event, etc, skipConfirmation)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

without this boolean conversion the documented default behaviour will be lost

  // 3. Manually issue the request when you are ready
  evt.detail.issueRequest(); // or evt.detail.issueRequest(true) to skip the built-in window.confirm()
});

it is expected that users will call issueRequest() with no input or (false) and it will then continue with the request after you have prevented the original request and if you pass undefined or false it converts this into boolean false and performs the normal confirm dialog action after you have had a chance to do your own handling. If you pass in (true) it will just do the request with no more confirm as you have already done it your own way somehow.

So we can't just change this with this simple change without breaking existing behaviour.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well then all that needs to be done to preserve existing behavior is to ensure that any value other than true or a string gets converted to false, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants