Extend Blade on your terms How many times have you wished that a specific directive existed in Blade? If the answer to that question is “many,” then do I have a surprise for you. You can create your own directives in Blade. First, you need to create a service provider using the php artisan make:provider command. This provider will register your Blade directives with Laravel. # php artisan make:provider CustomBladeServiceProvider INFO Provider [app/Providers/CustomBladeServiceProvider.php] created successfully. # <?php namespace App\Providers; use Illuminate\Support\ServiceProvider; class CustomBladeServiceProvider extends ServiceProvider { /** * Register services. * * @return void */ public function register() { // } /**
Category: Laravel
Embed logic directly into your HTML In the last article we covered the @class and @style directives to implement conditional styling in Blade. But, there are other HTML attribute directives that are present in Blade that we can utilize: @checked directive @selected directive @disabled directive @readonly directive @required directive @checked directive With the @checked directive, the radio button or checkbox will be checked if the condition is truthy. Route::get(‘/directive-test’, function () { return view(‘html-directives.index’, [‘isActiveVar’ => true]); }); The $isActiveVar variable is set to true and passed to the html-directives.index Blade file. <label for=”isActive”>Is Active?</label> <input type=”checkbox” id=”isActive” name=”isActive” value=”isActive” @checked( old(‘isActive’, $isActiveVar) ) /> Inside the Blade file, the @checked directive accepts an argument that will be truthy.
Style smart, render dynamic With Blade Components, conditional styling refers to the ability to add different styles to HTML elements based on certain conditions. Blade provides several conditional directives that can be used to accomplish this. The @if directive can be used to conditionally apply styles to an element based on a specific condition. For example, to apply a different background color to an element based on a variable value, you could use: @if ($showRed) <div style=”background-color: red;”> Red Background </div> @else <div style=”background-color: blue;”> Blue Background </div> @endif We can test this with the following route: Route::get(‘/conditional-styling’, function () { return
Environment checks made simple There comes a time when you want to use environmental variables in your Blade components. But, how do you do it? There are a couple of different ways. We’ll take a look at the env() function first and then the directive itself. https://www.dinocajic.com/laravel-p64-rendering-jason-in-blade/ Using the env() function Let’s open our .env file and take a look at some of the variables that are already defined there. APP_NAME=Laravel APP_ENV=local APP_KEY=base64:X2mYdNpqK29Z21Fb9Dx6PDa6Jwd6k4ThXuP+VYd9dco= APP_DEBUG=true APP_URL=http://laravel-tutorials.test LOG_CHANNEL=stack LOG_DEPRECATIONS_CHANNEL=null LOG_LEVEL=debug DB_CONNECTION=mysql DB_HOST=mysql DB_PORT=3306 DB_DATABASE=laravel_tutorials DB_USERNAME=sail DB_PASSWORD=password We can access any of those variables with our env() function. Create a new Blade file and a route to access it.
Serve structured data straight from Blade Continuing with our previous theme on views, let’s get back into Blade. We frequently work with JavaScript and need to utilize the array data that’s sent from our Laravel application to our Blade component. How do you transform that data from a Laravel type array to a JSON file? https://www.dinocajic.com/laravel-p63-optimizing-views/ The first method is something that you’re most likely familiar with: json_encode. While this does work, there is a better way to do it and that’s utilizing the Js::from method. This method ensures that your JSON is properly escaped. If you’re running on a newer version of
Render faster, shine brighter We’re wrapping up our discussion on views and what better place to finish up on than optimizing our views. https://www.dinocajic.com/laravel-p62-view-composers/ Normally, Blade templates are compiled when requested by the user. Laravel will check to see if a compiled version of the view exists first, and if it does, it will send it, otherwise it will compile it and then send it. If a compiled version exists, Laravel will determine if the uncompiled version has modifications that are dated after the compiled version. If they are, Laravel will recompile the view before sending it. As you can
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
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