Laravel 11: New Slim Base Controller with No Traits

Another new change in the Laravel 11 skeleton, which hides features like `$this-authorize()` or `$this-validate()` from Controllers.

- - - - -
Support the channel by checking out my products:

- - - - -
Other places to follow:

[ikarolaborda]

Laravel 11 is closer to what Symfony Skeleton has been delivering for some years, yet it still maintains the fancy laravel way of doing things, just adding the “use only what you need, when you need it” philosophy. I like that…

[MzungaElephant]

I was skeptical about this change, watching this I'm not sure why, cheers 👍

[JJASMR]

Interesting, especially about the "$this->validate()" syntax. I've used it a lot in quite small, usually invokable controllers since first learning Laravel, but I see how "$request->validate()" is more streamlined and explicit.

[sawood]

I like the changes. I started using a "Gate" idea in my APIs to reinforce keeping controllers as small as possible. Assuming the request has all of the right permissions it is then passed on to the right class to retrieve data.

[Fanmadeb]

I usually create single responsibility controllers with just one __invoke method and almost never even extend any base controller.
It works just fine.
I wasn't even aware (anymore) of these traits :D
If I want to validate the request parameters, I create a specific (form-)request class.
Authentication is done in middleware and authorization using gates, policies or similar functionalities. This is often even done inside the action classes called by the controller.
Doing too much in the controllers is usually a bad sign anyway.
I mean, of course I sometimes do everything in a controller (or even in a callback directly in the request definition), but that's only for very simple logic or PoCs.
So while I'm not (yet?) happy with all the changes to Laravel 11, I do like this one.
But that's all subjective, of course :)

[jonashansen]

👋I used to use the older syntaxes and still have some controllers that haven’t been touched in years.

I used to prefer using string aliases bound in the app container for the portability, can just yank & paste snippets without thinking about import stmts.
With the introduction of real-time facades, additional testing features like mock and spy, and resolving in global namespace thru aliases I’m now defaulting to Facades.

I think the overhead is worth it.
An extra feature I have yet to use, but is nice to have, is being able to override a facade alias once and have it automatically effect everywhere

[spicynoodle]

Nice, this can save some space in the opcache buffer

[mdismailhossain]

also check in controllers will not work by default

[saravanasai]

The Gate is so clear now. Because I face once in a project which policy does it use.. Where it is configured

[danielsmartins]

Please i need help with $this->middleware(), it was removed in laravel 11. what traits do i need to import to be able access the $this->middleware() in laravel controllers

[maximilianominetto]

For me it is better solution, the code should reflect the intention of the programmer not magic.
Regards.

[underflowexception]

I dont like how laravel hides the underlying logic makes it harder to debug issues

All the interfaces should be there by default and if you want to remove it then go for it

Release aftee release the framework just gets more bloated

[lukmauu]

I did not like 11 at all, I think Laravel is getting too mysterious and magical. We need more clear code no magic