Why Livewire and why this blog?

Friday, 18th December 2020

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!

Theme: Light - Dark - System