Freek Van der Herten - Simplification Tips and Tricks

[@DrewRoberts]

This guy is a Freek! I need more conference talks like this in my life.

[@Unclaimed3172]

This guy is great. Provide great tips and mantained great packages. Thank you Freek.

[@ProgrammingwithPeter]

Freek is freaking awesome! The laravel community needs talks like this. Even tho i create projects while recording, it's hard to showcase features like this ones. Great talk. I like the action classes(i used them in my series too) is just that i like to name the method "run".

[@iraklisg]

Thank you for this interesting video. I'm not sure, though, that I get the difference between View-Models and Laravel's built-in View Composer, rather than been more explicit. I mean conceptually they both serve as a place where you can organize some logic needed in the View 🤔

[@rfpdl]

Really good. Saves me lines of code. Thank you!

[@nor15din]

I like this guy!

[@equals5StaR]

Isnt the Blade X view partials using ViewModels breaking the MVC model by calling Country::all() basically from a view, and not calling the db layer from controller and passing it to the view?

[@Jossnaz]

loved the query builder and the talk in the start. Blade X and viemodel? seems to make things more complex though. Maybe you shouldve taken your time (which you didnt have) to explain a bit more why this is good. You could just create blade components right? and run php code inline to get, say the categories... question is if that is efficient. But distributing the logic via new life cycles / structures that you have to explain to everyone coming to that project... and efficiency is hopefully not the problem to begin with

[@mirasmustimov1504]

lots of cool ideas!

[@aArcziMetin2]

Nice. I also do use actions in the same way! 😊

[@ahmedhelal174]

How to show the menu for moving the class into namespance here kzbin.info/www/bejne/fKmkdJtqjZKLmZI ?

[@Patrickdaawsome]

If you like this also check out stitcher.io/blog/laravel-beyond-crud

[@anticom1337]

Strongly disagree with the proposed patterns. A controller is supposed to logically group a set of actions (by resource / page / topic). Moreover if your actions are getting too complex just refactor them to an event listener and emit an event in the controller. That way you can reuse the event listener in for example an artisan command. I feel like he's rather working against the primitives provided by laravel instead of working with them.

[@Jossnaz]

I cant follow. You criticized only one pattern. "A controller is supposed to group a set of actions" he didnt violate that. And how is emitting an event better than directly calling the class. You prefer a code base that emits a thousand events? really? if you have a stronger point, please feel free to make your case.

[@anticom1337]

@@Jossnaz By having invokable controllers they don't group a set of actions but you have only exactly one action per controller. Don't get me wrong, I like the idea of having slim controllers, however usually this is achived by injecting services into your actions and let the service house the logic you need. I have the feeling that due to primitives such as Facades etc. that Laravel gives you, developers typically underestimate and under-use dependency injection mechanisms. After all afaik Laravel's dependency injection container even is PSR-11 compliant and hence offers a commonly known mechanism to loosely couple different domain objects in your application. Regarding events the clear advantage is, that they allow you to add additional listeners to events in the future. For example think about a UserRegisteredEvent. You could have an OnboardingEmailService that sends out an email as well as a FetchGravatarService that tries to retrieve a gravatar for your users avatar whenever a new user registers on your app. IMHO this is a very powerful concept and is compliant with Open-Closed-Principle. This pattern leans more towards Event Sourcing architecture and can be very powerful since you can distribute it accross machines using CQRS etc. Honnestly I don't know whether there are any Laravel libs out there that add CQRS capabilities to your apps.

[@Jossnaz]

@@anticom1337 I highly appreciate your comment. I wouldnt make the controllers invokable either. And what you call "Service" they just use the thing they call "Action". Afaik that is the same, at least that is what I assumed when I saw it. Events -> how is that better than calling the code explicitly when you register a user? It is your own code, right. You dont have to create a space for someone to hook into your events like for example the whole mess around wordpress. Write the code explicitly, its your own code! no need to create a mess with X listeners and a weird execution order, with separated code logic in different places, now nobody knows any more what gets executed. On register, call code explicitly. And if you want to have async code, laravel has the job queue built into itself right? no need to run everything sync. Wayyy better. Want to write another wordpress platform? ok _expose_ events but I wouldnt use my own events probably in most cases for my core code even when doing "wordpress" v2.

[@ahmedhelal174]

Thank you so much here is some source code which in the great talk query bulider not included I used laravel 7 blade components instead of the package github.com/AhmedHelalAhmed/laravel-simplification-tips-and-tricks that may help someone

[@fear-h1r]

this guy has no chill

[@najamhaq]

'nah'

[@HEADEPIC]

what theme is that?

[@freekmurze]

freek.dev/uses