To over-engineer or not to over-engineer

How to hold a hammer

I don't want to try to summarize this one lol.

Nothing is static, everything is a wave

If I had to identify with one thing, it'd be that.

I'm a builder

You can produce results greater than your abilities if you simply choose to not settle.

Don't settle

I'm building the new core for Livewire and want to tell you a little bit about it

Livewire's new core

I used to be all complex about money tracking, now I'm not...

The simple way I track money

I've been doing door to door sales - it's pretty fun

Selling door to door

What I'm feeling about twitter these days

Paternity leave and twitter

We had a kid

Brief thoughts and insights from Caleb. Mostly on work. Mostly while drinking tea.

Livewire as a project is brilliant, fascinating and fantastic.  This podcast continues in the stead of being open source and almost verbosely transparent.   Hearing Caleb’s reasoning behind some of the decisions and solutions followed just builds more trust.   The podcast is also constantly filled with snippets of brilliance that can be applied to many different aspects of not just computing, but life in general.

Give it a listen, I am sure you won’t be disappointed!

Transparency is Golden

I have been following Caleb and Livewire since the very beginning and this is amazing insight into not only the technology but also everything else that goes into a major open source project. I love every episode.

Amazing Insight from a New Open Source Framework

Notes On Work - by Caleb Porzio

[00:00:00] Caleb: Okay. Today. We're going to talk about Livewire the name. Where did it come from? How did how did we get here? What what changed along the way and what are some of the problems that I'm still coming across? So Livewire as you know, it was inspired by a package called Phoenix live. So Phoenix is a framework like laravel for the language Elixir like laravel is to PHP and Chris McCord the author of Phoenix. He demoed this new tool these working on called live view Phoenix live view and I saw the blog post for this my mind blew up and I spent the next eight months building live where and it started out being really similar to the live view and now it's become something different but similar in some ways and definitely took inspiration from so. So the first name that Livewire had was Phoenix light was a phoenix live view laravel proof-of-concept not an official name, but that was the first thing I called. [00:01:00] It was just a proof of concept for Phoenix live view inside laravel and I thought that I might just call it laravel live view but I wasn't sure like I thought that might be kind of lame to just steal someone's name for another for a package in another Community. Like if it was like, I don't know view redox or something instead of view acts like kind of. On spin on it. So that's what it was out of the gate. The first the first name I came up with kind of off the cuff. I think was lightwire so light wire and basically the my goal was I wanted to convey something like electroluminescence electroluminescence. I don't know like luminescent electric but not I don't know. So I like what I wanted wire. I don't know why I came up with wire. But I wanted wire and because it connects things and it's you know, I want to basically I wanted live where it's funny because I can't think of why I wouldn't pick a live wire but I definitely struggled with it for a while. I [00:02:00] had tons and tons of names written down on envelopes and paper and whatever like what am I going to call this thing? I just didn't love light. And I think maybe part of why I didn't love it as people kept like Miss stating it. I think they were saying I think maybe they were saying Livewire by accident. Maybe that was my cue. I forgot the process. Basically it was this process of me like sitting with an idea and brainstorming a bunch and then after a while the right the right name sort of emerges because it's the one with the fewest surprises. It's like the principle of least surprise. It's one of the few surprises. It meets all the criteria. Is best is anyone else would and probably more so that's kind of how I made the decision. It wasn't an obvious like oh, this is Livewire. It was like it took some tumbling, you know to get there to that point. So I called it live where then the next step is. So live view is capital L and capital V. And so the question is is it live wire with a capital? W? Or is it just live where one word [00:03:00] and so this is something I struggled with and still do struggle with because people do write it as live where with a capital W from time to time because I think that and that's just kind of tells me like that's what at least some people assume. It's how you would spell it and I would probably assume that too but here's the reason why I'm sort of sticking with Livewire lowercase. W this is kind of crazy, but it's one of those things that actually matters to me. I'm trying to think of an example. There's other examples of packages sort of named like this like maybe sigh shell the thing under Artisan Tinker. There's definitely other packages that have how man I can't think of a good one. There are definitely good ones though. Shoot. Anyway when you are if you live where is going to have a classes? It's going to be a namespace in PHP, right and when you import that namespace, is it going to be live? Capital W wire like if it's if it's live wire in the same way, like if you have HTML a class called literally you want [00:04:00] to call it HTML. Is it going to be all capitals for your acronyms or is going to be Capital H lowercase T. Ml I would do Capital H lowercase T. Ml I think there's some standard somewhere that says that's what you should do. I don't know but I treat acronyms as word. When I'm studly casing them for classes, so kind of naturally I think I would do live wire with all lowercase and not do the the capital W and a class name space because then it's sort of like when you make a like a hashing, you know how like encryption if you encrypt something. You can decrypt it. It's like to way if you hash it's one way you have something and you can never you can never make it back to its original form. I felt like the Livewire capital W name for class importing was a similar idea that if you just saw a used statement in PHP that said use capital L IV E capital W IR e you wouldn't know if it's two words or if it's [00:05:00] one word with that capital W. It's ambiguous. It doesn't work the other way around and something about that just hurts my brain. It adds a little bit of friction. That's like oh this if you do this weird thing where you have. Word that has multiple capitals You Now enter the world of confusion. So I thought I would make it not confusing and live. Where is one word one word, and I think I really sort of came to this when I was writing the. My composure dot Json file where I'm autoloading the root Source namespace. What am I going to Auto load that route class and it's and it's live wire with one word and that's kind of what I suck with. So that's that that's part one of the naming story. Oh man. We're already at five minutes and forty. I'll have to rush part 2, so I need to make a so GitHub. What am I going to make GitHub? So GitHub live where / live wires. Sorry the live just get up / live wires taken. What am I going to do? There is a live where well, I don't know because I don't want [00:06:00] it to necessarily just be like laravel this I wanted to be its own thing and Taylor has publicly stated that people should not prefix their packages with laravel because people get confused and think their official and Taylor like LLC laravel like it's trademarked. You can't just use it. So I tried to avoid that. So I was like, all right. Well forget whole organization. Maybe I'll have live boy or PHP Live Wire PHP is also it's actually mostly JavaScript like it's written mostly in JavaScript and it's a kind of like a JavaScript framework. So would it be live where JS know, it would be you know, well, okay be live where laravel yeah, but that's kind of weird so you can see the weirdness in the domain name. Live where framework.com is what I landed on for the domain name because the suffix to something like well, I'm not going to do live where PHP and I'm not going to do live or JSL do live where framework.com that felt. Okay, but I don't even know what I was thinking when I made the Twitter handle live where it was taken, of course, so I did live wire laravel reads horribly. It always bugged [00:07:00] me every time I saw it. I needed a different name. It couldn't just be Live Wire. And I liked the laravel context. It was later live where Larry Bell and I didn't feel as bad about using laravel my name if it was a weird suffix, you know, but that's really annoying. And every time I saw her wrote it, I just felt gross about it. So all of this was just sort of culminating into just this kind of bad feeling about the name that it just wasn't settled yet. So I was on an airplane to go fly fishing recently. And and on the way there I started writing down. Basically, I'd like mine dumped everything in my brain about the direction of live where and one of the area's is naming. I really wanted to settle on a name and get it off of Caleb or zo / Live Wire because that just feels like kind of like immature to me. Like it's an immature project. So I wrote here. I have the note right here. It was one of those things where I just sat down and I finally had time alone to think without the internet or any distractions and I had the solution just pretty much [00:08:00] came to me immediately was like. So am I going to call layer of a live wire or Live Wire? Well, I guess I still don't know but it's going to be Live Wire because I don't want to infringe on Taylor's laravel trademark. So but I realized the perfect domain name is laravel - live wire.com and the perfect Twitter name is at laravel live where those are the two things that I know then there was a question of do I make the GitHub or. Organization laravel - live where / live wire or just live wire / live where anyway, I wrote down no matter what I have to ask Taylor about this. So Taylor in my mind. I'm thinking well, you know, I know Taylor personally, so maybe he'll you know, I don't also want to take advantage of him and I don't want to put pressure on him, but it is like a pretty popular package like it's something I've pretty much dedicated like my life to at the moment. So it's not like I'm just kind of offhandedly creating a packet at something. Probably going to be around for a long time and hopefully be pretty like popular. And so maybe it's warranted here and I'm sure he'd empathize that the domain [00:09:00] names are really hard to get anything that feels natural and I figured I'll just tell them that I'm not going to use like laravel in like logo and The Branding at all. So anyway reached out to him like yesterday or two days ago and he said fine by me and so that that's it. I change the domain name last night at like 10:00 p.m. Two layer of a live where.com. I change the GitHub organization to just live wire / live where I don't know if that's the best move I had to this is actually legal don't come at me, but I had to like pay a guy in Bitcoin to get that organization. He was just squatting on it. So yeah, but I feel I feel good about the name finally. It's Livewire capital L. I'm going to change the logo at some point capital L live wire at laravel live where layer of alive where.com. And GitHub / Libor / Libor because I want to do composer require live. We're live. We're not composer require layer of alive or / live where I want you to be able to remember it and so you can just because that's the most natural thing as composer require live our special ever. Okay, we are at time. Thanks for listening as always [00:10:00] TTYL.

[00:00:00] Caleb: Okay. Today. We're going to talk about Livewire the name. Where did it come from? How did how did we get here? What what changed along the way and what are some of the problems that I'm still coming across? So Livewire as you know, it was inspired by a package called Phoenix live. So Phoenix is a framework like laravel for the language Elixir like laravel is to PHP and Chris McCord the author of Phoenix. He demoed this new tool these working on called live view Phoenix live view and I saw the blog post for this my mind blew up and I spent the next eight months building live where and it started out being really similar to the live view and now it's become something different but similar in some ways and definitely took inspiration from so. So the first name that Livewire had was Phoenix light was a phoenix live view laravel proof-of-concept not an official name, but that was the first thing I called. [00:01:00] It was just a proof of concept for Phoenix live view inside laravel and I thought that I might just call it laravel live view but I wasn't sure like I thought that might be kind of lame to just steal someone's name for another for a package in another Community. Like if it was like, I don't know view redox or something instead of view acts like kind of. On spin on it. So that's what it was out of the gate. The first the first name I came up with kind of off the cuff. I think was lightwire so light wire and basically the my goal was I wanted to convey something like electroluminescence electroluminescence. I don't know like luminescent electric but not I don't know. So I like what I wanted wire. I don't know why I came up with wire. But I wanted wire and because it connects things and it's you know, I want to basically I wanted live where it's funny because I can't think of why I wouldn't pick a live wire but I definitely struggled with it for a while. I [00:02:00] had tons and tons of names written down on envelopes and paper and whatever like what am I going to call this thing? I just didn't love light. And I think maybe part of why I didn't love it as people kept like Miss stating it. I think they were saying I think maybe they were saying Livewire by accident. Maybe that was my cue. I forgot the process. Basically it was this process of me like sitting with an idea and brainstorming a bunch and then after a while the right the right name sort of emerges because it's the one with the fewest surprises. It's like the principle of least surprise. It's one of the few surprises. It meets all the criteria. Is best is anyone else would and probably more so that's kind of how I made the decision. It wasn't an obvious like oh, this is Livewire. It was like it took some tumbling, you know to get there to that point. So I called it live where then the next step is. So live view is capital L and capital V. And so the question is is it live wire with a capital? W? Or is it just live where one word [00:03:00] and so this is something I struggled with and still do struggle with because people do write it as live where with a capital W from time to time because I think that and that's just kind of tells me like that's what at least some people assume. It's how you would spell it and I would probably assume that too but here's the reason why I'm sort of sticking with Livewire lowercase. W this is kind of crazy, but it's one of those things that actually matters to me. I'm trying to think of an example. There's other examples of packages sort of named like this like maybe sigh shell the thing under Artisan Tinker. There's definitely other packages that have how man I can't think of a good one. There are definitely good ones though. Shoot. Anyway when you are if you live where is going to have a classes? It's going to be a namespace in PHP, right and when you import that namespace, is it going to be live? Capital W wire like if it's if it's live wire in the same way, like if you have HTML a class called literally you want [00:04:00] to call it HTML. Is it going to be all capitals for your acronyms or is going to be Capital H lowercase T. Ml I would do Capital H lowercase T. Ml I think there's some standard somewhere that says that's what you should do. I don't know but I treat acronyms as word. When I'm studly casing them for classes, so kind of naturally I think I would do live wire with all lowercase and not do the the capital W and a class name space because then it's sort of like when you make a like a hashing, you know how like encryption if you encrypt something. You can decrypt it. It's like to way if you hash it's one way you have something and you can never you can never make it back to its original form. I felt like the Livewire capital W name for class importing was a similar idea that if you just saw a used statement in PHP that said use capital L IV E capital W IR e you wouldn't know if it's two words or if it's [00:05:00] one word with that capital W. It's ambiguous. It doesn't work the other way around and something about that just hurts my brain. It adds a little bit of friction. That's like oh this if you do this weird thing where you have. Word that has multiple capitals You Now enter the world of confusion. So I thought I would make it not confusing and live. Where is one word one word, and I think I really sort of came to this when I was writing the. My composure dot Json file where I'm autoloading the root Source namespace. What am I going to Auto load that route class and it's and it's live wire with one word and that's kind of what I suck with. So that's that that's part one of the naming story. Oh man. We're already at five minutes and forty. I'll have to rush part 2, so I need to make a so GitHub. What am I going to make GitHub? So GitHub live where / live wires. Sorry the live just get up / live wires taken. What am I going to do? There is a live where well, I don't know because I don't want [00:06:00] it to necessarily just be like laravel this I wanted to be its own thing and Taylor has publicly stated that people should not prefix their packages with laravel because people get confused and think their official and Taylor like LLC laravel like it's trademarked. You can't just use it. So I tried to avoid that. So I was like, all right. Well forget whole organization. Maybe I'll have live boy or PHP Live Wire PHP is also it's actually mostly JavaScript like it's written mostly in JavaScript and it's a kind of like a JavaScript framework. So would it be live where JS know, it would be you know, well, okay be live where laravel yeah, but that's kind of weird so you can see the weirdness in the domain name. Live where <a href="http://framework.com" rel="nofollow" target="_blank">framework.com</a> is what I landed on for the domain name because the suffix to something like well, I'm not going to do live where PHP and I'm not going to do live or JSL do live where <a href="http://framework.com" rel="nofollow" target="_blank">framework.com</a> that felt. Okay, but I don't even know what I was thinking when I made the Twitter handle live where it was taken, of course, so I did live wire laravel reads horribly. It always bugged [00:07:00] me every time I saw it. I needed a different name. It couldn't just be Live Wire. And I liked the laravel context. It was later live where Larry Bell and I didn't feel as bad about using laravel my name if it was a weird suffix, you know, but that's really annoying. And every time I saw her wrote it, I just felt gross about it. So all of this was just sort of culminating into just this kind of bad feeling about the name that it just wasn't settled yet. So I was on an airplane to go fly fishing recently. And and on the way there I started writing down. Basically, I'd like mine dumped everything in my brain about the direction of live where and one of the area's is naming. I really wanted to settle on a name and get it off of Caleb or zo / Live Wire because that just feels like kind of like immature to me. Like it's an immature project. So I wrote here. I have the note right here. It was one of those things where I just sat down and I finally had time alone to think without the internet or any distractions and I had the solution just pretty much [00:08:00] came to me immediately was like. So am I going to call layer of a live wire or Live Wire? Well, I guess I still don't know but it's going to be Live Wire because I don't want to infringe on Taylor's laravel trademark. So but I realized the perfect domain name is laravel - live <a href="http://wire.com" rel="nofollow" target="_blank">wire.com</a> and the perfect Twitter name is at laravel live where those are the two things that I know then there was a question of do I make the GitHub or. Organization laravel - live where / live wire or just live wire / live where anyway, I wrote down no matter what I have to ask Taylor about this. So Taylor in my mind. I'm thinking well, you know, I know Taylor personally, so maybe he'll you know, I don't also want to take advantage of him and I don't want to put pressure on him, but it is like a pretty popular package like it's something I've pretty much dedicated like my life to at the moment. So it's not like I'm just kind of offhandedly creating a packet at something. Probably going to be around for a long time and hopefully be pretty like popular. And so maybe it's warranted here and I'm sure he'd empathize that the domain [00:09:00] names are really hard to get anything that feels natural and I figured I'll just tell them that I'm not going to use like laravel in like logo and The Branding at all. So anyway reached out to him like yesterday or two days ago and he said fine by me and so that that's it. I change the domain name last night at like 10:00 p.m. Two layer of a live <a href="http://where.com" rel="nofollow" target="_blank">where.com</a>. I change the GitHub organization to just live wire / live where I don't know if that's the best move I had to this is actually legal don't come at me, but I had to like pay a guy in Bitcoin to get that organization. He was just squatting on it. So yeah, but I feel I feel good about the name finally. It's Livewire capital L. I'm going to change the logo at some point capital L live wire at laravel live where layer of alive <a href="http://where.com" rel="nofollow" target="_blank">where.com</a>. And GitHub / Libor / Libor because I want to do composer require live. We're live. We're not composer require layer of alive or / live where I want you to be able to remember it and so you can just because that's the most natural thing as composer require live our special ever. Okay, we are at time. Thanks for listening as always [00:10:00] TTYL.

The Name

As I fight "the war of art", I'm learning more and more about myself and the way I work every day. This episode I talk about my weekly workflow and how I leverage meetings and commitments to do my best work.

As I fight "the war of art", I'm learning more and more about myself and the way I work every day. This episode I talk about my weekly workflow and how I leverage meetings and commitments to do my best work.

I Do My Best Work When People Are Watching

Okay. I'm standing here at my desk feeling pretty good for two reasons. The first reason is I solved a pretty hard validation problem in live wire. The second reason is, uh, it's, there's a giant blanket of snow outside and it's been snowing all day yesterday and all night really soft, nice, perfect white snow. It's not even Thanksgiving. And we broke our rule and played Christmas music and actually decorated for Christmas because we were just feeling in the mood. Um. And it's just white outside, which is really nice. So thank you for, thank you for that snow. Oh, I solved a hard validation problem and I want to tell you about it. So validation, it's been a long road to get where we are, and I thought we were at a good place with validation, but really we were at a good place for demoing validation. I'll explain what I mean by that. So in episode five, I, I just called the evolution of validation and I, I talk about how I went from going, all right, I live way or could not. Handle validation at all. By validation, I mean like form validation, like showing this field is required and stuff. Um, forms are pretty common thing and in web apps and so validation's also pretty common and live wire could, there's, this was sort of a fork in the road. I could not deal with validation at all. Um, but I wanted, I wanted live wire to support. Some, you know, making validation easier. So what you could do without any, you know, anything official Livewire you could, like at the, the olden days in Laravel, you could create, you can manually create a validator with rules and data, um, and pull it from wherever, from your Livewire data, and then you could run validator Aero validate. Or you could run fails, probably put fails in a conditional and then manually, you know, build up, uh, some data for the errors and show the errors and yada, yada. But I wanted it to feel native. I wanted you to feel like you were in a controller method and you could just do. This arrow validate, um, which would be the equivalent of request arrow validate. So you could just do this arrow, validate pass in some rules and it would Intuit, it would like link up the rules with the data on the live wire object. And so if you use live where you've probably used validation and you know what I'm talking about, it feels really sleek. It feels really intuitive. And I already talked about how it was a long road to get to that point of it feeling intuitive. Um, that's episode five. So since then. Uh, so the, it feels really good and it looks really good for demos, but in reality, there's a problem with it. So the problem is I implemented it in such a way. That it's pretty simple. Like you run this arrow validate and actually, you know, does what layer of L does inside and throws a validation exception. And it bubbles up. And I have a little catcher and I catch the validation exception and I pass the errors into the view. So you have an error message bag, so your execution gets interrupted, but your components still renders and you get that errors, message bag, you know, money sign errors, probably arrow has or arrow any or arrow GAT or something like that. Um. So that that's the way it exists currently. The problem with that is the errors aren't persisted from request to request. So you have a form and you submit it, and then let's say you have some validation in the submit method or something, and then the validation errors are shown as soon as Livewire makes any sort of update and probably your, your data binding, your input elements. So if you have an input element called name, all right, let's start concrete. You have a form with a name and an email. No username and password and the username field is just an input type text, passwords, input type password. They both have wire, colon model username and password, and their data bound to the Livewire component. So every time you type into him. They sends an Ajax requests and updates the data on the component. Then you have a submit button that does wire colon click a submit method. In the submit method, you have this arrow validate and you validate that user name and password are required, let's say. Okay, so the user's typing in, let's say they don't type anything in and they just hit the submit button. They see this fields required, and then they see this fields required the other field. So they type in the username field and now Livewire sends an Ajax request to update that field and all the validation is just wiped. So all the validation messages disappear, but they only updated one field. Now what you'd rather have. Now that's not, that's not horrible, but the default behavior for  like without Livewire would be, you would type and the validation messages wouldn't disappear until you hit the submit button again. Right. And let's say that you, that you implemented a few JS. Handling of this so you could real time validate and like sundae Jack's requests or whatever, realtime validate it would validate only the field and the validation messages and the other fields wouldn't update unless you updated those field values. Very hard to explain. Um, but I hope you're kind of tracking then it's just kind of this, this weird problem that at first felt, it just felt a little weird to me. Like, okay, this is the easiest solution, I'm going to do it, but it doesn't solve all the problems. And then when I would think about a way of handling validation, like maybe had just persist validation from requests or requests, it would break another use case. Um, so I just kind of left it and there's, there've been get hub issues submitted about this, and it's kind of jarring. Like people don't expect that behavior. They're like, validation messages disappear after update, you know? And I'm like, yeah, that's actually how it's supposed to work. But I know it's not ideal. So what we really did. Uh, so we, I started this big discussion in an issue that somebody submitted to, lots of people have been kind of weighing in on it. And it took me a little bit to figure out, but really like, there's two different kinds of validates. There's probably more than that, but there's two primary primary types of validation in a, in a web app. But let's just say in Livewire, there's form validation. So they're like, honest submit, the kind of validation that that happens every time you hit the button. That does the thing. And then there's realtime validation, the kind of thing that might, is probably more common on an auto saving form. Um, but even on a, even on a normal like button forms that there's real time validation, they both behave differently with the button you want. Um, you want all the errors to persist, uh, across requests. You want them to sit there, um, with the, with the realtime validation, you want them to update but only update the field. So like I explained, it's a little bit hard to visualize, but you can imagine that there's these big differences. So basically I had to sit down and realize that, okay, the first thing I need to do is figure out how I'm going to persist validation from requests or request. So like I talked about in a couple episodes before that, uh, I think a lovely refactor was the, um, was the episode. And it's, it's where I refactored LA live lawyers core. To basically the the back end core to do this hydrate dehydrate middleware stack where like the request comes in and I slowly build up the Livewire component from the request with these different middleware slices. And then when the request goes back out, before it goes back out, ID hydrate the instance into a response. And then JavaScript stores, it passes it back, yada yada. So this was kind of nice cause all I had to do was add one piece of middleware called, um, I think I called it persist validation. I don't know, persistent errors, maybe I called it. And so basically I do that before I D hydrate the component. I see. Hey, um, whenever, I don't have to tell you in line by line what I did. But basically each component keeps track of an error bag. Now, um, if you don't know how, how level validation works, it's kind of interesting. You've probably encountered message bags before and Laravel but you probably, you know, it's kind of a nebulous thing to you. Like you kind of know that the error bag has a message bag and a message bag is like a broader concept. But, um. And that's how you get that nice like error errors. Arrow has errors, arrow, any, right? Um, but anyway, so live where now it keeps track of a message bag and there's lots of weird complicated things it has to do. Um, but I'll just give you the gist because we're already eight minutes at eight minutes, and hopefully I described the problem enough that you can understand that it's an annoying problem. It's hard to solve, but. I finally solved it. And, um, uh, okay. So instead of going out about the implementation, I'll tell you the, how you use it effectively. In that previous example where we had username and password and then that submit button when you hit that submit button. Now the validation error show, but when you update a field, they won't disappear. They'll stay stagnant. This, this is the exact behavior, um, of a traditional form submission where when you hit submit and it runs some validation, the validation is static. So as you're typing in username and you already had the username field is required message, it's still showing while you're typing in. Then you click the button again and it reevaluates the validation. If it passes, they're all cleared and you do whatever you do. If it fails, you get the new validation messages. Okay? That's use case number one. Use case number two, and this is the thing that I've been banging my head against the wall for so long and I realized I wa I can't use the same, this arrow validate. So I have a new method called this arrow validate only. And this is presumably you're doing real time validation, and if you're doing that, you're doing it in an updated hook. So Livewire has these updated hooks which run every time you try to update a piece of input. So let's say you have your updated hook. Or updated username or whatever updated hook that gets the value that's being updated. You do this arrow validate only, and then you pass in the field. That's the name of the field. You pass in all the rules after that. Um, and then it's smart. It validates only that field and it merges the airbag with the old Arabic. So as you type in, you get validation messages, but you don't get messages for the other fields until you start typing into them. And when you type into them, it doesn't clear the other validation message that exists. It merges with them. So they still exist. So basically it's a way of doing validation where you're only validating one field in one field only, but the other ones persist. Hopefully this makes sense. I have like five seconds left. Coming up with the name validate only was hard. That was a whole other story. I'm really happy with it. I thought about like validate realtime, blah, blah, blah. We're at 10 minutes. Thanks for listening. Hope you enjoy this validation. We'll be tagging the next release. Bye.

Okay. I'm standing here at my desk feeling pretty good for two reasons. The first reason is I solved a pretty hard validation problem in live wire. The second reason is, uh, it's, there's a giant blanket of snow outside and it's been snowing all day yesterday and all night really soft, nice, perfect white snow. It's not even Thanksgiving. And we broke our rule and played Christmas music and actually decorated for Christmas because we were just feeling in the mood. Um. And it's just white outside, which is really nice. So thank you for, thank you for that snow. Oh, I solved a hard validation problem and I want to tell you about it. So validation, it's been a long road to get where we are, and I thought we were at a good place with validation, but really we were at a good place for demoing validation. I'll explain what I mean by that. So in episode five, I, I just called the evolution of validation and I, I talk about how I went from going, all right, I live way or could not. Handle validation at all. By validation, I mean like form validation, like showing this field is required and stuff. Um, forms are pretty common thing and in web apps and so validation's also pretty common and live wire could, there's, this was sort of a fork in the road. I could not deal with validation at all. Um, but I wanted, I wanted live wire to support. Some, you know, making validation easier. So what you could do without any, you know, anything official Livewire you could, like at the, the olden days in Laravel, you could create, you can manually create a validator with rules and data, um, and pull it from wherever, from your Livewire data, and then you could run validator Aero validate. Or you could run fails, probably put fails in a conditional and then manually, you know, build up, uh, some data for the errors and show the errors and yada, yada. But I wanted it to feel native. I wanted you to feel like you were in a controller method and you could just do. This arrow validate, um, which would be the equivalent of request arrow validate. So you could just do this arrow, validate pass in some rules and it would Intuit, it would like link up the rules with the data on the live wire object. And so if you use live where you've probably used validation and you know what I'm talking about, it feels really sleek. It feels really intuitive. And I already talked about how it was a long road to get to that point of it feeling intuitive. Um, that's episode five. So since then. Uh, so the, it feels really good and it looks really good for demos, but in reality, there's a problem with it. So the problem is I implemented it in such a way. That it's pretty simple. Like you run this arrow validate and actually, you know, does what layer of L does inside and throws a validation exception. And it bubbles up. And I have a little catcher and I catch the validation exception and I pass the errors into the view. So you have an error message bag, so your execution gets interrupted, but your components still renders and you get that errors, message bag, you know, money sign errors, probably arrow has or arrow any or arrow GAT or something like that. Um. So that that's the way it exists currently. The problem with that is the errors aren't persisted from request to request. So you have a form and you submit it, and then let's say you have some validation in the submit method or something, and then the validation errors are shown as soon as Livewire makes any sort of update and probably your, your data binding, your input elements. So if you have an input element called name, all right, let's start concrete. You have a form with a name and an email. No username and password and the username field is just an input type text, passwords, input type password. They both have wire, colon model username and password, and their data bound to the Livewire component. So every time you type into him. They sends an Ajax requests and updates the data on the component. Then you have a submit button that does wire colon click a submit method. In the submit method, you have this arrow validate and you validate that user name and password are required, let's say. Okay, so the user's typing in, let's say they don't type anything in and they just hit the submit button. They see this fields required, and then they see this fields required the other field. So they type in the username field and now Livewire sends an Ajax request to update that field and all the validation is just wiped. So all the validation messages disappear, but they only updated one field. Now what you'd rather have. Now that's not, that's not horrible, but the default behavior for like without Livewire would be, you would type and the validation messages wouldn't disappear until you hit the submit button again. Right. And let's say that you, that you implemented a few JS. Handling of this so you could real time validate and like sundae Jack's requests or whatever, realtime validate it would validate only the field and the validation messages and the other fields wouldn't update unless you updated those field values. Very hard to explain. Um, but I hope you're kind of tracking then it's just kind of this, this weird problem that at first felt, it just felt a little weird to me. Like, okay, this is the easiest solution, I'm going to do it, but it doesn't solve all the problems. And then when I would think about a way of handling validation, like maybe had just persist validation from requests or requests, it would break another use case. Um, so I just kind of left it and there's, there've been get hub issues submitted about this, and it's kind of jarring. Like people don't expect that behavior. They're like, validation messages disappear after update, you know? And I'm like, yeah, that's actually how it's supposed to work. But I know it's not ideal. So what we really did. Uh, so we, I started this big discussion in an issue that somebody submitted to, lots of people have been kind of weighing in on it. And it took me a little bit to figure out, but really like, there's two different kinds of validates. There's probably more than that, but there's two primary primary types of validation in a, in a web app. But let's just say in Livewire, there's form validation. So they're like, honest submit, the kind of validation that that happens every time you hit the button. That does the thing. And then there's realtime validation, the kind of thing that might, is probably more common on an auto saving form. Um, but even on a, even on a normal like button forms that there's real time validation, they both behave differently with the button you want. Um, you want all the errors to persist, uh, across requests. You want them to sit there, um, with the, with the realtime validation, you want them to update but only update the field. So like I explained, it's a little bit hard to visualize, but you can imagine that there's these big differences. So basically I had to sit down and realize that, okay, the first thing I need to do is figure out how I'm going to persist validation from requests or request. So like I talked about in a couple episodes before that, uh, I think a lovely refactor was the, um, was the episode. And it's, it's where I refactored LA live lawyers core. To basically the the back end core to do this hydrate dehydrate middleware stack where like the request comes in and I slowly build up the Livewire component from the request with these different middleware slices. And then when the request goes back out, before it goes back out, ID hydrate the instance into a response. And then JavaScript stores, it passes it back, yada yada. So this was kind of nice cause all I had to do was add one piece of middleware called, um, I think I called it persist validation. I don't know, persistent errors, maybe I called it. And so basically I do that before I D hydrate the component. I see. Hey, um, whenever, I don't have to tell you in line by line what I did. But basically each component keeps track of an error bag. Now, um, if you don't know how, how level validation works, it's kind of interesting. You've probably encountered message bags before and Laravel but you probably, you know, it's kind of a nebulous thing to you. Like you kind of know that the error bag has a message bag and a message bag is like a broader concept. But, um. And that's how you get that nice like error errors. Arrow has errors, arrow, any, right? Um, but anyway, so live where now it keeps track of a message bag and there's lots of weird complicated things it has to do. Um, but I'll just give you the gist because we're already eight minutes at eight minutes, and hopefully I described the problem enough that you can understand that it's an annoying problem. It's hard to solve, but. I finally solved it. And, um, uh, okay. So instead of going out about the implementation, I'll tell you the, how you use it effectively. In that previous example where we had username and password and then that submit button when you hit that submit button. Now the validation error show, but when you update a field, they won't disappear. They'll stay stagnant. This, this is the exact behavior, um, of a traditional form submission where when you hit submit and it runs some validation, the validation is static. So as you're typing in username and you already had the username field is required message, it's still showing while you're typing in. Then you click the button again and it reevaluates the validation. If it passes, they're all cleared and you do whatever you do. If it fails, you get the new validation messages. Okay? That's use case number one. Use case number two, and this is the thing that I've been banging my head against the wall for so long and I realized I wa I can't use the same, this arrow validate. So I have a new method called this arrow validate only. And this is presumably you're doing real time validation, and if you're doing that, you're doing it in an updated hook. So Livewire has these updated hooks which run every time you try to update a piece of input. So let's say you have your updated hook. Or updated username or whatever updated hook that gets the value that's being updated. You do this arrow validate only, and then you pass in the field. That's the name of the field. You pass in all the rules after that. Um, and then it's smart. It validates only that field and it merges the airbag with the old Arabic. So as you type in, you get validation messages, but you don't get messages for the other fields until you start typing into them. And when you type into them, it doesn't clear the other validation message that exists. It merges with them. So they still exist. So basically it's a way of doing validation where you're only validating one field in one field only, but the other ones persist. Hopefully this makes sense. I have like five seconds left. Coming up with the name validate only was hard. That was a whole other story. I'm really happy with it. I thought about like validate realtime, blah, blah, blah. We're at 10 minutes. Thanks for listening. Hope you enjoy this validation. We'll be tagging the next release. Bye.

Hard Validation Problems

Okay, so I'm writing a test a JavaScript test in Livewire and I am about to use a testing utility that I've created. So I have this utils dot J's file inside my testing folder for JavaScript and it's where I have all of my testing helpers and they're all in charge of the same thing. They're in charge of mounting Livewire. Making Live Wire breathing Live Wire into existence in JavaScript and usually you pass in there for a component. So I think the basic function I have is called Mount and you pass in HTML the HTML of the component and that's it. And then once you've done that you can say Mount and then you pass the HTML now you can do stuff with it. You can you know document that query selector get a button that has wire click on it click and then you can assert that, you know some payload was sent. So there's a bunch of these Mount helpers started out as one called Mount and I tried to make it do too many things in a star to get gross. So I just duplicated it and called the next one mount with data may be so I have a bunch of them and there's mount mount as root Mount is Route and return mount with a vent mount in return. Mount and error mount with data there's tons of them and they all have the almost the exact same structure slightly different parameters, but the basic structure inside of them and they all just do something slightly different. So I know that there is an abstraction waiting here someday, it will occur to me, but it is not it hasn't occurred to me yet and I'm just being patient with it. So I'm speaking this out to you. As a reminder as a thought piece, whatever that sometimes you just have to be patient with abstractions. So here I want to write a test and I realized I need a new one. I could try to retrofit and another one but really I need a new one and it's going to be a very specific one. And I know and that's a little bit of pain like I'm experiencing pain because I'm copying pasting a bunch of code. And I've had to change things that I've missed and changing another ones and I've experienced issues and pain because of that. So this is not ideal and I'm doing it and I recognize that I know it's not ideal. It's not good, but it's an ideal on ideal scenario because this is all scope to one file. It's one big file and they're just. A ton of basically the same method with a different name different parameters in slightly different implementation, but they're all in one file. So it's not like I have it's not spread across different files this kind of goes back to the single file principal like my tolerance for nastiness is a little bit higher when it's all scope to one file. And in this case it is but anyway, I went to add this thing and I just kind of realized that it's painful and I thought for a second. Is there any abstraction emerging yet? And no it's not. But at some point it will maybe it's just me being a little bit lazy and just wanting to copy and paste instead of roll up my sleeves and really figure something out that works for everything. But really it's not it's not causing big problems in my app and the abstraction hasn't prevented it presented itself. So I'm just going to be patient with it. Being patient with abstractions can one first thought was being patient with abstractions can be a little bit more dangerous when there's no trigger set up and by trigger, I mean something that's going to remind you that you need an abstraction in this case. My trigger is having to add a new function. That's a pain Point triggers me to think about abstractions if that didn't exist. Then I could let bad abstractions or unobstructed code lie dormant my next thought with that was well if I construct a code is lying dormant and being harmless and there's no trigger that makes you feel pain then maybe it's fine. Maybe you don't need the abstraction because abstractions are meant to serve us. We're not there to serve abstractions. So anyway, there is an abstraction waiting here. That would serve me. I know it. I know it would make my tests more flexible. I know I know there's something there's some implementation. That allows the developer the flexibility to do what they want to do without needing all these different methods, but for now, I'm going to copy and paste one of these methods and add yet another method called Mount and return listener or something like that, whatever. I'm about to do it, and that's all I wanted to tell you. Sometimes you have to be patient with abstractions. Don't rush it. Hopefully it presents itself to you, but don't force it if it's not ready yet. So, thanks.

Okay, so I'm writing a test a JavaScript test in Livewire and I am about to use a testing utility that I've created. So I have this utils dot J's file inside my testing folder for JavaScript and it's where I have all of my testing helpers and they're all in charge of the same thing. They're in charge of mounting Livewire. Making Live Wire breathing Live Wire into existence in JavaScript and usually you pass in there for a component. So I think the basic function I have is called Mount and you pass in HTML the HTML of the component and that's it. And then once you've done that you can say Mount and then you pass the HTML now you can do stuff with it. You can you know document that query selector get a button that has wire click on it click and then you can assert that, you know some payload was sent. So there's a bunch of these Mount helpers started out as one called Mount and I tried to make it do too many things in a star to get gross. So I just duplicated it and called the next one mount with data may be so I have a bunch of them and there's mount mount as root Mount is Route and return mount with a vent mount in return. Mount and error mount with data there's tons of them and they all have the almost the exact same structure slightly different parameters, but the basic structure inside of them and they all just do something slightly different. So I know that there is an abstraction waiting here someday, it will occur to me, but it is not it hasn't occurred to me yet and I'm just being patient with it. So I'm speaking this out to you. As a reminder as a thought piece, whatever that sometimes you just have to be patient with abstractions. So here I want to write a test and I realized I need a new one. I could try to retrofit and another one but really I need a new one and it's going to be a very specific one. And I know and that's a little bit of pain like I'm experiencing pain because I'm copying pasting a bunch of code. And I've had to change things that I've missed and changing another ones and I've experienced issues and pain because of that. So this is not ideal and I'm doing it and I recognize that I know it's not ideal. It's not good, but it's an ideal on ideal scenario because this is all scope to one file. It's one big file and they're just. A ton of basically the same method with a different name different parameters in slightly different implementation, but they're all in one file. So it's not like I have it's not spread across different files this kind of goes back to the single file principal like my tolerance for nastiness is a little bit higher when it's all scope to one file. And in this case it is but anyway, I went to add this thing and I just kind of realized that it's painful and I thought for a second. Is there any abstraction emerging yet? And no it's not. But at some point it will maybe it's just me being a little bit lazy and just wanting to copy and paste instead of roll up my sleeves and really figure something out that works for everything. But really it's not it's not causing big problems in my app and the abstraction hasn't prevented it presented itself. So I'm just going to be patient with it. Being patient with abstractions can one first thought was being patient with abstractions can be a little bit more dangerous when there's no trigger set up and by trigger, I mean something that's going to remind you that you need an abstraction in this case. My trigger is having to add a new function. That's a pain Point triggers me to think about abstractions if that didn't exist. Then I could let bad abstractions or unobstructed code lie dormant my next thought with that was well if I construct a code is lying dormant and being harmless and there's no trigger that makes you feel pain then maybe it's fine. Maybe you don't need the abstraction because abstractions are meant to serve us. We're not there to serve abstractions. So anyway, there is an abstraction waiting here. That would serve me. I know it. I know it would make my tests more flexible. I know I know there's something there's some implementation. That allows the developer the flexibility to do what they want to do without needing all these different methods, but for now, I'm going to copy and paste one of these methods and add yet another method called Mount and return listener or something like that, whatever. I'm about to do it, and that's all I wanted to tell you. Sometimes you have to be patient with abstractions. Don't rush it. Hopefully it presents itself to you, but don't force it if it's not ready yet. So, thanks.

Be Patient With Abstractions

So funny thing at one point I was actually going to charge for Livewire. That's funny to hear me say that right now, but you've not even that long before larrikin. I mean way before larrikin, but even right before Larrick on I was like really running the numbers and thinking, you know, all right, how much can I make on this thing? Like put a lot of work into this basically quit my job and haven't worked in like four or five months. I've like to make some money redeem some of this value. Okay, I'll charge for live or that's the thing. I'm not going to try to like raise a board or do patreon stuff. Like that doesn't work. I'm just going to charge for it, you know charging for software. That's the thing people do so I messaged Adam Ladd and I basically had this plan and I really believe I stood to make like 15 grand. I think I could have maybe. Now in hindsight, I probably definitely couldn't anybody know I would have been 15 grand. And you know, I even knew that myself like 15 grand is not worth it for the work. I put into it 15 grand. No way. I'd rather just not have that money and has something that everybody can use and grow it's an open-source, you know project I mentioned I asked a couple people for advice and one of those people was mr. Adam wave and and he gave it to me straight. Like I knew he would you said something like. Dude, you're going to make like $200 to something. Like I don't know what he said maybe more than that. I think that's what he was saying about patreon. He's like, yeah, if you pay trying to make $200 if you charge for it, you know, whatever basically somewhere in this this midst of him, like giving it to me straight was like but don't underestimate the value of you know, your reputation of like building building. Your reputation is like a open-source maintainer contributor person who created something pretty big. That stuck with me. Those are not his words, but sort of kind of that's what he was saying and that stuck with me for sure big time that that yeah, right. I mean this seems so obvious, but I had to be reminded that like. that. This is this is a big step for me like this is this is a real contribution something that if I execute well, if I if it's if it's as useful as I think it could be and I execute it. Well could be something that most layer of elapsed use, you know, that would be crazy and it's kind of it's not just like a little like package, you know, it's a it's a way of developing it's a system. It's a framework unto itself. That's pretty big deal. So. This could kind of open some doors for me. And I don't know he reminded me of that and that that just was a good reminder for me. That's all I needed now is like yeah, you're right. You know what? Yeah reputation is a thing. I guess. I'm my mind. I felt like I sort of had that reputation of felt like it's like sort of I don't know if. If you're putting like laravel celebrities and tears, I'm probably like a second or third-tier celebrity and that's what I feel like, you know in terms. I don't know for using my follower can be like screw humility. This is like how I picture myself based on Twitter followers, and I don't know just general like my connections with people in the community whatever but I think I'm at that level and I just sort of felt like that was. Heil a high enough level or something, I don't know but. He reminded me that there's you know, there's more to be had there's more to be reputed for I don't know there's more of a reputation to have more doors will open if I contribute something of value to the community more than just my little tip tweets and blog posts and stuff like that. So anyway, I'm saying all this because I'm reflecting on this. I'm about to travel to Europe for full-stack EU and this is funny because there's like lots of people. But first I've never been to Europe and a lot of my family. My mom is never been in Europe. My dad has never been in Europe Brothers never been in Europe. My sisters have been here, you know, there's. I don't know. It's like it's kind of a big deal for me, even though I travel a lot. I been a lot of places and I imagined that I would go here whether or not I was speaking somewhere. But you know, there's somebody who's paying for my flights and a couple nights in a hotel to go to Europe and talk about not actually about Livewire but stuff like it like like Frank asked me to talk about live organized like well, they're not all PHP developers. Maybe I shouldn't but but this is in some way in some indirect Way live where open the door for me to go talk about this. And next year I'm going to shoot for you know, the other conference is laravel EU or Larrick on EU and stuff like that. And those are doors. You know, that's sort of like this is the kind of thing that I feel funny saying to the laravel community because a lot of community members do this sort of thing this traveling and whatever. But you know what? I tell my family about this they're like to like what like this thing that you're working on is take you around the world, like people are paying, you know, whatever a thousand dollars for you to fly over and hundreds more to stay in a hotel and whatever and talk about this thing for help for 30 minutes what that's insane. Like, you know, people are just like dump on my dad. He's so funny. He's like, you know, he's so proud and just like can't believe this you know, which is really funny. It's again funny saying to this crowd because I think this you know, I don't know if it's I don't know just definitely not as big of a deal than it is to my parents. And anyway, so so going to Europe and then I get an email. The other day, I don't know about a week ago from somebody who works for a company called Prisma Kai got to look into it. I think it's Prismatic and and this guy's like Hey, we're starting a new YouTube video on YouTube channel, where were interviewing like open-source maintainers. We've had West boss on we've had named a couple other big names and he's like. So and I you know, I follow you on Twitter and I heard that you're going to be in Belgium. Would you be up for flying to Paris and US interviewing you you know for our YouTube channel and I'm like well hell, yeah, like that's super cool and you know that they offer to like sponsor my travel to Paris from Belgium. Like that's insane just for a YouTube interview. I don't know so it's for me that like I'm being transparent here like. These are kind of big moments. These are moments where I go home and like this is something like this is more than nothing. This is somebody who's follows me on Twitter and wants to fly me somewhere to hear me talk like they're big moments and I guess I take pride in them and I feel good about them and I'm humbled by them or whatever, you know. Yeah, so so it feels pretty good. And that's why I'm reflecting on this and I'm like, you know, a lot of this is because of Livewire and. I think I could have maybe shot for some of these things without it. But live wires. The thing is the thing that that I guess I'm most known for at the moment and hopefully will become more known for as it becomes more valuable and and whatever so, I don't know I'm saying here. I guess what I'm saying though is like I underestimated the value of the reputation of it. I didn't really think of it like that. I thought of it first it was like just fun and a really useful tool and then I started to get my sights set on like maybe I could actually fund. My life with this tool and I think that maybe was a lofty goal at the time maybe eventually down the road. But but then I sort of shifted my sites to this is about my reputation. Like I want to build something. I want to make it really good as good as I can possibly make it really useful do a really good job on the docks and educational materials and everything just make it a really valuable tool for laravel developers and and I'll be recognized for that, you know, and that'll build their reputation and then it'll be kind of like a tool in my. Tool, I don't know like like a Resume Builder, you know something that that that I'll be able to any job I go to like I'm going to point a live wire. I'm gonna be like, hey, yeah, I spent a ton of time working on this open source project and you can see all the code. I wrote here and all the people you can see how I managed a how to Big open source project, you know, so it's been a wild ride and really good time and. Yeah, so that's that I think now is maybe a good it's pretty late and I got to go to bed these last three episodes. You can probably hear I have a cold and it's late at night. And so I'm really like quiet right now, but I was just in the reflective mood and I'm about to leave for Europe for two weeks and I'm putting the pen down. I'm not going to be on the computer too much. I will be at full stack you but outside of that will be traveling and doing whatever else so I'm going to be a little bit quiet. I'll release these. Maybe over the next two weeks, but but things will be a little quiet. I won't be really around much, but I'm but when I get back I'm going to be hitting it hard. So so there's definitely some exciting stuff to come in the Live Wire front that I can't wait to talk about and work on it. Whatever so stay tuned. Thanks for listening to Lon. Enjoy your cab ride by.

So funny thing at one point I was actually going to charge for Livewire. That's funny to hear me say that right now, but you've not even that long before larrikin. I mean way before larrikin, but even right before Larrick on I was like really running the numbers and thinking, you know, all right, how much can I make on this thing? Like put a lot of work into this basically quit my job and haven't worked in like four or five months. I've like to make some money redeem some of this value. Okay, I'll charge for live or that's the thing. I'm not going to try to like raise a board or do patreon stuff. Like that doesn't work. I'm just going to charge for it, you know charging for software. That's the thing people do so I messaged Adam Ladd and I basically had this plan and I really believe I stood to make like 15 grand. I think I could have maybe. Now in hindsight, I probably definitely couldn't anybody know I would have been 15 grand. And you know, I even knew that myself like 15 grand is not worth it for the work. I put into it 15 grand. No way. I'd rather just not have that money and has something that everybody can use and grow it's an open-source, you know project I mentioned I asked a couple people for advice and one of those people was mr. Adam wave and and he gave it to me straight. Like I knew he would you said something like. Dude, you're going to make like $200 to something. Like I don't know what he said maybe more than that. I think that's what he was saying about patreon. He's like, yeah, if you pay trying to make $200 if you charge for it, you know, whatever basically somewhere in this this midst of him, like giving it to me straight was like but don't underestimate the value of you know, your reputation of like building building. Your reputation is like a open-source maintainer contributor person who created something pretty big. That stuck with me. Those are not his words, but sort of kind of that's what he was saying and that stuck with me for sure big time that that yeah, right. I mean this seems so obvious, but I had to be reminded that like. that. This is this is a big step for me like this is this is a real contribution something that if I execute well, if I if it's if it's as useful as I think it could be and I execute it. Well could be something that most layer of elapsed use, you know, that would be crazy and it's kind of it's not just like a little like package, you know, it's a it's a way of developing it's a system. It's a framework unto itself. That's pretty big deal. So. This could kind of open some doors for me. And I don't know he reminded me of that and that that just was a good reminder for me. That's all I needed now is like yeah, you're right. You know what? Yeah reputation is a thing. I guess. I'm my mind. I felt like I sort of had that reputation of felt like it's like sort of I don't know if. If you're putting like laravel celebrities and tears, I'm probably like a second or third-tier celebrity and that's what I feel like, you know in terms. I don't know for using my follower can be like screw humility. This is like how I picture myself based on Twitter followers, and I don't know just general like my connections with people in the community whatever but I think I'm at that level and I just sort of felt like that was. Heil a high enough level or something, I don't know but. He reminded me that there's you know, there's more to be had there's more to be reputed for I don't know there's more of a reputation to have more doors will open if I contribute something of value to the community more than just my little tip tweets and blog posts and stuff like that. So anyway, I'm saying all this because I'm reflecting on this. I'm about to travel to Europe for full-stack EU and this is funny because there's like lots of people. But first I've never been to Europe and a lot of my family. My mom is never been in Europe. My dad has never been in Europe Brothers never been in Europe. My sisters have been here, you know, there's. I don't know. It's like it's kind of a big deal for me, even though I travel a lot. I been a lot of places and I imagined that I would go here whether or not I was speaking somewhere. But you know, there's somebody who's paying for my flights and a couple nights in a hotel to go to Europe and talk about not actually about Livewire but stuff like it like like Frank asked me to talk about live organized like well, they're not all PHP developers. Maybe I shouldn't but but this is in some way in some indirect Way live where open the door for me to go talk about this. And next year I'm going to shoot for you know, the other conference is laravel EU or Larrick on EU and stuff like that. And those are doors. You know, that's sort of like this is the kind of thing that I feel funny saying to the laravel community because a lot of community members do this sort of thing this traveling and whatever. But you know what? I tell my family about this they're like to like what like this thing that you're working on is take you around the world, like people are paying, you know, whatever a thousand dollars for you to fly over and hundreds more to stay in a hotel and whatever and talk about this thing for help for 30 minutes what that's insane. Like, you know, people are just like dump on my dad. He's so funny. He's like, you know, he's so proud and just like can't believe this you know, which is really funny. It's again funny saying to this crowd because I think this you know, I don't know if it's I don't know just definitely not as big of a deal than it is to my parents. And anyway, so so going to Europe and then I get an email. The other day, I don't know about a week ago from somebody who works for a company called Prisma Kai got to look into it. I think it's Prismatic and and this guy's like Hey, we're starting a new YouTube video on YouTube channel, where were interviewing like open-source maintainers. We've had West boss on we've had named a couple other big names and he's like. So and I you know, I follow you on Twitter and I heard that you're going to be in Belgium. Would you be up for flying to Paris and US interviewing you you know for our YouTube channel and I'm like well hell, yeah, like that's super cool and you know that they offer to like sponsor my travel to Paris from Belgium. Like that's insane just for a YouTube interview. I don't know so it's for me that like I'm being transparent here like. These are kind of big moments. These are moments where I go home and like this is something like this is more than nothing. This is somebody who's follows me on Twitter and wants to fly me somewhere to hear me talk like they're big moments and I guess I take pride in them and I feel good about them and I'm humbled by them or whatever, you know. Yeah, so so it feels pretty good. And that's why I'm reflecting on this and I'm like, you know, a lot of this is because of Livewire and. I think I could have maybe shot for some of these things without it. But live wires. The thing is the thing that that I guess I'm most known for at the moment and hopefully will become more known for as it becomes more valuable and and whatever so, I don't know I'm saying here. I guess what I'm saying though is like I underestimated the value of the reputation of it. I didn't really think of it like that. I thought of it first it was like just fun and a really useful tool and then I started to get my sights set on like maybe I could actually fund. My life with this tool and I think that maybe was a lofty goal at the time maybe eventually down the road. But but then I sort of shifted my sites to this is about my reputation. Like I want to build something. I want to make it really good as good as I can possibly make it really useful do a really good job on the docks and educational materials and everything just make it a really valuable tool for laravel developers and and I'll be recognized for that, you know, and that'll build their reputation and then it'll be kind of like a tool in my. Tool, I don't know like like a Resume Builder, you know something that that that I'll be able to any job I go to like I'm going to point a live wire. I'm gonna be like, hey, yeah, I spent a ton of time working on this open source project and you can see all the code. I wrote here and all the people you can see how I managed a how to Big open source project, you know, so it's been a wild ride and really good time and. Yeah, so that's that I think now is maybe a good it's pretty late and I got to go to bed these last three episodes. You can probably hear I have a cold and it's late at night. And so I'm really like quiet right now, but I was just in the reflective mood and I'm about to leave for Europe for two weeks and I'm putting the pen down. I'm not going to be on the computer too much. I will be at full stack you but outside of that will be traveling and doing whatever else so I'm going to be a little bit quiet. I'll release these. Maybe over the next two weeks, but but things will be a little quiet. I won't be really around much, but I'm but when I get back I'm going to be hitting it hard. So so there's definitely some exciting stuff to come in the Live Wire front that I can't wait to talk about and work on it. Whatever so stay tuned. Thanks for listening to Lon. Enjoy your cab ride by.

The Value Of A Reputation

[00:00:00] Caleb: I am having a ton of fun recording these I've started episode 1 and I'm on the episode 6 and just one sitting so not on npm Livewire is not an npm. You cannot do npm install Live Wire. Well, you actually might be able to I think Livewire was taken but that was one kind of early problem. But this is another story of something that's just invisible that at one time. I thought differently and struggled with. The JavaScript portion of live or so JavaScript like Livewire if you go and get Hub in the repo, I forget what the percentage is it something like 60 or 65% JavaScript. So there's a huge JavaScript portion JavaScript and PHP. So to include it I thought of course. Well, I would have a package and it would be on npm. And when you install live where you would do composer require live, we're live wire and npm install live wire in a perfect world. Unfortunately, the GitHub organization like I mentioned last episode live wire was not available. So that was hard and npm install live wires. [00:01:00] Also not available. I would need you know to be like npm install layer of alive or something like that. So that was just generally annoying but I thought of course I would need a separate repo. And the separate npm package and managed at all, but for starters, I while I was developing and I'm like, you know what I'm going to yag me this and I'm just going to stick all of the JavaScript in line in a script tag on every page. So when you do at Livewire assets, this was just my stand-in this was not meant to be permanent because I'm still thinking like, oh everybody's got an app dot JS and level mix and they're all going to be using this and then, you know, you're not allowed to do something outside of that. You have to work within that. But I left it in the script tag for a long time because I was doing these user tests. And so I'm looking at David temples user tests and I had to coach him through how to get the npm how to get the npm thing locally and npm Link it so we can symlink his local Livewire JavaScript thing and get it running inside [00:02:00] just stupid. So I just threw it right inside of a blade directive so that when I'm user testing users. Can just use it really easily and not have to deal with all that npm garbage, which is funny because basically that that sentiment has stood since then it's like well if that applied to that small user testing group, even if it's on npm it applies to everybody like who wants to mess around with npm. Npm is a nightmare. So put it first it was in a script tag and I'm like, all right. This is the best user experience, but it's not responsible. Like unloading a freaking massive script tag on every single page all the time. Like that's definitely not viable for production. And I think I think I changed this like not even that long before I launched Live Wire was one of those things it's like. Livewire works and that's just for like development right now. So this is okay. But at some point I'm going to have to be responsible and put it in npm. So when I went to do that make that decision, I really sort of held fast to the Simplicity of like what if I didn't [00:03:00] have it on npm if I have it on npm than any time. I work on the JavaScript. I'm gonna have to push to a separate repo manage separate tags and releases it. Basically I'm turning my work in from one into two. Like it's the same like reason that micros that I like heavily resist microservices is because you don't understand the cost of distributed systems like at you just you're duplicating all like so many pieces of work. There's so much more friction. So I wanted the development to be frictionless for me and a mono repo is very frictionless and friendly for me. So that is what I decided to go with the next question was how do I get this to not. How do I get this to not just load on everybody's page? Okay. Well, so this is funny because now I know that like packages like laravel Nova telescope. They they handle this by you publishing assets. So in laravel, if you're a package maintainer, there's like a this Arrow publishes inside of your service provider or you can say [00:04:00] when a user types Artisan vendor publish and then your service provider name or whatever. Basically you can you can stick files in their larval. So I so telescope does this by sticking, you know, it's JavaScript assets inside of like public / vendors. / probably telescope / probably telescope that mean that JS or something so I could have done that but I didn't really like that because I don't I hate doing vendor publish. I absolutely hate it maybe not as much for configs, but still it's like if I look at your install instruction, we've gotten so good with with laravel there was a time. Not that long ago when there was no auto-discovery and you had to manually add the service provider to app that PHP. That was a dark time. And it every installing any package felt. There was a hurdle for newcomers to install packages. I remember the friction of that. I remember being intimidated by adding a service provider the name service provider is intimidating to me. So adding a package now is as easy as [00:05:00] composer require. Why would I add on another layer of vendor publish? Where does it publish? What does it publish and then when I upgrade the JavaScript assets, they have to remember to republish or have to add some automation to automatically publish an overwrite. It just didn't feel good. So I had this brilliant idea. What if I served JavaScript from a route. It's like what if I just had a route like in laravel like in my search fried if I register route:: get. Livewire dot JS literally and then just echoed out all the you know, the contents of my built Javascript file. So turns out that that is a no-go it works but the caching is totally broken because of course if your browser is hitting a PHP endpoint, it's not going to Cache the results like a file its going to like hit the new hit the end point every time so that because it's Dynamic. So I dug into like can I fake caching you can you can spoof that? It's just returning a file. You have to add a bunch of cache headers. It's really complex. I got it to work locally and then till came in not that long ago and he like [00:06:00] totally whipped it into shape and gave me all the right headers. Like it's there's certain things that you have to calculate. That's just absolutely Bonkers that we're still not even doing because doing it's just ridiculous. So anyway, he still likes vendor published because of nginx cashing in whatever soap. I added that for him. Will he pull requested it but. Laravel is not on npm. It's just it's just all contain. The JavaScript is invisible to you. You shouldn't ever have to worry about it by default. When I thought that was really nice and it sort of speaks the the overall the overarching goal or principle here for Live Wire is Apple. Like I want it to be integrated. I want it to be easy and seamless. I want it to be zero config. I want you to have to do nothing. Like I right now it's composer require Live Wire Live Wire and at live where assets on your page to load the assets. I'd even like toyed with how could I get rid of that live our assets? So [00:07:00] once you compose require, you're literally using Live Wire, like that's that's kind of a deep dark goal, but I think that's too far. Anyway, there is a sliding scale where if I have in my mind that configuration is, okay. And that you know, like like dealing with files and settings for users is okay. I'm going to I'm going to make decisions in that direction if I decide that that's not okay. I'll make decisions in the other direction. And that's where I have all the fun is pushing that envelope like how integrated. Can I make this tool? How many things can I take care of for the user and make it invisible? So that they don't feel any pain or see any metal and this is some developers don't like this like till he's like, I would much rather publish the assets and have control over those files myself, and that's fine. So I think that's that's sort of My Philosophy with with most projects that I do like better phpunit same sort of philosophy is like make it like sensible defaults exactly like 0 config sensible defaults, [00:08:00] but you can but ADD extension points for developers who want extension points. Now you can publish a config file for live where if you want to customize things, but you don't have to you could never deal with the config file and you would be fine. Like that's sort of that's that's a goal of mine. So live where 0 config not on npm. I never have to deal with npm now. Which is great and I don't have to have that moral dilemma. Do I do npm layer of a live wire and get Taylor to give me permission for that or do I do live where / framework - framework and feel like gross for the rest of my life or at Livewire. Whatever. I don't know. It's a hard enough life. That's that's what I got for you today. Thanks.

[00:00:00] Caleb: I am having a ton of fun recording these I've started episode 1 and I'm on the episode 6 and just one sitting so not on npm Livewire is not an npm. You cannot do npm install Live Wire. Well, you actually might be able to I think Livewire was taken but that was one kind of early problem. But this is another story of something that's just invisible that at one time. I thought differently and struggled with. The JavaScript portion of live or so JavaScript like Livewire if you go and get Hub in the repo, I forget what the percentage is it something like 60 or 65% JavaScript. So there's a huge JavaScript portion JavaScript and PHP. So to include it I thought of course. Well, I would have a package and it would be on npm. And when you install live where you would do composer require live, we're live wire and npm install live wire in a perfect world. Unfortunately, the GitHub organization like I mentioned last episode live wire was not available. So that was hard and npm install live wires. [00:01:00] Also not available. I would need you know to be like npm install layer of alive or something like that. So that was just generally annoying but I thought of course I would need a separate repo. And the separate npm package and managed at all, but for starters, I while I was developing and I'm like, you know what I'm going to yag me this and I'm just going to stick all of the JavaScript in line in a script tag on every page. So when you do at Livewire assets, this was just my stand-in this was not meant to be permanent because I'm still thinking like, oh everybody's got an app dot JS and level mix and they're all going to be using this and then, you know, you're not allowed to do something outside of that. You have to work within that. But I left it in the script tag for a long time because I was doing these user tests. And so I'm looking at David temples user tests and I had to coach him through how to get the npm how to get the npm thing locally and npm Link it so we can symlink his local Livewire JavaScript thing and get it running inside [00:02:00] just stupid. So I just threw it right inside of a blade directive so that when I'm user testing users. Can just use it really easily and not have to deal with all that npm garbage, which is funny because basically that that sentiment has stood since then it's like well if that applied to that small user testing group, even if it's on npm it applies to everybody like who wants to mess around with npm. Npm is a nightmare. So put it first it was in a script tag and I'm like, all right. This is the best user experience, but it's not responsible. Like unloading a freaking massive script tag on every single page all the time. Like that's definitely not viable for production. And I think I think I changed this like not even that long before I launched Live Wire was one of those things it's like. Livewire works and that's just for like development right now. So this is okay. But at some point I'm going to have to be responsible and put it in npm. So when I went to do that make that decision, I really sort of held fast to the Simplicity of like what if I didn't [00:03:00] have it on npm if I have it on npm than any time. I work on the JavaScript. I'm gonna have to push to a separate repo manage separate tags and releases it. Basically I'm turning my work in from one into two. Like it's the same like reason that micros that I like heavily resist microservices is because you don't understand the cost of distributed systems like at you just you're duplicating all like so many pieces of work. There's so much more friction. So I wanted the development to be frictionless for me and a mono repo is very frictionless and friendly for me. So that is what I decided to go with the next question was how do I get this to not. How do I get this to not just load on everybody's page? Okay. Well, so this is funny because now I know that like packages like laravel Nova telescope. They they handle this by you publishing assets. So in laravel, if you're a package maintainer, there's like a this Arrow publishes inside of your service provider or you can say [00:04:00] when a user types Artisan vendor publish and then your service provider name or whatever. Basically you can you can stick files in their larval. So I so telescope does this by sticking, you know, it's JavaScript assets inside of like public / vendors. / probably telescope / probably telescope that mean that JS or something so I could have done that but I didn't really like that because I don't I hate doing vendor publish. I absolutely hate it maybe not as much for configs, but still it's like if I look at your install instruction, we've gotten so good with with laravel there was a time. Not that long ago when there was no auto-discovery and you had to manually add the service provider to app that PHP. That was a dark time. And it every installing any package felt. There was a hurdle for newcomers to install packages. I remember the friction of that. I remember being intimidated by adding a service provider the name service provider is intimidating to me. So adding a package now is as easy as [00:05:00] composer require. Why would I add on another layer of vendor publish? Where does it publish? What does it publish and then when I upgrade the JavaScript assets, they have to remember to republish or have to add some automation to automatically publish an overwrite. It just didn't feel good. So I had this brilliant idea. What if I served JavaScript from a route. It's like what if I just had a route like in laravel like in my search fried if I register route:: get. Livewire dot JS literally and then just echoed out all the you know, the contents of my built Javascript file. So turns out that that is a no-go it works but the caching is totally broken because of course if your browser is hitting a PHP endpoint, it's not going to Cache the results like a file its going to like hit the new hit the end point every time so that because it's Dynamic. So I dug into like can I fake caching you can you can spoof that? It's just returning a file. You have to add a bunch of cache headers. It's really complex. I got it to work locally and then till came in not that long ago and he like [00:06:00] totally whipped it into shape and gave me all the right headers. Like it's there's certain things that you have to calculate. That's just absolutely Bonkers that we're still not even doing because doing it's just ridiculous. So anyway, he still likes vendor published because of nginx cashing in whatever soap. I added that for him. Will he pull requested it but. Laravel is not on npm. It's just it's just all contain. The JavaScript is invisible to you. You shouldn't ever have to worry about it by default. When I thought that was really nice and it sort of speaks the the overall the overarching goal or principle here for Live Wire is Apple. Like I want it to be integrated. I want it to be easy and seamless. I want it to be zero config. I want you to have to do nothing. Like I right now it's composer require Live Wire Live Wire and at live where assets on your page to load the assets. I'd even like toyed with how could I get rid of that live our assets? So [00:07:00] once you compose require, you're literally using Live Wire, like that's that's kind of a deep dark goal, but I think that's too far. Anyway, there is a sliding scale where if I have in my mind that configuration is, okay. And that you know, like like dealing with files and settings for users is okay. I'm going to I'm going to make decisions in that direction if I decide that that's not okay. I'll make decisions in the other direction. And that's where I have all the fun is pushing that envelope like how integrated. Can I make this tool? How many things can I take care of for the user and make it invisible? So that they don't feel any pain or see any metal and this is some developers don't like this like till he's like, I would much rather publish the assets and have control over those files myself, and that's fine. So I think that's that's sort of My Philosophy with with most projects that I do like better phpunit same sort of philosophy is like make it like sensible defaults exactly like 0 config sensible defaults, [00:08:00] but you can but ADD extension points for developers who want extension points. Now you can publish a config file for live where if you want to customize things, but you don't have to you could never deal with the config file and you would be fine. Like that's sort of that's that's a goal of mine. So live where 0 config not on npm. I never have to deal with npm now. Which is great and I don't have to have that moral dilemma. Do I do npm layer of a live wire and get Taylor to give me permission for that or do I do live where / framework - framework and feel like gross for the rest of my life or at Livewire. Whatever. I don't know. It's a hard enough life. That's that's what I got for you today. Thanks.

Not On NPM

Hello again. Uh, this is a serial episode, so I'm recording this one second after I just recorded the last one. So the last episode, we talked about these hard validation problems, and hopefully I illustrated to you some of the issues that really STEM from a difference that I wasn't aware of that I wasn't really, that I hadn't formalized, but I cleared up the difference that there's two types of valid two types of things people are trying to do in an app. Then I was able to solve it. When I separated out into two separate methods, validate and validate only, and I think it's going to be intuitive. I'm going to document it up and I think everybody is just going to think it. Uh, it works the way it should work and I'm, I'm so happy with it. Half. So happy with it. Like I finally, this has been. Something nagging in the back of my mind that's not perfect. And now in my mind, it's perfect in my mind. Maybe it's not in reality, but I think it's perfect. So I'm putting it to bed, um, and I can move on with my life. Uh, but this brings me to a bit of a bigger discussion. Um. This problem I, there's two ways I could have approached this. So, you know, the way I did approach it, um, I also could have approached it a different way, which is actually how I started approaching it. I. You get an a get hub issue where somebody says, Hey, it would be cool if the validation persisted from request to request, you know? Oh, yeah, yeah. Okay. We should make that available. Well, how do we do that? Maybe we'll add a config option. Maybe we'll add someone. How would we configure that ability? Okay, well, what if we have a trait called persists validation that maybe you just add used, persists validation. We document it. Okay. Right, right. So that's fine. And I actually started that way. I actually have a trait in a sample app called persist validation that I was messing with, and then, okay, that real time validation, they want maybe have a thing called persist validation and only validates specific fields or whatever. Okay. Maybe we have used real time validation, whatever. You just keep adding in these options. That describe the functionality, but they don't describe the use case. Um, and this was the road I was starting down, but it felt fuzzy to me, and I just hate adding more documentation for specific functionality that you have to now understand and know you have to understand everything that I understand and, and it's hard for me to understand this stuff. So why would I burden every user with that? So basically I had a choice. And I've had this choice a hundred times in Livewire, and every time I come across this choice, I don't realize it. It is that choice right away. But when I do realize that it's a choice between an invisible feature and a visible feature, and by that I mean an invisible feature is something that user will never notice. A visible feature is like them looking up how to do a specific thing and adding a trait and whatever. Once I realized that it's, that, that, that, uh, that fork in the road, I just. Choose the invisible, the invisibility route. I just go with the invisible. Um, and that, that's been my path with this whole Livewire thing is like, find the way that people expect it should work, which is so hard. And it takes like, user testing is super value. Interviewing people, using it yourself, dogfooding it, thinking about it a lot. Um, those are all the things I employ to anticipate how a user. Would expect it to work and then make it work the way they expect it to work. So basically I picture, like I picture a cartoon character, like walking in space and the road is like filling in as they walk, you know, like, it's like. The road is maybe it's like a brick road and the bricks are floating up from the abyss and just kind of assembling in front of them and maybe their eyes are closed in, they're whistling a happy tune, and they have no idea that if the road stops building itself, they'll fall to their death. But it's just magically happening as they go. I think that's the, the, and now I literally just came up with that right now. Um, it's pretty off the wall, but, uh, I think it's actually kind of. I think it's kind of accurate. That's what I want Livewire to be. I want it to be a road that assembles in front of you and you have no idea. You think you're just walking and whistling and happy tune. But underneath the hood there's like crazy stuff happening, you know, to make this happen. Um, and from an implementation perspective, I tend towards the simple implementation. I tend towards wanting it to be a simple tool with a bare set of, that's another balance. I'm, everything in life is balances, but that's another balance that competes with this value of invisibility. The value of a simple implementation, a simple set of tools that the user understands and can manipulate. I think of it kind of like the react versus view dichotomy where VJs has a lot of, um, it has a wider API because it caters to specific use cases with specific API APIs where react is more like a bare set of tools. And for those use cases, you can use a, that set of tools to accomplish what you need to accomplish. Um, and certain people like. There's differences in both of them, and there's different things to like with view. It might cater to specific things really well, but because you don't, I actually think that this, this is not an all encompassing. This is a reduction of view in react. I'm just saying that, but let's just go with the metaphor and let's just, uh, um, turn these two tools into characatures with view. With a wider API that is more specific for specific use cases for use cases, it, um, it fits the needs really well for those things. But then when there's needs outside of it, you feel like you're hacking something, um, or you're doing something that's unintended because it's more opinionated, where react is less opinionated and it's more of a bare bones set of tools. You, uh, when you, it has a slimmer API, so you have to employ more mojo to figure out how to do something and you run the risk of doing it in a not ideal way because. You don't understand it that well, the learning curve is higher, but when you run across something that you don't know how it solves you, you pretty much already do that for everything else. So you'll feel okay, you know, I'm mixing and matching techniques to get the job done. Okay, so that's a competing, those are competing values. This like, I want to, I want live wear to feel invisible. And also I want live where to fear, feel like a bare bones set of tools that's implemented in a simple way and is a transparent tool. I think that, and that's where react is moving towards with this hooks thing. This like a, you know, this hooks reveal the nature, the true nature of react or whatever, and it. Totally steepen the learning curve and a lot of people, it just kind of boggles their mind. Um, it's very confusing. They use effect hook specifically. Um, and it's something in that people talk about a lot. And this, I think this is an example of like maybe Dan AB off and I, I don't know that much about react. So again, just go with the metaphor or analogy. So like Dan Habermas was saying, well, I'm going to, let's reveal what, let's provide an API that reveals the way react works. Then. People can use it too. It's two. It's op most optimal. You know, they, you know, I, it makes sense. I understand that temptation. Um, where I imagine Avenue has a different approach to his tool, um, view. So anyway, so it's a competing thing where I want live, where to feel invisible. I also want it to feel like you understand how it works so that you can mix and match and be creative with it. It's a very, very hard thing to balance, but I'll say that in general, I choose in visibility as much as I can. Yeah. It's funny. That is, that is something intention because now that I'm saying it, the more I choose invisibility, often the, the more complex I'm making the inner workings of Livewire. And there's so many examples of this, but I guess I'll just give you two examples in the past two days. So I paired with my buddy Mark yesterday. Um, he's Mark salmon, shout out to him. He's, he's an awesome guy, is using live wire in a project. And so I just called them up to pair with him, um, and sort of get, you know, like what are the problems he's facing and whatnot. And so we talked about, um, what did we talk about? We talked about a specific. Holy crap. I don't even remember right now. Well, let's just say that it'll hit me as I'm talking about it, but it was a feature and, and I was sort of saying, well, yeah, we could add this, this option, this like. Config option or we could just handle this automatically. And he was like, well, maybe we could add a config option. And, and, and it quickly, it was apparent to me again, Oh, this is the choosing visibility thing. Now we have to make it invisible. We have to do it the way that you'd expect it to work. And so the validation thing is the same way. I chose invisibility. I chose to work really hard to understand how people expect it to work. It anticipate their use cases. And then build the road right in front of them so that they don't worry about it. They're not thinking, you know, when they use this arrow validate and the validation just works in persist across requests, they'll go, Oh yeah, that's how it's supposed to work. They won't even say that. It'll just work the way they think it should work. They have no idea what's going on under the hood. And the pains that I went through to like deal with message bags and persisting message bags and merging message bags and persisting only specific fields and message bags and, and detecting if it's a validation error. From, that was like thrown inside the component or if it, you already added a with errors onto the view that the render function returns like, ah, the story goes on and on and on, and there's a hundred examples of this in live where I chose the route of invisibility, even though it means making the app a little bit more complex and, but that's, that's just what I want live where to be. I don't know. I want it to be something that, that, that just feels like scary, easy to use an install. Like the installation steps are still two steps. You don't have to publish a config file, you don't have to configure anything. You're just composer require add the little assets and you're off to the races. So anyway, that's, that's my, that's my labor on a, on Livewire is making it feel. Completely invisible, hopefully, and seamless. Yeah, but who knows? Maybe one day I'll want to reveal the nature of Livewire and add hooks and make it really hard to use, except for really smart people, and then they'll all feel superior and talk about our conferences and everybody will feel inferior and decide that it's definitely the way to go because whatever. Bye.

Hello again. Uh, this is a serial episode, so I'm recording this one second after I just recorded the last one. So the last episode, we talked about these hard validation problems, and hopefully I illustrated to you some of the issues that really STEM from a difference that I wasn't aware of that I wasn't really, that I hadn't formalized, but I cleared up the difference that there's two types of valid two types of things people are trying to do in an app. Then I was able to solve it. When I separated out into two separate methods, validate and validate only, and I think it's going to be intuitive. I'm going to document it up and I think everybody is just going to think it. Uh, it works the way it should work and I'm, I'm so happy with it. Half. So happy with it. Like I finally, this has been. Something nagging in the back of my mind that's not perfect. And now in my mind, it's perfect in my mind. Maybe it's not in reality, but I think it's perfect. So I'm putting it to bed, um, and I can move on with my life. Uh, but this brings me to a bit of a bigger discussion. Um. This problem I, there's two ways I could have approached this. So, you know, the way I did approach it, um, I also could have approached it a different way, which is actually how I started approaching it. I. You get an a get hub issue where somebody says, Hey, it would be cool if the validation persisted from request to request, you know? Oh, yeah, yeah. Okay. We should make that available. Well, how do we do that? Maybe we'll add a config option. Maybe we'll add someone. How would we configure that ability? Okay, well, what if we have a trait called persists validation that maybe you just add used, persists validation. We document it. Okay. Right, right. So that's fine. And I actually started that way. I actually have a trait in a sample app called persist validation that I was messing with, and then, okay, that real time validation, they want maybe have a thing called persist validation and only validates specific fields or whatever. Okay. Maybe we have used real time validation, whatever. You just keep adding in these options. That describe the functionality, but they don't describe the use case. Um, and this was the road I was starting down, but it felt fuzzy to me, and I just hate adding more documentation for specific functionality that you have to now understand and know you have to understand everything that I understand and, and it's hard for me to understand this stuff. So why would I burden every user with that? So basically I had a choice. And I've had this choice a hundred times in Livewire, and every time I come across this choice, I don't realize it. It is that choice right away. But when I do realize that it's a choice between an invisible feature and a visible feature, and by that I mean an invisible feature is something that user will never notice. A visible feature is like them looking up how to do a specific thing and adding a trait and whatever. Once I realized that it's, that, that, that, uh, that fork in the road, I just. Choose the invisible, the invisibility route. I just go with the invisible. Um, and that, that's been my path with this whole Livewire thing is like, find the way that people expect it should work, which is so hard. And it takes like, user testing is super value. Interviewing people, using it yourself, dogfooding it, thinking about it a lot. Um, those are all the things I employ to anticipate how a user. Would expect it to work and then make it work the way they expect it to work. So basically I picture, like I picture a cartoon character, like walking in space and the road is like filling in as they walk, you know, like, it's like. The road is maybe it's like a brick road and the bricks are floating up from the abyss and just kind of assembling in front of them and maybe their eyes are closed in, they're whistling a happy tune, and they have no idea that if the road stops building itself, they'll fall to their death. But it's just magically happening as they go. I think that's the, the, and now I literally just came up with that right now. Um, it's pretty off the wall, but, uh, I think it's actually kind of. I think it's kind of accurate. That's what I want Livewire to be. I want it to be a road that assembles in front of you and you have no idea. You think you're just walking and whistling and happy tune. But underneath the hood there's like crazy stuff happening, you know, to make this happen. Um, and from an implementation perspective, I tend towards the simple implementation. I tend towards wanting it to be a simple tool with a bare set of, that's another balance. I'm, everything in life is balances, but that's another balance that competes with this value of invisibility. The value of a simple implementation, a simple set of tools that the user understands and can manipulate. I think of it kind of like the react versus view dichotomy where VJs has a lot of, um, it has a wider API because it caters to specific use cases with specific API APIs where react is more like a bare set of tools. And for those use cases, you can use a, that set of tools to accomplish what you need to accomplish. Um, and certain people like. There's differences in both of them, and there's different things to like with view. It might cater to specific things really well, but because you don't, I actually think that this, this is not an all encompassing. This is a reduction of view in react. I'm just saying that, but let's just go with the metaphor and let's just, uh, um, turn these two tools into characatures with view. With a wider API that is more specific for specific use cases for use cases, it, um, it fits the needs really well for those things. But then when there's needs outside of it, you feel like you're hacking something, um, or you're doing something that's unintended because it's more opinionated, where react is less opinionated and it's more of a bare bones set of tools. You, uh, when you, it has a slimmer API, so you have to employ more mojo to figure out how to do something and you run the risk of doing it in a not ideal way because. You don't understand it that well, the learning curve is higher, but when you run across something that you don't know how it solves you, you pretty much already do that for everything else. So you'll feel okay, you know, I'm mixing and matching techniques to get the job done. Okay, so that's a competing, those are competing values. This like, I want to, I want live wear to feel invisible. And also I want live where to fear, feel like a bare bones set of tools that's implemented in a simple way and is a transparent tool. I think that, and that's where react is moving towards with this hooks thing. This like a, you know, this hooks reveal the nature, the true nature of react or whatever, and it. Totally steepen the learning curve and a lot of people, it just kind of boggles their mind. Um, it's very confusing. They use effect hook specifically. Um, and it's something in that people talk about a lot. And this, I think this is an example of like maybe Dan AB off and I, I don't know that much about react. So again, just go with the metaphor or analogy. So like Dan Habermas was saying, well, I'm going to, let's reveal what, let's provide an API that reveals the way react works. Then. People can use it too. It's two. It's op most optimal. You know, they, you know, I, it makes sense. I understand that temptation. Um, where I imagine Avenue has a different approach to his tool, um, view. So anyway, so it's a competing thing where I want live, where to feel invisible. I also want it to feel like you understand how it works so that you can mix and match and be creative with it. It's a very, very hard thing to balance, but I'll say that in general, I choose in visibility as much as I can. Yeah. It's funny. That is, that is something intention because now that I'm saying it, the more I choose invisibility, often the, the more complex I'm making the inner workings of Livewire. And there's so many examples of this, but I guess I'll just give you two examples in the past two days. So I paired with my buddy Mark yesterday. Um, he's Mark salmon, shout out to him. He's, he's an awesome guy, is using live wire in a project. And so I just called them up to pair with him, um, and sort of get, you know, like what are the problems he's facing and whatnot. And so we talked about, um, what did we talk about? We talked about a specific. Holy crap. I don't even remember right now. Well, let's just say that it'll hit me as I'm talking about it, but it was a feature and, and I was sort of saying, well, yeah, we could add this, this option, this like. Config option or we could just handle this automatically. And he was like, well, maybe we could add a config option. And, and, and it quickly, it was apparent to me again, Oh, this is the choosing visibility thing. Now we have to make it invisible. We have to do it the way that you'd expect it to work. And so the validation thing is the same way. I chose invisibility. I chose to work really hard to understand how people expect it to work. It anticipate their use cases. And then build the road right in front of them so that they don't worry about it. They're not thinking, you know, when they use this arrow validate and the validation just works in persist across requests, they'll go, Oh yeah, that's how it's supposed to work. They won't even say that. It'll just work the way they think it should work. They have no idea what's going on under the hood. And the pains that I went through to like deal with message bags and persisting message bags and merging message bags and persisting only specific fields and message bags and, and detecting if it's a validation error. From, that was like thrown inside the component or if it, you already added a with errors onto the view that the render function returns like, ah, the story goes on and on and on, and there's a hundred examples of this in live where I chose the route of invisibility, even though it means making the app a little bit more complex and, but that's, that's just what I want live where to be. I don't know. I want it to be something that, that, that just feels like scary, easy to use an install. Like the installation steps are still two steps. You don't have to publish a config file, you don't have to configure anything. You're just composer require add the little assets and you're off to the races. So anyway, that's, that's my, that's my labor on a, on Livewire is making it feel. Completely invisible, hopefully, and seamless. Yeah, but who knows? Maybe one day I'll want to reveal the nature of Livewire and add hooks and make it really hard to use, except for really smart people, and then they'll all feel superior and talk about our conferences and everybody will feel inferior and decide that it's definitely the way to go because whatever. Bye.

Choose Invisibility

Using view with Livewire. So this is the part of the show where Larry comes out and sings a silly song. This is the part of the show my lyric on talk where I you know this for me was like a show-stopping moment. Like, you know, I was demoing some pretty cool stuff with Livewire getting you know, the audience seemed to be pretty engaged that I showed how you can pop into view component and instead of the model you can do while your model and you get the same data binding. Then you just use a view component that you already have and that there was this moment like I expected Applause, but nobody applauded it was just silent and then I said something like pretty cool huh? And then a bunch of people started clapping and I mean, I think it was just one of those moments where everybody was like what the f like. Wow. Did this even what like, how does that work? And it is pretty crazy that that that Prospect of like yeah live where all this is really cool. Yeah, but you know, I love you like I need view for you know, my little I don't know tag input elements or whatever you think you need view for and and this was a moment where I was like, whoa, I can use both. Yeah, so I really wanted. Live where to work with UJS. I don't we haven't really talked about the whole strategy of how I got that to work. It's actually kind of a funny story. So maybe I'll give you the skinny of it, but basically view JS does Dom dipping right like few JS is a front-end framework that. You know, your component is rendered. It renders the template. All right. So how does view work view takes your template turns it into basically render functions render function that spits out a virtual Dom which is a Json tree of elements and their attributes and their children. And then anytime something's updated. It re-renders that little Json tree the virtual Dom. It takes a difference of the two dumbs. You know, the one that's like actually implemented and like shown on the screen and the new one that it just rendered out of the component takes a dip and then it patches so it updates on the screen and then your page updates and everybody's happy and all is well. It's basically have UJS works. That's how most front-end Frameworks kind of work. So live. Where does the same thing kind of accept it gets the Dom from from the server instead of managing virtual Dom trees. It gets it in plain HTML does the Dom dipping and patching? So you have two things that are both trying to different patch the Dom they're trying to control the Dom they they have control over their own little domains. So it's an issue at first I thought well. Livewire is just not going to work with UJS. It's just not in the cards for it. But this is one of those examples of me thinking like me learning pretty early on that. Okay, anything that I think is impossible or like way too hard to bother with that's not necessarily true. Like don't trust that instinct give it time. The the solution might present itself. If you feel like it's mandatory. If you feel like it needs to happen just decide that it has to happen and then figure out how to do it. This is one of those things that you know, took me a long time at first. I thought no not possible. Then I thought this is huge for the success of live where I like for people to use this in their apps. They're going to want to use View and if they can it's going to be huge for like, you know, just adoption in general. So I decided that you know, if they if it all possible this thing needs to happen. I need to make it happen somehow. So I couldn't really I tried a bunch of things. You know, I like just I tried, you know, letting View kind of handle the Dom and then Live Wire after the fact and whatever and like reinitializing view after Livewire updated everything and all this stuff, but they're man, there's crazy things like when you initialize view inside of a so you have your div your div with an ID of app and then you initialize your view component on that page and it takes control of that div and then adds all that stuff. So whatever HTML you have. Vue.js is going. Take that HTML and strip out all the white space in the new lines are all the like new line tags so you don't realize it. But when you're when you're right, like when you hit enter inside an HTML file, you're actually adding an element in the Dom. It's a text element. So if you're actually crawling the Dom with like next element or sit or sibling next to bling or whatever, you'll get these elements, but they're not. They're not normal element nodes or whatever. I forget all the names. It's a the text element and they have a body of a new line character, you know, so so I was having this this and that's all included in the Dom dipping stuff so live, where's doing this Dom dipping, but when you initialize view view wipes out all those new line breaks so live wires getting a mismatch. It's saying hey from the server. I'm getting these line breaks. I'm looking in the Dom there's no line breaks. And so every time it's doing all this crazy stuff. It's just crazy. So I was really frustrated and I didn't really know how to make it work. So I stride to manually remove the line breaks on the server side like parse out the HTML before I send it to the front end tried a bunch of different things. Basically what I ended up doing what the answer was and this is funny because I my buddy Mitch and I like we just paired on this in my apartment for probably like 4 hours one evening. We put the laptop up on the screen and we just switched off driving. I sat on the couch and he would just you know hack at it. See if you can get something working then we switch off and I try to get something working and we honestly we couldn't we got a couple things working but we couldn't get anything work in like really reliably that felt good and then it just kind of hit me like what if I let view manage the Dom. And Live Wire gets the one live or gets the HTML back from the server. It will take the HTML render it, you know, like put it into the Dom like not in the real Don yet, but just like fake mounted into some invisible Dom if you're probably totally lost on this if you're not super familiar with like JavaScript Dom stuff, but you know, like you can document dot create element and do stuff with that and that's dumb but it's just not mounted on the page, but it exists, you know, So do that sort of thing create some Dom element that's not on the page. But with all this HTML and then initialize a dummy view instance, like initialize it with view with with just a blank view instance. And just to have you do the formatting now views done the formatting and now I can do the Dom diff because. Because it's going to match whatever view did to the code before it's kind of hard to explain. But basically that's that's kind of the solution that's in place right now is like live there goes his view on this page. Okay views on this page, then I'll let view do the manipulating so that all the Dom diffs, you know work well and whatever again hard to explain I also detect if if I am doing the Dom dipping and one of the elements is a view component. I skip it in Live Wire and I let you handle that component completely. So anyway, that's the solution it's been that way for a long time and that works pretty well, but there's a bunch of little weird issues, you know, like one issue is well events, like if you admit events and view, they're not native Dom events or not those like custom events that you can listen to with like document dot add event. Listener. Their views has its own event bus, you know, so I hack into that a little bit to get wire model to work, but the other event emission stuff just doesn't work. That's kind of a bummer. And then also if you add view components like conditionally with view with Livewire like with blade add if you know Live Wire doesn't know to reinitialize like the view instance and so I don't know. I'm sure there's a kind of quick fix that would make that work but. But there's you know a little little bugs. I'm trying to make two front-end Frameworks work well with each other which is kind of hard. So basically the other day you probably saw my tweet but I discovered off this is funny because D: die I haven't released this podcast yet that no plans to merge podcast, but on the last no plans to merge podcast. We basically I'm basically telling him. Okay, dude, here's what I need. I need something that allows me to write a view component, but not have View. Like take over the whole app. I just need View kind of isolated to its own component. Like if I make like a some custom input component. I want to have a tag called some custom input and I don't want like a view name space around it. I don't want it to be in a view environment. I just want that element to be like a custom web component written in view that just kind of lives on its own. Not long after we recorded a podcast I started digging and I basically discovered exactly what I've been looking for. I don't know why I haven't looked explicitly before. There's a package called view custom element. I think that basically turns any view component into a web component. And if you're not familiar with web components web components are it's like a it's a I don't want to say up and coming because it's been up and coming for a long time. It's an API that's likes gonna suppose. I don't know the promise is that native browser functionality will allow you to make custom web custom elements like a normal element, but custom with its own JavaScript functionality and template just like a component like a react component or a view component, but this will be like native in browser functionality and it does exist already but there's lots of hard things hard problems with it uses the shadow Dom if you never heard of The Shadow Dom it's a whole topic, but basically it takes your view component. It turns it into a custom web element, which is awesome because you get all the benefits of custom web elements, like just native browser support, but you don't have to deal with all the annoying API of writing them and you know native JavaScript. So basically this is huge for Livewire and I kind of thought that and I tweeted it out whenever then I was pairing with somebody a client of mine. And he's like, yeah, I really want to add this view component into my life where component but you know, I can't get it to work and you know, we could have massaged it got it to work and I was pretty doubtful about it. But and this had to do with that conditional loading thing that I was like, oh man, I should do this view custom element thing. I pulled it in. And Bam, like it just worked beautifully because Livewire just thinks it's normal Dom because views not trying to like hijack everything. So I don't know if this makes sense to you, but I know I'm like cramming in what I wanted to be the whole episode in the last 10 seconds, but. But our times over I'm watching the time go that's what I think the future of view is. Okay, I'll go ten extra seconds to tell you that the future of view not the future of you. The future of view with Live Wire is going to be these custom web elements. I think I'm going to remove the like. Promise of using your view inside along with Livewire because it's just kind of I don't know. It just seems like it's going to spell out disaster. Just tell people if you really want to use your view components use this view custom element package and Adam that way and it'll be clean and like it'll just work perfectly so many less unknowns and you can listen to the. The events because this package converts those View events in a native Dom events. So this is kind of like a high-level me blabbering on about View and Livewire skipping over a lot of stuff, but I don't know. Hopefully you found it enjoyable. Thanks for the extra 44 seconds. Enjoy your hike.

Using view with Livewire. So this is the part of the show where Larry comes out and sings a silly song. This is the part of the show my lyric on talk where I you know this for me was like a show-stopping moment. Like, you know, I was demoing some pretty cool stuff with Livewire getting you know, the audience seemed to be pretty engaged that I showed how you can pop into view component and instead of the model you can do while your model and you get the same data binding. Then you just use a view component that you already have and that there was this moment like I expected Applause, but nobody applauded it was just silent and then I said something like pretty cool huh? And then a bunch of people started clapping and I mean, I think it was just one of those moments where everybody was like what the f like. Wow. Did this even what like, how does that work? And it is pretty crazy that that that Prospect of like yeah live where all this is really cool. Yeah, but you know, I love you like I need view for you know, my little I don't know tag input elements or whatever you think you need view for and and this was a moment where I was like, whoa, I can use both. Yeah, so I really wanted. Live where to work with UJS. I don't we haven't really talked about the whole strategy of how I got that to work. It's actually kind of a funny story. So maybe I'll give you the skinny of it, but basically view JS does Dom dipping right like few JS is a front-end framework that. You know, your component is rendered. It renders the template. All right. So how does view work view takes your template turns it into basically render functions render function that spits out a virtual Dom which is a Json tree of elements and their attributes and their children. And then anytime something's updated. It re-renders that little Json tree the virtual Dom. It takes a difference of the two dumbs. You know, the one that's like actually implemented and like shown on the screen and the new one that it just rendered out of the component takes a dip and then it patches so it updates on the screen and then your page updates and everybody's happy and all is well. It's basically have UJS works. That's how most front-end Frameworks kind of work. So live. Where does the same thing kind of accept it gets the Dom from from the server instead of managing virtual Dom trees. It gets it in plain HTML does the Dom dipping and patching? So you have two things that are both trying to different patch the Dom they're trying to control the Dom they they have control over their own little domains. So it's an issue at first I thought well. Livewire is just not going to work with UJS. It's just not in the cards for it. But this is one of those examples of me thinking like me learning pretty early on that. Okay, anything that I think is impossible or like way too hard to bother with that's not necessarily true. Like don't trust that instinct give it time. The the solution might present itself. If you feel like it's mandatory. If you feel like it needs to happen just decide that it has to happen and then figure out how to do it. This is one of those things that you know, took me a long time at first. I thought no not possible. Then I thought this is huge for the success of live where I like for people to use this in their apps. They're going to want to use View and if they can it's going to be huge for like, you know, just adoption in general. So I decided that you know, if they if it all possible this thing needs to happen. I need to make it happen somehow. So I couldn't really I tried a bunch of things. You know, I like just I tried, you know, letting View kind of handle the Dom and then Live Wire after the fact and whatever and like reinitializing view after Livewire updated everything and all this stuff, but they're man, there's crazy things like when you initialize view inside of a so you have your div your div with an ID of app and then you initialize your view component on that page and it takes control of that div and then adds all that stuff. So whatever HTML you have. Vue.js is going. Take that HTML and strip out all the white space in the new lines are all the like new line tags so you don't realize it. But when you're when you're right, like when you hit enter inside an HTML file, you're actually adding an element in the Dom. It's a text element. So if you're actually crawling the Dom with like next element or sit or sibling next to bling or whatever, you'll get these elements, but they're not. They're not normal element nodes or whatever. I forget all the names. It's a the text element and they have a body of a new line character, you know, so so I was having this this and that's all included in the Dom dipping stuff so live, where's doing this Dom dipping, but when you initialize view view wipes out all those new line breaks so live wires getting a mismatch. It's saying hey from the server. I'm getting these line breaks. I'm looking in the Dom there's no line breaks. And so every time it's doing all this crazy stuff. It's just crazy. So I was really frustrated and I didn't really know how to make it work. So I stride to manually remove the line breaks on the server side like parse out the HTML before I send it to the front end tried a bunch of different things. Basically what I ended up doing what the answer was and this is funny because I my buddy Mitch and I like we just paired on this in my apartment for probably like 4 hours one evening. We put the laptop up on the screen and we just switched off driving. I sat on the couch and he would just you know hack at it. See if you can get something working then we switch off and I try to get something working and we honestly we couldn't we got a couple things working but we couldn't get anything work in like really reliably that felt good and then it just kind of hit me like what if I let view manage the Dom. And Live Wire gets the one live or gets the HTML back from the server. It will take the HTML render it, you know, like put it into the Dom like not in the real Don yet, but just like fake mounted into some invisible Dom if you're probably totally lost on this if you're not super familiar with like JavaScript Dom stuff, but you know, like you can document dot create element and do stuff with that and that's dumb but it's just not mounted on the page, but it exists, you know, So do that sort of thing create some Dom element that's not on the page. But with all this HTML and then initialize a dummy view instance, like initialize it with view with with just a blank view instance. And just to have you do the formatting now views done the formatting and now I can do the Dom diff because. Because it's going to match whatever view did to the code before it's kind of hard to explain. But basically that's that's kind of the solution that's in place right now is like live there goes his view on this page. Okay views on this page, then I'll let view do the manipulating so that all the Dom diffs, you know work well and whatever again hard to explain I also detect if if I am doing the Dom dipping and one of the elements is a view component. I skip it in Live Wire and I let you handle that component completely. So anyway, that's the solution it's been that way for a long time and that works pretty well, but there's a bunch of little weird issues, you know, like one issue is well events, like if you admit events and view, they're not native Dom events or not those like custom events that you can listen to with like document dot add event. Listener. Their views has its own event bus, you know, so I hack into that a little bit to get wire model to work, but the other event emission stuff just doesn't work. That's kind of a bummer. And then also if you add view components like conditionally with view with Livewire like with blade add if you know Live Wire doesn't know to reinitialize like the view instance and so I don't know. I'm sure there's a kind of quick fix that would make that work but. But there's you know a little little bugs. I'm trying to make two front-end Frameworks work well with each other which is kind of hard. So basically the other day you probably saw my tweet but I discovered off this is funny because D: die I haven't released this podcast yet that no plans to merge podcast, but on the last no plans to merge podcast. We basically I'm basically telling him. Okay, dude, here's what I need. I need something that allows me to write a view component, but not have View. Like take over the whole app. I just need View kind of isolated to its own component. Like if I make like a some custom input component. I want to have a tag called some custom input and I don't want like a view name space around it. I don't want it to be in a view environment. I just want that element to be like a custom web component written in view that just kind of lives on its own. Not long after we recorded a podcast I started digging and I basically discovered exactly what I've been looking for. I don't know why I haven't looked explicitly before. There's a package called view custom element. I think that basically turns any view component into a web component. And if you're not familiar with web components web components are it's like a it's a I don't want to say up and coming because it's been up and coming for a long time. It's an API that's likes gonna suppose. I don't know the promise is that native browser functionality will allow you to make custom web custom elements like a normal element, but custom with its own JavaScript functionality and template just like a component like a react component or a view component, but this will be like native in browser functionality and it does exist already but there's lots of hard things hard problems with it uses the shadow Dom if you never heard of The Shadow Dom it's a whole topic, but basically it takes your view component. It turns it into a custom web element, which is awesome because you get all the benefits of custom web elements, like just native browser support, but you don't have to deal with all the annoying API of writing them and you know native JavaScript. So basically this is huge for Livewire and I kind of thought that and I tweeted it out whenever then I was pairing with somebody a client of mine. And he's like, yeah, I really want to add this view component into my life where component but you know, I can't get it to work and you know, we could have massaged it got it to work and I was pretty doubtful about it. But and this had to do with that conditional loading thing that I was like, oh man, I should do this view custom element thing. I pulled it in. And Bam, like it just worked beautifully because Livewire just thinks it's normal Dom because views not trying to like hijack everything. So I don't know if this makes sense to you, but I know I'm like cramming in what I wanted to be the whole episode in the last 10 seconds, but. But our times over I'm watching the time go that's what I think the future of view is. Okay, I'll go ten extra seconds to tell you that the future of view not the future of you. The future of view with Live Wire is going to be these custom web elements. I think I'm going to remove the like. Promise of using your view inside along with Livewire because it's just kind of I don't know. It just seems like it's going to spell out disaster. Just tell people if you really want to use your view components use this view custom element package and Adam that way and it'll be clean and like it'll just work perfectly so many less unknowns and you can listen to the. The events because this package converts those View events in a native Dom events. So this is kind of like a high-level me blabbering on about View and Livewire skipping over a lot of stuff, but I don't know. Hopefully you found it enjoyable. Thanks for the extra 44 seconds. Enjoy your hike.

Using Vue With Livewire

[00:00:00] **Caleb: **All right. I got a problem for you. So we're going to talk about polling in live lawyer Pol ing not pulling but pulling and so first the concept of polling is instead of using something like Pusher websockets to. Events from the server side you use polling to pull the server on an interval like every second or so for new for news from the server this way you don't have to deal with server-side server-sent events websockets all of that extra craziness that gets added to your app. You can just simply use Ajax inside some sort of time interval and pull for. Common use cases for this are maybe like if you have like a notification button in the top like navbar that has a little alert thing like a little red dot if there's new notifications that could be a websocket driven thing or you could just pull every 10 seconds or so five or ten seconds. [00:01:00] You know to an end point to just see if there's any new notifications. So anyway, it's pretty common practice and it's been used for a long time and I still like it because it's really simple I prefer it over Pusher until you know, my needs are big. Anyway, so this all came about because I was showing David Hemphill Livewire like way back when and he's like, how would I accomplish this in Live Wire? And he had toaster notification was a toaster notifications know it was like he was building. I don't know if it was the something for the 4J or for the for GUI or Nova or chipper probably chipper and he needed to know the status of a deployment or something like that. He needed a button to go from red to Green as you know as the progress of something sort of progress. And he said how would I comes in Live Wire and I was like, okay. I need to make polling. I need to make some sort of feature to pull easily with live where because the potential is totally there. So I added this directive called wire: Pole. So anywhere inside of your Livewire component, let's say you have let's [00:02:00] say live or components just a div and inside that div or on that that route give you a Dwyer: pull and then inside of it you Echo out the current time in PHP and you rendered on the page now, I think the default is like 2 or 5 seconds. I can't remember every two or five seconds. I think it's too. Every two seconds the time we'll update because Live Wire every will stood like a JavaScript set interval and fire off a request to the server get the new Don with the new date time and swap it into the page. So it's a pretty cool feature and I just kind of left it in there. It was it was documented pretty poorly fast-forward till maybe a month ago. I don't know a couple weeks ago probably till cross. He's a till he corrects me with his last name. It's like couscous till. Bruce I don't know. Sorry till he's a friend of mine great guy till is like number five contributor to laravel Corey's been, you know pitching in and open source for a long long [00:03:00] time. So he got into live wearing he pinged me and he said hey, I want to use a live wire for this. Is it good for this? And basically he wanted to make a little messaging system where you could have like conversations? And then other users could add messages and it would get added if a new message was there and he said I would need something. You know, this Library support web sockets blah blah blah and I said well if you use Pusher live where does support level Echo but what you I think you could probably get away with is just pulling and he's like well one dude, I didn't even find it and I look through all the docs. So I updated the dock so that it's like a first-class citizen. Feature and then he's like yeah that could probably work. So we got on a call and we hacked it out and we got the implementation working which was really cool. But he's like, you know, dude honestly, this is probably maybe a little bit Overkill but there's just something about having a machine having everybody's tab just sitting there. Well at the time the default was like 500 milliseconds. So every half a [00:04:00] second an Ajax request was being sent he's like if they have five tabs open. That's a zillion Ajax request like that server load is just too much. So even if I slow it down, I just feel like people are gonna have all these tabs open. He's like, I wonder if you could do something to make the pulling lie dormant. So we immediately Googled for a page visibility API. That's what it's called. We didn't know that at the time but it exists. I'm like I bet exist. I bet something and you know in. JavaScript ER you know HTML. Yeah JavaScript the JavaScript spec exists. That's that gives you an API for detecting if a browser is inactive, like if a user switches tabs, and there is it's called the page visibility API and it's a little event that gets fired on the document. So you do document dot add event listener for I think it's called visibility change and then you get document dot hidden is a Boolean value just in. In your browser that is true or false depending on if the browser is hidden. So you set up an event listener and [00:05:00] you can you know check on document dot hidden to get your value if the browser tab is hidden or not. So this is something that kind of lingered in the background that to him was like a deal breaker. Like I need something to I need it to do this before I can implement this and I just got to it yesterday. I was like, you know what? I'm just going to spike this out. I bet it'll take me five minutes. And I was right it was very simple feature. So here was my Approach their I guess I'll first say what what might have been a knee-jerk reaction approach is to somehow remove. So when wire when Live Wire to text wire pole on an element, it will register a set interval. It will register a set interval that fires off an Ajax request on Livewire every you know by default. Like I said to two seconds I think so that's just running so you could start you could delete that set interval. I think I think you can clear set interval like you can clear settimeout. So maybe [00:06:00] that would be an option is like register this this listener so that when the page is not visible destroy that interval then when it becomes visible recreate the interval, so I wanted something a little bit simpler. So what I decided to do was to create a global state so I have a global Livewire store in JavaScript. It's like a Singleton or I store all the state. It's anything that's common to all live where components. It's like the god Livewire store. It's a Singleton. Like I said, So I can put Global State on that. So I put a little piece of global State called Live Wire is in background that defaults to false and then on boot. I registered this listener that listens for the visibility change and I set that to true or false. Now inside my set interval where that registers when live or detects wire pole. It's going to just do a check and say hey is Live Wire in the background or in the foreground? If it's in the background just return return early, like don't get to actually fire the Ajax request. So one benefit of this actually this is like what I love about a lot of these live or [00:07:00] JavaScript problems is your really zooming in on a problem like. You're going really deep into like the frame by frame details of a problem. So what I mean by that is so this means that if if it's let's say it's every 5 Seconds that this Ajax request gets sent if you leave the tab after 3 seconds. It's going to get to that fight that fifth second. It'll be in the background and it won't fire the Ajax request. When you go back to visit the tab, there's only like, you know, you can figure out the percentage when you come back to visit this tab. The interval is still running. So the chances of you hitting it at the perfect Mark are really Slim meaning that it's not going to be like you come back to the page and then you have to wait 5 seconds for a new poll. It's like it'll probably be some amount of time already progressed through that hole. When you come back to the page so likely because that was one of his Hang-Ups is like well, then what if you come back to the page and then you're flooded with all this new info, you know, if you have to [00:08:00] wait like let's say it's a 10 second pulley have to wait 10 seconds. When you come back to the page. It's unlikely that it would be the full ten seconds. But that aside somebody in the GitHub repository. This is a GitHub issue. Somebody was like Hey, wouldn't it be cool if you slow down the polling? Instead of just cut it off just slow it way down while it's in the background and I was like, yeah, that would be cool. And my initial reaction was yeah, but that'd be super hard. Like I would have to change the interval of a set interval and then change it back when page visibility. But I was recently inspired by if you listen to no plans to merge my other podcast you've heard us talk about the sessions Lottery. This is the thing Taylor uses a lottery like a random chance thing in laravel to clear to do the session garbage collection so every. Approximately hundredth request gets tasked with clearing the whole app session garbage. But so I decided to apply the same principle that instead in my set interval for the [00:09:00] polling instead of just firing the the Ajax request or instead of just sorry. Just checking to see if live wires in background and then cutting off Ajax requests. If it is I do this is literally the code it's like if is in background. And and then I do math dot random to get a number between 0 and 1 it gives you a decimal between 0 and 1 if math dot random is greater than .95 and what that does is it like couches my conditional with an extra check for five percent. So it's basically like 5% of the time. Oh, no, I'm sorry. I think it's an or statement if it's in the background. Right right now it's an and if it's in the background and math dot random is greater than .95 then block the requests or less than point. I can't think of it right now, whatever. I'm bullying impaired, but the concept is that I added in this little buffer so that if it's in the background five percent of requests are slipped through so that you can still [00:10:00] pull little by little oh my gosh. I'm at 10 minutes. I hope you enjoyed this. Thanks. Bye.

[00:00:00] **Caleb: **All right. I got a problem for you. So we're going to talk about polling in live lawyer Pol ing not pulling but pulling and so first the concept of polling is instead of using something like Pusher websockets to. Events from the server side you use polling to pull the server on an interval like every second or so for new for news from the server this way you don't have to deal with server-side server-sent events websockets all of that extra craziness that gets added to your app. You can just simply use Ajax inside some sort of time interval and pull for. Common use cases for this are maybe like if you have like a notification button in the top like navbar that has a little alert thing like a little red dot if there's new notifications that could be a websocket driven thing or you could just pull every 10 seconds or so five or ten seconds. [00:01:00] You know to an end point to just see if there's any new notifications. So anyway, it's pretty common practice and it's been used for a long time and I still like it because it's really simple I prefer it over Pusher until you know, my needs are big. Anyway, so this all came about because I was showing David Hemphill Livewire like way back when and he's like, how would I accomplish this in Live Wire? And he had toaster notification was a toaster notifications know it was like he was building. I don't know if it was the something for the 4J or for the for GUI or Nova or chipper probably chipper and he needed to know the status of a deployment or something like that. He needed a button to go from red to Green as you know as the progress of something sort of progress. And he said how would I comes in Live Wire and I was like, okay. I need to make polling. I need to make some sort of feature to pull easily with live where because the potential is totally there. So I added this directive called wire: Pole. So anywhere inside of your Livewire component, let's say you have let's [00:02:00] say live or components just a div and inside that div or on that that route give you a Dwyer: pull and then inside of it you Echo out the current time in PHP and you rendered on the page now, I think the default is like 2 or 5 seconds. I can't remember every two or five seconds. I think it's too. Every two seconds the time we'll update because Live Wire every will stood like a JavaScript set interval and fire off a request to the server get the new Don with the new date time and swap it into the page. So it's a pretty cool feature and I just kind of left it in there. It was it was documented pretty poorly fast-forward till maybe a month ago. I don't know a couple weeks ago probably till cross. He's a till he corrects me with his last name. It's like couscous till. Bruce I don't know. Sorry till he's a friend of mine great guy till is like number five contributor to laravel Corey's been, you know pitching in and open source for a long long [00:03:00] time. So he got into live wearing he pinged me and he said hey, I want to use a live wire for this. Is it good for this? And basically he wanted to make a little messaging system where you could have like conversations? And then other users could add messages and it would get added if a new message was there and he said I would need something. You know, this Library support web sockets blah blah blah and I said well if you use Pusher live where does support level Echo but what you I think you could probably get away with is just pulling and he's like well one dude, I didn't even find it and I look through all the docs. So I updated the dock so that it's like a first-class citizen. Feature and then he's like yeah that could probably work. So we got on a call and we hacked it out and we got the implementation working which was really cool. But he's like, you know, dude honestly, this is probably maybe a little bit Overkill but there's just something about having a machine having everybody's tab just sitting there. Well at the time the default was like 500 milliseconds. So every half a [00:04:00] second an Ajax request was being sent he's like if they have five tabs open. That's a zillion Ajax request like that server load is just too much. So even if I slow it down, I just feel like people are gonna have all these tabs open. He's like, I wonder if you could do something to make the pulling lie dormant. So we immediately Googled for a page visibility API. That's what it's called. We didn't know that at the time but it exists. I'm like I bet exist. I bet something and you know in. JavaScript ER you know HTML. Yeah JavaScript the JavaScript spec exists. That's that gives you an API for detecting if a browser is inactive, like if a user switches tabs, and there is it's called the page visibility API and it's a little event that gets fired on the document. So you do document dot add event listener for I think it's called visibility change and then you get document dot hidden is a Boolean value just in. In your browser that is true or false depending on if the browser is hidden. So you set up an event listener and [00:05:00] you can you know check on document dot hidden to get your value if the browser tab is hidden or not. So this is something that kind of lingered in the background that to him was like a deal breaker. Like I need something to I need it to do this before I can implement this and I just got to it yesterday. I was like, you know what? I'm just going to spike this out. I bet it'll take me five minutes. And I was right it was very simple feature. So here was my Approach their I guess I'll first say what what might have been a knee-jerk reaction approach is to somehow remove. So when wire when Live Wire to text wire pole on an element, it will register a set interval. It will register a set interval that fires off an Ajax request on Livewire every you know by default. Like I said to two seconds I think so that's just running so you could start you could delete that set interval. I think I think you can clear set interval like you can clear settimeout. So maybe [00:06:00] that would be an option is like register this this listener so that when the page is not visible destroy that interval then when it becomes visible recreate the interval, so I wanted something a little bit simpler. So what I decided to do was to create a global state so I have a global Livewire store in JavaScript. It's like a Singleton or I store all the state. It's anything that's common to all live where components. It's like the god Livewire store. It's a Singleton. Like I said, So I can put Global State on that. So I put a little piece of global State called Live Wire is in background that defaults to false and then on boot. I registered this listener that listens for the visibility change and I set that to true or false. Now inside my set interval where that registers when live or detects wire pole. It's going to just do a check and say hey is Live Wire in the background or in the foreground? If it's in the background just return return early, like don't get to actually fire the Ajax request. So one benefit of this actually this is like what I love about a lot of these live or [00:07:00] JavaScript problems is your really zooming in on a problem like. You're going really deep into like the frame by frame details of a problem. So what I mean by that is so this means that if if it's let's say it's every 5 Seconds that this Ajax request gets sent if you leave the tab after 3 seconds. It's going to get to that fight that fifth second. It'll be in the background and it won't fire the Ajax request. When you go back to visit the tab, there's only like, you know, you can figure out the percentage when you come back to visit this tab. The interval is still running. So the chances of you hitting it at the perfect Mark are really Slim meaning that it's not going to be like you come back to the page and then you have to wait 5 seconds for a new poll. It's like it'll probably be some amount of time already progressed through that hole. When you come back to the page so likely because that was one of his Hang-Ups is like well, then what if you come back to the page and then you're flooded with all this new info, you know, if you have to [00:08:00] wait like let's say it's a 10 second pulley have to wait 10 seconds. When you come back to the page. It's unlikely that it would be the full ten seconds. But that aside somebody in the GitHub repository. This is a GitHub issue. Somebody was like Hey, wouldn't it be cool if you slow down the polling? Instead of just cut it off just slow it way down while it's in the background and I was like, yeah, that would be cool. And my initial reaction was yeah, but that'd be super hard. Like I would have to change the interval of a set interval and then change it back when page visibility. But I was recently inspired by if you listen to no plans to merge my other podcast you've heard us talk about the sessions Lottery. This is the thing Taylor uses a lottery like a random chance thing in laravel to clear to do the session garbage collection so every. Approximately hundredth request gets tasked with clearing the whole app session garbage. But so I decided to apply the same principle that instead in my set interval for the [00:09:00] polling instead of just firing the the Ajax request or instead of just sorry. Just checking to see if live wires in background and then cutting off Ajax requests. If it is I do this is literally the code it's like if is in background. And and then I do math dot random to get a number between 0 and 1 it gives you a decimal between 0 and 1 if math dot random is greater than .95 and what that does is it like couches my conditional with an extra check for five percent. So it's basically like 5% of the time. Oh, no, I'm sorry. I think it's an or statement if it's in the background. Right right now it's an and if it's in the background and math dot random is greater than .95 then block the requests or less than point. I can't think of it right now, whatever. I'm bullying impaired, but the concept is that I added in this little buffer so that if it's in the background five percent of requests are slipped through so that you can still [00:10:00] pull little by little oh my gosh. I'm at 10 minutes. I hope you enjoyed this. Thanks. Bye.

Smart Polling

All right, so you're probably expecting my answer to this why I believe in Live Wire to be kind of like the last episode pretty soft broad vague inspirational. I don't know but. It's actually not it's pretty concrete. I believe in Live Wire because of one moment three years ago. I was reading a blog post by th where he demonstrates. Why? Why are we just a Jackson Json? Why not Ajax HTML already rendered on the back end and then just swap it into the page and you know, and he called it server render JavaScript and the rails Community is kind of all about this I discovered it and it hit me like a ton of bricks and I went whoa. And I was just immediately enamored with the idea. I used it in a project and it worked exactly as well as I thought it would and I was able to use blade but still, you know, get all the benefits of you know deferring loading a jack seeing this stuff, you know, whatever like making Dynamic pages that don't reload but still just using blade for everything and I was enamored with it. And from that on like that that has been a known good to me. Like there's so little downside to that strategy. It's crazy. And that's why you know, I'm sure I've talked about this a hundred times. You've seen this in every talk that I've given whatever like GitHub you open up xhr Tab and devtools get up devtools and you just see Ajax request flying off the handle and almost none of them are returning Json. They're all returning rendered HTML these P Jax to do this. And so why is this the reason that I believe in live wires the reason because that's what live where is it's built on this concept Live Wire is age axing HTML. There's a bunch of extra stuff that makes it super duper seamless. So you don't have to before you would have to do the wiring yourself. You have to trigger the Ajax request and you have to swap it into the page. Livewire hand gives you a nice API for when to trigger. The request to get new Json or sorry new HTML and it's smarter than just just wiping out the HTML with the new HTML. It does the Dom dipping stuff like we've talked about but that's it. That's what it is at its core like at its core. That's what it is. So if that's the problem live wires solution. And there's a lot of other features in Livewire a lot of extra things a lot of huge potential for ways. It can be used really clever things. Like we've talked about the prefetch stuff and dirty detection and loading States and all sorts of stuff that it grants you that's really nice and whatever huge potential. But at the end of the day strip all those things away and live we're still useful for this use case and it's a pretty big one. So this is why I believe in live where I believe in live where in general but but I got to be honest. It's definitely, you know times that I doubt certain features or doubt certain use cases and a pretty vocal about him. I mean, I the whole counter examples just. BS like I wouldn't use live wire for a counter, I feel kind of weird every time I use Livewire to just like show or hide something on a click, you know, I feel like whole Ajax request for a freaking toggle. Like I should be using JavaScript for that. Like I feel that way, you know, so in that way the live where water is a little bit muddy, but but forget about that stuff like let's talk about. Let's talk about swapping and ajax deferred loading, you know, like Auto searching, you know form like a story table stored in real-time validation realtor auto-saving forms. Like these are all things that. That live wire is not adding anything like you're already submitting Ajax request. You're just sending Json doing the templating on the front end and by doing that you're dealing with the templating in a totally separate language that's not easily testable. And isn't it is totally separated from your front end. So you need like double the routes and double the code. Basically we're live. We're just allows you to basically cut out that whole other half and stay inside the world, you know. So in that sense, I believe in Live Wire like when I doubt myself when I doubt the project things like that like the end of the day I have to remind myself that hey like takeaway Live Wire and I'm still going to basically build my own Live Wire, like I'm basically gonna use these same principles and end up building something that's not as powerful as Livewire. So I guess. Some of the times that I yeah, I don't know. So that's why I believe in Livewire. It's very concrete I believe in it because it's built around a Jackson HTML and swapping it into a page based on some sort of trigger and that to me is an incredibly powerful pattern the rails Community has been on top of this for ever and big companies like GitHub. Base camp anything that uses turbo links. They're all built around this this principle and it is just crazy powerful. So in that sense, I believe in Live Wire and I think Live Wire will always have a place because it provides you with my opinion one of the best ways to to leverage that that technology which is pretty interesting because. Like a Phoenix live view does that but it uses web sockets and it's way more integrated and it's kind of a different cell, you know, so Live Wire live or has maybe more of a modest cell and I think that's why I live where needs to to be more aware of how to make it work well with JavaScript because in you know Phoenix, they have the speed that we're just not going to have with their Phoenix. What's it called Phoenix channels the websocket stuff and you know, long-running server instances and all that stuff. Like we're just not going to become as fast is as they can. I mean they're making games in Phoenix live view that we're not going to be doing that in Livewire. So Live Wire is. It's not a worse Phoenix live view in my mind. It's not just a slower live view. It takes a lot of the the API from live view because it's a freaking Kick-Ass API and it uses the principles and solves the need of something like turbolinks pjx, you know server render JavaScript those techniques that are already using Ajax and you know, That yeah, so so in that sense, that's why I believe in live lawyer and I think it solves this this problem pretty well. It fits into its own little niche. It's not a worse version of anything. It's it's own thing. If anything it's a better version of something. So so that's why I believe in it. That's that's what I tell myself and that's why I will I will use it, you know. Yeah, so, so that's that's the snippet here coming in at six minutes and 30 seconds. That's a lot of extra time. I hope you use that time. Well, enjoy your enjoy the rest of your trout fishing trip. Thank you.

All right, so you're probably expecting my answer to this why I believe in Live Wire to be kind of like the last episode pretty soft broad vague inspirational. I don't know but. It's actually not it's pretty concrete. I believe in Live Wire because of one moment three years ago. I was reading a blog post by th where he demonstrates. Why? Why are we just a Jackson Json? Why not Ajax HTML already rendered on the back end and then just swap it into the page and you know, and he called it server render JavaScript and the rails Community is kind of all about this I discovered it and it hit me like a ton of bricks and I went whoa. And I was just immediately enamored with the idea. I used it in a project and it worked exactly as well as I thought it would and I was able to use blade but still, you know, get all the benefits of you know deferring loading a jack seeing this stuff, you know, whatever like making Dynamic pages that don't reload but still just using blade for everything and I was enamored with it. And from that on like that that has been a known good to me. Like there's so little downside to that strategy. It's crazy. And that's why you know, I'm sure I've talked about this a hundred times. You've seen this in every talk that I've given whatever like GitHub you open up xhr Tab and devtools get up devtools and you just see Ajax request flying off the handle and almost none of them are returning Json. They're all returning rendered HTML these P Jax to do this. And so why is this the reason that I believe in live wires the reason because that's what live where is it's built on this concept Live Wire is age axing HTML. There's a bunch of extra stuff that makes it super duper seamless. So you don't have to before you would have to do the wiring yourself. You have to trigger the Ajax request and you have to swap it into the page. Livewire hand gives you a nice API for when to trigger. The request to get new Json or sorry new HTML and it's smarter than just just wiping out the HTML with the new HTML. It does the Dom dipping stuff like we've talked about but that's it. That's what it is at its core like at its core. That's what it is. So if that's the problem live wires solution. And there's a lot of other features in Livewire a lot of extra things a lot of huge potential for ways. It can be used really clever things. Like we've talked about the prefetch stuff and dirty detection and loading States and all sorts of stuff that it grants you that's really nice and whatever huge potential. But at the end of the day strip all those things away and live we're still useful for this use case and it's a pretty big one. So this is why I believe in live where I believe in live where in general but but I got to be honest. It's definitely, you know times that I doubt certain features or doubt certain use cases and a pretty vocal about him. I mean, I the whole counter examples just. BS like I wouldn't use live wire for a counter, I feel kind of weird every time I use Livewire to just like show or hide something on a click, you know, I feel like whole Ajax request for a freaking toggle. Like I should be using JavaScript for that. Like I feel that way, you know, so in that way the live where water is a little bit muddy, but but forget about that stuff like let's talk about. Let's talk about swapping and ajax deferred loading, you know, like Auto searching, you know form like a story table stored in real-time validation realtor auto-saving forms. Like these are all things that. That live wire is not adding anything like you're already submitting Ajax request. You're just sending Json doing the templating on the front end and by doing that you're dealing with the templating in a totally separate language that's not easily testable. And isn't it is totally separated from your front end. So you need like double the routes and double the code. Basically we're live. We're just allows you to basically cut out that whole other half and stay inside the world, you know. So in that sense, I believe in Live Wire like when I doubt myself when I doubt the project things like that like the end of the day I have to remind myself that hey like takeaway Live Wire and I'm still going to basically build my own Live Wire, like I'm basically gonna use these same principles and end up building something that's not as powerful as Livewire. So I guess. Some of the times that I yeah, I don't know. So that's why I believe in Livewire. It's very concrete I believe in it because it's built around a Jackson HTML and swapping it into a page based on some sort of trigger and that to me is an incredibly powerful pattern the rails Community has been on top of this for ever and big companies like GitHub. Base camp anything that uses turbo links. They're all built around this this principle and it is just crazy powerful. So in that sense, I believe in Live Wire and I think Live Wire will always have a place because it provides you with my opinion one of the best ways to to leverage that that technology which is pretty interesting because. Like a Phoenix live view does that but it uses web sockets and it's way more integrated and it's kind of a different cell, you know, so Live Wire live or has maybe more of a modest cell and I think that's why I live where needs to to be more aware of how to make it work well with JavaScript because in you know Phoenix, they have the speed that we're just not going to have with their Phoenix. What's it called Phoenix channels the websocket stuff and you know, long-running server instances and all that stuff. Like we're just not going to become as fast is as they can. I mean they're making games in Phoenix live view that we're not going to be doing that in Livewire. So Live Wire is. It's not a worse Phoenix live view in my mind. It's not just a slower live view. It takes a lot of the the API from live view because it's a freaking Kick-Ass API and it uses the principles and solves the need of something like turbolinks pjx, you know server render JavaScript those techniques that are already using Ajax and you know, That yeah, so so in that sense, that's why I believe in live lawyer and I think it solves this this problem pretty well. It fits into its own little niche. It's not a worse version of anything. It's it's own thing. If anything it's a better version of something. So so that's why I believe in it. That's that's what I tell myself and that's why I will I will use it, you know. Yeah, so, so that's that's the snippet here coming in at six minutes and 30 seconds. That's a lot of extra time. I hope you use that time. Well, enjoy your enjoy the rest of your trout fishing trip. Thank you.

Why I Believe In Livewire

All right. So I started recording another episode and basically ended up just talking about where Livewire is headed and thought, well, why don't I name this properly? So calling this current roadmap, I cut the episode off early and I'm just going to rerecord it. So the. A current roadmap of live wire, so live where I'm just wanting to give you an idea of where things are at in my brain and with the project and whatnot. So I've talked about it at two conferences now, a bunch of meetups. There's a good solid amount of people in the repository submitting issues and some submitting pull requests and moving the project forward. I'm pairing with people. I've had. Uh, I'm going to basically have like five pair programming sessions this week, total one last week where I talk with people about the project, about their issues with it, things. And these are people who are using it and who are in the repository every day. Um. So that the original episode was called keeping my finger on the pulse, and maybe I'll record another episode talking about that, but for now, I just want to give you the roadmap. So the project's getting more solid. When I released it at lexicon con, I felt like it was cool. I felt, I felt like the API was there. I felt like I knew, I felt like it was good enough to tag a 1.0 in terms of API. But I didn't feel like it was there under the hood. Um, pretty much the main reason being that it's, it's like 60% JavaScript or 50%. I don't know it, it waivers between 40 and 60% of Javas JavaScript, JavaScript core. So the Java script part, that's the tricky part. That's the part that I have to deal with. Browser support, Dom diffing woes. Hear me. Yeah. Um, that's the big one. That's honestly the big one. Um, a lot of that stuff. So making the, making it, you know, it's a pretty ambitious project in terms of implementation. Like I'm just solving whackadoo problems all the time, and I want to make sure that a lot of people have used it and tried it with different things and it works seamlessly. And I'm just now feeling like we're getting to that point. I'm just now feeling like I'm starting to see that it seems like there's a lot of issues in the repository, but a lot of them are related and now I can start kind of closing them in bulk. And a lot of them are related to dumb diffing. And as I, as I hardened that core, um, those things, you know, just get addressed as we go. So I'm feeling good about the project. I'm feeling like it's much more dependable that I'm having these conversations with people and they're going, you know, I'm asking you what are the issues you're experiencing. They named one or two that's known or that I already fixed, and then they say, but honestly, that's about it. It really kind of works for me. It just works well. I don't know, and that's really good to hear and I'm hearing that more. More and more. Um, so that's good. Alright. So, and that's the thing I kept telling people and they're like, well, when are you going to tag a release when it and I S or what are your plans? And I, you know, when I'm standing at the press releases and everybody's, you know, shoving a mic in my face, like, what are your plans with live layer and wait, okay. Um. Yeah. So what am I plans at that time? I said, well, I'm just focused on getting the core heart. And at the moment I'm not gonna do educational materials. I'm not gonna do pro subscriptions or anything like that. I'm going to make the core, you know, ma, you probably have heard different things along the way, cause I often do have ambitions, but I've, every time I settle them back and go, no, no, no, just make the core hard, get people using it in production, get a wide user base that's dedicated. Make a tool that's very useful and very good, and then all these things will be added unto you. So that has been, that has been my thinking, and I feel like I'm reaching the end of that point. I feel like I'm, I'm not gonna give a timeline, but I feel like we're headed in that direction of me feeling like this is a good tool. It's pretty solid. Now let's start building stuff with it. Let's start teaching people how to build stuff with it. Let's tag a 1.0. Well, let's offer, you know, enterprise support. Let's, let's really make this thing happen. Which is funny because it's, you know, this is like, we're going on 10 months here. I'm, this is, I'm in it for the long haul. Like I'm in the long game. And that's something I think about more and more these days is like, that's a lesson I'm sure I've talked about before. Huge lesson I've learned with this tool is like, okay. Um, be in it for the long haul. Like, don't, don't play the short game, play the long game. And, and, uh, I dunno, I'm calmer about it now. I'm not as worried about another tool coming up that's bigger and better or something. Like I'm just kind of focused on this and making it good over time. Um, and eventually. With enough effort and with enough a heart, I think it will, um, get, get the recognition that get the amount of recognition that it deserves, whatever that is. So, which I hope will be pretty high. So the roadmap ahead of me now, after I start to get some of this stuff on your doubt, which I, like I said, we're getting ironed out. Um, I'm gonna start building stuff. With it. Um, I need to have a project built with it personally before I tag a 1.0 the next big milestone is tagging the 1.0 and there's two things I want to make sure. Well, three things that I want to make sure are done before I tag one point. Oh the first thing is I want to, um, I want to have used it in a project myself. The first and biggest thing. So I, I do dummy stuff all the time with it. I use it a lot, but I wanna use it in a real SAS app and I'm sure I'll, you know, leverage that SAS app as like a, maybe a course or just a fruit. Maybe I'll pair or I'll stream like me building it or whatever, but, um, I want to build a SAS app with it that's full and functional and I'm sure that I will encounter things that I will modify live wire to meet. But once I have a full SAS app built, that I believe is your average Sassa app. And built and I'm happy with it. I will write educational materials. Um, I'll write educational materials. Uh, based off of that. So those are the three things, educational materials, the app. And then the third thing I didn't mention, which is the testing of the app. So I'll use the Livewire testing utilities for the app, but I also want to have a dusk test suite that tests everything in the app. And this will be a end to end test of Livewire, basically. So I want to use every feature in live wire inside the app. And I want to have a dusk test suite that tests these things. And the reason being is not that I think everybody should be using dusk when they're using live wire, but it's so that I have something for, um, I have something for Livewire that when I go to tag a new release, I can run it against this entire suite in a real app and get green, and then I will feel a hundred percent good that, uh, that it's safe to release. So. Um, so that, that is the plan ahead of me is use it in real stuff and talk about it and make sure it's tested and love it myself in a real application. So then we can tag 1.0 and then we're off to the races and then I'll start the big promotional campaign. Um, I'll go on the road. No, I won't. Okay. There you go.

All right. So I started recording another episode and basically ended up just talking about where Livewire is headed and thought, well, why don't I name this properly? So calling this current roadmap, I cut the episode off early and I'm just going to rerecord it. So the. A current roadmap of live wire, so live where I'm just wanting to give you an idea of where things are at in my brain and with the project and whatnot. So I've talked about it at two conferences now, a bunch of meetups. There's a good solid amount of people in the repository submitting issues and some submitting pull requests and moving the project forward. I'm pairing with people. I've had. Uh, I'm going to basically have like five pair programming sessions this week, total one last week where I talk with people about the project, about their issues with it, things. And these are people who are using it and who are in the repository every day. Um. So that the original episode was called keeping my finger on the pulse, and maybe I'll record another episode talking about that, but for now, I just want to give you the roadmap. So the project's getting more solid. When I released it at lexicon con, I felt like it was cool. I felt, I felt like the API was there. I felt like I knew, I felt like it was good enough to tag a 1.0 in terms of API. But I didn't feel like it was there under the hood. Um, pretty much the main reason being that it's, it's like 60% JavaScript or 50%. I don't know it, it waivers between 40 and 60% of Javas JavaScript, JavaScript core. So the Java script part, that's the tricky part. That's the part that I have to deal with. Browser support, Dom diffing woes. Hear me. Yeah. Um, that's the big one. That's honestly the big one. Um, a lot of that stuff. So making the, making it, you know, it's a pretty ambitious project in terms of implementation. Like I'm just solving whackadoo problems all the time, and I want to make sure that a lot of people have used it and tried it with different things and it works seamlessly. And I'm just now feeling like we're getting to that point. I'm just now feeling like I'm starting to see that it seems like there's a lot of issues in the repository, but a lot of them are related and now I can start kind of closing them in bulk. And a lot of them are related to dumb diffing. And as I, as I hardened that core, um, those things, you know, just get addressed as we go. So I'm feeling good about the project. I'm feeling like it's much more dependable that I'm having these conversations with people and they're going, you know, I'm asking you what are the issues you're experiencing. They named one or two that's known or that I already fixed, and then they say, but honestly, that's about it. It really kind of works for me. It just works well. I don't know, and that's really good to hear and I'm hearing that more. More and more. Um, so that's good. Alright. So, and that's the thing I kept telling people and they're like, well, when are you going to tag a release when it and I S or what are your plans? And I, you know, when I'm standing at the press releases and everybody's, you know, shoving a mic in my face, like, what are your plans with live layer and wait, okay. Um. Yeah. So what am I plans at that time? I said, well, I'm just focused on getting the core heart. And at the moment I'm not gonna do educational materials. I'm not gonna do pro subscriptions or anything like that. I'm going to make the core, you know, ma, you probably have heard different things along the way, cause I often do have ambitions, but I've, every time I settle them back and go, no, no, no, just make the core hard, get people using it in production, get a wide user base that's dedicated. Make a tool that's very useful and very good, and then all these things will be added unto you. So that has been, that has been my thinking, and I feel like I'm reaching the end of that point. I feel like I'm, I'm not gonna give a timeline, but I feel like we're headed in that direction of me feeling like this is a good tool. It's pretty solid. Now let's start building stuff with it. Let's start teaching people how to build stuff with it. Let's tag a 1.0. Well, let's offer, you know, enterprise support. Let's, let's really make this thing happen. Which is funny because it's, you know, this is like, we're going on 10 months here. I'm, this is, I'm in it for the long haul. Like I'm in the long game. And that's something I think about more and more these days is like, that's a lesson I'm sure I've talked about before. Huge lesson I've learned with this tool is like, okay. Um, be in it for the long haul. Like, don't, don't play the short game, play the long game. And, and, uh, I dunno, I'm calmer about it now. I'm not as worried about another tool coming up that's bigger and better or something. Like I'm just kind of focused on this and making it good over time. Um, and eventually. With enough effort and with enough a heart, I think it will, um, get, get the recognition that get the amount of recognition that it deserves, whatever that is. So, which I hope will be pretty high. So the roadmap ahead of me now, after I start to get some of this stuff on your doubt, which I, like I said, we're getting ironed out. Um, I'm gonna start building stuff. With it. Um, I need to have a project built with it personally before I tag a 1.0 the next big milestone is tagging the 1.0 and there's two things I want to make sure. Well, three things that I want to make sure are done before I tag one point. Oh the first thing is I want to, um, I want to have used it in a project myself. The first and biggest thing. So I, I do dummy stuff all the time with it. I use it a lot, but I wanna use it in a real SAS app and I'm sure I'll, you know, leverage that SAS app as like a, maybe a course or just a fruit. Maybe I'll pair or I'll stream like me building it or whatever, but, um, I want to build a SAS app with it that's full and functional and I'm sure that I will encounter things that I will modify live wire to meet. But once I have a full SAS app built, that I believe is your average Sassa app. And built and I'm happy with it. I will write educational materials. Um, I'll write educational materials. Uh, based off of that. So those are the three things, educational materials, the app. And then the third thing I didn't mention, which is the testing of the app. So I'll use the Livewire testing utilities for the app, but I also want to have a dusk test suite that tests everything in the app. And this will be a end to end test of Livewire, basically. So I want to use every feature in live wire inside the app. And I want to have a dusk test suite that tests these things. And the reason being is not that I think everybody should be using dusk when they're using live wire, but it's so that I have something for, um, I have something for Livewire that when I go to tag a new release, I can run it against this entire suite in a real app and get green, and then I will feel a hundred percent good that, uh, that it's safe to release. So. Um, so that, that is the plan ahead of me is use it in real stuff and talk about it and make sure it's tested and love it myself in a real application. So then we can tag 1.0 and then we're off to the races and then I'll start the big promotional campaign. Um, I'll go on the road. No, I won't. Okay. There you go.

Current Roadmap

[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.

[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.

The Evolution Of The Make Command

Okay. So this episode is going to be the one where I actually talk to you about what I came here to talk to you about. Hopefully listen to episode 9 about how Dom different works. So I'm at a fork in the road. I'm getting all these issues not a ton. You know, it's not like doesn't seem to be breaking everything for everybody. But this you know how I said the final piece of the puzzle was the backend caching thing, which if you haven't been following the project closely don't even know what I'm talking about, but I thought that was the final piece of the puzzle. This is the final piece of the puzzle in terms of what's the word Soul like reliability. This is the thing. This is the one part of Live Wire that gives me a little bit of the heebie-jeebies. It's a hard part. It's hard to understand. It's hard. It's just kind of a beast how Livewire does down dipping using morph dumb. Like I said, I've made updates to morph Dom like tons of them. So more Stones become a little bit of a Frankenstein inside Live Wire, but this is the piece of the puzzle that they're still it's still the cause of a lot of random issues on GitHub and I want it to be really. And UJS is Dom dipping stuff is really good. Like you almost never run into issues. And then when they make you do that key thing where if you have a loop like a V4 and you add: key you feel like oh that's really weird because you're not used to dealing you're not used to worrying about the Dom dipping that view JS is doing it just works. So I want to have that feeling out of the box and morph time just isn't cutting it. So I have this decision to make Dua a. Like really roll up my sleeves and grok morph down which I feel I've tried to do multiple times, but do I really roll up my sleeves and like manhandle morph Dom like understand it to the core write notes make, you know actual refactor it to make it more readable. It's insanely unreadable. Like if you try maybe just for fun go to the GitHub morph down repository. Look at morph Dom dot J's that big file and try to understand it. I dare you. It's a massive procedure. File and it's really hard to understand. So do I do that that's option A where I take more of them and I just make it my. Insert word that we shouldn't say here. So back on track. Yeah. Do I do that that's option A or option b is I switch to a virtual Dom strategy like I talked about before that has the benefit of I could literally Use SNAP dumb or any of these dumb different libraries that reactor view use, that would be great. That would be super easy. And sorry it was that part would be easy the part of like making something work beautifully, but getting it to work. I would have to translate all of the Dom into the virtual Dom and then do the dipping and translate it back whatever it be a lot of weirdness and I'm just not sure if that's something I want to do because I attempted it before I gave it a weekend and I ended up just killing that. So that's option be an option C is there's always the rewrite in the sky option C is do I write my own Dom differ like like more of them, but for exactly what I need. So option A is the most realistic one. It's the one I've been doing. I just keep hacking morph Dom until I get it to do. What I wanted to do. The pros of option AR is probably the least work and it's the least disruptive. But the cons of it are morph times hard to understand. It's very hard to understand and I don't even know if I'll be able to make it do what I want without almost rewriting it anyway option b where I switch to a virtual Dom strategy the pro is that I can rely on somebody else maintaining. Sorry, the pro of of option A another huge probe. The biggest Pro is that there's a whole group of people on GitHub that are constantly making sure that it works for everybody meaning it's been out there for a long time. There's lots of weird little if statements that detect stuff for certain browsers. Like if I were to write my own starting from scratch, I would be basically just Reinventing the wheel and all those areas. So option b is starting with a, you know, implementing a virtual Dom. Like Snap down that vue.js uses and if I do that the pro is like I said I get to use basically the hardened beautiful solid core that vue.js uses. The con is to adapt my strategy to that strategy would be a lot of heavy lifting and might result in just as much weird errors as I'm getting right now. Option C is the most enticing to me because I would get to understand and own every bit of it. And if I wrote that I would I would have written an understand every single nook and cranny of live wire from Back to Front I would have. Ownership of it and what understand all of it and it would all be in my brain and intentional and within my domain this is a pro and a con it's a pro because I totally understand it. It's a con because I have widened the codebase significantly and I would be Reinventing the wheel like I said before so it's a tough one, and I don't actually I'm not going to come to an answer right here on this call on this call. Like we're just kind you know, me and you were talking and I don't know what I'm going to do. So I'm just here to sort of vent and tell you my dom dipping woes. This is the last nasty part of Live Wire and if I can overcome this then Live Wire in my brain Live Wire will be clean and efficient on the front end and it's getting there. But this is kind of a missing piece. So you understand how Dom dipping works now and you understand the crossroads that I'm at in terms of strategies for the front end. I will hopefully do a follow-up post where I tell you what I decided to do and how it went right or wrong. But until then enjoy your hike and thank you for listening.

Okay. So this episode is going to be the one where I actually talk to you about what I came here to talk to you about. Hopefully listen to episode 9 about how Dom different works. So I'm at a fork in the road. I'm getting all these issues not a ton. You know, it's not like doesn't seem to be breaking everything for everybody. But this you know how I said the final piece of the puzzle was the backend caching thing, which if you haven't been following the project closely don't even know what I'm talking about, but I thought that was the final piece of the puzzle. This is the final piece of the puzzle in terms of what's the word Soul like reliability. This is the thing. This is the one part of Live Wire that gives me a little bit of the heebie-jeebies. It's a hard part. It's hard to understand. It's hard. It's just kind of a beast how Livewire does down dipping using morph dumb. Like I said, I've made updates to morph Dom like tons of them. So more Stones become a little bit of a Frankenstein inside Live Wire, but this is the piece of the puzzle that they're still it's still the cause of a lot of random issues on GitHub and I want it to be really. And UJS is Dom dipping stuff is really good. Like you almost never run into issues. And then when they make you do that key thing where if you have a loop like a V4 and you add: key you feel like oh that's really weird because you're not used to dealing you're not used to worrying about the Dom dipping that view JS is doing it just works. So I want to have that feeling out of the box and morph time just isn't cutting it. So I have this decision to make Dua a. Like really roll up my sleeves and grok morph down which I feel I've tried to do multiple times, but do I really roll up my sleeves and like manhandle morph Dom like understand it to the core write notes make, you know actual refactor it to make it more readable. It's insanely unreadable. Like if you try maybe just for fun go to the GitHub morph down repository. Look at morph Dom dot J's that big file and try to understand it. I dare you. It's a massive procedure. File and it's really hard to understand. So do I do that that's option A where I take more of them and I just make it my. Insert word that we shouldn't say here. So back on track. Yeah. Do I do that that's option A or option b is I switch to a virtual Dom strategy like I talked about before that has the benefit of I could literally Use SNAP dumb or any of these dumb different libraries that reactor view use, that would be great. That would be super easy. And sorry it was that part would be easy the part of like making something work beautifully, but getting it to work. I would have to translate all of the Dom into the virtual Dom and then do the dipping and translate it back whatever it be a lot of weirdness and I'm just not sure if that's something I want to do because I attempted it before I gave it a weekend and I ended up just killing that. So that's option be an option C is there's always the rewrite in the sky option C is do I write my own Dom differ like like more of them, but for exactly what I need. So option A is the most realistic one. It's the one I've been doing. I just keep hacking morph Dom until I get it to do. What I wanted to do. The pros of option AR is probably the least work and it's the least disruptive. But the cons of it are morph times hard to understand. It's very hard to understand and I don't even know if I'll be able to make it do what I want without almost rewriting it anyway option b where I switch to a virtual Dom strategy the pro is that I can rely on somebody else maintaining. Sorry, the pro of of option A another huge probe. The biggest Pro is that there's a whole group of people on GitHub that are constantly making sure that it works for everybody meaning it's been out there for a long time. There's lots of weird little if statements that detect stuff for certain browsers. Like if I were to write my own starting from scratch, I would be basically just Reinventing the wheel and all those areas. So option b is starting with a, you know, implementing a virtual Dom. Like Snap down that vue.js uses and if I do that the pro is like I said I get to use basically the hardened beautiful solid core that vue.js uses. The con is to adapt my strategy to that strategy would be a lot of heavy lifting and might result in just as much weird errors as I'm getting right now. Option C is the most enticing to me because I would get to understand and own every bit of it. And if I wrote that I would I would have written an understand every single nook and cranny of live wire from Back to Front I would have. Ownership of it and what understand all of it and it would all be in my brain and intentional and within my domain this is a pro and a con it's a pro because I totally understand it. It's a con because I have widened the codebase significantly and I would be Reinventing the wheel like I said before so it's a tough one, and I don't actually I'm not going to come to an answer right here on this call on this call. Like we're just kind you know, me and you were talking and I don't know what I'm going to do. So I'm just here to sort of vent and tell you my dom dipping woes. This is the last nasty part of Live Wire and if I can overcome this then Live Wire in my brain Live Wire will be clean and efficient on the front end and it's getting there. But this is kind of a missing piece. So you understand how Dom dipping works now and you understand the crossroads that I'm at in terms of strategies for the front end. I will hopefully do a follow-up post where I tell you what I decided to do and how it went right or wrong. But until then enjoy your hike and thank you for listening.

My DOM Diffing Woes

Hey friends, it has been a tiny bit. Uh, I'll have, you know that I actually did record a bunch of episodes, but. I wouldn't publish them right away and then I would delete them when I went back to record another one because I don't know, that's just kind of how I am. If I don't get something out right away, I end up second guessing it or looking at it and thinking, Oh, that wasn't well done or it wasn't clear enough, and I'll delete it and then just start something else. So, um, that's a bad habit of mine. And I've, uh, done that for the past, like month, almost a month on this podcast. I swear I've deleted. Probably over six or seven. Um, but that's over. So the big update, um, there's been a lot going on with Livewire and that's partially why they been so many videos and partially why I haven't published them, because it's confusing and it's hard to explain and it's frustrating. And I don't know. I don't want to drag you down with me, but I think, uh, or I'm at a point of clarity. I'm at a point of decisiveness, so let me catch you up a little bit. Um. I've, I believe I've done an episode at some point about protected properties, but here's, here's kind of the gist of this. This is the biggest problem in Livewire, quote, unquote. That's what I titled the, this forum posts that I made. Oh, by the way, there's a form. You should check it out. There's a forum post called help me solve the biggest problem Livewire, and this is, this is, this is a problem that has sort of, I don't want to say haunted me, but it's been around since almost the beginning. So here's the problem statement. Live foyer. Livewire, Livewire Livewire PHP is a one shot deal. When you make a layer of all requests, the whole thing just runs and then spits the HTML out to the server and then the user triggers some update, like a URL change, and it does that. Again, their browser, however, has a long running process, so that's why VJs and these other Java Java script is a, there's a runtime in the browser and it's continuously running and waiting for user interaction and whatnot. So in Phoenix live view, a Phoenix or elixir on the backend is a continuous process. So they can create a parody between the backend process and the front end process. So the user's browser session with their JavaScript, and then the servers backend session. Um, and there can be a one-to-one, so there can be a process for user on the page. So they can do all sorts of nice things. Well, I chose really, really early on to not go that route because PHP just isn't there yet. And our PHP WebSockets and an asynchronous PHP, um, there's, there's stuff about it and there's stuff out there, but they're either require extensions or fancy things that just nobody wants to fanangle with finagle, finagle with. Um, so I chose early on, let's just do Ajax. Let's make Livewire. Let's make it's network transfer protocol, Ajax, and so Ajax is stateless. This is a fancy word, but what it means is so a long running incident, instances, state full, it has a state, you can change it, you can mutate it. It lives in one place. Stateless is something that gets passed around, so live where actually lives in the request and response data that goes to and fro a server. I guess Livewire on the front end is stateful, but on the backend it's stateless. So Livewire keeps, keeps track of what the current state of a component is. Then when you make an update, say a click on something that has wire colon click, it sends an Ajax request with the payload back to the server. It hydrates up the component, um, and then it does a taction and then a dehydrates it back to the new data in HTML, puts it back on the front end and rinse and repeat. So I've probably said that a thousand times. I hope you understand that by now. I think that's something that, that's one of those big key pieces of knowledge to understand. And if you didn't build Livewire, I can imagine it's frustrating to wrap your head around and seems odd. It's like hearing a Ave talk about the virtual Dom and how it just means nothing to you. But if, if you had built it, you would understand. And it's not rocket science. Um, but it's just one of those things that, that, uh, you have to kind of open, open it up a little bit to understand or inspect your dev tools, or, I dunno, hear me spew it enough. Times to understand it. So that's the nature of this problem. Um, the problem comes from, we don't have a long running back end PHP instance. So how does this problem manifest itself? So basically all of the data of live wire gets transferred back and forth, like I said. So if you set a, um, you can pass data into a Livewire component right. So you could presumably pass in an eloquent model. And the first thing people tried to do when I launched live wire was save eloquent models to properties. So they would have a property called post, and they would, you know, set post to an eloquent model out of the database. And then they would get an error that says, Hey, you can't do that. You can only set. Like a a raise or integers or strings to public properties, and the reasoning for that is you're sending it to JavaScript. So I either have to serialize the whole PHP object and DCLI isn't whatever. There's so many weird things and up and things in the back of my mind like, well, I don't want to expose somebody's entire eloquent object to the front end. Like maybe they, I don't know, forgot to hide like a password field or. You know, I dunno, I'm exposing the, some part of their internal system. I'm telling the front end could inspect and see what class it is and what name's base. And I don't know, it just doesn't feel right to me. So that's the problem. And you don't actually need to store things that way. You don't need to store eloquent models. You can fetch them from the database, every update, but it's just not natural for people. So my first, my first plan of attack was I'm going to make protected properties. Uh, what people want. You can store anything in a protected property. And my strategy was I'll store it in a cash in the backend, and then when I'm rehydrating a component, I'll fetch the protected data out of the cash from the backend. So that's what I did. And that, that was me choosing the invisible path. That was me making a feature that was invisible. Now, people, when they're learning live, where they try to set up a public property, and. Uh, to an eloquent model. And they'll say, Hey, you can't do that. Um, try sending a protected property. And they do that and it works fine. And they read the docs and it gives them a little description of the differences and when to use what and they understand and they go, well, they go on their way. It's an invisible feature. They don't understand that it's cash in the back end. Even if they do, it's, they don't really understand the implications of that. So that's what I did. And there's some other wackiness I had to do to accomplish that. So it was a lot of magic. A lot of magic went into making that invisible feature. So then there was a GitHub issue that came in that basically said, Hey, back buttons don't work and my stomach just dropped night cause I, it's one of those things that I realized immediately what it was. It's like, Oh, they have a protected property. They've gone to a new page. Now they hit the back button and the protected property is out of sync with their public properties. Um, kind of a long story why that is. But I dunno, when you hit the back button, it loads a cast result of the HTML, which has all the public data encoded in it. So live wear boots up with the initial data that the component has. But the protected data is like the down the road data. So kind of weird to describe, but. I dunno. Um, so that, that's the issue of public data protected data. There's this drift and the drift happens because there's two paradigms going on in live where now each component has stateful data in a cache that's actually like living and lives on the backend and can be mutated and state list data on the front end. The data object that gets passed back and forth. Oh, it's so many words. I'm hearing myself explain to them. I'm hearing myself explain it to myself. And if I didn't know everything about this, there would be kind of sparks like, you know, flying in my brain. And it would, it would not it, but not, it's not an easy thing to grasp. So. So the high level problem is there's two types of data in Livewire. And making those work nicely together is problematic. And because I'm dealing with a cash, you get all the problems that come with dealing with a cash, cash and validation. Um, cash bloat, a cash drift. There's all of these things and there's plenty of different hacks I could have added on top of this system and added layer and layer and layer. To make this, to keep this feature and visible and to keep the feature working and just fix bug after bug bug whack-a-mole. But I opted for a simpler route with the help of my buddy Mitch. We sat down and he walked me through this problem and he's sort of a sounding board for me and, and we kinda hashed out all the different paths and realized. We're happier if we got rid of protected properties and put the onus on the user, which is my least favorite thing to do, it makes Livewire harder to use. I chose to go against the invisible path. Um, I tried to provide some API. Like a recommended API for this computed properties we can talk about in another episode. So I have a couple of recommended ways to do it, but I still get get hub issues right now. We've made the update and I still get get hub issues of people saying, Hey, this thing's broken. Hey, that thing's broken. But really what they mean is protected properties don't work anymore. And then somebody comes in and says, Oh yeah, protected properties don't work. Here's the posts. Go read it. So it pains me inside to do that, but I thought about it a long, long, long, long, long, long time. And at the end of the day, I will be able to sleep soundly. And I think, here's how I can sum it up. I've all this time, like I reached for the invisible features. I want live to feel invisible in native to people, but there's certain cases. Where it almost is deceitful. Like me making this feature invisible, invisible makes it seem like something simple and safe is happening, but it's a really complex system loaded with magic, and it seems to see full, to me now, I feel like I need to expose the underbelly in this way so that users use the tool responsibly. It requires more knowledge on their end, but they'll understand the tool. At a deeper level, and I think that's going to be for the best. I think we're going to be better off and hate developers like complexity, right? So I'm giving them something complex. There you go. Have fun. All right. Thanks.

Hey friends, it has been a tiny bit. Uh, I'll have, you know that I actually did record a bunch of episodes, but. I wouldn't publish them right away and then I would delete them when I went back to record another one because I don't know, that's just kind of how I am. If I don't get something out right away, I end up second guessing it or looking at it and thinking, Oh, that wasn't well done or it wasn't clear enough, and I'll delete it and then just start something else. So, um, that's a bad habit of mine. And I've, uh, done that for the past, like month, almost a month on this podcast. I swear I've deleted. Probably over six or seven. Um, but that's over. So the big update, um, there's been a lot going on with Livewire and that's partially why they been so many videos and partially why I haven't published them, because it's confusing and it's hard to explain and it's frustrating. And I don't know. I don't want to drag you down with me, but I think, uh, or I'm at a point of clarity. I'm at a point of decisiveness, so let me catch you up a little bit. Um. I've, I believe I've done an episode at some point about protected properties, but here's, here's kind of the gist of this. This is the biggest problem in Livewire, quote, unquote. That's what I titled the, this forum posts that I made. Oh, by the way, there's a form. You should check it out. There's a forum post called help me solve the biggest problem Livewire, and this is, this is, this is a problem that has sort of, I don't want to say haunted me, but it's been around since almost the beginning. So here's the problem statement. Live foyer. Livewire, Livewire Livewire PHP is a one shot deal. When you make a layer of all requests, the whole thing just runs and then spits the HTML out to the server and then the user triggers some update, like a URL change, and it does that. Again, their browser, however, has a long running process, so that's why VJs and these other Java Java script is a, there's a runtime in the browser and it's continuously running and waiting for user interaction and whatnot. So in Phoenix live view, a Phoenix or elixir on the backend is a continuous process. So they can create a parody between the backend process and the front end process. So the user's browser session with their JavaScript, and then the servers backend session. Um, and there can be a one-to-one, so there can be a process for user on the page. So they can do all sorts of nice things. Well, I chose really, really early on to not go that route because PHP just isn't there yet. And our PHP WebSockets and an asynchronous PHP, um, there's, there's stuff about it and there's stuff out there, but they're either require extensions or fancy things that just nobody wants to fanangle with finagle, finagle with. Um, so I chose early on, let's just do Ajax. Let's make Livewire. Let's make it's network transfer protocol, Ajax, and so Ajax is stateless. This is a fancy word, but what it means is so a long running incident, instances, state full, it has a state, you can change it, you can mutate it. It lives in one place. Stateless is something that gets passed around, so live where actually lives in the request and response data that goes to and fro a server. I guess Livewire on the front end is stateful, but on the backend it's stateless. So Livewire keeps, keeps track of what the current state of a component is. Then when you make an update, say a click on something that has wire colon click, it sends an Ajax request with the payload back to the server. It hydrates up the component, um, and then it does a taction and then a dehydrates it back to the new data in HTML, puts it back on the front end and rinse and repeat. So I've probably said that a thousand times. I hope you understand that by now. I think that's something that, that's one of those big key pieces of knowledge to understand. And if you didn't build Livewire, I can imagine it's frustrating to wrap your head around and seems odd. It's like hearing a Ave talk about the virtual Dom and how it just means nothing to you. But if, if you had built it, you would understand. And it's not rocket science. Um, but it's just one of those things that, that, uh, you have to kind of open, open it up a little bit to understand or inspect your dev tools, or, I dunno, hear me spew it enough. Times to understand it. So that's the nature of this problem. Um, the problem comes from, we don't have a long running back end PHP instance. So how does this problem manifest itself? So basically all of the data of live wire gets transferred back and forth, like I said. So if you set a, um, you can pass data into a Livewire component right. So you could presumably pass in an eloquent model. And the first thing people tried to do when I launched live wire was save eloquent models to properties. So they would have a property called post, and they would, you know, set post to an eloquent model out of the database. And then they would get an error that says, Hey, you can't do that. You can only set. Like a a raise or integers or strings to public properties, and the reasoning for that is you're sending it to JavaScript. So I either have to serialize the whole PHP object and DCLI isn't whatever. There's so many weird things and up and things in the back of my mind like, well, I don't want to expose somebody's entire eloquent object to the front end. Like maybe they, I don't know, forgot to hide like a password field or. You know, I dunno, I'm exposing the, some part of their internal system. I'm telling the front end could inspect and see what class it is and what name's base. And I don't know, it just doesn't feel right to me. So that's the problem. And you don't actually need to store things that way. You don't need to store eloquent models. You can fetch them from the database, every update, but it's just not natural for people. So my first, my first plan of attack was I'm going to make protected properties. Uh, what people want. You can store anything in a protected property. And my strategy was I'll store it in a cash in the backend, and then when I'm rehydrating a component, I'll fetch the protected data out of the cash from the backend. So that's what I did. And that, that was me choosing the invisible path. That was me making a feature that was invisible. Now, people, when they're learning live, where they try to set up a public property, and. Uh, to an eloquent model. And they'll say, Hey, you can't do that. Um, try sending a protected property. And they do that and it works fine. And they read the docs and it gives them a little description of the differences and when to use what and they understand and they go, well, they go on their way. It's an invisible feature. They don't understand that it's cash in the back end. Even if they do, it's, they don't really understand the implications of that. So that's what I did. And there's some other wackiness I had to do to accomplish that. So it was a lot of magic. A lot of magic went into making that invisible feature. So then there was a GitHub issue that came in that basically said, Hey, back buttons don't work and my stomach just dropped night cause I, it's one of those things that I realized immediately what it was. It's like, Oh, they have a protected property. They've gone to a new page. Now they hit the back button and the protected property is out of sync with their public properties. Um, kind of a long story why that is. But I dunno, when you hit the back button, it loads a cast result of the HTML, which has all the public data encoded in it. So live wear boots up with the initial data that the component has. But the protected data is like the down the road data. So kind of weird to describe, but. I dunno. Um, so that, that's the issue of public data protected data. There's this drift and the drift happens because there's two paradigms going on in live where now each component has stateful data in a cache that's actually like living and lives on the backend and can be mutated and state list data on the front end. The data object that gets passed back and forth. Oh, it's so many words. I'm hearing myself explain to them. I'm hearing myself explain it to myself. And if I didn't know everything about this, there would be kind of sparks like, you know, flying in my brain. And it would, it would not it, but not, it's not an easy thing to grasp. So. So the high level problem is there's two types of data in Livewire. And making those work nicely together is problematic. And because I'm dealing with a cash, you get all the problems that come with dealing with a cash, cash and validation. Um, cash bloat, a cash drift. There's all of these things and there's plenty of different hacks I could have added on top of this system and added layer and layer and layer. To make this, to keep this feature and visible and to keep the feature working and just fix bug after bug bug whack-a-mole. But I opted for a simpler route with the help of my buddy Mitch. We sat down and he walked me through this problem and he's sort of a sounding board for me and, and we kinda hashed out all the different paths and realized. We're happier if we got rid of protected properties and put the onus on the user, which is my least favorite thing to do, it makes Livewire harder to use. I chose to go against the invisible path. Um, I tried to provide some API. Like a recommended API for this computed properties we can talk about in another episode. So I have a couple of recommended ways to do it, but I still get get hub issues right now. We've made the update and I still get get hub issues of people saying, Hey, this thing's broken. Hey, that thing's broken. But really what they mean is protected properties don't work anymore. And then somebody comes in and says, Oh yeah, protected properties don't work. Here's the posts. Go read it. So it pains me inside to do that, but I thought about it a long, long, long, long, long, long time. And at the end of the day, I will be able to sleep soundly. And I think, here's how I can sum it up. I've all this time, like I reached for the invisible features. I want live to feel invisible in native to people, but there's certain cases. Where it almost is deceitful. Like me making this feature invisible, invisible makes it seem like something simple and safe is happening, but it's a really complex system loaded with magic, and it seems to see full, to me now, I feel like I need to expose the underbelly in this way so that users use the tool responsibly. It requires more knowledge on their end, but they'll understand the tool. At a deeper level, and I think that's going to be for the best. I think we're going to be better off and hate developers like complexity, right? So I'm giving them something complex. There you go. Have fun. All right. Thanks.

The BIG Update

[00:00:00] Caleb: Okay. This one is straight up silly in hindsight. It's another invisible feature. So the validation and live wire as it stands. I'll describe to you how it behaves right now. If you have a form in Livewire and you have a bunch of input elements and you wire model those input elements two pieces of data inside your component. So if you have a form with a name and an email, you might have wire model name while your model email and then on your class you would have to public property. Public money sign name and then email set to whatever the default so you want them to be. So if you wanted to validate on this, let's say I have a button called submit you'd listen for the submit method on a form or listen for a click method or whatever and fire a method inside your live where component or an action called submit then inside of their you want to do some validation. So the first thing I had this was the first sorry, I'm describing it as it is. Now, here's how it is. Now [00:01:00] you would do this Arrow validate and. Behaves exactly like request Arrow validate. Now you pass in your validation rules and the keys. So you'd say name name is the key and then the value is let's say required pipe Min six or something. It will reference the value of the piece of data called name inside the component just as if it was like a request in laravel like you have data in a request and then you do request Arrow validate you pass in the rules and extra messaging and whatever and then it fires of elevation exception. Right? So this works the same exact way it works intuitively you look at it and you go. Oh that makes perfect sense. This is really easy. I get how to use it because I'm already using it this way. It wasn't always like that my first. In a validation in Livewire at first I thought okay people are going to want to people are going to want to have. Multiple validation sets I was sort of picturing it like you would declare the validation on the component. [00:02:00] So at first I think I had a pup property called validates, which first I stressed out about that name was like protected validates. Is it validates or validator or rules? I didn't really know actually in hindsight rules is probably the best name, but at the time it was validate so protected validates equals and then you have an array that you declare of all the validation rules right on the class. And then, you know just kind of how I. But it would be an array of arrays because I thought well you wouldn't want just one for a component. Let's say you had multiple sets of data that you wanted to validate inside that component. You need to have multiple. So started going down this whole Rabbit Hole of these concept of forms, like Livewire had the concept of forms at one point. We're like and I forgot even how you would denote them in the template like wire: form and then the name and it would keep track of all that data and it would reference the specific that anyway, it was a mess and it was super complicated. So I went know instead of having [00:03:00] instead of having multiple on we're just going to stick with one because this is way easier. So you just have this protected validates and then all the validation rules declared as a class property and then you have this Arrow. Inside of a method that calls on that protected property does the validation and does what it needs to do the problem with this one of the problems with this like a practical problem outside of it. Just feeling weird. Is that so I guess okay. Here's the two problems. The first problem. Like I mentioned is it's restricted to one set of data when you're running this Arrow validate your running the validation for the entire component. That's problem. Number one problem. Number two is if you want Dynamic validation or anything like that, you're declaring it inside of a class property. So you can't do any, you know, you can't like column method or anything, you know, you just have to use the string validation syntax. So those are the two small Hang-Ups. It just didn't feel Perfectly Natural. And again, this is one that through the process of user testing. It just [00:04:00] kind of got honed and I think I think Lucas Mitch it. Yeah, so. Well, I yeah, I don't actually know. Yeah, so when I did a user test with Lucas Mitchell another core laravel contributor number like 2 or 3 or something, he he was super kind to do this and he was ridiculously helpful actually like change the course of Livewire by just you know handful of things he said. But he so I have notes here like this validates type of so clearly I can see that that it's this Arrow validates at the time and then I have all these notes for how to make the validation nicer. So I don't know if it was his user test or one after we're just realized that make the freaking validator function work. The way request validate Works pass in do this Arrow validate and then pass in the rules as you need them and reference the data directly. I don't know. I mean it sounds this is kind of a silly one and as I'm saying it it's silly but it took a long time for me to arrive at that and I guess [00:05:00] it's just a story of a feature just not feeling great. It just felt tacked on it didn't feel natural. It felt like I had created something that you had to learn how it works. But when I arrived at the perfect solution, which is this Arrow validates and then passing the rules. It makes sense to people they immediately get it it clicks. You can use anything you would normally use with requests are validate because I just forward to the validation stuff. Anyway, you can pass in the same exact parameters. You can pass invalidation messaging rules, whatever it makes sense. Um, I guess in theory the perfect solution is to do or I guess the most invisible solution is to do request Arrow validate, but then I would have to hijack the request it would be nasty users would be like well am I they would get confused about what a request is. So a money sign this Arrow validate I think is the perfect solution. It's invisible. You don't even notice you don't even notice it it just makes sense. It makes perfect sense and I don't remember the evolution of this but this was [00:06:00] another one. When you call that it if throw if you you know hit a validation issue, it will throw the validation exception that a normal request validator does and it will provide the money sign errors. Object the errors bag to the view that gets rendered. So that was just a like a tiny bit of hackery to do that. Like the implementation wasn't the hard part. It was coming up with the idea. And once I did it just felt Supernatural so validation just feels so native in Livewire and that that's a huge goal for me with Livewire and that is just the process of user testing and time is just making it feel like laravel making it feel like a first-class Citizen and basically any feature I try to see if. Laravel conventions or functionality or something that I can pull on so that I get that familiarity and I'm not teaching you a new syntax that you're just either know it from vue.js or from laravel and that's sort of a [00:07:00] big overarching goal with Livewire is to just feel natural. If you're a view / level developer one of the while I'm sort of down this hole one of the issues that you come across with that is pulling from conventions. You get the benefit of the assumptions of the user. So the user gets the benefit of familiarity. They're familiar with how it works right away off the bat, which is great. And that's awesome. But they also have assumptions and if those assumptions are incorrect, you can cause confusion for them. So this is really tough balance. We're like the this Arrow validate that so a good example would be if I did request error validation. They would feel natural to them because that's what they're used to using but they might have questions like. Well is this data from the request is all the data just request data from reach live where I request. Where does it come from what it you know that it is request hijacked. Can I not use your quest? Can I use your crust other places? Can I use form requests, you know it like leads them down these Trails of [00:08:00] thoughts that are incorrect. So it's kind of this really tight balance of balancing. Yeah that tension between like leveraging familiarity with. And not confusing your users or misrepresenting the underlying technology and it's a tightrope. I continued to walk recently having conversations with Sebastian to dine about maybe adding some sort of props type syntax like view has for Livewire, but it would work subtly different in certain ways that it's just one of those concerns I have it's one of the first it's like I really want to add this. I want it to feel natural like. But I don't want to confuse the hell out of people and and they you know, they're using this and they think well if I change a prop going into it, then the child should update right like stuff like that. So Live Wire is a joy to work on and this was one that I'm really happy with the outcome and feels like a supernatural solution. Whoa. I saved you an entire minute or a minute early. I'll sign off now you can go eat [00:09:00] snacks with the time left. Before before whatever you're doing comes up. Okay. Thanks. Bye.

[00:00:00] Caleb: Okay. This one is straight up silly in hindsight. It's another invisible feature. So the validation and live wire as it stands. I'll describe to you how it behaves right now. If you have a form in Livewire and you have a bunch of input elements and you wire model those input elements two pieces of data inside your component. So if you have a form with a name and an email, you might have wire model name while your model email and then on your class you would have to public property. Public money sign name and then email set to whatever the default so you want them to be. So if you wanted to validate on this, let's say I have a button called submit you'd listen for the submit method on a form or listen for a click method or whatever and fire a method inside your live where component or an action called submit then inside of their you want to do some validation. So the first thing I had this was the first sorry, I'm describing it as it is. Now, here's how it is. Now [00:01:00] you would do this Arrow validate and. Behaves exactly like request Arrow validate. Now you pass in your validation rules and the keys. So you'd say name name is the key and then the value is let's say required pipe Min six or something. It will reference the value of the piece of data called name inside the component just as if it was like a request in laravel like you have data in a request and then you do request Arrow validate you pass in the rules and extra messaging and whatever and then it fires of elevation exception. Right? So this works the same exact way it works intuitively you look at it and you go. Oh that makes perfect sense. This is really easy. I get how to use it because I'm already using it this way. It wasn't always like that my first. In a validation in Livewire at first I thought okay people are going to want to people are going to want to have. Multiple validation sets I was sort of picturing it like you would declare the validation on the component. [00:02:00] So at first I think I had a pup property called validates, which first I stressed out about that name was like protected validates. Is it validates or validator or rules? I didn't really know actually in hindsight rules is probably the best name, but at the time it was validate so protected validates equals and then you have an array that you declare of all the validation rules right on the class. And then, you know just kind of how I. But it would be an array of arrays because I thought well you wouldn't want just one for a component. Let's say you had multiple sets of data that you wanted to validate inside that component. You need to have multiple. So started going down this whole Rabbit Hole of these concept of forms, like Livewire had the concept of forms at one point. We're like and I forgot even how you would denote them in the template like wire: form and then the name and it would keep track of all that data and it would reference the specific that anyway, it was a mess and it was super complicated. So I went know instead of having [00:03:00] instead of having multiple on we're just going to stick with one because this is way easier. So you just have this protected validates and then all the validation rules declared as a class property and then you have this Arrow. Inside of a method that calls on that protected property does the validation and does what it needs to do the problem with this one of the problems with this like a practical problem outside of it. Just feeling weird. Is that so I guess okay. Here's the two problems. The first problem. Like I mentioned is it's restricted to one set of data when you're running this Arrow validate your running the validation for the entire component. That's problem. Number one problem. Number two is if you want Dynamic validation or anything like that, you're declaring it inside of a class property. So you can't do any, you know, you can't like column method or anything, you know, you just have to use the string validation syntax. So those are the two small Hang-Ups. It just didn't feel Perfectly Natural. And again, this is one that through the process of user testing. It just [00:04:00] kind of got honed and I think I think Lucas Mitch it. Yeah, so. Well, I yeah, I don't actually know. Yeah, so when I did a user test with Lucas Mitchell another core laravel contributor number like 2 or 3 or something, he he was super kind to do this and he was ridiculously helpful actually like change the course of Livewire by just you know handful of things he said. But he so I have notes here like this validates type of so clearly I can see that that it's this Arrow validates at the time and then I have all these notes for how to make the validation nicer. So I don't know if it was his user test or one after we're just realized that make the freaking validator function work. The way request validate Works pass in do this Arrow validate and then pass in the rules as you need them and reference the data directly. I don't know. I mean it sounds this is kind of a silly one and as I'm saying it it's silly but it took a long time for me to arrive at that and I guess [00:05:00] it's just a story of a feature just not feeling great. It just felt tacked on it didn't feel natural. It felt like I had created something that you had to learn how it works. But when I arrived at the perfect solution, which is this Arrow validates and then passing the rules. It makes sense to people they immediately get it it clicks. You can use anything you would normally use with requests are validate because I just forward to the validation stuff. Anyway, you can pass in the same exact parameters. You can pass invalidation messaging rules, whatever it makes sense. Um, I guess in theory the perfect solution is to do or I guess the most invisible solution is to do request Arrow validate, but then I would have to hijack the request it would be nasty users would be like well am I they would get confused about what a request is. So a money sign this Arrow validate I think is the perfect solution. It's invisible. You don't even notice you don't even notice it it just makes sense. It makes perfect sense and I don't remember the evolution of this but this was [00:06:00] another one. When you call that it if throw if you you know hit a validation issue, it will throw the validation exception that a normal request validator does and it will provide the money sign errors. Object the errors bag to the view that gets rendered. So that was just a like a tiny bit of hackery to do that. Like the implementation wasn't the hard part. It was coming up with the idea. And once I did it just felt Supernatural so validation just feels so native in Livewire and that that's a huge goal for me with Livewire and that is just the process of user testing and time is just making it feel like laravel making it feel like a first-class Citizen and basically any feature I try to see if. Laravel conventions or functionality or something that I can pull on so that I get that familiarity and I'm not teaching you a new syntax that you're just either know it from vue.js or from laravel and that's sort of a [00:07:00] big overarching goal with Livewire is to just feel natural. If you're a view / level developer one of the while I'm sort of down this hole one of the issues that you come across with that is pulling from conventions. You get the benefit of the assumptions of the user. So the user gets the benefit of familiarity. They're familiar with how it works right away off the bat, which is great. And that's awesome. But they also have assumptions and if those assumptions are incorrect, you can cause confusion for them. So this is really tough balance. We're like the this Arrow validate that so a good example would be if I did request error validation. They would feel natural to them because that's what they're used to using but they might have questions like. Well is this data from the request is all the data just request data from reach live where I request. Where does it come from what it you know that it is request hijacked. Can I not use your quest? Can I use your crust other places? Can I use form requests, you know it like leads them down these Trails of [00:08:00] thoughts that are incorrect. So it's kind of this really tight balance of balancing. Yeah that tension between like leveraging familiarity with. And not confusing your users or misrepresenting the underlying technology and it's a tightrope. I continued to walk recently having conversations with Sebastian to dine about maybe adding some sort of props type syntax like view has for Livewire, but it would work subtly different in certain ways that it's just one of those concerns I have it's one of the first it's like I really want to add this. I want it to feel natural like. But I don't want to confuse the hell out of people and and they you know, they're using this and they think well if I change a prop going into it, then the child should update right like stuff like that. So Live Wire is a joy to work on and this was one that I'm really happy with the outcome and feels like a supernatural solution. Whoa. I saved you an entire minute or a minute early. I'll sign off now you can go eat [00:09:00] snacks with the time left. Before before whatever you're doing comes up. Okay. Thanks. Bye.

The Evolution Of Validation

So before I talk about what Live Wire is all about I think it's worth noting that I don't control Live Wire Live Wire controls me. So I want Live Wire to become what it's going to become sounds kind of crazy and weird. But but really I try not to have too strict of a vision for it because. I want to be able to roll with how with what emerges you know, like as people use it as I use it the vision for it's going to change good use cases for are going to change we're going to be informed as we go so live Where could change form? I don't know. I want it to be fluid at this point rather than you know have a very strict idea of what I wanted to be. I want it to kind of I don't know. Evolve on its own it sounds kind of weird but what is live, we're all about. So I think what I want to say here is the things about Livewire that have nothing to do with Live Wire itself. Because Live Wire represents change in my thinking and my development habits and really a core belief that came from you've heard me say it a thousand times. My journey has been from you know little I don't know newbie developer making apps and codeigniter and jQuery and using bootstrap and admin templates and all that stuff and then. Getting into layer cast leveling up learning object orientation feeling like a badass and then watching that view series getting into view going deep into view and feeling like a god developer. Not really but feeling like a pretty capable developer feeling like I can you know, I have a place at the at the table at meetups. You know that are all talking about hot JavaScript things. You know, I'm in the hot JavaScript stuff and full sack and microservices and Json apis and rest and all that stuff. I don't know. I felt I felt like I don't know like that there that was in some way sort of a peek. For me, but really that I mean that that seam and it's I think a lot of people follow that same path but like, you know, and you've I started started talking about 20% time the podcast that Daniel nice to host at the time and my Lair can talk two years ago called embrace the back end where I started to really question. Some of the ideas or some of the ways that I've been developing my apps like I'd gone a little bit too far. Everything was a jack stand. I had like separated the back and in the front end and really just ended up with apps that are just way freaking more complex than they need to be Point Blank. And so the rest of the so the journey down from that Hill the journey sort of down from JavaScript Mountain down to reality going back to like native form submissions and blade and stuff like that little inline scripts and inline Styles and things like that. And that's where live where sort of comes in is live. Where is just a piece of that puzzle on that journey and live or is about about the whole journey, like that's it's a tool that represents that way of thinking so I don't necessarily expect that everybody who thinks this way is going to use Live Wire because it's not for everybody. I think it solves a very specific need and it solves it really well and I think it's a good accessory tool. Like I don't think people need to start writing their entire apps with Livewire. If you know the way I would write an app is I would start with out live wires far as I could. And then when I needed to add it, I would because you know, there is such thing. As you I demand you do need a certain level of UI fanciness to sometimes that's the that provides the best user, you know experience, but that's you know, I try to resist even live wire as complexity, you know. Stick with straight HTML and CSS so far I can get with that native form submissions stuff like that. Then as soon as I need some Dynamic functionality. I'm not looking for a whole page reload, you know live wires away to get a quite a bit of a bang for your buck and then beyond that, you know, you know, my thoughts behind that so really what Live Wire is all about is more than then a framework that allows you to. JavaScript type stuff in PHP and uses Ajax and whenever it's about resisting the complexity of the whole JavaScript ecosystem and it's pretty freaking ridiculous where it's gotten I think in my opinion, there's not enough voices out there. These sort of preaching the evils of I'm going to get religious about this preaching the evils of these these huge tools and these huge tools these big bad tools like react and view the things that everybody uses and every app. It's crazy. Like all the jobs are for these tools everybody you write an app. Yeah, what are we going to write the front of know we write in react right into you? It's ubiquitous. Everybody's doing this. It's crazy. It's so crazy and people feel bad about Native form submissions. You feel like a dope. I don't know. I there's a part of me that does and if you're what your page reloads. Like that somehow some sort of like Marv on your front end like it's not an SP a it's not buttery smooth. It's not perfectly JavaScript templated Ideal World you actually like interact with a real Dom or use a real Dom API like dot class list or something or use a polyfill or something like that. Those things have all become. I don't know like bad in some way and that you know, these pure beautiful built everything. Modular bundle of fide webpack parcel purple blue pink I don't know react view world is that's just been created is absolutely Bonkers and there's tons of power in it. No doubt. These paradigms are huge the things they teach us are huge. And what they can do is huge but I think honestly They're just causing more harm than good for the average web app. There is an end of the spectrum where they are a godsend and there's another end of the spectrum where they're not where they are way way Overkill and that's that's what live where is all about is that that end of the spectrum the middle ground the github's. The base camps the I don't know the coin basis the banking apps the everything but a giant social media platform or some like desktop app style site. You know what I'm saying? Like like Pocket Casts. I don't know any like podcast management app every like 90% of the web apps that I use don't need that stuff. And so I'm writing this talk for full stack. You called right less.js and I wrote basically dislike dashboard with like account management stuff and a bunch of forms and stuff like that. I wrote it as a view SBA just to kind of like we demonstrate to myself. What it's like, you know and man it does feel good. Actually. It feels there's a lot about it. That feels really good. Like it's really clean. But you cannot deny the amount of extra code. I had to write the amount of code that is now untested unless I get in a JavaScript testing and the amount of logic. I have to maintain not to mention all the accessibility concerns like not adding form tags not you know modal's that are just hand-rolled without like our your labels and Aria roles and. So many things that you're just doing yourself that I don't know. It's just crazy. So anyway, and then like the whole kind of right less.js talk for full saki you I take this app and I work it back to just plain HTML and CSS and a little bit of JavaScript and form submission stuff like that and just show how like freaking simple. It is compared to the other way and how you get more test coverage more accessibility or usability. But it actually feels the same way like I use the app and it feels the same way. I pop in some turbolinks and I do some extra fun stuff and basically we end up with two apps that behave the exact same way except one has a whole bundle build process with npm and isn't you know, like I you know on my whole like speech like the front end stuffs not tested because it's you know, template it in JavaScript, whatever. Anyway, that's kind of a ramble but basically. Basically, I'm just being reminded that we've been drawn in by both by half one part UI fanciness meaning like instead of just a like an input type file we have. Drop Zone JS craziness and view plugins that everything's just fancy as hell instead of just like native stuff that just works on all browsers all the time because we're kind of afraid of it or feel like it's like gross or something. I don't know we pull in view select for the simplest things. I know I do. Yeah, so there's that. It's like one part you I Fancy Pants - and then it's one part developers liking new tools that feel Sleek clean modern ideal all of those things. They're all good feelings, like view feels very good in that way. Where you can kind of get this just vague sense that the Dom is old school and I don't know you have to cater to Old browsers and stuff like that. Like it definitely get that there's that exists but at the end of the day like if we're talking about developer productivity. Accessibility user experience all that stuff like men. You cannot deny the productivity gain when you step away from those big tools, and I don't know that's just been speed. It's been like drilled into my brain more and more. Yeah, so that's what live wires all about Live Wire is a piece of that of that that picture. I don't know. It's just a piece of that. It's not the whole thing. So, it's 10 minutes. Thanks.

So before I talk about what Live Wire is all about I think it's worth noting that I don't control Live Wire Live Wire controls me. So I want Live Wire to become what it's going to become sounds kind of crazy and weird. But but really I try not to have too strict of a vision for it because. I want to be able to roll with how with what emerges you know, like as people use it as I use it the vision for it's going to change good use cases for are going to change we're going to be informed as we go so live Where could change form? I don't know. I want it to be fluid at this point rather than you know have a very strict idea of what I wanted to be. I want it to kind of I don't know. Evolve on its own it sounds kind of weird but what is live, we're all about. So I think what I want to say here is the things about Livewire that have nothing to do with Live Wire itself. Because Live Wire represents change in my thinking and my development habits and really a core belief that came from you've heard me say it a thousand times. My journey has been from you know little I don't know newbie developer making apps and codeigniter and jQuery and using bootstrap and admin templates and all that stuff and then. Getting into layer cast leveling up learning object orientation feeling like a badass and then watching that view series getting into view going deep into view and feeling like a god developer. Not really but feeling like a pretty capable developer feeling like I can you know, I have a place at the at the table at meetups. You know that are all talking about hot JavaScript things. You know, I'm in the hot JavaScript stuff and full sack and microservices and Json apis and rest and all that stuff. I don't know. I felt I felt like I don't know like that there that was in some way sort of a peek. For me, but really that I mean that that seam and it's I think a lot of people follow that same path but like, you know, and you've I started started talking about 20% time the podcast that Daniel nice to host at the time and my Lair can talk two years ago called embrace the back end where I started to really question. Some of the ideas or some of the ways that I've been developing my apps like I'd gone a little bit too far. Everything was a jack stand. I had like separated the back and in the front end and really just ended up with apps that are just way freaking more complex than they need to be Point Blank. And so the rest of the so the journey down from that Hill the journey sort of down from JavaScript Mountain down to reality going back to like native form submissions and blade and stuff like that little inline scripts and inline Styles and things like that. And that's where live where sort of comes in is live. Where is just a piece of that puzzle on that journey and live or is about about the whole journey, like that's it's a tool that represents that way of thinking so I don't necessarily expect that everybody who thinks this way is going to use Live Wire because it's not for everybody. I think it solves a very specific need and it solves it really well and I think it's a good accessory tool. Like I don't think people need to start writing their entire apps with Livewire. If you know the way I would write an app is I would start with out live wires far as I could. And then when I needed to add it, I would because you know, there is such thing. As you I demand you do need a certain level of UI fanciness to sometimes that's the that provides the best user, you know experience, but that's you know, I try to resist even live wire as complexity, you know. Stick with straight HTML and CSS so far I can get with that native form submissions stuff like that. Then as soon as I need some Dynamic functionality. I'm not looking for a whole page reload, you know live wires away to get a quite a bit of a bang for your buck and then beyond that, you know, you know, my thoughts behind that so really what Live Wire is all about is more than then a framework that allows you to. JavaScript type stuff in PHP and uses Ajax and whenever it's about resisting the complexity of the whole JavaScript ecosystem and it's pretty freaking ridiculous where it's gotten I think in my opinion, there's not enough voices out there. These sort of preaching the evils of I'm going to get religious about this preaching the evils of these these huge tools and these huge tools these big bad tools like react and view the things that everybody uses and every app. It's crazy. Like all the jobs are for these tools everybody you write an app. Yeah, what are we going to write the front of know we write in react right into you? It's ubiquitous. Everybody's doing this. It's crazy. It's so crazy and people feel bad about Native form submissions. You feel like a dope. I don't know. I there's a part of me that does and if you're what your page reloads. Like that somehow some sort of like Marv on your front end like it's not an SP a it's not buttery smooth. It's not perfectly JavaScript templated Ideal World you actually like interact with a real Dom or use a real Dom API like dot class list or something or use a polyfill or something like that. Those things have all become. I don't know like bad in some way and that you know, these pure beautiful built everything. Modular bundle of fide webpack parcel purple blue pink I don't know react view world is that's just been created is absolutely Bonkers and there's tons of power in it. No doubt. These paradigms are huge the things they teach us are huge. And what they can do is huge but I think honestly They're just causing more harm than good for the average web app. There is an end of the spectrum where they are a godsend and there's another end of the spectrum where they're not where they are way way Overkill and that's that's what live where is all about is that that end of the spectrum the middle ground the github's. The base camps the I don't know the coin basis the banking apps the everything but a giant social media platform or some like desktop app style site. You know what I'm saying? Like like Pocket Casts. I don't know any like podcast management app every like 90% of the web apps that I use don't need that stuff. And so I'm writing this talk for full stack. You called right less.js and I wrote basically dislike dashboard with like account management stuff and a bunch of forms and stuff like that. I wrote it as a view SBA just to kind of like we demonstrate to myself. What it's like, you know and man it does feel good. Actually. It feels there's a lot about it. That feels really good. Like it's really clean. But you cannot deny the amount of extra code. I had to write the amount of code that is now untested unless I get in a JavaScript testing and the amount of logic. I have to maintain not to mention all the accessibility concerns like not adding form tags not you know modal's that are just hand-rolled without like our your labels and Aria roles and. So many things that you're just doing yourself that I don't know. It's just crazy. So anyway, and then like the whole kind of right less.js talk for full saki you I take this app and I work it back to just plain HTML and CSS and a little bit of JavaScript and form submission stuff like that and just show how like freaking simple. It is compared to the other way and how you get more test coverage more accessibility or usability. But it actually feels the same way like I use the app and it feels the same way. I pop in some turbolinks and I do some extra fun stuff and basically we end up with two apps that behave the exact same way except one has a whole bundle build process with npm and isn't you know, like I you know on my whole like speech like the front end stuffs not tested because it's you know, template it in JavaScript, whatever. Anyway, that's kind of a ramble but basically. Basically, I'm just being reminded that we've been drawn in by both by half one part UI fanciness meaning like instead of just a like an input type file we have. Drop Zone JS craziness and view plugins that everything's just fancy as hell instead of just like native stuff that just works on all browsers all the time because we're kind of afraid of it or feel like it's like gross or something. I don't know we pull in view select for the simplest things. I know I do. Yeah, so there's that. It's like one part you I Fancy Pants - and then it's one part developers liking new tools that feel Sleek clean modern ideal all of those things. They're all good feelings, like view feels very good in that way. Where you can kind of get this just vague sense that the Dom is old school and I don't know you have to cater to Old browsers and stuff like that. Like it definitely get that there's that exists but at the end of the day like if we're talking about developer productivity. Accessibility user experience all that stuff like men. You cannot deny the productivity gain when you step away from those big tools, and I don't know that's just been speed. It's been like drilled into my brain more and more. Yeah, so that's what live wires all about Live Wire is a piece of that of that that picture. I don't know. It's just a piece of that. It's not the whole thing. So, it's 10 minutes. Thanks.

What Livewire Is All About

Hey everybody, right now. It is pouring rain outside my window in my office and I just love that so much. I love the sound. It makes me feel like I'm in a cozy shelter like a fort when your kid anyway. So I titled this new design pattern the plug-in pattern so this may exist or not or whatever. But basically it's something that I've been pondering about this new way of writing code that I want to move the live work or two. And I think it'll be interesting and useful for really any project but probably more open source projects, who knows. So the idea is I'm actually coming up with this off the cuff. So it's going to sound like like it's well thought out but it's not the idea. That all or as much functionality as you can for a core four core features inside of a plug-in or package. You should write as plug-ins for for that package what I mean by that is so Livewire offers all these directives. So wire: click while your colon pole, you know, anything like that. I eventually would like to allow the user to register their own hooks so that you could make wire: funada Ledoux. I don't know and and the syntax might be something like Livewire dot directive register the name and then some call back or something like that. Well, what if. Even the internal hooks. Sorry the internal directives what if they used the exact same system so that if your Source diving you're not, you know, it's not like I guess userland and whatever the opposite of that is core core software land feels. The same so an example of this in laravel would be lets say so when you register a custom blade directive and laravel. So blade directive is the at whatever so a diff is a blade directive if you want to register a custom one, it's Blade the blade facade:: directive you pass in a name and then you pass in a callback that you know that you return the rendered HTML from when you Source dive laravel, you'll find it's not as simple like you don't find any place in laravel core that all the. Are registered that way they're inside of these compiler traits and they're like the it or the like let's say the unless directive is a method called compiled unless and there's magic happening and do that which I think you know isn't a great experience as a source diver. Maybe it makes sense for somebody writing the laravel framework, but how cool would it be if even the core laravel? Directives were where actual you know, custom register directed. So somewhere in their vocal cords, he played:: directive so this this could apply to so many different areas of Livewire the obvious one. The one that I the one that I sort of came to this with was custom directives, but I start to think about it how I could apply it in all sorts of different ways. So there's custom directives. There's custom actual blade directives inside Livewire that I'd like to offer where you can register blade directives that only. Run within a live wire request. So you're not, you know messing with the global blade namespace. So there's actually only one right now that exists the at this directive for JavaScript stuff. But but I want to make those extensible and actual plugins like right now. I have a trait called use pagination. I think that basically makes a Livewire component all. It adds functionality for for pagination. It kind of hijacks levels default pagination. So maybe there's a way that I could make this more extensible and use it in the core. Another thought I had was data tables that's going to be something that a really common use case for Livewire at some point. I really want to sink my teeth into it and make a data tables implementation like a first-class API that you can use to make data tables in your apps with Livewire. And I think this is the kind of thing that maybe I wouldn't want in core. Maybe I would want it to be like a composer require Livewire / data tables and it all just kind of works. So anyway, this is kind of where my brain is going and one of the founding motivations behind. This is the make more things the same principle. I think this is a Sandi Metz thing. I don't really remember exactly but I think it is Sandi Metz. I'm probably just paraphrasing but I love this piece of coding wisdom make more things the same and this is a perfect example the things that were different before so in in registering blade directives in laravel to use that example, there's the. The way that it's used in the core. Where is this custom these custom traits with these methods and then there's the way that users can use and user land like blade colon colon directive to register your custom directives to apply the make more things the same pattern is too. Make one unified interface for registering blade directives whether it's user register our developer registering a blade directive or Taylor creating a new blade direct at this way. So that that sort of the the plug-in pattern here's another place that I want to apply it. This is a little bit more zoomed in and a lower level. Detail so Livewire is kind of like vue.js in that it does Dom dipping. So when live where calls out to the server, it renders blade or start renders some Dom gets the HTML back it Compares it with what's on the page and it uses a plug-in called morph Dom that walks through the Dom tree and decides if things are the same or if they're different and if they're different it only updates what's different. So this way you're not wiping out big parts of your Dom and you know, losing focus stayed and input values and all. Stuff like that. It's really efficient, and it's really fast and this is all great. But there's lots of things I have to do so morph down provides hooks itself for things like on before L update which is like before an element is updated by morph Dom you can do stuff to it or decide to disable that behavior. So there's these hooks that morphed I'm offers and there's all sorts of like it's really hard to just jump into this without explaining live where Corbett. Basically there's lots of places where an element is created updated or destroyed Live Wire is the thing that's doing that. And I have to hook hook things unto their and to those those places in the life cycle for everything to work. So one example is wire: loading when you add that directive to an element, it's hidden by default, but then when live wires loading, it adds like display block or something to the elements so that it shows. So there's I have this loading manager. It's a class that basically keeps track of all the elements that have that directive attached so that I can toggle them and and toggle them all I can type of them on and off. So this pattern if I move to this pattern instead of having these these little like Livewire or sorry loading manager dot register loading or something scattered throughout the code base if I had a unified interface that was like on before element destroyed. And a user and user land so you and you're using live where you can hook into this yourself if you want to do stuff and I can hook into it for all sorts of core functionality. So that's a little bit hard to explain without giving specific code examples or without you seeing the code base. But just know that there's tons of instances where this would be super useful. The reason this all came about is because I'm reading Sebastian to dyn's. I never know if I pronounce his name, right? I really should ask him that Sebastian to dyn's blog post. You just did a blog post on like using vanilla J's to solve a simple problem instead of reaching for view right up my alley. I love it. I love what he did. Forget about Livewire. He did the right thing. It's great. It's a great post. You should check it out, but I can't help but read it and think oh my gosh, this would be so much easier in Livewire. But one thing that it was missing that he had was offline state. So he added a little indicator in the top right that shows when the connection is offline because it's okay to give you the gist. It's a status page for Flair that new era tracking app that shows I think it's just the the flare app status page. It's like if flare is working if the flare servers are up or down I don't even. And it gives some sort of indication like red or green and he's just pulling like we talked about in the last episode where he's just hitting Ajax hitting the server swapping in HTML every so often but he listens to an online or offline event that browsers fire when computer goes offline and if that's the case, he shows a little off line indicator in the top, right so, you know that you're not getting a live update and I think that's really cool live where doesn't have anything like that people have asked in the GitHub. So I thought well I should add a wire: And to an element so that I can toggle. So let's just say it works like while you're loading if if the thing is online than whatever that element is its just doesn't show if the app goes offline then those elements that have a wire: offline will show so I went to add this and I thought oh man, I'm gonna have to register this just like I did the loading indicator. So everywhere. I handle wire loading. I have to handle wire offline. I thought if I moved to this make everything a plug-in make everything extensible make everything hooks that I could make one hook. That that is just like, you know, I could just hook in. Okay, I can have one file that's just in charge of the offline functionality and hook into the places. I need to hook into them. So maybe this is called the hooking pattern or whatever. There's probably a million different things here. But the way I see it, we're all so it's all skirting around this principle of like make everything extensible make everything lifecycle hooks so that the users can register their own things in a custom unified way and you can too and it's all founded on the. Support of make more things the same. I hope this was interesting for you. I'm literally about to go right this refactor. I just wanted to let you know what I was doing before I get to it. So thanks for listening as always some outro music that doesn't exist now then identity.

Hey everybody, right now. It is pouring rain outside my window in my office and I just love that so much. I love the sound. It makes me feel like I'm in a cozy shelter like a fort when your kid anyway. So I titled this new design pattern the plug-in pattern so this may exist or not or whatever. But basically it's something that I've been pondering about this new way of writing code that I want to move the live work or two. And I think it'll be interesting and useful for really any project but probably more open source projects, who knows. So the idea is I'm actually coming up with this off the cuff. So it's going to sound like like it's well thought out but it's not the idea. That all or as much functionality as you can for a core four core features inside of a plug-in or package. You should write as plug-ins for for that package what I mean by that is so Livewire offers all these directives. So wire: click while your colon pole, you know, anything like that. I eventually would like to allow the user to register their own hooks so that you could make wire: funada Ledoux. I don't know and and the syntax might be something like Livewire dot directive register the name and then some call back or something like that. Well, what if. Even the internal hooks. Sorry the internal directives what if they used the exact same system so that if your Source diving you're not, you know, it's not like I guess userland and whatever the opposite of that is core core software land feels. The same so an example of this in laravel would be lets say so when you register a custom blade directive and laravel. So blade directive is the at whatever so a diff is a blade directive if you want to register a custom one, it's Blade the blade facade:: directive you pass in a name and then you pass in a callback that you know that you return the rendered HTML from when you Source dive laravel, you'll find it's not as simple like you don't find any place in laravel core that all the. Are registered that way they're inside of these compiler traits and they're like the it or the like let's say the unless directive is a method called compiled unless and there's magic happening and do that which I think you know isn't a great experience as a source diver. Maybe it makes sense for somebody writing the laravel framework, but how cool would it be if even the core laravel? Directives were where actual you know, custom register directed. So somewhere in their vocal cords, he played:: directive so this this could apply to so many different areas of Livewire the obvious one. The one that I the one that I sort of came to this with was custom directives, but I start to think about it how I could apply it in all sorts of different ways. So there's custom directives. There's custom actual blade directives inside Livewire that I'd like to offer where you can register blade directives that only. Run within a live wire request. So you're not, you know messing with the global blade namespace. So there's actually only one right now that exists the at this directive for JavaScript stuff. But but I want to make those extensible and actual plugins like right now. I have a trait called use pagination. I think that basically makes a Livewire component all. It adds functionality for for pagination. It kind of hijacks levels default pagination. So maybe there's a way that I could make this more extensible and use it in the core. Another thought I had was data tables that's going to be something that a really common use case for Livewire at some point. I really want to sink my teeth into it and make a data tables implementation like a first-class API that you can use to make data tables in your apps with Livewire. And I think this is the kind of thing that maybe I wouldn't want in core. Maybe I would want it to be like a composer require Livewire / data tables and it all just kind of works. So anyway, this is kind of where my brain is going and one of the founding motivations behind. This is the make more things the same principle. I think this is a Sandi Metz thing. I don't really remember exactly but I think it is Sandi Metz. I'm probably just paraphrasing but I love this piece of coding wisdom make more things the same and this is a perfect example the things that were different before so in in registering blade directives in laravel to use that example, there's the. The way that it's used in the core. Where is this custom these custom traits with these methods and then there's the way that users can use and user land like blade colon colon directive to register your custom directives to apply the make more things the same pattern is too. Make one unified interface for registering blade directives whether it's user register our developer registering a blade directive or Taylor creating a new blade direct at this way. So that that sort of the the plug-in pattern here's another place that I want to apply it. This is a little bit more zoomed in and a lower level. Detail so Livewire is kind of like vue.js in that it does Dom dipping. So when live where calls out to the server, it renders blade or start renders some Dom gets the HTML back it Compares it with what's on the page and it uses a plug-in called morph Dom that walks through the Dom tree and decides if things are the same or if they're different and if they're different it only updates what's different. So this way you're not wiping out big parts of your Dom and you know, losing focus stayed and input values and all. Stuff like that. It's really efficient, and it's really fast and this is all great. But there's lots of things I have to do so morph down provides hooks itself for things like on before L update which is like before an element is updated by morph Dom you can do stuff to it or decide to disable that behavior. So there's these hooks that morphed I'm offers and there's all sorts of like it's really hard to just jump into this without explaining live where Corbett. Basically there's lots of places where an element is created updated or destroyed Live Wire is the thing that's doing that. And I have to hook hook things unto their and to those those places in the life cycle for everything to work. So one example is wire: loading when you add that directive to an element, it's hidden by default, but then when live wires loading, it adds like display block or something to the elements so that it shows. So there's I have this loading manager. It's a class that basically keeps track of all the elements that have that directive attached so that I can toggle them and and toggle them all I can type of them on and off. So this pattern if I move to this pattern instead of having these these little like Livewire or sorry loading manager dot register loading or something scattered throughout the code base if I had a unified interface that was like on before element destroyed. And a user and user land so you and you're using live where you can hook into this yourself if you want to do stuff and I can hook into it for all sorts of core functionality. So that's a little bit hard to explain without giving specific code examples or without you seeing the code base. But just know that there's tons of instances where this would be super useful. The reason this all came about is because I'm reading Sebastian to dyn's. I never know if I pronounce his name, right? I really should ask him that Sebastian to dyn's blog post. You just did a blog post on like using vanilla J's to solve a simple problem instead of reaching for view right up my alley. I love it. I love what he did. Forget about Livewire. He did the right thing. It's great. It's a great post. You should check it out, but I can't help but read it and think oh my gosh, this would be so much easier in Livewire. But one thing that it was missing that he had was offline state. So he added a little indicator in the top right that shows when the connection is offline because it's okay to give you the gist. It's a status page for Flair that new era tracking app that shows I think it's just the the flare app status page. It's like if flare is working if the flare servers are up or down I don't even. And it gives some sort of indication like red or green and he's just pulling like we talked about in the last episode where he's just hitting Ajax hitting the server swapping in HTML every so often but he listens to an online or offline event that browsers fire when computer goes offline and if that's the case, he shows a little off line indicator in the top, right so, you know that you're not getting a live update and I think that's really cool live where doesn't have anything like that people have asked in the GitHub. So I thought well I should add a wire: And to an element so that I can toggle. So let's just say it works like while you're loading if if the thing is online than whatever that element is its just doesn't show if the app goes offline then those elements that have a wire: offline will show so I went to add this and I thought oh man, I'm gonna have to register this just like I did the loading indicator. So everywhere. I handle wire loading. I have to handle wire offline. I thought if I moved to this make everything a plug-in make everything extensible make everything hooks that I could make one hook. That that is just like, you know, I could just hook in. Okay, I can have one file that's just in charge of the offline functionality and hook into the places. I need to hook into them. So maybe this is called the hooking pattern or whatever. There's probably a million different things here. But the way I see it, we're all so it's all skirting around this principle of like make everything extensible make everything lifecycle hooks so that the users can register their own things in a custom unified way and you can too and it's all founded on the. Support of make more things the same. I hope this was interesting for you. I'm literally about to go right this refactor. I just wanted to let you know what I was doing before I get to it. So thanks for listening as always some outro music that doesn't exist now then identity.

New Design Pattern: The Plugin Pattern

Hey friends, lots of new things are going on in my life and I don't have time to tell you about all of them, so I'm just going to pick one. You know what, I'll preview all of them and then I'll tell you specifically about one Alpine is popping off. Um, I think it's hilarious how I put a year of my life, like full time weeks into Livewire. And worked so hard on this thing. And then Alpine, I just kind of like farted out and it's probably going to be way more popular than live where it's like the universe is cruel joke on me. Um. But it's not, it's not entirely accurate because a, I basically wrote Alpine for Livewire. You know, like I, I had already learned how to write a front end framework, so it was really easy for me to write. And it came out of months and months and months and months of just kind of like chipping away at a problem. And then, I don't know, the solution just kinda hit me all at once. Um, and Alpine is in the JavaScript community and who doesn't love a new JavaScript framework? Like, Oh, it's crazy. You want to be rich and famous. Just build a JavaScript framework and everybody will think it's the hotness for awhile. We'll see if it stands the test of time. I mean, I think it will, um, because it is different than it's been. It's the stimulus killer. Like if you've used stimulus, I hate stimulus stimulus sucks. Um, I'm sorry that that was rash of me. Stimulus is great in its, uh, ethos and philosophy, but if you ever wrote it, it was LA, LA, LA, LA, LA LA. I do not like it. So Alpine in my mind is the stimulus killer. Um, so I've been refactoring people's stimulus code to Alpine and haven't really run across any shortcomings yet. I mean, stimulus is so simple and dumb anyway. Like it's, it does even more than it. So. Anyway, enough trashing stimulus and hyping my own thing. If you're interested in Alpine, go check it out. It's pretty exciting. Okay. That's Alpine. Um, Oh. Which by the way, is the new name for project decks. If you didn't follow that at some point, cause I realized I didn't record any episodes since I talked about project ducks, but that's that. So live wire onto Livewire. Um, I am very excited about live where I'm going to be launching 1.0 at Laracon us in fee or lyric on online in February, and that's going to be pretty great. And, uh, but basically, so what I want is to get it, I want to build an app with it personally and get it to where I want it to be. Um. And then launch 1.0 so now I'm in that phase where like, okay, I have to start building things myself with it and putting them out there. So I'm going to create like inertia has pink CRM. It's like a little sample app you can download. It's written with inertia. Livewire needs, something like that for sure. And I've wanted to do it for a long time, but I've just, you know, kicked the can down the road. Well, I'm, I'm now, I'm drinking from the can. Is that the proper metaphor? So that's what we're going to do. I'm going to create an application. And it's going to be open sourced and it's going to be my idea of what a perfect application written or what perfect live way or whatever. How I would write an application with live where it, my goal is to make it your everyday average layer of El app with tables and forms and modals and dropdowns and slide outs and. Date pickers and blah, blah, blah. Maybe some comments, maybe some real time chat, maybe some infinite scrolling, maybe some deferred loading. There are tons of opportunities there, and I may a record screencasts about the whole process and put them into a course or a paid subscription thing like Livewire casts. Because, uh, your homeboy has to make some loot on Livewire pretty soon before he goes broke, or his wife kicks him out of the house and makes him get a real job at a local Costco. Um, so barring that event, uh. We'll see what I'm going to do with that. So keep your eye out for that. It's actually been really fun already. Um, I haven't the master branch open in one tab of Livewire and then I have the app. I'm building, I'm calling it project L, by the way, because I punted on the name again. Um, and I have project L open in another tab. And as I work on it, basically my, my goal is like, I want it to be perfect. So anytime I encounter anything that's imperfect, whether it's Livewire or Leora, Vel I will attack the problem. So that's what I've been doing. So if I already like made a ton of changes to my local Livewire installed to make the whole experience just better and to, you know, hone it, um, because now I'm using it. And I want it to be perfect. So, uh, also Laravel I encountered something I wanted and Caravel I hit up Taylor and he liked the idea. So I PRT it to the framework. It's a tiny, tiny thing. But, um, he's totally on board with, with, uh, terraforming of Vela. That's a big word. I'll just say with making changes to layer Velda support live wire and make it better. So that is huge that I have his support. Oh, I haven't even got to the trail apart, so. The other day I met a bear and his name was Jonathan Renick. Um, so Jonathan running can I paired the other day and he was kind of showing me around his SAS app that he has. We were talking about like if it even be possible to do something that like that in Livewire. He's like, yeah. You know, uh, like how would you do something like this? And he did some really heavy Java script stuff. I mean, this app, that dude's nuts, like he's, he's doing some crazy stuff. This app, he's got like this data table of, of data and you can just like drag and drop on any kind of like an Excel, like in any comp column, um, in a row and like drag rows and edit in batch and really not so stuff. And then he's got this report builder where you can like, drag. There's like a column order thing on the left and you can like sort the columns just by dragging them in a different order and the whole page refreshes. So right now it's not written an inertia. It's mostly VJs. And I think turbo links. Um, but I imagine that's probably why he built inertia was basically to like, it's, I remember talking to him in the early days and he was like, should I call it turbo view and restrict it to view or should I open it up? And then he named it turbo links and opened it up. But basically, uh, so I started messing with this drag thing. We were pairing on it, how I could make a plugin for live, where to do this, this drag ability. Long story short, I ended up writing Trello in it last night, um, with live foyer in this little draggable utility that we created and the thing, so that, that's pretty cool. And it really just kind of showed me like, Whoa, okay. So I, in my mind, I thought live foyers good for like form submissions and little stuff where you'd normally write an Ajax request and then the really nitty gritty fancy stuff. You gotta use Java script or view or something like that. Well, I think I'm changing my tune, especially with Alpine coming out, and here's the route, the revelation I had. I'm like, why is it, why is it that this sorting thing is so clean? So here's what we're achieving with sorting, using this JavaScript sorting library. I can have three rows of HTML and I can, let's say that those are stored, they're generated from blades, they're stored in an array in Livewire, like. Called, let's say they're two dues, they're called two dues. There's three two dues, and I looped for each them in blade, and I show those three to do's in their own span tags, or maybe their own ally tags within a UL. And if you can drag them around and the JavaScript library while you're dragging, won't really touch the order of the Dom. But then when you let go, or maybe it does, who knows, whatever, when you're dragging, you're messing with the Dom. And then when you let go, the Dom is in its final state, right? So if I have FUBAR, Baz and I drag bar. In front of Fu and I drop it, the HTML has changed. And now the first ally is bar, and then food, and then BAS. Okay. So you can hook into these drag stop events so that when you let go of the mouse, there's an event and I can fire off a Livewire request that says, Hey, here's the new order of the two dues. It can update the data, re-render the blade, and when the blade comes back to the front end to do, it's Dom diffing. There's no difference. Because it's all data-driven. So I don't know if you're following this, but this is the key, basically. Okay. Here's what it was. I thought Livewire was good for pessimistic UIs. That means like you why's that hang on the server before they update. So let's say you're adding a card to a Trello column. When you hit enter to add the card, if you want a stored in the database, and this is even with VJs, like a pessimistic approach is to wait for the Ajax request to finish. Then reload all the columns, which will have your new card. An optimistic UI is one where you type into, uh, uh, the add card thing. You hit enter, it adds a immediately with JavaScript, and then it makes the server round trip. So I thought Livewire is no good for Pesach, for optimistic UIs. It's more for pessimistic wise, but it's totally not at all. And this is why, if you think of your HTML as a. Data transfer is a transport protocol, data transfer protocol, I don't know, whatever. This is something DHH talks about with turbo links. He's like, why does, why is Jason the only transport? The only valid transport protocol? HTML is a fine transport protocol. So if you think about about HTML as if it's your data. So take the same pattern of an optimistic UI like Trello written in view. You'd have some piece of data that is your schema of the columns and the cards and everything. Then when you, when you add a card, you update that schema so you're, you know, you push to some array or something and then your template automatically refreshes and then in the background, you send off an Ajax request to the backend and you get it back and maybe it has the exact same. Jason payload on its way back, and then you swap it into the object so that when you refresh the page, you can get, you know, a fresh, a fresh schema. So basically what I'm saying is live wire can do the same thing with HTML. If you make an HTML change with JavaScript, and if the state is driven from the backend, you can then, then on the next refresh, if you laser only update the state right. Livewire won't find any issue with the Dom diff. Oh, I know nobody's tracking this cause I'm barely tracking it, but it is a revelation and it's huge and live where it can be used for so many more things than I thought it would. It's 10 10 bye. Thank you for listening.

Hey friends, lots of new things are going on in my life and I don't have time to tell you about all of them, so I'm just going to pick one. You know what, I'll preview all of them and then I'll tell you specifically about one Alpine is popping off. Um, I think it's hilarious how I put a year of my life, like full time weeks into Livewire. And worked so hard on this thing. And then Alpine, I just kind of like farted out and it's probably going to be way more popular than live where it's like the universe is cruel joke on me. Um. But it's not, it's not entirely accurate because a, I basically wrote Alpine for Livewire. You know, like I, I had already learned how to write a front end framework, so it was really easy for me to write. And it came out of months and months and months and months of just kind of like chipping away at a problem. And then, I don't know, the solution just kinda hit me all at once. Um, and Alpine is in the JavaScript community and who doesn't love a new JavaScript framework? Like, Oh, it's crazy. You want to be rich and famous. Just build a JavaScript framework and everybody will think it's the hotness for awhile. We'll see if it stands the test of time. I mean, I think it will, um, because it is different than it's been. It's the stimulus killer. Like if you've used stimulus, I hate stimulus stimulus sucks. Um, I'm sorry that that was rash of me. Stimulus is great in its, uh, ethos and philosophy, but if you ever wrote it, it was LA, LA, LA, LA, LA LA. I do not like it. So Alpine in my mind is the stimulus killer. Um, so I've been refactoring people's stimulus code to Alpine and haven't really run across any shortcomings yet. I mean, stimulus is so simple and dumb anyway. Like it's, it does even more than it. So. Anyway, enough trashing stimulus and hyping my own thing. If you're interested in Alpine, go check it out. It's pretty exciting. Okay. That's Alpine. Um, Oh. Which by the way, is the new name for project decks. If you didn't follow that at some point, cause I realized I didn't record any episodes since I talked about project ducks, but that's that. So live wire onto Livewire. Um, I am very excited about live where I'm going to be launching 1.0 at Laracon us in fee or lyric on online in February, and that's going to be pretty great. And, uh, but basically, so what I want is to get it, I want to build an app with it personally and get it to where I want it to be. Um. And then launch 1.0 so now I'm in that phase where like, okay, I have to start building things myself with it and putting them out there. So I'm going to create like inertia has pink CRM. It's like a little sample app you can download. It's written with inertia. Livewire needs, something like that for sure. And I've wanted to do it for a long time, but I've just, you know, kicked the can down the road. Well, I'm, I'm now, I'm drinking from the can. Is that the proper metaphor? So that's what we're going to do. I'm going to create an application. And it's going to be open sourced and it's going to be my idea of what a perfect application written or what perfect live way or whatever. How I would write an application with live where it, my goal is to make it your everyday average layer of El app with tables and forms and modals and dropdowns and slide outs and. Date pickers and blah, blah, blah. Maybe some comments, maybe some real time chat, maybe some infinite scrolling, maybe some deferred loading. There are tons of opportunities there, and I may a record screencasts about the whole process and put them into a course or a paid subscription thing like Livewire casts. Because, uh, your homeboy has to make some loot on Livewire pretty soon before he goes broke, or his wife kicks him out of the house and makes him get a real job at a local Costco. Um, so barring that event, uh. We'll see what I'm going to do with that. So keep your eye out for that. It's actually been really fun already. Um, I haven't the master branch open in one tab of Livewire and then I have the app. I'm building, I'm calling it project L, by the way, because I punted on the name again. Um, and I have project L open in another tab. And as I work on it, basically my, my goal is like, I want it to be perfect. So anytime I encounter anything that's imperfect, whether it's Livewire or Leora, Vel I will attack the problem. So that's what I've been doing. So if I already like made a ton of changes to my local Livewire installed to make the whole experience just better and to, you know, hone it, um, because now I'm using it. And I want it to be perfect. So, uh, also Laravel I encountered something I wanted and Caravel I hit up Taylor and he liked the idea. So I PRT it to the framework. It's a tiny, tiny thing. But, um, he's totally on board with, with, uh, terraforming of Vela. That's a big word. I'll just say with making changes to layer Velda support live wire and make it better. So that is huge that I have his support. Oh, I haven't even got to the trail apart, so. The other day I met a bear and his name was Jonathan Renick. Um, so Jonathan running can I paired the other day and he was kind of showing me around his SAS app that he has. We were talking about like if it even be possible to do something that like that in Livewire. He's like, yeah. You know, uh, like how would you do something like this? And he did some really heavy Java script stuff. I mean, this app, that dude's nuts, like he's, he's doing some crazy stuff. This app, he's got like this data table of, of data and you can just like drag and drop on any kind of like an Excel, like in any comp column, um, in a row and like drag rows and edit in batch and really not so stuff. And then he's got this report builder where you can like, drag. There's like a column order thing on the left and you can like sort the columns just by dragging them in a different order and the whole page refreshes. So right now it's not written an inertia. It's mostly VJs. And I think turbo links. Um, but I imagine that's probably why he built inertia was basically to like, it's, I remember talking to him in the early days and he was like, should I call it turbo view and restrict it to view or should I open it up? And then he named it turbo links and opened it up. But basically, uh, so I started messing with this drag thing. We were pairing on it, how I could make a plugin for live, where to do this, this drag ability. Long story short, I ended up writing Trello in it last night, um, with live foyer in this little draggable utility that we created and the thing, so that, that's pretty cool. And it really just kind of showed me like, Whoa, okay. So I, in my mind, I thought live foyers good for like form submissions and little stuff where you'd normally write an Ajax request and then the really nitty gritty fancy stuff. You gotta use Java script or view or something like that. Well, I think I'm changing my tune, especially with Alpine coming out, and here's the route, the revelation I had. I'm like, why is it, why is it that this sorting thing is so clean? So here's what we're achieving with sorting, using this JavaScript sorting library. I can have three rows of HTML and I can, let's say that those are stored, they're generated from blades, they're stored in an array in Livewire, like. Called, let's say they're two dues, they're called two dues. There's three two dues, and I looped for each them in blade, and I show those three to do's in their own span tags, or maybe their own ally tags within a UL. And if you can drag them around and the JavaScript library while you're dragging, won't really touch the order of the Dom. But then when you let go, or maybe it does, who knows, whatever, when you're dragging, you're messing with the Dom. And then when you let go, the Dom is in its final state, right? So if I have FUBAR, Baz and I drag bar. In front of Fu and I drop it, the HTML has changed. And now the first ally is bar, and then food, and then BAS. Okay. So you can hook into these drag stop events so that when you let go of the mouse, there's an event and I can fire off a Livewire request that says, Hey, here's the new order of the two dues. It can update the data, re-render the blade, and when the blade comes back to the front end to do, it's Dom diffing. There's no difference. Because it's all data-driven. So I don't know if you're following this, but this is the key, basically. Okay. Here's what it was. I thought Livewire was good for pessimistic UIs. That means like you why's that hang on the server before they update. So let's say you're adding a card to a Trello column. When you hit enter to add the card, if you want a stored in the database, and this is even with VJs, like a pessimistic approach is to wait for the Ajax request to finish. Then reload all the columns, which will have your new card. An optimistic UI is one where you type into, uh, uh, the add card thing. You hit enter, it adds a immediately with JavaScript, and then it makes the server round trip. So I thought Livewire is no good for Pesach, for optimistic UIs. It's more for pessimistic wise, but it's totally not at all. And this is why, if you think of your HTML as a. Data transfer is a transport protocol, data transfer protocol, I don't know, whatever. This is something DHH talks about with turbo links. He's like, why does, why is Jason the only transport? The only valid transport protocol? HTML is a fine transport protocol. So if you think about about HTML as if it's your data. So take the same pattern of an optimistic UI like Trello written in view. You'd have some piece of data that is your schema of the columns and the cards and everything. Then when you, when you add a card, you update that schema so you're, you know, you push to some array or something and then your template automatically refreshes and then in the background, you send off an Ajax request to the backend and you get it back and maybe it has the exact same. Jason payload on its way back, and then you swap it into the object so that when you refresh the page, you can get, you know, a fresh, a fresh schema. So basically what I'm saying is live wire can do the same thing with HTML. If you make an HTML change with JavaScript, and if the state is driven from the backend, you can then, then on the next refresh, if you laser only update the state right. Livewire won't find any issue with the Dom diff. Oh, I know nobody's tracking this cause I'm barely tracking it, but it is a revelation and it's huge and live where it can be used for so many more things than I thought it would. It's 10 10 bye. Thank you for listening.

AlpineJS | Project-L | Building Trello With Livewire (My Revelation)

A new superpower I've been discovering is writing drafts religiously. Any thought or idea I have, I throw up a draft. What can hurt? It has lots of benefits and I'll talk all about them.

A new superpower I've been discovering is writing drafts religiously. Any thought or idea I have, I throw up a draft. What can hurt? It has lots of benefits and I'll talk all about them.

Write Drafts. For Everything. All The Time.

Hey there today. I want to talk about Dom diffing so and my dom different woes first. What what is dumb diffing? So Live Wire is a front-end framework. What am I even saying? It's not even useful knowledge. You know, it's a front-end framework. Let's jump in so view JS when you make a component in Judea. It takes your template. There's a machine that takes your Dom template that template tag and turns it into a Json representation of that Dom tree. So understanding a Dom tree is like step one and all this process and it's actually way simpler than you think a Dom tree is. Up basically nodes and their children and that's how its represented, you know, an HTML or XML you have something a node in this case with an opening tag and a closing tag and anything inside of it is a child of that node. So each node has three properties. This is all you need to know about Dom trees and dipping and tree walking. It's the key to understanding dipping and walking each Dom node has three properties one is its name? And that's the tag name. So if it's a div that's div if it's a button is button to it's the attributes the attributes on it are href class on click whatever and the third is its children, which is just an array of more Dom nodes. So if you followed what I said right there, you understand virtual Dom's you understand the normal Dom you understand render functions render methods inside of. Inside a few JSU understand jsx and what it compiles to and you might not even realize it but you understand all that now because that's really as simple as it is when you write a template in vue.js and compiles all that to a render method which basically returns a Json representation of that Dom tree that you just wrote into Json. So with UJS when you make a change you click on something the template is re-rendered. I think I'm as I'm saying this I'm questioning myself. Let's just pretend it's that way when you click on something the render function re-renders. Yeah, the render function re-renders regenerating a new Json representation of the Dom Tree View JS Compares that representation to the old representation or the one that's currently on the page and it does a diff and it's so how does the diff is picture? Both it's just to Json objects side by side starts at the top one and it compares the two it says hey, are you the same? Okay, you're the same are your children the same? They're the same. Alright, let's move on. Are you the same? No, you're different. Okay, so I either need to. I then need to decide if I'm going to update if they are the same. They're just a little bit different and I need to update the old one or if they're totally different. I need to add this to to the new tree. So it does its own decision making process walking down this tree to figure out if an element needs to be updated or added or removed. Those are the three things that can happen in element can be added updated or removed and it compares the to Json representations. So. The plug-in that it actually uses view uses. It's called Snap. Damn. It was a it's a package. That is I think no longer really popular because it's basically been absorbed into vue.js score. I think there is another JavaScript framework that uses it but you can actually dive the ajaces core and you'll find that it's not a package dependency. They like pulled it into the project like the files are just there and they wrote a little shout-out to it. Like this is, you know jacked from snap dumb. We changed a few things. So that was all black box me for a long time, but that's actually how vue.js works. And that's it's not that complex jsx does the same thing Deus Ex is not anything specific to react it can be but the idea of jsx is that it takes the special syntax and turns it into some sort of virtual Dom and all of virtual Dom is is a Json object with things and those things are nodes or you can call them nodes, whatever they're just item. In the in the Json tree and they have three things. They have the name the attributes and their children. Okay. So, how does Live Wire fit into all this? So Live Wire is it's another front-end framework. Like I told you in the beginning and when you make an update to it instead of it, you know, just rerun during re running some render method like vue.js would it calls out to the server to get the Dom it calls up to the server blade runs gives us our Dom. We know that. And it takes the difference of the two, so there is no there is no virtual Dom representation in theory. I could keep a virtual Dom representation. I could convert the Dom from the server into Json and then I can use that to compare and patch and are different patch. That's what people say when they're talking about virtual Dums so I could do that and I actually spent a weekend hacking on that to see if I could get that to work and I did get it to work. But it's kind of weird because it's an intermediate step and whatever but what it actually does is I use a package called morph Dom so morph time is unique in this space because it takes existing Dom and does all this logic. It's the same fundamental concept of snap Dom or any virtual Dom dipping Library. It just uses actual Dom elements instead of using Json. It uses a Dom tree like the kind of tree you get when you do document dot query selector something. That you get an element and then you get it, you know, you can do dot children and everything. It uses that so it actually touts itself as being faster than most virtual Dom libraries because the Dom is just really fast or certain operations on the dumb are really fast. Some are really slow and it sort of has this white list of like, here's all the things that are really fast operations to execute on the dumbly children or sibling or appendchild stuff like that so or get attributes and whatnot. So that's morph Tom and live where uses more of dumb one of the reasons. I reached for morph down because Phoenix live view uses morph Dom and I knew that from day one and I went. Oh, I'll just use this morphe down because then I don't have to deal with virtual Dom and Json. I can literally just morph down here. Let me break this down if this is sounding all like pie-in-the-sky type deal morph Dom is a function. It's actually like three files. That's the whole package. It's one of them's a pretty nasty big file. It's a function called morph Dom and what you do is you pass in a Dom element into as the first the first parameter and the second one you pass in either a string of dumb like an HTML string or another Dom element and what it will do is it will take the first Dom element that you gave it and it will morph it into what you pass in as a second argument. That is literally. How morph Tom how you use more of them? It's one function with two parameters granted. There's a bunch of config options and basically a bunch of lifecycle hooks. You can hook into like on before update on before remove that sort of thing. So getting an understanding of morph down and how it works is actually just SuperDuper useful to you understanding my woes and my problem isn't with the front end of Livewire. Morphed seems amazing. It seems like the Silver Bullet but I've struggled with it since day one and I've had these these problems there's a bunch of them and it's hard to get into all of them. But what I've decided to do is pull in my own version of morph dumb. So instead of forking it and managing a fork, I'd literally just like copy the files and put it in my my project. This may be bad practice in open-source land. I'm sure it is I it is known that it's morphed. I'm. If you were Source diving you it's not like I pretend it's my code. I think I even wrote a little shout-out to morph them. But either way that is that's what's going on. And I've had to make in line edits. I try to tag them with at Livewire update or something like that like some little comment. That's just like hey I had to hack this thing so that if we ever need to upgrade morph dumb, we can not just like remove changes I made and there's certain things that morph Dom is just actually sucks out of the box that I can't. I can't believe certain things are the way they are and I've talked about it on the GitHub repository Scott. Scott newcomers actually really great. He stepped in and he's been maintaining the project and there's just it's just an application that a bunch of people use differently and it's hard to get a consensus on how to use it, but it's a struggle of mine right now and that's what I'm here to tell you about. So, I think this episode is just going to be a how Dom dipping works. And then in the future, maybe I'll let you in on my woes but that's what I started to do right now is I deal with lots of bugs if people saying like just weird functionality just stuff that's weird and live wire and a lot of times it's because morph Dom thinks that you've liked made a massive update to the dominant wipes all the elements and rebuilds them all when really it just failed to recognize that you've changed one thing. Or that you added an element in the middle. The most common place to shows up is when people are conditionally showing validation messages and it div appears in the middle of the Dom tree and morph Tom things. Hey a new div appeared the div and everything after it needs to be destroyed and recreated. So I'm dealing with that right now and I have a sort of a fork in the road that I was going to tell you about. But let's just keep this episode to how Dom different. Thanks for listening along. Oh, yeah, this is like the first episode I'm recording after launching the podcast. Thanks for listening people seem to really like it and I hope you do too hit me up with feedback on Twitter if at larvae live where I kill a boar zero just hit me up and let me know what you think about it. I'm really interested to hear that stuff. So thanks a lot. Enjoy your drive or your coffee or whatever you're doing right now. See ya.

Hey there today. I want to talk about Dom diffing so and my dom different woes first. What what is dumb diffing? So Live Wire is a front-end framework. What am I even saying? It's not even useful knowledge. You know, it's a front-end framework. Let's jump in so view JS when you make a component in Judea. It takes your template. There's a machine that takes your Dom template that template tag and turns it into a Json representation of that Dom tree. So understanding a Dom tree is like step one and all this process and it's actually way simpler than you think a Dom tree is. Up basically nodes and their children and that's how its represented, you know, an HTML or XML you have something a node in this case with an opening tag and a closing tag and anything inside of it is a child of that node. So each node has three properties. This is all you need to know about Dom trees and dipping and tree walking. It's the key to understanding dipping and walking each Dom node has three properties one is its name? And that's the tag name. So if it's a div that's div if it's a button is button to it's the attributes the attributes on it are href class on click whatever and the third is its children, which is just an array of more Dom nodes. So if you followed what I said right there, you understand virtual Dom's you understand the normal Dom you understand render functions render methods inside of. Inside a few JSU understand jsx and what it compiles to and you might not even realize it but you understand all that now because that's really as simple as it is when you write a template in vue.js and compiles all that to a render method which basically returns a Json representation of that Dom tree that you just wrote into Json. So with UJS when you make a change you click on something the template is re-rendered. I think I'm as I'm saying this I'm questioning myself. Let's just pretend it's that way when you click on something the render function re-renders. Yeah, the render function re-renders regenerating a new Json representation of the Dom Tree View JS Compares that representation to the old representation or the one that's currently on the page and it does a diff and it's so how does the diff is picture? Both it's just to Json objects side by side starts at the top one and it compares the two it says hey, are you the same? Okay, you're the same are your children the same? They're the same. Alright, let's move on. Are you the same? No, you're different. Okay, so I either need to. I then need to decide if I'm going to update if they are the same. They're just a little bit different and I need to update the old one or if they're totally different. I need to add this to to the new tree. So it does its own decision making process walking down this tree to figure out if an element needs to be updated or added or removed. Those are the three things that can happen in element can be added updated or removed and it compares the to Json representations. So. The plug-in that it actually uses view uses. It's called Snap. Damn. It was a it's a package. That is I think no longer really popular because it's basically been absorbed into vue.js score. I think there is another JavaScript framework that uses it but you can actually dive the ajaces core and you'll find that it's not a package dependency. They like pulled it into the project like the files are just there and they wrote a little shout-out to it. Like this is, you know jacked from snap dumb. We changed a few things. So that was all black box me for a long time, but that's actually how vue.js works. And that's it's not that complex jsx does the same thing Deus Ex is not anything specific to react it can be but the idea of jsx is that it takes the special syntax and turns it into some sort of virtual Dom and all of virtual Dom is is a Json object with things and those things are nodes or you can call them nodes, whatever they're just item. In the in the Json tree and they have three things. They have the name the attributes and their children. Okay. So, how does Live Wire fit into all this? So Live Wire is it's another front-end framework. Like I told you in the beginning and when you make an update to it instead of it, you know, just rerun during re running some render method like vue.js would it calls out to the server to get the Dom it calls up to the server blade runs gives us our Dom. We know that. And it takes the difference of the two, so there is no there is no virtual Dom representation in theory. I could keep a virtual Dom representation. I could convert the Dom from the server into Json and then I can use that to compare and patch and are different patch. That's what people say when they're talking about virtual Dums so I could do that and I actually spent a weekend hacking on that to see if I could get that to work and I did get it to work. But it's kind of weird because it's an intermediate step and whatever but what it actually does is I use a package called morph Dom so morph time is unique in this space because it takes existing Dom and does all this logic. It's the same fundamental concept of snap Dom or any virtual Dom dipping Library. It just uses actual Dom elements instead of using Json. It uses a Dom tree like the kind of tree you get when you do document dot query selector something. That you get an element and then you get it, you know, you can do dot children and everything. It uses that so it actually touts itself as being faster than most virtual Dom libraries because the Dom is just really fast or certain operations on the dumb are really fast. Some are really slow and it sort of has this white list of like, here's all the things that are really fast operations to execute on the dumbly children or sibling or appendchild stuff like that so or get attributes and whatnot. So that's morph Tom and live where uses more of dumb one of the reasons. I reached for morph down because Phoenix live view uses morph Dom and I knew that from day one and I went. Oh, I'll just use this morphe down because then I don't have to deal with virtual Dom and Json. I can literally just morph down here. Let me break this down if this is sounding all like pie-in-the-sky type deal morph Dom is a function. It's actually like three files. That's the whole package. It's one of them's a pretty nasty big file. It's a function called morph Dom and what you do is you pass in a Dom element into as the first the first parameter and the second one you pass in either a string of dumb like an HTML string or another Dom element and what it will do is it will take the first Dom element that you gave it and it will morph it into what you pass in as a second argument. That is literally. How morph Tom how you use more of them? It's one function with two parameters granted. There's a bunch of config options and basically a bunch of lifecycle hooks. You can hook into like on before update on before remove that sort of thing. So getting an understanding of morph down and how it works is actually just SuperDuper useful to you understanding my woes and my problem isn't with the front end of Livewire. Morphed seems amazing. It seems like the Silver Bullet but I've struggled with it since day one and I've had these these problems there's a bunch of them and it's hard to get into all of them. But what I've decided to do is pull in my own version of morph dumb. So instead of forking it and managing a fork, I'd literally just like copy the files and put it in my my project. This may be bad practice in open-source land. I'm sure it is I it is known that it's morphed. I'm. If you were Source diving you it's not like I pretend it's my code. I think I even wrote a little shout-out to morph them. But either way that is that's what's going on. And I've had to make in line edits. I try to tag them with at Livewire update or something like that like some little comment. That's just like hey I had to hack this thing so that if we ever need to upgrade morph dumb, we can not just like remove changes I made and there's certain things that morph Dom is just actually sucks out of the box that I can't. I can't believe certain things are the way they are and I've talked about it on the GitHub repository Scott. Scott newcomers actually really great. He stepped in and he's been maintaining the project and there's just it's just an application that a bunch of people use differently and it's hard to get a consensus on how to use it, but it's a struggle of mine right now and that's what I'm here to tell you about. So, I think this episode is just going to be a how Dom dipping works. And then in the future, maybe I'll let you in on my woes but that's what I started to do right now is I deal with lots of bugs if people saying like just weird functionality just stuff that's weird and live wire and a lot of times it's because morph Dom thinks that you've liked made a massive update to the dominant wipes all the elements and rebuilds them all when really it just failed to recognize that you've changed one thing. Or that you added an element in the middle. The most common place to shows up is when people are conditionally showing validation messages and it div appears in the middle of the Dom tree and morph Tom things. Hey a new div appeared the div and everything after it needs to be destroyed and recreated. So I'm dealing with that right now and I have a sort of a fork in the road that I was going to tell you about. But let's just keep this episode to how Dom different. Thanks for listening along. Oh, yeah, this is like the first episode I'm recording after launching the podcast. Thanks for listening people seem to really like it and I hope you do too hit me up with feedback on Twitter if at larvae live where I kill a boar zero just hit me up and let me know what you think about it. I'm really interested to hear that stuff. So thanks a lot. Enjoy your drive or your coffee or whatever you're doing right now. See ya.

How DOM Diffing/Patching Works

The best podcast episodes on non-current politics. Covering topics such as universal basic income, democracy, poverty & justice and more. For anyone interested in learning more about politics that affect that world, not just now, but in the longer term. Add episodes you're interested into your queue below!

Best Non-Current Politics Podcasts

The best podcast episodes of the most interesting stories and things. From skyping someone while they're in space, to tracking down and meeting a telephone scammer in person, to the story of a Galapagos. These episodes will keep you and all your friends entertained and captivated for hours. Learn something new in every episode! Add episodes you're interested into your queue below!