It happens we need to handle some widely available variables and pass them to our blade files. Instead of using the view()->share() function from our controllers, we should consider using a different approach, the composers.

Getting started with composers

In many cases, we share data from our controllers. For smaller projects it’s fine, but as our project starts to grow, we might move the logic to a dedicated class. It keeps our controller cleaner, and we collect similar functionality to the same place.

It’s a good idea to make a new service provider, where we are defining the data for the specified routes. With the make:provider command Laravel generates the provider. The only job left is to extend our providers array in the app config.

Defining our view composers

We call the composer method on the View facade. With the first parameter, we have the possibility to specify a directory or a wildcard where the given data should be shared. The second parameter is a closure where we can define the variable name and the data we want to pass. We are also able to give a composer class as a parameter instead of creating a closure.

// app/providers/ComposerServiceProvider.php

<?php

namespace App\Providers;

use Illuminate\Support\Facades\View;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\ServiceProvider;
use App\Http\Composers\ProfileComposer;

class ComposerServiceProvider extends ServiceProvider
{
    public function boot()
    {
        View::composer('*', function ($view) {
            $view->with('currentUser', Auth::user());
        });

        View::composer('admin.*', function ($view) {
            $view->with('role', Auth::user()->role);
        });

        View::composer('*', ProfileComposer::class);
    }
}

In the first example, we use the wildcard what makes accessible the $currentUser variable across all the views. To share variables for particular views, we can use the view directory names to restrict the access of a variable. Like in our second example we prefix the wildcard admin. parameter, to make the $role variable accessible only in views, what take place in the admin directory.

In the third example, we pass a composer class as the second parameter. It’s recommended when your logic is using other services, or it’s just not that simple to keep it in a closure. You can see a specific example in the official Laravel documentation.

The point of using composers

We can work with variables in our blade files in the same way. There is nothing to change or fix. The point is we share data with the views in one dedicated class, instead of using the view()->share() function all the time. That makes our controllers a bit cleaner. Of course, there are some cases when we need to use other solutions, but this is a nice way to reorganize logic and keep clean the main part of our application.

You can read more about the composers in the official Laravel documentation.