V3 events API proposal?

[calebporzio]

I want to ditch ->emit(), ->emitUp(), ->emitTo(), ->emitSelf, and ->dispatchBrowserEvent()...

...and just got with: ->dispatch()

1 simple method on the backend to dispatch a browser event that other Livewire or Alpine components can listen for.

I want it to work just like a normal "click" browser event, meaning the event is dispatched on the root element of the Livewire component and bubbles up from the window.

The "dispatch" part of it feels clear to me, the listener part doesn't.

It makes sense to me to similarly make listeners intuitive: a component event listener is registered on the root element of the component.

But this is a breaking change. A component would only then listen to dispatches from children, not from sibling components like v2.

We could add a simple syntax to allow listeners to be registered on "window" like you would in Alpine to achieve this.

I like that because Livewire and Alpine would basically have the same implementation, mental model, and usage for events and listeners.

But this would be a breaking change and I want to hear from YOU about how you use events and if this change makes sense to you or not.

Thanks!

[iAmKevinMcKee]

Currently I don’t have to think about whether my components are siblings or parents/children, and that’s how I prefer it.

I need component A to send a message to component B, so I emitTo. So simple.

I would not like to have to consider whether it’s a parent / sibling / child. I feel like that’s a step backwards.

[calebporzio]

I should also add. I think there will definitely be a ->dispatchTo(). That makes sense to me. It's the ->dispatchUp story that is confusing to me

[JayBizzle]

Would be happy with that. Don’t think I’ve ever used emitUp() 👍🏻

[iAmKevinMcKee]

Good words Kevin. Are you saying that you mostly use ->emitTo and not just ->emit most times?

I only ever use emit or emitTo. I use emitTo when I know it’s just going to one component because it makes it easier to understand the code when I come back to it.

All other cases I use emit.

I throw Livewire components around my codebase like confetti so I have no concept of up or down. 🤪

[JayBizzle]

I throw Livewire components around my codebase like confetti so I have no concept of up or down. 🤪

This made me LOL but we are exactly the same. Sprinklings of Livewire everywhere 😁

[akulmehta]

I have to agree with Kevin. Often times I need to emit events from one component which is nested in one component, to a completely different component. But I also have instances where I need to emitUp.

Example:
What if one page has two instances of a component A nested in two separate instances of component B, on the same page (probably generated as a result of a for loop), the emitUp allows me to emit specific information to the parent of that component.

classDiagram
    component_b_1 <-- component_a_1
    component_b_2 <-- component_a_2

Loading

In the above case, emitTo doesn't work well because the if one does emitTo('component-b') from component A1, it would update both instances of B right? emitUp helps in this case.

Maybe I am misunderstanding or there is another more elegant way of doing things. But I feel this breaking change would really hurt, and I am not sure if what is being proposed will fill the gaps it creates.

[calebporzio]

So if we go with ->dispatch() The next question becomes: What's the story for deciding to listen for an event globally? or only from children?

A: Make the API v2-esque

• By default all listeners listen on window
• All ->dispatch() calls dispatch to window
• If you want to dispatch only to parents, call dispatchUp

B: Make API browser-event-esque

• By default listeners listen on the root component element and events dispatch from roots (so this means listeners listen to children only by default)
• If you want to listen for an event from any component on the page, you can designate "global" or "window" when registering the Livewire event listener

A is the most backwards compatible, but it has a more complex implementation and maybe isn't as intuitive.

B is more of a seamless path as it leverages basic browser event behavior, but flips the control of scope from dispatchers to listeners, and I want to make sure that doesn't make the feature less useful. Also want to make sure "children-only" isn't a bad default.

[ariaieboy]

As long as we have the option to send events globally, it does not matter at all.
livewire v3 is a major release and it's alright to introduce breaking changes in major releases, especially in projects like livewire that are kinda new and is not as mature as let's say laravel.
Laravel spent more than 10 years building a solid foundation and right now the major releases are boring and 90% backward compatible :D

I think that you and the team of livewire v3 want to make V3 perfect before the release but keep this in mind that you can release livewire v4 and introduce more breaking changes and make that even better.

laravel for example released major versions every 6 months for years. and they changed their release cycle recently to yearly releases.

If you want to make the migration seamless you can mark the deprecated methods in V3 and introduce the alternatives and then remove the deprecated functions in V4.

[calebporzio]

Yep, good context. Thanks!

[elijahcruz12]

I like it! Here goes to me refactoring the game I made using livewire 😂

[lucasweaver10]

I would always vote for long-term significant improvement of the framework at the cost of some reasonable refactoring, so I don't mind the breaking change factor. And as you've described it, in the few cases I use emitUp/To I think the new functionality will still work just fine. Thanks for asking :)

[renky]

In one special application I use events globally. In that case I have 2 Livewire-Components living together on the same Page. One is kind of a Menu where I can select filters. The second is the Component that shows the results to me. I know this all can be done in different ways, but thats how it grew... If filters are changed in the one component, it is sent to the other via events. So yes - with the window solution this would also work - but currently it's just easy to "emit"...

[calebporzio]

That's very helpful to know. Thanks!

[ijpatricio]

Hey Caleb,

Do your thing. I trust your hunch :)

I'm not experienced enough with Livewire, so when you say this

I like that because Livewire and Alpine would basically have the same implementation, mental model, and usage for events and listeners.

it makes sense, but also... JS (Alpine/Vue/etc) has mechanisms (Store/Pinia/etc or tinyEmmiter/mitt.js) that are handy some time to time!

Is this something we wouldn't be able to do in V3's backend with such a change?

[akr4m]

I like the idea of unifying the event handling methods in V3, making it more consistent with Alpine. The single ->dispatch() method will simplify the learning curve and improve the development experience. In terms of tech, making listeners more intuitive by registering them on the root element of the component seems like a smart move.

My opinion is that, as long as we have a way to handle global events and provide a clear migration path, this breaking change is worth it for the long-term benefits. It simplifies event handling and aligns Livewire with Alpine, making it more intuitive for developers. Though it's a breaking change, the long-term benefits are worth it. Clear migration guides would help ease the transition.

So I would like single ->dispatch() method, and I'm excited to see Livewire V3 evolve!

[namumakwembo]

I have always thought that the current event $emitters we have in V2 to be sufficient ,for example one of my concerns is about the $this->emitSelf('refresh'); , I realized it plays an important role in speed Optimization because It does not trigger any other similar listeners on the page ;that is ,if the page has multiple Livewire components such as comments, listings , feed etc . Not knowing if the new dispatcher will have be able to accommodate this too