The problem with observers is that it works with different layer than events/listeners - there can be some models that when modified always needs to modify additional data (like modifying user relationship to groups should always link/unlink user to certain additional relations. Doing so by listeners we always need to remember that when you need to modify the user group (let's say you make an endpoint for an api for CRM for the external app to sync data with yours) you always need to remember to create certain events (or attach the same listeners to new events). With observers everything is already managed as the way it should be. As for the global scope example, there is one, that is used almost by everybody: softdeletes.
I think you are right, being careful and thinking of new devs that come into the team is a great practice, committing those into production doesn't really look safe
My tip would be to avoid these features unless you know why it will not cause any problems using any of them. I personally only use event listeners, because I have a logging trait that allows me to log model changes on update. It doesn't really change the behavior of anything else. It's only relevant in context of itself and therefore - safe
The attribute method for Observers and Scopes also has the benefit of the IDE being fully aware of what happens with the class/model unlike with the boot method. It can show you that there are observers (or scopes) connected to that if you hover over the model for example
We always have to take out "magic" from a long term project. No problem using them for quick mvps or poc, they are also great in a "one shot delivery", yet when it comes down to a long term project that will have several people involved, then clarity is your best friend. There is no documentation that can replace a well written code, because in the end "what the system does?" is what is coded. Also, at my current job we say that the circle of programming life is: Do things simple because you don't know other way, then you start doing them way more complex and automated becaused you learned how to, and then, when you are mature enought, you write it simple again because you know that it's better to keep in the future. 🤣
Instead of writing scope globally that is kind of hidden, I prefer to write them within the model and recurring scope as traits to be reusable by other models . Although, laravel 11 syntax makes it better. Nonetheless, if you don't need it don't ask for it. Features are only meant to be used when the need arises.
Off topic question , is there any way to track database schema changes in MySQL? i mean just like a log, that record username, timestamp and what had old and what is new change .
The things is Jefery is an experienced developer and an experienced teacher (I first learned from him html+css 10 years ago and those lessons stuck), but even he at a certain point cant "dumb down" (no insult intended) things. There is so many ways to remake the "beginners guide". From a different standpoint, Laravel as an ecosystem still manages to have things for beginners and more advanced features. The more advanced features have kind been pushed either by the industry, mentality, or all those haters that want to slap the "enterprise level" badge on a project. By enterprise i mean a bigger team, more management, more code review, internal way of structuring and coding a project. I was recently approached by somebody needing help with hes university theses, and at a certain point I had to ask my girl friend for help because the guy didn't understand even the most basic terminologies.
I find context() very useful to set client_id in multitenant application. no need to mess with session/cookie. as session/cookie are based on logged in user and often regenerate on login/logout and client id solely depend on subdomain.
Why do not use Auth facade? You get additional layer of application where you do not need to know if the user is logged in by session or bearer token. Everything is set from the guard and depending on the driver you will get the same results but with differend code under the hood.
I find it useful in local environment to output a Log::debug line in the Observer so if I'm debugging something it will remind me that there's actually an observer running.
The problem with observers is that it works with different layer than events/listeners - there can be some models that when modified always needs to modify additional data (like modifying user relationship to groups should always link/unlink user to certain additional relations. Doing so by listeners we always need to remember that when you need to modify the user group (let's say you make an endpoint for an api for CRM for the external app to sync data with yours) you always need to remember to create certain events (or attach the same listeners to new events). With observers everything is already managed as the way it should be.
As for the global scope example, there is one, that is used almost by everybody: softdeletes.
I think you are right, being careful and thinking of new devs that come into the team is a great practice, committing those into production doesn't really look safe
My tip would be to avoid these features unless you know why it will not cause any problems using any of them.
I personally only use event listeners, because I have a logging trait that allows me to log model changes on update. It doesn't really change the behavior of anything else. It's only relevant in context of itself and therefore - safe
The attribute method for Observers and Scopes also has the benefit of the IDE being fully aware of what happens with the class/model unlike with the boot method.
It can show you that there are observers (or scopes) connected to that if you hover over the model for example
(great video btw)
We always have to take out "magic" from a long term project. No problem using them for quick mvps or poc, they are also great in a "one shot delivery", yet when it comes down to a long term project that will have several people involved, then clarity is your best friend.
There is no documentation that can replace a well written code, because in the end "what the system does?" is what is coded.
Also, at my current job we say that the circle of programming life is: Do things simple because you don't know other way, then you start doing them way more complex and automated becaused you learned how to, and then, when you are mature enought, you write it simple again because you know that it's better to keep in the future. 🤣
Event and listeners does not return data. If you data to be return then an Actions might be a good option
It's a good point, knowing that you wouldn't know those actions in the models unless you look for it.
Instead of writing scope globally that is kind of hidden, I prefer to write them within the model and recurring scope as traits to be reusable by other models . Although, laravel 11 syntax makes it better.
Nonetheless, if you don't need it don't ask for it. Features are only meant to be used when the need arises.
Changing the config is only for tests imo, it's a recipe for disaster anywhere else, messing with mutability like this will mess up the whole project
Off topic question , is there any way to track database schema changes in MySQL? i mean just like a log, that record username, timestamp and what had old and what is new change .
Don't know, never done it on Laravel level, but there are a few Laravel logging packages.
The things is Jefery is an experienced developer and an experienced teacher (I first learned from him html+css 10 years ago and those lessons stuck), but even he at a certain point cant "dumb down" (no insult intended) things. There is so many ways to remake the "beginners guide".
From a different standpoint, Laravel as an ecosystem still manages to have things for beginners and more advanced features. The more advanced features have kind been pushed either by the industry, mentality, or all those haters that want to slap the "enterprise level" badge on a project. By enterprise i mean a bigger team, more management, more code review, internal way of structuring and coding a project.
I was recently approached by somebody needing help with hes university theses, and at a certain point I had to ask my girl friend for help because the guy didn't understand even the most basic terminologies.
I find context() very useful to set client_id in multitenant application. no need to mess with session/cookie. as session/cookie are based on logged in user and often regenerate on login/logout and client id solely depend on subdomain.
Why do not use Auth facade? You get additional layer of application where you do not need to know if the user is logged in by session or bearer token. Everything is set from the guard and depending on the driver you will get the same results but with differend code under the hood.
I find it useful in local environment to output a Log::debug line in the Observer so if I'm debugging something it will remind me that there's actually an observer running.
well done, thanks. I thing Sushi is using config database overide
⏳ 1:25