Hi everyone, the featured code was mine (just a starter for a big project), which featured a directory structure designed for larger projects, thinking ahead about scalability. Povilas provided great feedback on it being over-engineered for a smaller project, which I completely agree with. Honestly i think using laravel for any small project is an overkill in itself (its like using a sword to kill a bee). It's a valuable reminder to balance complexity with the project's size. Also for the admin authentication, i chose to go with custom solution instead for breeze, etc is because its going to be more complex later. Highly recommend checking out this series if you're looking to improve your coding skills!
A project can be really small and still need authentication, authorization for resources control access, database management (migration, etc), notifications, queues, and so one! So its far from being a sword to kill a bee.
I remember when I was a beginner, my goal was to make a structure that can be extended without problems, for example using a global model class that extends Laravel's model and similar case for other vendor classes, 😅
always remember coding about KISS but readable. If we always think every possibility, everything could happen and it is infinity. And then you will over handle the logic, and over engineered but the reality it could be just rarely to be used. You will spend too much time in testing, debugging, reading the code, teaching your junior how to read the code. Stop the possibility / make it less, and you won't get loss and focus the main thing.
We have a full course on multi-language Laravel, so pretty sure you will find it somewhere here, depending on what package (if any) you're using: laraveldaily.com/course/multi-language-laravel
Hello sir, I have this kind of problem, maybe it's stupid but hey I'm just want to know that. For example, I have the menu header blade and need to return data from db, so create a Provider like this below. So can you answer that what I did is wrong or there is another way to do it
Yeah, seems good to me! View Composers are a proper way to set such global variables. Maybe, two things to consider changing: 1. Doing it in the AppServiceProvider instead of creating a separate one 2. Separating ViewComposer into its own class, to shorten the Provider code to fit other features: laravel.com/docs/11.x/views#view-composers
Hello! I have a project where I needed menu items and other data in the header, and after testing some solutions a bit, I decided to do a Provider just like you did.
Hi everyone, the featured code was mine (just a starter for a big project), which featured a directory structure designed for larger projects, thinking ahead about scalability. Povilas provided great feedback on it being over-engineered for a smaller project, which I completely agree with. Honestly i think using laravel for any small project is an overkill in itself (its like using a sword to kill a bee). It's a valuable reminder to balance complexity with the project's size. Also for the admin authentication, i chose to go with custom solution instead for breeze, etc is because its going to be more complex later. Highly recommend checking out this series if you're looking to improve your coding skills!
A project can be really small and still need authentication, authorization for resources control access, database management (migration, etc), notifications, queues, and so one! So its far from being a sword to kill a bee.
@o_lobato Imo, for smaller projects, we got smaller framework like CI4, etc
can I clone it too so that I can learn from you approach? thank you so much
I remember when I was a beginner, my goal was to make a structure that can be extended without problems,
for example using a global model class that extends Laravel's model and similar case for other vendor classes, 😅
always remember coding about KISS but readable.
If we always think every possibility, everything could happen and it is infinity.
And then you will over handle the logic, and over engineered but the reality it could be just rarely to be used.
You will spend too much time in testing, debugging, reading the code, teaching your junior how to read the code.
Stop the possibility / make it less, and you won't get loss and focus the main thing.
I think a Trait should have been used here.
Do more of these pleass
It’s really interesting
flashToast can use inside helper funtion also
Thank you
"Premature optimization is the root of all evil."
- Donald Knuth
Hey how would you approche in laravel 11 translatable url slugs? When user switches pages language so it updates the slugs into url menu.
The same way as with earlier laravel versions
Hey @ can you please provide some guide (link, post) where i can learn more about this ? I wasn't able to find it.
We have a full course on multi-language Laravel, so pretty sure you will find it somewhere here, depending on what package (if any) you're using: laraveldaily.com/course/multi-language-laravel
Which contact channel can I use to send a code for analysis?
Email povilas@laraveldaily.com
Very good video.
nice
Hello sir, I have this kind of problem, maybe it's stupid but hey I'm just want to know that. For example, I have the menu header blade and need to return data from db, so create a Provider like this below. So can you answer that what I did is wrong or there is another way to do it
Yeah, seems good to me! View Composers are a proper way to set such global variables.
Maybe, two things to consider changing:
1. Doing it in the AppServiceProvider instead of creating a separate one
2. Separating ViewComposer into its own class, to shorten the Provider code to fit other features: laravel.com/docs/11.x/views#view-composers
Hello! I have a project where I needed menu items and other data in the header, and after testing some solutions a bit, I decided to do a Provider just like you did.
@@LaravelDaily thank you sir , and weird I dont see notification from youtube when someone reply to me
@@FallHealer2375 cool , I did some research but not sure if my way is good or not