Keep every Blade view in sync—share once, use everywhere Let’s get back to views. There are a few more concepts that we should cover, like how do you share data with all views? We’ll recap what we’ve done so far and take a look at an another option. https://www.dinocajic.com/laravel-p60-resource-route-names/ How Have We Passed Data to Views So Far? The second argument of our view method accepts an array of data. In the example below, we grabbed the data from the database and passed it to our view. public function index() { $cars = PersonalCar::with([‘brand’, ‘model’])->orderBy(‘year’, ‘desc’)->get(); return view(‘personalcars/index’, [ ‘title’ => ‘Personal
Articles
Name routes your way One advantage of creating routes in Laravel is that you also get to name those routes. So, when you need to reference them, you simply reference the name and not the route itself. If you later decide to change the route, your code still works since you’re referencing the name and not the route itself. https://www.dinocajic.com/laravel-p59-partial-resource-routes/ If you remember from an earlier article, we used the name method to name our route. Route::get(‘/get-started’, function() { return “Get Started”; })->name(‘getting-started’); To name a resource route is not too different. We just need to override the names that we want
Register only what you need with partial resource routes If you haven’t figured out Laravel’s flexibility just yet, I believe this article will definitely solidify it. Not only did the Laravel developers think of most common concepts, they’ve also though about exceptions to those concepts. https://www.dinocajic.com/laravel-p58-resource-controllers/ For example, in the previous article we walked through resource controllers and we finished with creating all of the routes with a single line of code. use App\Http\Controllers\CameraController; Route::resource(‘cameras’, CameraController::class); But what if we didn’t want to utilize the resource route creation technique for all of our routes, but we wanted to utilize its
Simplify CRUD with resource controllers There are a set of repetitive tasks that occur on most resources. If you wanted to display cameras on your web-application, you would most likely want to: View all Camera See a form to insert a new camera Process the camera insertion Retrieve a particular camera See a form to update a camera (with fields already pre-populated) Process the update Delete a camera https://www.dinocajic.com/laravel-p57-controller-middleware/ What if we stepped and looked at the characteristics of a camera, like the camera’s brand and model. We could have a resource controller for each of those as well where
Secure actions with controller-level middleware Where do you add your middleware? We looked at adding it to our routes file, but we also added it to our Kernel.php in a previous example. Now we’re looking to add it to our Controller? Won’t this get confusing? https://www.dinocajic.com/laravel-p56-dependency-injection-in-controllers/ If you need to freshen up on the middleware in routes topic, check out the article that I wrote on it when we looked at route groups. https://medium.com/geekculture/laravel-p54-route-groups-middleware-and-controllers-f41804f40d31 We looked at adding it in our Kernel file when we were implementing the throttle:web middleware. <?php namespace App\Http; use Illuminate\Foundation\Http\Kernel as HttpKernel; class Kernel extends HttpKernel { // … /** *
Inject services, unclutter your controllers Since we just tackled everything route related, the next logical step is to get into Controllers. There are those that would have argued that we should have covered migrations, Models and then Controllers/Routes/Views, and there’s no disagreeing with that statement. Maybe I should write two Laravel article series concurrently. In the routing concept, without getting too far into the weeds, the Controller comes next. https://www.dinocajic.com/laravel-p55-soft-deleted-models-in-routes/ It’s not that we haven’t covered controllers yet, we just haven’t dug into some of the more infrequently/complicated functionality yet. Most of the concepts that we have already covered in
Route to trashed records with confidence Running through a tutorial series like this isn’t as straightforward as it seems. You want to cover topics in a specific order and yet each time you get to a new topic, you realize that you need to cover something else in order to do it. For example, after going through some of the easier topics in Laravel, I figured we could tackle some of the topics on their own, like Routes, Models, Controllers, etc. I’m in somewhat of dilemma right now. The last topic of the route series that I wanted to cover
Organize routes, secure them, and keep controllers lean The final topic that I wanted to touch upon in the web.php file are routing groups. We’re not fully finished talking about routes considering that we really haven’t even touched on the api.php file, which is used frequently as well. https://www.dinocajic.com/laravel-p53-rate-limiting/ We looked at route groups in an earlier article. If you need a refresher, you may check it out here. https://medium.com/geekculture/laravel-p23-route-groups-8d4ce3e8e083 What I really wanted to focus on here is adding middleware to a group and grouping a specific controller. Applying Middleware to a Group To apply middleware to a specific group, you simply use
Throttle traffic, keep your API safe For the sharp-eyed readers, you might have noticed a method called configureRateLimiting in the RouteServiceProvider in our previous article. protected function configureRateLimiting() { RateLimiter::for(‘api’, function (Request $request ) { return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip()); }); } What this does is limits the user’s requests per minute. The default is set to 60 requests per minute. If you needed to modify the number of requests, this is where you would typically do it (i.e. change it from 60 to 100). https://www.dinocajic.com/laravel-p52-explicit-route-model-binding/ As you can see in the code, the rate limiter’s are defined in the RateLimiter facade’s for method. It accepts a rate limiter and a closure that returns
Take full control of model resolution in your routes When would you ever need to explicitly bind a model vs utilize Laravel’s implicit binding? A frequently asked question that I frequently find doesn’t have an appropriate, or simple enough, response. Because of that, I don’t see it used as frequently as it should be. https://www.dinocajic.com/laravel-p51-route-model-implicit-binding/ In the previous example, we used the following implicit route-model binding technique. use App\Models\User; Route::get(‘/implicit-binding/{user}’, function (User $user) { return $user; }); What if we wanted to only return the user that has been verified. What I normally see is the following code: use App\Models\User;