Views are a means for displaying your data. You should always strive to keep any logic and calculations out of your views at all times, instead carrying out all of this implementation in your controllers. This leaves your views slim and simple to reason about.

Although Laravel supports templating with plain PHP files, Laravel's Blade templating engine is simple and powerful. It provides control structures that allow you to iterate over arrays of data that you might return from your database, conditionally display content, inherit from and extend other layouts, and even abstract reusable components.

Naming and usage #

View filenames must be camelCase.

View files should be named alongside your routes, wherever possible. It's easier to locate the view file for the users.index route if it is in resources/views/users/index.blade.php and not called accounts.blade.php or userIndex.blade.php.

class UsersController
    public function index()
        return view('users.index');

Blade Templates #

Always use four spaces for indentation.

    <li><a href="{{ route('', $user) }}">Michael Dyrynda</a></li>

Control structures should not be surrounded by, or contain spaces. Whilst this is not necessarily "better" or "worse" than alternatives, it is a stylistic choice of formatting for projects based on Founder.

// Good
    Something good

// Bad
@if ($condition)
    Something bad
@elseif ( $someOtherCondition )
    Also bad

HTML Attributes #

HTML attributes should always be written in the same order as described in Mark Otto's code guide.

When working with HTML elements that have many attributes, align the attributes one under the other for easier readability. Ensure the closing bracket sits on it's own line, underneath the opening tag's opening bracket.

This also aims to reduce unnecessary changes in version control if you were to change the last

<a class="no-underline hover:underline text-indigo"
   title="View user Michael Dyrynda"
    Michael Dyrynda

View composers #

View composers allow you to inject data into each specified view in your application. They are useful, for example, to push the authenticatd user into all of your views and indeed whether or not you have an authenticated user at all.

Use View Composers with caution, however, as whilst they are a good way to share data with your views, it is not always apparent to a new - or even return - developer in your codebase to know where the variables come from and where they are defined. If you do use them, create a fresh Service Provider and be sure to include Composer in the class name to make its purpose clear.