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

[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.

[bee-interactive]

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..

[shokanshi]

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.

[PhiloNL]

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

[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!

[yabdab]

Is it safe to use Livewire 4 with modal yet?

[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)

[yabdab]

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

[PhiloNL]

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

[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?

[nuernbergerA]

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

[bee-interactive]

@nuernbergerA +1 for me too

[PhiloNL]

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

[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

[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? 😄

[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