Laravel: View Composer

Marcel Domke
Dec 2, 2018 · 3 min read

I am working since version 4.2 with Laravel and I am still a big fan of it. Of course over the years I learned a lot about it, ran into issues, was cursing, but still I am excited to check out what is coming up next.

One of the exciting features Laravel provides is the view composer. In my opinion a really powerful view extension which allows the developer to pass variables from a global point to the template.

First of all you need to know that there are two different types of view composers. Class based and Closure Based.

The difference is pretty simple, closures are easy to use without putting to much effort into the setup but they lead to overloading of the service provider.

Class based view composers on the other hand lead you directly to the design principle separation of concerns. Another benefit is that you are able to test isolated this piece of code and it is easier for other developers to maintain the existing code.

In computer science, separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity and encapsulation with the help of information hiding.

In the example, you can see that the View::composer method has two parameters.

The first parameter is a string or an array of view names, which you want to listen to. This means, if this template gets rendered, your view composer gets triggered and will pass the included variables to the view.

Instead of selecting all templates manually you can also use wildcards. This can be done by the Asterisk (*) character and it is really useful if you want to append data to every view, even more if the application has a complex template structure with several subfolders.

Use cases could be for example the sidebar or navigation elements which need to be in each view.

The second parameter is either the closure or the class name of the view composer.

In both ways you have the parameter $view bound as a parameter and with it you can simply append variables to the view by using the method ->with().

As you might know Laravel works a lot with providers you can now guess what is coming next? Yes, we have to register a service provider and within the provider we can make use of the just learned usage of the view composer.

View Composer Service Provider

The only thing left now is registering the new service provider in the ~/config/app.php

That’s it, now we are good to go and can test the view composer.

Let’s imagine we have a page called /detail and this page needs a simple array of navigation items (see code below).

Navigation Composer example for the test

To test now our view composer Laravel provides us the right tools, by using ->assertViewHas(). This method checks if our view composer is listening to the right view and appends the variable $navigation to it.

View Composer test

I know this is the most basic test you could possibly write, but it is a good start to see if the view composer works.

Either closure or class based view composers will simplify the code and make it easier for other developers to work with it. Also it is a part of Laravel and why should we not use such a powerful service.

I am looking forward to new features of Laravel and I hope that I was maybe able to show you something new.

Marcel Domke

Written by

Lead Developer / Cloud-Services Cloud-Panel at ABOUT YOU GmbH Employed since 01.06.2015