Notes On Work - by Caleb Porzio

Latest Episodes:

Submit Pull Requests Oct 09, 2019

Show notes

So today I want to talk about pull requests pull requests. Yeah. So on GitHub, there's issues. Every repository has issues. It's a little tab. You can submit bugs and stuff feature requests, whatever and then there's the pull request Tab and there's a little notification next to each little Tab and GitHub that tells you the amount.

In there so issues is always way higher than pull requests. There are more issues than there are pull requests something that's as a maintainer now for a decent sized project. Like I've maintained products before I still do but live where is definitely the biggest one and there are overwhelmingly more issues than there are pull request.

And as a maintainer pull request help a lot a lot more than issues do issues health and I try to be grateful for every contribution no matter what it is and I consider an issue submission a contribution. So I'm thankful for all of it, but pull requests are exponentially more helpful because well you're pitching in I don't have to do the work or you know, all of it.

So pull requests are really nice. What do I want to talk about pull request? Well, I think I want to talk to my past self. And my past self never really submit pull requests occasionally, I would I got into pull requesting to the laravel core. I think it started with a document may be a comment fix or a doc fix or something and I pull requested it and to my surprise Taylor accepted it now as maintainer.

I know how helpful little typo put PR is R. I love them. They're great. I love it. I see a little PR I can grok exactly what it is. It improves the framework. I hit merge done good to go. Um, if any part of you thinks that that's somehow below anything or anyone don't think that submit them no matter how small.

But anyway, so started submitting a laravel course small things and had decent success getting them merged I guess and that was kind of my foray into open source contributions outside of little ones here and there but I never really did a decent. Well, I take that back. I did I did submit a decent-sized feature one time but that's not the point of this the point of this is that I for a long time thought that submitting a PR well one it's a lot of work.

So it takes, you know, there's some tech overhead. You have to know how to like Fork something pull it down locally use it in a project, you know, make sure it works and all that but there's a lot of emotional things like, you know, just maybe you have imposter syndrome. You feel like you're not worthy.

You feel like you're not going to be able to do an implementation. That looks good. You don't want you don't want to look bad. Who knows what? So I'm here to tell you to submit pull requests if you can and if you're willing pull requests are super helpful, and as a maintainer, this is the message I want to tell people is contribute no matter what your level of skill no matter what your level of know how anything just contribute.

I love it when people contribute you can submit a with PR that's just maybe a handful of code changes its incomplete but it's a whip and you can say hey I got this started. Can you help out? You know, can you help me get to the finish line? I will absolutely do that. Another thing that's worth mentioning kind of a caveat is that you should make sure that it's something that needs to be that that's like is wanted that's warranted by the the grand poobah whoever that is in the repository and for live where it's me making sure that it's something I would want in the core or would that we all want whatever.

Before you do all the work, that's the only reason it's not even like annoying to close a pull request or anything. It just hurts me when I get a pull request that somebody really poured a lot of time and effort into and it's something that isn't part of the vision for the framework and I have to deny it or something like that doesn't feel good.

And I try not to do that. I try to work with the person change it, you know, whatever make it rescue some value out of it, but unfortunately, I also try not to let my own like emotions of trying to be a. Generous person in change the framework, you know, I want to make sure that the framework is good on its you know, like, you know what I'm saying?

So pull requests submit them early and often as maintainer. Like I said, I appreciate when a poor request is submitted even when it's half finished and I try to pitch in so when I get a pull request. If it's something that's warranted something that I want or that you know has been talked about in an issue beforehand.

I glanced through it. I look through and I might submit some comments. But really I don't think of it like a code review like it's not like a code review for a co-worker or something that I'm doing. I'm I'm going to do work. You know, I'm not gonna I'm not going to write a ton of if it's something that that you're really pushing hard for and I don't really want.

Then maybe I'll do that. Like I think I've done that once where I'm like, okay, you really want I think it was for better phpunit. Somebody's really want some feature in there and it's just going to add work for me. I don't even think it's necessary but it won't harm the package and they really wanted in there.

So I'm like, all right, you can do it. You got to do all the work though, like and you and this pull request has to be good before I merge it. So I'll comment on little lines like well, what about this? You should do this formatting. Why is this space in here? You know? Why? Why did you choose this instead of this stuff like that?

But like for Livewire in general I get a pull request and I'm not nitpicking like that. I might so I can actually sometimes it doesn't work. But a lot of times I'll check out that branch. Locally and I'll contribute to the pull request myself. So it'll be kind of a teamwork thing like you submit stuff and then I'll make a bunch of edits and and you know submit them back comment on the pull request.

We'll talk about it. We'll work together on it. Sometimes I just merge a pull request and then I take it over from their Taylor. Does that that's something I saw Taylor do he does that a lot? Like if it's he rarely Just Hits merge and then leaves it into core he messes with it. He cleans it up. He makes it his own.

And so I do that if you submit something I try to I also try to make sure you get credit. So like sometimes it's easier for me to just like wipe a pull request and do it myself. It's funny, but that's actually a somewhat common occurrence, but I try not to do that ever. I don't think I think maybe once I did in the beginning and it because of some weird issues and and that person didn't get credit.

We talked it over and it was okay, but I try to give the person who started the pull request. Credit give credit where credit is due type thing and I will work hard to make sure that you show up as the contributor for this thing and that you could contribution credit and all that stuff. So anyway submit pull requests, please please early and often submit them if there's something in the framework you want.

You know that mean talk about it. Make sure we want it to be, you know, first submit an issue proposed it I'll try to get back to you and then submit a pull request. I think that's all I have to say on that. Yeah, so go forth submit things contribute. I'm happy to help out and pitch in we're working together on this also.

No, shame. No shame in Bad Code. No shame in whatever. I totally understand code is written in a context and I have lots of. Less than ideal code written in less-than-ideal contexts, and I understand that. So there you go. Thanks. See ya.

Change Your Environment (On Silencing Twitter) Oct 07, 2019

Show notes

So yesterday I'm standing on my porch waiting for a ride and I pull out my phone and I start scrolling through Twitter and I read something that this isn't necessarily anything out of the ordinary, but I read a tweet from a friend who let's just say did something good like. Insert good thing here that a developer does on Twitter has a hot tip tweet launches course is a sap a blog post you name it and I immediately felt bad about myself just a little bit not anything crazy, but just a tiny bit of bad and I recognized it and I took action.

I changed my environment and I opened up. My followers on sorry the people I'm following on Twitter and I unfollowed every single person that I follow on Twitter close my phone put it back in my pocket and things have been a little bit different since that time. So let me unpack all of that. What led to this?

Why did I do it? What does it have to do with Livewire? That kind of stuff. So I've been feeling let's say in a slump. I've been in a bit of a development slum. You know, I'm working on Livewire I'm slogging through issues not glamorous work dealing with Muddy issues and people around me my friends.

My peers are launching things and it seems like more than ever. Does that feel like that to you like this, especially the spots you guys and some of those I think of them as the Europeans, Because they're European but all of those guys Frakes Frank screw his Entourage, they're all launching things like every other day and every time that happens, I feel I'm happy for them.

And I should say I should be happy for them. But I feel a little bit shittier about myself. Not a lot but a little bit sometimes it's worse than other times and when I'm feeling good about myself when I'm launching things. I can handle it better, you know that stuff happens and I'm fine with it. I feel good about it.

The hard part is when it's your friends. So people closer to me recently have launched some things and it has it. Just kind of weighs on me in this odd way and we know this this is how social media works. We all share the best of what we have to offer we see that we compared it to ourselves. And we feel bad about ourselves and that's what it's just kind of been for me and that's been weighing on me, and I've actually been noticing it.

That I've been feeling less good about Livewire. I've been feeling less good about my development skills about my ability to focus the things I've been putting out all sorts of things are just sort of picture start to sometimes I know what it's like when I'm in a good Zone and I know what it's like when I'm in a mad Zone and this is the bad Zone and I think most of it is caused by Twitter.

Honestly, it's caused by me watching my friends and people around me. Doing better than me, at least it seems that way and I should be able to cope with this and you know, I do and a lot of times, you know, there's a lot of ways to get over pumps like this one every life just happens for me and waves and I know that they'll be another hi.

But I can do things to mitigate that I can meditate I can intentionally. I can remove the Twitter app for my phone. I've done that a bunch of times and I can intentionally go on Twitter last so I can you know, whatever I can meditate on why I should be happy for these people and you can get all crazy and Buddhist about it and recognize that the only person.

The only thing that recognizes any difference and has any need to compare as your ego, and that doesn't actually exist. So if anybody's looking for some heady stuff, that's that's a that's a tactic of mine. But in reality what I needed to do was change my environment. So this is what this episode is about is changing your environment making things happen in your life.

Easily by changing your environment. This is this is all wrapped up in the like make the change easy then make these you change it's one of those deep fundamental truths in life that I've arrived to honestly in the sense that I had didn't take it from The Mountaintop or a stone tablet. I've just experienced this in my life.

So clearly that it's one of those keys. It's a key to life for me is changing environment. I first came across this Zen habits. I have been a longtime reader of Zen habits. I don't know if anybody. Read that I don't really read it anymore. But Leo, you know, he's all about this sort of thing.

Anybody who's all about habit-forming is has encountered this. I mean, this is such a common common tool quitting smoking, you know, I'd really hard to quit smoking when everybody around you smokes hard to quit smoking when you work at a cigarette stand or at a restaurant where you get a break and it becomes a ritual and all your friends smoke.

It's a lot easier to quit smoking when you don't have those things when your environment is changed so you can change your environment and make behavioral changes really really really easy. So in this case, I needed to change my environment. It's like if I want to this is, you know a real thing. I wanted to stop watching TV at night before bed.

For all the reasons that mess with your sleep, you know, I should be talking with my wife all of these things. It's just not good and it's a lot of it is me escaping my own brain that type of thing is me escaping my own brain not wanting to just lay there in silence putting on the TV. It's the easy thing to do so I could just discipline myself.

I could just decide I'm not going to do this. It's gonna be very hard and I'm likely going to fail maybe I'll succeed for a little bit but then I'll fail a way to guarantee that that happens is to change my environment and what that looks like is. You could you could throw your TV out of the window of a 7-story building and that will guarantee success for you.

In my case changing my environment was moving my TV in the living room. It's too much work for me to get out of bed. Go unplug the TV and lug it back in move a shelf put it on. That's that's it. That's enough work that it deters me from ever really thinking to do that. And now I don't watch TV before bed so that behavior was changed because I change my environment.

So in this instance, I needed to change my environment and what that looked like is. Unfollowing every single person on Twitter because now I don't have a timeline anymore. It's been one day and it's actually really interesting I go to my computer and my my muscle memory is to just go twitter.com, but I don't do that.

I didn't do that the past, you know day and a half I guess because there's nothing waiting for me, you know, there's nothing there. I haven't tweeted so there's probably no notifications and there's no timeline with anything on it. So there's nothing for me to read. So I guess a couple caveats here.

I've avoided doing this for a long time. I thought about this before because I could see how it would be so would bring such Clarity it would remove so much noise for my life and I've known that but one it's how I engage in the community and talk with my friends and read about what they're doing and stuff like that.

To it's kind of a golden rule thing like do unto others as you would have them do unto you I don't like follow unto others as you would want them to follow you sort of thing. So I. Try to not be super stingy with following people. I know what it means to be followed by somebody. You respect if I'm that person.

I want to be that person at least but I know what it's like to be on the other end of that Daniel and I used to at Titan we would like it was kind of this friendly competition who could get the four pack of followers who could get Adam Jeffrey Taylor and Matt, I think and and every time we got one we would take a picture and send it to each other and immense it meant a lot.

Um, Chris coil followed me and I was like, I took a picture and...

Open The Black Box (The Solution To My DOM Diffing Woes) Oct 03, 2019

Show notes

So last time we chatted well two times ago talked about my dom diffing woes. Why dom diffing matters in Livewire why it's not perfect why it's super frustrating. Well, I have good news. We're through the woods a little bit and I feel a lot better about where where I'm at with the whole situation in Livewire.

So I want to talk about how I got there. Where to begin so I had mentioned that there's a fork in the road right now. I'm using a package called morph Dom. It's the same package that Phoenix live view uses for Dom diffing and it works. Okay out of the box. I had to do some tweaking I found some bugs right away, but I've encountered a few nebulous bugs that just kind of reveal that morphdom isn't the most advanced Dom differ.

Maybe another way of putting this it I guess the more specific way of putting this it doesn't it doesn't look ahead. So it does Dom diffing but it doesn't predict the future like other Dom differs do and they can basically more intelligently figure out what the actual diff is. It's kind of hard to describe.

But anyway, I don't want to get into like implementation details here. I want to talk about the big picture. So I. Morph time sort of because it's the thing that I've been using and I've been hacking on it. Like I have like duct tape around it and things like that. I've actually, you know pulled it into the project and change specific lines in the code base.

So I kind of own it in my project and their gives you there's like a certain feeling about. About a package that you haven't written about really any code that you haven't written. It doesn't always feel good and your judgements usually clouded. I think a lot of there's like a lot of biases there.

A lot of people think that the code is more poorly written than it actually is if they didn't write it there's all that sort of stuff and it really is hard to reason about there's like one giant while loop with a while loop nested inside of it and a ton of conditionals like probably like eight layers of nesting really hard to follow.

So I definitely feel that way about this code base. I don't understand it makes me feel bad. So of course, there's always the rewrite in the sky well for talk about the rewrite in the sky. There's always new plugins that you can try and I've tried them before I wasted a couple weekends on you trying to switch to a virtual Dom diffing Library.

So I went back to the internet and. Try to see you know, what's out there. What are the alternatives to morphdom morphdom is specific in some specific ways for for a tool like Livewire that I can't just use any Dom differ because a lot of them work with virtual dumbs which live where doesn't use and if that doesn't make sense to you don't worry about it, but there's kind of this niche of Dom differs that work with actual Dom in the browser, which is what Livewire needs so I found an alternative that I don't know if I have some wood across before which is kind of crazy.

Decently popular, you know, the first thing I look at is GitHub Stars. It's funny. It's kind of an arbitrary metric but really it's like it's kind of like on Amazon when you look at. Like sometimes I just look at the amount of reviews and that is that like Swayze my decision, you know. Yeah, so I look at GitHub stars and I go all right.

Is this something that is just Niche somebody started a year ago or two years ago and they're not going to continue keeping up or whatever. So I look at GitHub stars and I look at the last commit date. Those are two things I look at when I open up a GitHub repository. The last commit date was an August that's not bad.

And there's like 500 something GitHub Stars. That's also not bad. I think morph Tom has like 2,000 now, but when I started using it, it was more like a thousand so. So this all looks good to me. I'm like, okay this could work. And so I pull it down. I open a new branch and I pull it down just to do a proof of concept.

This is really important as well as like to basically for any stuff like this. I mean this is kind of obvious stuff, but but it is a good reminder that don't don't start rewriting something like it's it doesn't take that much effort to try something. The problem is when you don't know when to stop trying and we'll talk about that in a minute, but it doesn't take that much effort to try something.

It's good to try. Things near the next time you're in like a meeting or whatever like a Sprint planning or something and there's people talking Ad nauseam about what Solutions might work and what effort they might take take, you know an hour and pull the freaking thing down and actually use it for 5 minutes and it'll actually inform your decision in a huge way.

So I decided to just pull it down and start just hacking on it seeing if I could retrofit into Live Wire and make it work. So that part didn't take me too long. But like I said the risk in that is that you think it's going to work and so you you go down the road and it's it can be a long road and you have to decide when enough is enough.

If you keep going you push forward you fix the bugs you make it match the old behavior and give it and get the new Behavior or you punt on it. And you say you know. But this is too involved. There's too many unknowns here. This is going to take too long. I'm not going to chase this right now.

That's a really really hard decision to make potentially the most difficult decision to make in development. But one of the most important decisions to make so. I did what I wanted it to do right away. Like the thing that morphdom didn't do if Dom did like it's a smart dom differ. Oh, it's more advanced than morphdom in some ways, but there was some other Hang-Ups and so I just started fixing them like one by one and a basically I've read the whole source code.

I've grabbed everything, you know, I went really deep down the whole probably took me a day and a half two days. And I came up and was basically frustrated because I couldn't get it to work. Right? So I went and found another library and did sort of the same thing and then I contemplated. Well, maybe I just get an actual virtual Dom differ like the one vue.js uses pull that in that way.

My basically my virtual Dom diffing will be Rock Solid because it's views core, but but I'll have to do some weird tinkering to get it to work with dhamma in the browser. So I thought about that and basically it all left me in this place. We're just feeling down this this is you know, it's all like a if you picture it like like a hike or something.

It's this is the well maybe a Hikes not the right word. But you're at the bottom of the pit. This is the part where you're you're just you're alone and you're at the bottom of the pit and you don't have any good solution in front of you you feel bad about what's happening. What exists right? Now you start to get that imposter syndrome you start to look at other people and think everybody's better than you everybody's projects better than you and just not feel good about yourself.

And that's pretty much where I was for a handful of days and I didn't know the right way forward. So yesterday I thought you know what I think what I need to do is just do the hard work do the hard work of really owning morph dumb like understand it. Understand every line of it. I've walked it line by line before but I mean really like I mean sit down and read through morphed them until I feel like I know how it works completely to a point that I can change it, you know, like sit down and do that.

So I did and guess what it didn't take me that long. It like it's crazy how that happens. But I'm sure you can relate to this experience where you wear something seems sort of Out Of Reach so you avoid it but when you look it in the eye it's you know, 10 minutes away. I'm thinking of another story where I tried to...

SFP: The Single File Principle Oct 03, 2019

Show notes

Okay today. I want to talk about a new principal object oriented principle. I just made up called SFP the single file principle and this is also sort of my way of communicating something without saying SRP single responsibility principle which tends to get people with their torch and pitchforks out or the stone tablets and preach from the mountaintops or be mad about the people preaching for the mountaintops or whatever, you know, there's been a lot of discussion around it.

So I don't really want to talk about it. But basically this is a really practical principle that I'm going to State as such if you are implementing a feature or if you recognize a I'm just going to use the word feature the fancy term would be a reason to change but if you recognize a feature or you're adding a feature in your app, see if you can keep it all to one file if the file is too big.

Then maybe you'd have to think about this in smaller terms and see if there's some features you can keep to one file. This sounds so silly and so obvious but I'm telling you this is actually one of the most valuable patterns that I employ when I'm writing code. So I'll give you a few practical examples and hopefully it'll start to sink in.

So when I started writing Livewire basic, I mean there's a whole other episode to talk about how. How code design emerges rather than as like planned like I don't really plan designs almost ever. I just start writing code that feels right and I just keep following that right feeling and a couple principles and patterns and I start to see when patterns emerge and then I tackle them and refactor and things like that.

I don't think you can really do much planning up front. But anyway started to build Live Wire and certain pattern started to emerge and here was one eye when I was we're going to talk about the make Command the famous make Command where you type artist and. Artisan make Livewire and then the component name.

I had to turn the component name into a class name space because I need to create that file and I also need to convert it into a view name like a blade file name. There's a bunch of other stuff I need to do. What is the name of the component? Is it you know, if it's counter, it's just counter.

What's the name of the class? What's the name of the class name space the full name space the file path the view the view name like Livewire dot counter and the view file clap path like resources views Live Wire, right? So there's a lot of these things so and there's relative paths and there's absolute past.

There's just it goes on and on and I recognized so for the first iteration, I wrote all this logic inside of the command class inside of the class. I wrote called Livewire may come in. And but I forget exactly where I needed it next but maybe I wrote the Livewire component discover, which we can talk about another episode but inside the discoverer I needed to I needed to use a lot of this logic.

So, you know, I had I had an option you have a fork in the road. I could just copy and paste the logic from the command. Or I could make an abstraction abstraction. And what would that be? I don't know. Maybe it would be a trait. Maybe it would be some helper functions. I'm not really sure yet. And as a rule of thumb, I generally just start with copy and pasting I think j-mac talks about the rule of three.

I don't know if that's something he coin, but I've definitely heard it before. And the idea is that an abstraction or something is not duplicated or like you live with one level of duplications. So if you copy and paste code once that's fine, but if you need it for the third time, then you should think about an abstraction.

It's a good rule of thumb and I try to follow that myself but in this instance, so I did that and then another I forget the next thing but I needed it again. Then the meeting in a lot of places and so the question is, how am I going to do? You know, where am I going to put this logic and it's funny because what I'm saying it, it sounds so obvious make a class that's responsible for parsing out all of these different, you know.

Strings from your the name of the component, but at the time you know how these things work. Like if you're literally copy and pasting maybe it's a little bit obvious but there's always like a minor variation in what one part of the code needs and the other one. So it's hard to recognize the duplication and it's even harder to recognize what the abstraction should be.

But basically I ended up making one file called Live Wire. I don't even know it's changed names a bunch of times now. It's like Livewire component parser or something like that and the idea is you pass in. We pass in like the app namespace of the laravel app and you pass in the views directory and you pass in the name of the component like counter and then you get all these methods like file classpath class name class namespace absolute path relative path few names United space all of these things contents tab contents all the stuff.

And now it's all in one file so I can write a unit test now and this is funny because I don't write a lot of unit tests. But when I put it when I isolate all of this logic into one file, then I feel okay about writing unit tests where I can just throw at it like a hundred different permutations.

Like I'm going to say test that counter spits out and then a bunch of assertions like specific assertions like this path this file path, whatever and then I do a bunch of those to test a bunch of permutations, and now that class is like really well unit tested and everything else can depend on.

Lively so that's kind of an obvious example, but maybe a harder example is something I talked about in episode 8 where we talked about my new design pattern called. What did I even call it? I don't know. I can't even see in the sidebar right now unless I expand and now I can see. It is called the plug-in pattern right where I kind of talked about making things extensible and I mentioned writing hooks.

So refactoring some front-end features two hooks instead of them just being code split out throughout the app. Okay, you probably aren't tracking what I'm saying. So let me break it down in Live Wire, there are let's say the we've been talking about polling. So let's stick with pulling wire: pole you register it.

And then somewhere in the code base and live or is codebase. There's a file called node initializer that when a new when it's when it adds a new node it goes. Hey, is there any Livewire directives on this node? Okay, and it'll go through a switch statement and be like is there wire: pole? Okay.

There is now set up a set Interval Timer to fire an Ajax request every so often but the thing is I also need to add code and other places. I need to know that if it updates and it's removed to remove that that. So I have to go find the piece of the code where component element is updated and there's a bunch more of these things.

So like I said before I kind of had these I had these features sprawled out throughout different parts of the code base because that's honestly saying it right now it seems so obvious but that's that's like the thing to do. That's what you reach for that your knee-jerk reaction and it's hard to recognize how to do it.

Otherwise. But I switched to this hooks pattern where I made this hooks manager where certain parts of the code Base fire Hooks and other parts register handlers for those hooks. So now I have one file in charge of polling and if I delete that file. Pulling disappears from the app. It's completely gone.

Same thing with loading States anything like while you're loading inside Live Wire, that's all happening in one file. Now, it was sprawled out but cross like four five files. Now, it's one file called loading States dot JS because I can just register hook...

My DOM Diffing Woes Sep 25, 2019

Show notes

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.

How DOM Diffing/Patching Works Sep 25, 2019

Show notes

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

New Design Pattern: The Plugin Pattern Sep 23, 2019

Show notes

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

Smart Polling Sep 20, 2019

Show notes

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

Not On NPM Sep 20, 2019

Show notes

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

The Evolution Of Validation Sep 20, 2019

Show notes

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

Our TOPPODCAST Picks

Follow Us

Stay Connected

Notes On Work – by Caleb Porzio

Related Podcasts

Links

Stay Connected