The BIG Update

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