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.
I'm a big fan of state machines. If you've got a complicated process flow with many branches and events, it's going to be a challenge to keep track of where things are within the workflow. A state machine allows you to keep track of the progress and it's easy to see where things get sent when or if it gets stuck. There are of course many ways to deal with this scenario but a spaghetti of events and listeners isn't at the top of my list. I've used this method (state machine) for a questionnaire for a research project where the target group had to fill in a questionnaire every 3 months for 18 months, each one with registration, MFA, introduction/instruction email, terms and services agreement email with link to accept it, email notifications, reminders (and keeping track if sent already and if it was successful), closing missed questionnaires, opening next questionnaires etc. The previous dev indeed had used events and listeners and it was a complete mess to debug or add/remove/disable steps. With state machine it was easy.
Having this level of abstraction is always nice to have available but I've inherited projects where the previous dev(s) have used events and listeners in such a granular manner that while everything is neatly abstracted it is also a pain in the bum to debug or step through the code. The relationships between events and listeners are not always immediately apparent and it’s not always clear which listeners respond to an event without checking the EventServiceProvider first. Sometimes private methods in the Job class containing the business logic (in this case TicketPurchased and NewOrderPlaced) makes more sense as it is easier to trace what is happening where.
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.
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: ruclips.net/video/-ezOz6vPLoo/видео.html
This is a great option! I think it really comes down to personal preference and what feels “messy” or “smooth” to you. But I agree sometimes an Action class can be perfect. ☺️ -Josh
Good to know, but ... If not queued, the listeners execute inline, and if one fails, the rest won't execute. There you have it 'sometimes' it is not working! Just wait until someone decides to fire an event from the listener and then again and again. It's not fiction, just the paradise I live in
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 ?
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.
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.
I'm a big fan of state machines. If you've got a complicated process flow with many branches and events, it's going to be a challenge to keep track of where things are within the workflow. A state machine allows you to keep track of the progress and it's easy to see where things get sent when or if it gets stuck.
There are of course many ways to deal with this scenario but a spaghetti of events and listeners isn't at the top of my list.
I've used this method (state machine) for a questionnaire for a research project where the target group had to fill in a questionnaire every 3 months for 18 months, each one with registration, MFA, introduction/instruction email, terms and services agreement email with link to accept it, email notifications, reminders (and keeping track if sent already and if it was successful), closing missed questionnaires, opening next questionnaires etc.
The previous dev indeed had used events and listeners and it was a complete mess to debug or add/remove/disable steps. With state machine it was easy.
Having this level of abstraction is always nice to have available but I've inherited projects where the previous dev(s) have used events and listeners in such a granular manner that while everything is neatly abstracted it is also a pain in the bum to debug or step through the code. The relationships between events and listeners are not always immediately apparent and it’s not always clear which listeners respond to an event without checking the EventServiceProvider first. Sometimes private methods in the Job class containing the business logic (in this case TicketPurchased and NewOrderPlaced) makes more sense as it is easier to trace what is happening where.
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.
Much much better audio than you usual Muddy low pitch audio!
Good ✓
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: ruclips.net/video/-ezOz6vPLoo/видео.html
This is a great option! I think it really comes down to personal preference and what feels “messy” or “smooth” to you.
But I agree sometimes an Action class can be perfect. ☺️
-Josh
It's a bit confusing for me to have the notification and the event sharing the same name, but nice example overall.
Just in time! :D
Good to know, but ...
If not queued, the listeners execute inline, and if one fails, the rest won't execute. There you have it 'sometimes' it is not working!
Just wait until someone decides to fire an event from the listener and then again and again. It's not fiction, just the paradise I live in
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 ?
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.
Which font and theme is it ?
Thx!
Nice Thumbnail
nice ears men :D