Let's talk about Events and Listeners

[@kmbo_0]

I never tried to use Events or Listners before as I was doing everything inside my Action class, but after watching this video, I think I'll give it a try. Very well explained.

[@Pekz00r]

I would strongly recommend against events and listeners in almost almost all cases. You should stick probably use Actions instead. The problem is that Events and listeners gets really messy and it is really hard to follow the code and see what side effects code has because events and listeners are too loosely coupled. If your actions gets too big and unwieldy, it is much better to just split your actions into several actions that calls each other instead. Jeffery Way explains this point very nicely in this video: kzbin.info/www/bejne/Y5bdgK1sq7V_pdE

[@brunosadventures3801]

For me working with events makes the code less understandable and readable. It is harder to find the code that is executed when a ticket is created. If you need more abstraction, just create an extra funtion or class with methods. Events can be handy for vendor packages where the event and listener code is not in the same repo.

[@matias.krabzik]

Just in time! :D

[@code75581]

Thanks for the video. Does the code inside the listener still run inside the job being processed ? If not what’s then the benefit of just abstracting The code ?

[@mrozbarry]

I believe it would run in the same fpm process, but I'm not sure if it runs inline. Either way, the main purpose is so the flow of code is isolated, you could test the user notification event listener in isolation, and your job code would only need to assert that the event was dispatched.

[@dominikbetlej7114]

Thx!

[@im_imon]

Which font and theme is it ?

[@helderneves91]

nice ears men :D