Keep controllers clean by using form requests in Laravel original
by Freek Van der Herten – 1 minute read – Edit
Posts tagged with controllers
by Freek Van der Herten – 1 minute read – Edit
– driesvints.com - submitted by Dries Vints – Edit
Dries Vints wrote a bost on why he uses single action controllers.
Read more [driesvints.com]
Join 9,500+ smart developers
Get my monthly newsletter with what I learn from running Spatie, building Oh Dear, and maintaining 300+ open source packages. Practical takes on Laravel, PHP, and AI that you can actually use.
No spam. Unsubscribe anytime. You can also follow me on X.
"Always fresh, useful tips and articles. Carefully selected community content. My favorite newsletter, which I look forward to every time."
by Freek Van der Herten – 2 minute read – Edit
From time to time our team needs to create fairly complicated CRUD interfaces from scratch. While this isn't rocket science, there surprisingly aren't that many good resource out there on how to do this. That's why our team dove in and published a couple of packages that can help create modern CRUD…
by Freek Van der Herten – 4 minute read – Edit
In this blog post, I'd like to highlight two tips to make controllers in Laravel feel much lighter.
– twitter.com – Edit
? Ever wanted to use the same controller to serve multiple formats?
— Adam Wathan (@adamwathan) February 15, 2018
Check out this set of macros that let you hit a single endpoint with different extensions to request the format you want:https://t.co/2sFGNf97be pic.twitter.com/HMNdicUWAy
?? Here's what it looks like in use: pic.twitter.com/zHo0GlAU6w
— Adam Wathan (@adamwathan) February 15, 2018
Read more [twitter.com]
– Edit
At this year's Laracon US Adam Wathan gave a talk titled "Cruddy By Design" on how to structure your controllers better. After the conference he published a new GitHub repo that contains the demo app he refactored on stage. The 4 main tips to improve your code come as PRs on the repo with a full description on why the change is valuable. Very cool stuff.
Using this convention as a "rule" is a good way to force yourself to keep your controllers from becoming bloated, and can often lead to learning interesting new things about your domain.For the presentation, I put together a demo app called "CastHacker" that showcases podcasts about software development. It's not a "real" app by any means (lots of imaginary features, no tests, etc.); it's just enough code to demonstrate the concepts from the presentation. Feel free to clone it and play with it locally if you like though.
I've written up each refactoring I shared in the presentation as a detailed pull request.
– Edit
Jerome Dalbert on his blog:
Splitting your Rails controllers when they have a very specific scope, too much logic, or too many mixed concerns can have a lot of good side effects in your code.It doesn’t mean that you never abstract. It just comes later down the road. At some point some logic needs to be shared by several controllers. Sometimes even a splitted controller with only one public method gets too big. Et cetera. This is where concerns, model methods, possibly background jobs, and even sometimes service objects (hopefully not too many) come into play.
The more your app grows, the more time you will need to spend to understand it, no matter how clean the code is. But splitting your controllers makes things easier.
http://jeromedalbert.com/how-dhh-organizes-his-rails-controllers/