Episode Details

Okay. I am recording this podcast right after a while. I'm kinda in the midst of a really, really fun refactor. One of those refactors that's just been building for awhile. Something I've been thinking about in the back of my mind. No, I've known that the architecture is wrong, uh, for this specific thing.

And I've just been sitting with the problem thinking about it, trying to come up with the. Trying to understand the problem well enough, come with the solution, yada, yada, yada. Finally did it. And I feel freaking great about it. And it's really, really, really improving the code base, like as we speak.

So let me walk you through it because this is a, it's another one of those refactors like the ones, it actually looks almost exactly like the ones we've talked about before on here where I started talking about like the hooks pattern, the, a single file pattern, like all these things, um, are all culminating for yet another refactor.

So let me walk you through it. It's a, it's fairly simple. So live wire. And you click a, you click something on the front end and instead of it just changing data and rerender during the front end, like few JS does, it goes back to the server and it changes the data. Rerender is a template on the back end.

It comes back to the browser changes the front end, right? That's how live view works. Phoenix live view. That's how Livewire works. Uh, so the difference between Phoenix live view and Livewire is that Phoenix live view keeps a background instance running. So. Where in VJs you have a component that's alive and it exists in the JavaScript runtime over time and live view.

There's a component that exists in the backend, and so Phoenix uses WebSockets to connect to that component and you can make calls to it and all sorts of stuff, and that makes it really fast and it's great. And yada, yada. Livewire version zero, zero one, uh, worked exactly like that, but then I moved away from WebSockets and now live voyeurs, stateless and uses Ajax requests to go back and forth.

So there's no long running instance. Um, because of that, I have to hydrate and dehydrate Livewire components on the back end. So every request that the browser makes, so you click a button in a live wire component, like you have wire click, and then some action. It sends a request off to the server and says, Hey, here's the idea of the component, here's the name of the component, here's the data the component has, and then a bunch of other stuff says, build up that component from all of this, from this state, because the front end stores the state, build up the component from this state.

Then run this action. Whatever you decided on the wire, click that after. Dehydrate the component back into a Jason array of state that I can store because I'm the front end and I have a run time, so I can keep track of the state here, and then the back end is completely stateless. So that's kind of a fundamental, how live wire works.

Little explanation. So I, I decided to explain it again because I know this is the kind of thing that seems, um, obvious to me, but if you're not building live warrior, then you're probably not totally aware of how it works. So that's kind of the ketchup. Okay. So in the back end, there's this concept of hydrating and dehydrating, but when I was programming it, like that concept was never really clear to me.

Um, like I said, it's been an evolution and I'm just sort of updating the code as I go. Um, so there's this, this kind of, this file that I actually like this file. It's one of the most powerful files in the whole system. It's called connection handler. And it's the thing that takes the incoming requests from the browser and it builds up a Livewire instance.

It calls the stuff on it, it gets the new render dominant, sends it back out all in one method. Um, it calls to a couple of different methods, but it's pretty tight. It's pretty clean. And