The Evolution Of The Make Command
The "make:livewire" command is one of the first things a new Livewire user types. It feels natural, and lacking in surprise. Surprisingly, it was quite a long road that led me here. Let's walk down that road.
Transcript:
[00:00:00] Caleb: Okay today I have this is a really fun one for me. It's pretty light on on the actual programming. So you shouldn't have to wrap too much around your head. But yeah, so Artisan, it's all about artisan. Make Live Wire that's what we're going to talk about artist and make live. Where is the first command you run when you're working on a live where component it creates your class and your view for the component and it should feel pretty natural.
You say artisan, make: Livewire counter and it creates a counter class and it creates a counter blade View and it's a simple as that. And this is an invisible feature this to you should feel natural and you should never think to yourself. Oh my gosh Livewire. It's so magnificent. This is so clever. You would think this is the obvious command for creating a component. Unfortunately. This is kind of the nature of these problems is that I almost never arrive at the obvious solution right away. It takes time. So I'm [00:01:00] going to tell you A Tale of the evolution of the Live Wire make Command and how it got to become an invisible featured like it.
So my knee-jerk reaction for a command will first I didn't even have commands to make to make live where components but I thought you know, wouldn't it be really nice if there was just a built-in, you know, make live where right. So at first it was Artisan Livewire: make because all my Live Wire commands were artists in Livewire colon, and then the command which makes sense you would sort of namespace that under Live Wire that makes sense. So I had Artisan live where: make then you would pass in the class kind of like you. Taking a test in live in laravel. So if you wanted counter you would do capital c. If you wanted a subdirectory, you would say components. Let's say it was components directory components backslash backslash counter just the way you would when you're Artisan making a tester or anything.
So that's what I initially had because that's sort of what felt natural in the moment [00:02:00] a couple Hang-Ups with this. One of them is that I would have to create the view manually. So every component has a class and a view and my first error was sort of thinking was just naturally I was. Of Livewire components as the classes and that the view section the template section was sort of secondary to it.
And that's my first mistake. I've slowly changed that thinking well, I guess I've if I thought about it, I never agreed with that way of thinking but that's just how I naturally approached problems like this because I had that in my mind. So that was the original incarnation of of Livewire make it was Artisan Livewire make and then the class name and then you had to create the view separately.
I had thought about create adding some sort of option or tag that you could do - - view to create a view as well kind of like adding a migration and a factory when you're making a model. The reason I resisted this is because I know in Lawton laravel, there's no artisan make View and that's something that I've looked for in a lot of people look for there's no artisan, make View [00:03:00] and I've read.
There's been pull requests for it. There's been comments and GitHub issues about it, but it's always been rejected. And I think there's even a third party package. I want to say by Yaz. I don't know maybe not but there's a third party package. I believe that offers this functionality for creating a layer of Bellevue. And I think one of the things is that unlike like a view, you know, and it's not as opinionated in laravel. You can customize the views directory and it's an array so you can add multiple directories for views so for reading that's fine, but for writing you have the decision of which director do you write to so that's probably one hang up the Taylor has I don't actually know the full story behind all this but I'm guessing that's sort of a. So and maybe it's also like when you're creating a view there's really no like boilerplate. It's just a file, but I know that I would like the ability to create a view in the command line because it just saves me having to right click new file in the right folder and type in the name. [00:04:00] So anyhow with Livewire I just immediately just thought that that was a bad idea because I guess Taylor thought it was a bad idea. So I just shouldn't do it. So then I was actually just going over some of my user testing notes. This is great because. I did a bunch of user tests with live where that's a story for another time how important user testing is, but I did a bunch of user tests for Livewire and I wrote them all down.
I wrote notes for all of them inside bear. So I just kind of searched user tests inside my bear Notes app and found all my live where user tests so I'm sort of flipping through and I find David hem pills. He's one of the first user tests. I. And I read through the notes and one of the notes says this is really funny because I totally forgot about this.
It says create view by default. No need to add - - view so maybe I had - - view available at this point in time, but he probably was like, oh like you should just create the view by default. I'm like, really you think that's okay and he's like, yeah, man, I would want it then he gave me permission.
Basically, I needed permission. [00:05:00] And once he gave that permission me, I was like, all right, let's do it. Never looked back never look back completely forgot that it didn't create the view by default automatically, then there's no other way. It just creates the class and the view for you right now.
So that was the first obvious Improvement was like well, yeah create the view and then that became invisible. Nobody cares. Nobody goes. Oh how cool it creates the view for you. They just go that's that makes sense. Okay, so the second thing is Artisan Live Wire make. And then the class name, I would accidentally type artisan make Livewire and then I'd have to you know, backspace backspace backspace and then correct myself and when I was doing these user tests and I did it, but I never noticed it.
It's just kind of my knee-jerk reaction. I didn't really think much of it. So I'm doing these user tests and I'm finding most people are doing the same thing. Most people forget. If it's Live Wire maker make Live Wire and they default to make: Livewire because every other artist in make Command is that way make: test make: model whatever.
So that [00:06:00] was one of those things that just came out of me really putting live wire through the fire as far as user testing and seeing that that's the way people's brains worked. So I thought well. I should change it to Artisan make live where because that's the natural thing. That's what people just reach for so I changed it and it became artisan make live.
Okay. So the next Improvement is it was you're still were specifying the class and that felt weird because it somehow felt like the class was a priority. Also when you're referencing a live wire component you would do at Livewire. Oh my gosh, I'm remembering things at the time when you included a live where component so right now with the counter component you do at Livewire and you pass in a string lowercase.
And if you have multiple words, it's Kebab case hyphenated. Like some counter would be some - counter right kind of like blade views same kind of casing so in the make Command. Well, sorry before in that in that blade directive. I didn't have that [00:07:00] ability. Mostly it was actually offered both out of the box. You can reference the class directly the component class. You could say at Livewire a. Backslash HTTP backslash Livewire backslash counter colon colon class or you could register an alias like you would in laravel component so you could say like Livewire. Counter and then pass in the component class.
So that's how it worked at the time that a lot of people I did user tests with were like I don't like referencing a class in my blade views that feels weird to me and I'm like, yeah, I know I kind of get that. I feel that way too. But are you going to like register a component for every single live where?
No, not really. So I forget the exact details of how that all changed. But basically that was another learning process for me was realizing that most people don't want to reference the class directly. So they're going to have to register these aliases and that's extra load. That's just extra work that you have to do. So that's a whole [00:08:00] other story of me implementing Auto registering Livewire components when you create a component, it's automatically detected Livewire has a manifest file that keeps track of all the components that have been generated and it automatically detects them. So anyway, that was another step in making this process invisible.
So now it's just a live wire, you know, make a sorry artisan make Live Wire and then counter so. That being said I switch to the auto registering thing. So now it's just you just reference it as lowercase count or counter in a string. So the final step was artisan make Live Wire and then instead of typing out the class name your typing out the name of the component and then live where intelligently in Furs the class name and the view name so you can say artisan make Livewire counter and it will.
Lowercase counter and it will translate that into uppercase counter class inside of a PhD be Livewire. And [00:09:00] vice versa for the view and now you can also do dot syntax because that's how you reference the views and I would think when you're doing nesting this is just easy so you could do like components dot counter artisan make live where components dot counter and then that would work and then you can reference the components that way at Livewire components dot count.
Right. So that is the evolution. It should feel invisible to you. You just artists and make live where counter and now you have counter available. It's an invisible feature, but there was sweat involved and it took me a long time to arrive at that place. So I hope this has been a lesson in iterative development the importance of user testing and how the invisible features just don't come to you off the bat they take time. So this is one of my favorites. I hope you enjoyed this and I hope it was inspiration for you and the projects you built. Thanks. That was a long pause. Okay. Bye.