Skip to content

dispatch('openModal') not working after upgrading to Livewire 4.0.1 #545

Description

@shokanshi

Using Wire-elements 3.0.3, as titled, dispatch('openModal') does not open any modal. Any idea what could be the cause? It was working with Wire 3.0.3 + Livewire 3.7.4.

Activity

  1. bee-interactive commented on Jan 16, 2026

    @bee-interactive
    Contributor

    Hi @shokanshi,

    After investigation, Livewire 4 introduces reserved parameter names for the dispatch() method that are silently extracted from the parameters array before being passed to event listeners.

    see change in the livewire/livewire repo here

    The following parameter names are now reserved and will be removed from the event payload:

      - component
      - ref
      - el
      - self
      - to
    

    The upgrade tool for wire-elements/modal (WireElementsModalUpgrade.php) actually migrated users TO this now-broken syntax:

    // The upgrade tool converted this (Livewire 2 style):
    $this->dispatch('openModal', 'edit-user', ['user' => 1]);

    // To this (Livewire 3 style) - which is NOW BROKEN in Livewire 4:
    $this->dispatch('openModal', component: 'edit-user', arguments: ['user' => 1]); -> This fail

    // PHP - Named parameters
    $this->dispatch('openModal', component: 'edit-user', arguments: ['user' => 1]); -> This fail

    // Blade/Alpine - Object syntax
    $dispatch('openModal', { component: 'edit-user', arguments: { user: 1 } }) -> This work

    // JavaScript - Object syntax
    Livewire.dispatch('openModal', { component: 'edit-user', arguments: { user: 1 } }) -> This work

    Temporary Workaround
    Until package are updated, use positional arguments:
    $this->dispatch('openModal', 'edit-user', ['user' => 1]);

    This issue should be addressed by @PhiloNL to see what strategy he wants to adopt.

    Edit:
    But it's working fine in my projetcts, without having to change anything, so it's maybe not completely related to this..

  2. shokanshi commented on Jan 16, 2026

    @shokanshi
    Author

    Thank you for the detailed explanation. I guess in the meantime I will have to use this workaround.

    Edit: I am able to get it to work using the provided workaround so I suppose the bug is related to your investigation.

  3. PhiloNL commented on Jan 16, 2026

    @PhiloNL
    Contributor

    Thanks for sharing. I'll look into this, looks like we might have to use a different property name.

  4. LukeCaaS commented on Jan 28, 2026

    @LukeCaaS

    Hi @shokanshi,

    After investigation, Livewire 4 introduces reserved parameter names for the dispatch() method that are silently extracted from the parameters array before being passed to event listeners.

    see change in the livewire/livewire repo here

    The following parameter names are now reserved and will be removed from the event payload:

      - component
      - ref
      - el
      - self
      - to
    

    The upgrade tool for wire-elements/modal (WireElementsModalUpgrade.php) actually migrated users TO this now-broken syntax:

    // The upgrade tool converted this (Livewire 2 style): $this->dispatch('openModal', 'edit-user', ['user' => 1]);

    // To this (Livewire 3 style) - which is NOW BROKEN in Livewire 4: $this->dispatch('openModal', component: 'edit-user', arguments: ['user' => 1]); -> This fail

    // PHP - Named parameters $this->dispatch('openModal', component: 'edit-user', arguments: ['user' => 1]); -> This fail

    // Blade/Alpine - Object syntax $dispatch('openModal', { component: 'edit-user', arguments: { user: 1 } }) -> This work

    // JavaScript - Object syntax Livewire.dispatch('openModal', { component: 'edit-user', arguments: { user: 1 } }) -> This work

    Temporary Workaround Until package are updated, use positional arguments: $this->dispatch('openModal', 'edit-user', ['user' => 1]);

    This issue should be addressed by @PhiloNL to see what strategy he wants to adopt.

    Edit: But it's working fine in my projetcts, without having to change anything, so it's maybe not completely related to this..

    Thank you for this, I was pulling my hair out wondering why none of my modals were opening anymore except the ones trigger by Alpine!

  5. yabdab commented on Feb 5, 2026

    @yabdab

    Is it safe to use Livewire 4 with modal yet?

  6. eleftrik commented on Feb 6, 2026

    @eleftrik

    @yabdab Don't know if "it's safe", but following @bee-interactive's instructions I was able to upgrade a Livewire 3 + Volt project and make it work with Livewire 4 (with wire-elements, of course)

  7. yabdab commented on Feb 6, 2026

    @yabdab

    @eleftrik yea, was just hoping to hear from @PhiloNL on an official status on this.

  8. PhiloNL commented on Feb 6, 2026

    @PhiloNL
    Contributor

    @yabdab you can use it with Livewire 4, but you need to use the workaround mentioned above for now given the keyword is reserved.

  9. theticraft commented on Mar 25, 2026

    @theticraft

    Like @bee-interactive wrote that the 'component' key is removed from the $params, should we escalate it to livewire/livewire since this package needs it?

  10. nuernbergerA commented on Apr 10, 2026

    @nuernbergerA

    this is a real blocker for me @PhiloNL would you accept a PR where we replace component with modalComponent?

  11. bee-interactive commented on Apr 10, 2026

    @bee-interactive
    Contributor

    @nuernbergerA +1 for me too

  12. PhiloNL commented on Apr 12, 2026

    @PhiloNL
    Contributor

    @nuernbergerA sure, debating between modalComponent or just target, what do you think?

  13. nuernbergerA commented on Apr 13, 2026

    @nuernbergerA

    im fine with ether
    ps also discussing with caleb to prefix all internal event params with "_" so this won't be an issue, so this will be just a backup if we dont find a solution on livewire

  14. PhiloNL commented on Apr 15, 2026

    @PhiloNL
    Contributor

    im fine with ether ps also discussing with caleb to prefix all internal event params with "_" so this won't be an issue, so this will be just a backup if we dont find a solution on livewire

    ✅ Is this 1:1 discussion or ongoing thread that I can follow? 😄

  15. nuernbergerA commented on Apr 20, 2026

    @nuernbergerA

    @PhiloNL

    im fine with ether ps also discussing with caleb to prefix all internal event params with "_" so this won't be an issue, so this will be just a backup if we dont find a solution on livewire

    ✅ Is this 1:1 discussion or ongoing thread that I can follow? 😄

    was a 1:1; conclusion:
    in livewire v5 this will be done better, for now we can just use a macro or have to deal with the reserved words.

    so i would open a pr and would pick modal_component as target might be more confusing with wire:target

  16. PhiloNL commented on Apr 21, 2026

    @PhiloNL
    Contributor

    @PhiloNL

    im fine with ether ps also discussing with caleb to prefix all internal event params with "_" so this won't be an issue, so this will be just a backup if we dont find a solution on livewire

    ✅ Is this 1:1 discussion or ongoing thread that I can follow? 😄

    was a 1:1; conclusion: in livewire v5 this will be done better, for now we can just use a macro or have to deal with the reserved words.

    so i would open a pr and would pick modal_component as target might be more confusing with wire:target

    Thanks! ModalComponent it is, just tag me in the PR, thanks! 🙌

  17. seabasss commented on May 14, 2026

    @seabasss

    @PhiloNL Is this merged, and also applies to the PRO version? I'm still getting this error. I've tried to not use named arguments, but I get this error from time to time with that solution even though I don't see any way an int can end up in my code: Trying to access array offset on int.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions