Repository navigation
dispatch('openModal') not working after upgrading to Livewire 4.0.1 #545
Description
Activity
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 - toThe 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 workTemporary 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..Reacted by shokanshi, LukeCaaS, Nima HeydariNasab and Dave RovertsReacted by Erik D'ErcoleThank 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.
Reacted by Bee InteractiveThanks for sharing. I'll look into this, looks like we might have to use a different property name.
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 - toThe 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 workTemporary 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!
Is it safe to use Livewire 4 with modal yet?
@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 you can use it with Livewire 4, but you need to use the workaround mentioned above for now given the keyword is reserved.
Reacted by Mike Yrabedra and Bee InteractiveLike @bee-interactive wrote that the
'component'key is removed from the$params, should we escalate it tolivewire/livewiresince this package needs it?this is a real blocker for me @PhiloNL would you accept a PR where we replace
componentwithmodalComponent?@nuernbergerA +1 for me too
@nuernbergerA sure, debating between
modalComponentor justtarget, what do you think?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 livewireim 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? 😄
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_componentastargetmight be more confusing withwire:targetim 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_componentastargetmight be more confusing withwire:targetThanks!
ModalComponentit is, just tag me in the PR, thanks! 🙌@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.
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.