Wire data into Blade with view composers In the last article we touched on sharing data with multiple views, but we never looked at why we would want to do that. Before we dig through view composers, we really should understand what question they’re trying to answer. https://www.dinocajic.com/laravel-p61-sharing-data-with-all-views/ What is a View Composer? Is a View Composer a Laravel term? No. A view composer is a design pattern used in web development that helps to separate the concerns of generating view data and rendering views in a web application. In a web application, views often require data from multiple sources, such as
Tag: Web Development
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
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
Implement effective DI patterns for cleaner, testable Laravel code I hope that the last article made sense. Dependency Injection really is a simple concept. I feel like you should understand it in its entirety before you state that you know “Dependency Injection in Laravel.” Before we get into Dependency Injection again, you should understand Laravel’s service container. What is a service container in Laravel? It’s simply a tool that manages dependencies and it is this tool that actually performs the dependency injection. https://medium.com/geekculture/laravel-p48-dependency-injection-concept-high-level-php-concept-482e9f13d97b In the previous article, we looked at an extremely simple dependency injection example. <?php class Driver { private Car
Elevate your Laravel apps with Vue, Tailwind, and Vue Router Do you keep your backend completely separate from your front-end or do you try to integrate the Vue and Laravel structure into one project? I prefer the latter. It’s not as intuitive as it should be. I used to love the UI presets before, where you can select either React or Vue and move on. Although not terrible, we do need to set this up properly. Installing Vue First, setup a new Laravel projects. I’m using Docker on a Mac, so my installation is pretty straightforward. curl -s “https://laravel.build/laravel-vue”