Josh Hanley

How to structure your layout file for Livewire

2021-01-11T12:00:43+11:00

In the previous article “How to use layout components in Livewire” we went through setting up an app layout component that Livewire can find. This article goes through setting up its contents for use with Livewire by adding the Livewire tags and going through a way to manage your header and page title.

The default app layout

Now that your layout component is configured to be recognised automatically by Livewire, it’s time to setup its contents to get Livewire running.

Open up your app.blade.php file.

If you are using a front end scaffolding like Laravel Breeze or Jetstream, or upgrading the layout file in an existing app, then you will already have a layout similar to below.

If you aren’t, you can always copy it from Laravel Breeze as it is a great starting point. But you will need to modify it as it contains asset links for app.css and app.js, which will need to be compiled, and that is not covered in this tutorial (just remove them if you won’t be using them).



    
        
        
        

        {{ config('app.name', 'Laravel') }}

        
        

        
        

        
        
    
    
        
            @include('layouts.navigation')

            
            
                
                    {{ $header }}
                
            

            
            
                {{ $slot }}

The Livewire app layout

The first thing to do when you setup Livewire in any app, is to configure Livewire’s styles and scripts tags (see Include The Assets).

To do this, we are going to use the blade component tag syntax, so it is consistent with the app layout component we have already setup.

In your app.blade.php file, you need to add inside the tags. I would recommended adding it after any other css stylesheets or style tags you may have, to ensure the Livewire styles have priority, as they contain some visibility and animation keyframe styles that Livewire needs to work.

Then you need add to the end of you body tag right before the closing tag. This ensure’s that Livewire runs after the page has finished loading.

But there is a catch. If you are installing Livewire into an existing app, you may already have some script tags or javascript assets added to the end of your body tag. If this is the case, then you need to make sure you put Livewire’s scripts first, before any other javascript libraries or script tags. Otherwise if you try to call any of Livewire’s javascript functions from any of these script tags or javascript files, then you will get errors.

NOTE: Put Livewire’s script tags at the end of the body, just before the closing tag but before any other javascript libraries or script tags.

Your layout file should now look something like the below. I have removed most things from the tags just to make the example shorter.



    
        
        
    
    
        
            @include('layouts.navigation')

            
            
                
                    {{ $header }}
                
            

            
            
                {{ $slot }}

With this setup Livewire will auto populate {{ $slot }} with the contents of your Livewire component blade file.

So you should be all ready to go to start creating components.

The rest of this article assumes you know how to setup and use a Livewire component, if not please see Making Components and Rendering Components in the Livewire docs.

But what about the header?

You may have noticed that there is a header in the default Breeze layout, which outputs the contents of the {{ $header }} variable.

But if any of you actually tried to setup a component using this layout by now, will know that we would currently be getting an error “Undefined variable: header”.

The $header variable is populated using a named slot (see the last section of Blade Templates - Slots).

You can populate the header slot by adding the x-slot tag with the name header at the top of your Livewire component blade file.

Now you may have seen in the Livewire docs “Make sure your Blade view only has ONE root element.” (See Returning Blade Views).

This is the only exception to this rule, as the blade compiler will actually remove the tags and their contents, and insert them into the correct location in the layout file.

Making the header interactive

With your header slot all configured, you may get to a point where you want to add a create button inside your page heading.

That should be simple enough, inside your Livewire component blade file, populate the tags for your header with a button and add wire:click to it . Making sure your Livewire component class has the corresponding method (but that is outside the scope of this tutorial).

Once added, refresh your page, click “Create!” and BAM! Nothing happens…

Not what you expected.

The reason is that, although the header slot contents were saved in the Livewire component blade file, when its rendered, those contents were actually outside of the area which Livewire can control. The area it currently has control of is everything inside {{ $slot }}.

If you look back at our layout you will see {{ $header }} is above this, so the blade compiler removes the header tags and contents from our Livewire component blade file, and adds them into the layout here.

This makes it inaccessible to Livewire which means the wire:click on the button won’t do anything.

How do we fix this?

First we change the body tags in our app.blade.php layout file to only have a slot and Livewire scripts (and any other javascript libraries and script tags).



    
        
        
    
    
        {{ $slot }}

Then we can create a page layout component with everything we just took out of the body tag.

Create a file called page.blade.php in out layouts folder.

resources/views/layouts/page.blade.php

Open it and add all the layout information we removed from the body tags (note it will also have it’s own {{ $slot }} tag).


    @include('layouts.navigation')

    
    
        
            {{ $header }}
        
    

    
    
        {{ $slot }}

Again to get this to work as a component, we would have to follow the same process as we used in the previous article, to create an inline blade component, this time for the page layout.

# Creates app/View/Components/PageLayout.php
php artisan make:component PageLayout --inline

Open PageLayout.php and change the render method to point to the new page layout view.

// app/View/Components/PageLayout.php
public function render()
{
    // Resolves to resources/views/layouts/page.blade.php
    return view('layouts.page');
}

Then back in your Livewire component blade view, just wrap everything you had in your tags.

Now go back to your browser, refresh, and click on that “Create!” button in the header.

It should now work! Success!

The page title

The last thing which is common to want to set, in your app layout, is the page title.

The default title in the head section of the Breeze layout looks like this.

{{ config('app.name', 'Laravel') }}

But you may want to specify a different title for each page of your app, or have a default if there is no title specified.

So I would recommend changing it to a named slot, for title, with a fall back of your app name.

{{ $title ?? config('app.name', 'Laravel') }}

This will allow us to populate the title of the page by passing it through the title named slot.

There are two ways to do this with Livewire which I will list below.

But be aware, no matter which method you use, Livewire will only set the title of the page on the first load. So if you try to change it in a subsequent request, within the same component, it won't change. If you need to do that, you will need to use javascript to do this.

Livewire will only set the title of the page on the first load.

One way is to add the title named slot, which contains your desired title, to the top of our Livewire component's blade view, like we originally did for header (but outside the page layout tags). The title will only take a string so I wouldn't be trying to add any html to this.

Our new page title

The other way is to specify it in the render method in your component class, by passing it as a data property into the layout method (see Configuring the Layout Component).

public function render() {
    return view('sample-component')
        ->layout('layouts.app', ['title' => 'Our new page title']);
}

The downside to this method is you need to specify the app layout for this to work.

Your app layout should now be all configured and ready to go.

If you have any questions or I have missed anything, please let me know.

Hope this helps!

How to use layout components in Livewire

2021-01-11T12:04:18+11:00

How to make an app layout component that can be used in your blade views and automatically used by full page Livewire components.

Setting up a layout component

Recently I converted my app to use blade components and one of the components I setup was for my app layout.

My original app layout file was stored at resources/views/layouts/app.blade.php and used @yield syntax (see Layouts Using Template Inheritance)

To make this a blade component, I moved the file to resources/views/components/layouts/app.blade.php and changed it to use the {{ $slot }} syntax (see Layouts Using Components).

This allowed me to wrap the contents of a blade view in an app layout tag like instead of using @extends and @section tags.

Now all my blade views can make use of that app layout component tag.

That layout component doesn’t work with Livewire (yet)

Out of the box, that app layout component won’t work with Livewire though.

When I started using Livewire, I saw that Livewire automatically uses the app layout file and populates {{ $slot }} for you (see Full Page Components).

That meant I didn’t need to wrap the contents of my full page Livewire component blade views with the app layout tag, as Livewire will handle that.

But for some reason that didn’t work. Nothing would load.

If you look closely at the full page components docs though, you will find that Livewire is actually looking for your app layout file in the old layouts location resources/views/layouts/app.blade.php, not in the components directory.

So Livewire can’t find find our newly created app layout component, as it’s looking in a different location.

To work around this, you have to resort to manually specifying it in your full page Livewire component’s render method, like this

public function render()
{
return view('livewire.sample-component')
->layout('components.layouts.app');
}

That’s painful though, as you have to specify this inside the render method of every full page Livewire component (trust me as I did this).

But there is another way.

The new app layout in the old app layout location

There is a technique you can use which makes use of a blade component class to point at a blade view file that is stored in a different location.

Take the new app layout component blade file, that uses the {{ $slot }} syntax, and move it back to the old location resources/views/layouts/app.blade.php, but keep the new syntax.

You can then create an inline blade component called Layouts/App

php artisan make:component Layouts/App --inline

Which generates this blade component php class (but no corresponding blade view)

app/View/Components/Layouts/App.php

Open up the newly create class and look at the render method, it will look something like this

public function render()
{
return <<<'blade'



blade;
}

Inside the render method, delete all the heredoc code (everything inside the render method) and instead you can return your app layout view (which we moved back out of the components directory earlier)

// app/View/Components/Layouts/App.php
public function render()
{
// Resolves to resources/views/layouts/app.blade.php
return view('layouts.app');
}

Now we are back to the way it was before, where you can use your app layout as component tags inside your standard blade views

Livewire can now also find it in the correct location, so you don’t need to use the layout method inside your Livewire render method. So you render should look something like this

// Your Livewire component class
public function render()
{
// This auto finds the layout in resources/views/layouts/app.blade.php
return view('livewire.sample-component');
}

That’s all there is to setting up a layout component that can be used in blade templates and by full page Livewire components (without having to specify it each time).

Read on if you want to look at how to change the layout tag to a different name that Laravel Breeze and Jetstream both use.

A better layout tag name

Laravel Breeze and Jetstream both make use of as their layout tag.

It would be much nicer if we could actually use for the tag as I find it reads better than . It also means we don’t have a component class file called App.php which could be confused with other app references.

If you prefer this, you can move the Layouts/App.php php class file that we generated earlier to the base components class directory and rename it

app/View/Components/AppLayout.php

Make sure you also open the file and change the class name to AppLayout.

Now your blade views can look like this

And Livewire shouldn’t be impacted as we didn’t touch the app layout blade view.

This is how Laravel Breeze and Jetstream both handle this, see example in their respective GitHub repositories below.
breeze/AppLayout.php · GitHub
jetstream/AppLayout.php · GitHub

Update:
The second part to this has been published, check it out How to structure your layout file for Livewire.

Hope this helps!

Why Livewire and why this blog?

2020-12-18T16:23:39+11:00

This article goes into why my excitement for Livewire led me to use it in my apps, contribute on GitHub and start this blog. Read this to find out how my Livewire journey began.

The desire

I’ve been watching the development of Livewire since v1 was released at Laracon in March 2019.

I loved the idea that everything was written in php and blade, which reduces my need to use javascript frameworks.

My main app had a mix of standard blade pages and some with small VueJS components mixed in. None of the Vue code in my app was unit tested. I don’t like switching contexts between blade and Vue when coding. Plus passing data from blade into Vue never felt great.

As you can imagine I was keen to convert my app over to Livewire and remove Vue. I started experimenting with it, make small test apps that contain some of the components my main app would need.

The delay

But converting my Vue code to Livewire had to wait. Even though this only added to my desire to get started, important things had to happen first.

I was in the process of converting my app from blade partials to blade components while also doing a redesign. Livewire integration would have to wait until that was all done.

While I was finishing the conversion, v2 of Livewire was released, in September 2020, with a whole heap of quality of life/ development improvements. That really solidified my desire to use Livewire in my app.

I finished the conversion to blade components around mid-October 2020, except for one complex form that was using Vue components for interactivity.

I’d intentionally left this form out, as it presented a good opportunity to finally get stuck into using Livewire, as it required interactivity. My intent was that I’d convert from Vue straight to Livewire and implement any blade components as I went along.

The start

This seemed like it was going to be pretty straight forward.

One of the core components in this form is that it has autocomplete inputs which integrate together. A complex task that has been done many times before.

What it needs to be able to do is filter (cascade) the results of one autocomplete input based upon the options selected in previous inputs; or have the option to auto populate multiple input fields based upon the selection in one dropdown.

So naturally, I jumped right into trying to build an autocomplete dropdown component using Livewire and AlpineJS.

For the AlpineJS side, I had just seen a great tutorial by Dan Harrin on “Building a custom select input with Alpine.js and Tailwind CSS”. I used his ideas as base for creating my Livewire/Alpine autocomplete.

I got an Alpine autocomplete working quite quickly with static data thanks to Dan’s tutorial, and started trying to integrate data from Livewire.

That’s when it all fell apart.

The problem

V2 of Livewire introduced a new feature called @entangle (see Sharing State Between Livewire And Alpine: @entangle). This offered the promise of syncing properties between Livewire and Alpine.

But as it was a new feature, it had some bugs. I opened a couple of issues on the Livewire GitHub along with some PR’s which added failing tests demonstrating the issues.

Now there were certainly work arounds, I could have gone back to managing the syncing of properties myself like others had done before entangle became available in V2. But I believed that entangle was a really handy feature, and with a few bug fixes, should work quite nicely.

At the time, I didn’t know much about how Livewire operates, so couldn’t be of much help fixing the entangle problems.

The solution

What I could do though, was help with issues that other people might be having, which has the benefit that I will learn more about Livewire in the process (and maybe it’ll free Caleb up to fix these more complicated bugs 😆).

I started going through the Livewire issues on GitHub and spending time on the Livewire Discord helping other people out with their problems.

I found that I really enjoyed helping others fix their problems. I’d previously worked for about 8 years in IT support, but there is a big difference between fixing general computer problems and trying to work out why someone’s Livewire code doesn’t run properly. Certainly a lot more interesting!

Plus I got to know a lot of Livewire’s features really well, through taking a problem someone was having, running their code, and experimenting with it trying to get it to run. A lot of the time it sent me digging through the documentation or Livewire core code to find out exactly how something works, to be able to better understand the solution.

This has the added benefit that it makes developing my apps quicker and smoother as I’m familiar with the common problems, have a better understanding of how it all works together, and know what features are available.

The blog

That’s where this blog comes in.

Up until now, I didn’t have a personal website or blog, as I wasn’t exactly sure of what I would write about.

But, as I’m solving problems I am finding a lot of interesting ways to achieve things and fix common problems, that I’d like to document and share so others can benefit from it.

So that’s how this blog began.

I hope that the content here can be useful to someone. Feel free to contact me on twitter or discord if have any questions, ideas or just want to chat!

And as always,

Hope this helps!
Josh