Add support for custom options and cancelable $dispatch#4608
Open
nicolagianelli wants to merge 2 commits intoalpinejs:mainfrom
Open
Add support for custom options and cancelable $dispatch#4608nicolagianelli wants to merge 2 commits intoalpinejs:mainfrom
$dispatch#4608nicolagianelli wants to merge 2 commits intoalpinejs:mainfrom
Conversation
EGAMAGZ
approved these changes
Jun 24, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Proposal: Extend $dispatch functionality
Hello everyone,
While working with AlpineJS to build a UI library for Laravel, I noticed some limitations in the magic function $dispatch. Specifically:
These limitations can lead to issues when building modular, event-driven components. Below, I explain the motivation and propose a minimal enhancement.
Problem Overview
Currently, it's not possible to customize event behavior (e.g., disabling bubbles). This becomes problematic in cases like:
A modal and a dropdown both dispatching an event named
closed.When used together, the parent modal might unintentionally respond to the dropdown's event, causing conflicts.
Yes, we could rename events (e.g.,
modal:closedvs.dropdown:closed), but this doesn't solve issues with nested modals or more complex component structures.Although dispatched events are marked as
cancelable: true, the function does not return the created CustomEvent.As a result, it's not possible to check whether preventDefault() was called.
This prevents useful patterns like:
This kind of control is useful for building modular components.
Proposed Solution
The required change is minimal:
Benefits