How would you make the example validation error response files for all your HTTP requests? He mentioned doing it in your CI/CD pipeline, but anybody got some thoughts on how?
Nope, that works fine. It's more of a traditional Laravel way to do things though, where as computed properties and public properties are more of a Livewire way to get data to the view as Livewire handles it for you. I personally don't like doing it that way, as I like to keep my render method clean. Using computed properties has the added bonus of memoisation and caching, plus they are easier to unit test than data called in the render method.
@@joshuahanley32 I've experimented a bit with #[Computed] and I love it. Thanks! Slowly migrating components as I am working on them. Looks much cleaner.
good talk, but the repository pattern tear-down was a bit of a straw-man. Using them everywhere is a bad idea (as the presenter demonstrated), but they can (and should) be used when complicated or re-usable queries need to be encapsulated and extracted outside of the controller layer
The only arguments _for_ repositories are straw man arguments: “But what if we change ORM? What if we change the database?” If you’re going to change your ORM, then you’re going to be writing code any way. Your “EloquentFooRepository” classes aren’t going to magically work if you decide to use say, Doctrine.
@@martinbean I don't think those are good arguments for using repositories. As I said, "using them everywhere is a bad idea". Repositories are useful for encapsulating complicated queries, re-using query logic between different classes, and hydrating objects outside of the eloquent/active record pattern (ie: domain objects in DDD). Using them as depicted in the video (e.g: simply wrapping all eloquent calls) is an obvious anti-pattern
@@coreymcmahon3969 Thanks for the feedback, and I take your point. I will say, its very difficult in a very small amount of time in a talk to cover all the nuance when you have 6 other topics you want to cover. For clarity, I wasn't calling for "never use repositories". I was calling for "don't just use them because you think there will be a benefit". Introduce them when (and precisely only when) theres a real need to make the tradeoffs. And the same goes for other patterns. Until theres an actual need, paint inside the lines and stay inside the lines as long as you possibly can. I tried to make this point towards the end of that section.
This is by far my top talk of the conference. I was able to relate to every and each part and it summarised all the issues I faced in my career pretty accurately. Thanks so much Sam for this talk
Great job, Jess Archer! Your introduction of Laravel Pulse at Laracon AU 2023 was fantastic. Your passion for Laravel and your presentation skills were truly impressive. Looking forward to more insights and updates from you in the future. Keep up the excellent work!
I don't have anything at this stage, but would be open to putting more information out there. Do you have anything in particular you would like to learn about?
Great tips! Biggest benefit imo of action classes (or any other business logic layer) is we can now reuse that logic in other parts of the system (API endpoints, Jobs, Commands, etc.). It's no longer tied down to the Livewire component itself.
How in this line $builder = $next($request); the variable $builder is really receiving the Eloquent\Builder? I just can't understand that. Where this is coming from?
Thankyou so much! I am building a large application from scratch, I have worked on several projects and we have like 500 models and its just insane how it just so ineffecient. This is such a beautiful approach. Thankyou Freek! <3
I like the way you think. I think you see the user point of view just as well as the api data handling best practices. (As far as I can tell from my experience.)
