Let's move on and review two-way data binding, and we'll take this in baby steps to make it really easy to understand. But real quick, I have pulled in a CSS utility framework called Tailwind. Don't worry, you don't need to know anything about it. It's just to help our forms be a bit more attractive. Okay, so if I were to add a little snippet here for a input and label, maybe we're creating a form to persist a User. If I view this in Firefox, here's what we get. Now it looks fine, but it's right up against the edges. So on my body tag, let's set some padding all around, and then maybe a maximum width.

Now it looks fine, but it's right up against the edges. So on my body tag, let's set some padding all around, and then maybe a max-width of large, and then the left and right margins to auto. And that's all the CSS will do here. Okay, so at this point, you have learned about one-direction data binding. If I had a name that I hardcoded to John Doe, sure enough, I can bind the value of this input to name. And if I come back, it should say John Doe, and it does. Okay, but again, this is binding in a single direction. It's a one-way street.

Yes, it works now, but as soon as I change the input, they become out of sync. And that's because we're not tracking when you type into the input. But often, for your form inputs, that is exactly what you want. Imagine the user fills out the form, and you then need to submit an AJAX request to a server. You need to hold on to that data. All right, so this is where x-model comes into play. Let me show you it, and then we will review exactly what's going on there. So I'm going to bind this to a property called name, the same one here. And with a single change, have a look. If I type into the input, now we've allowed for two-way data binding.

And with a single change, have a look. If I type into the input, now we've allowed for two-way data binding. Now let's take a step back and think, well, what's going on here? It sounds like, yes, if I give it a refresh, we are binding the value of the input to what we have stored in our data object. However, it looks like we're also listening for when the user creates an input event, or when they type into it. And when they do, we have to listen for that, and then update the underlying name. And you know what? That's exactly what's going on here.

Get the target of the event, which is the input, and then get the value of the input. Okay, so now you'll notice we get the same thing, because again, they are identical. This is the same as this. It's really important to understand. Now X model can be used mostly on your form inputs. You can use it on custom inputs as well, but for now, just think of it as being for your selects, your inputs, your text areas, your checkboxes, things like that. All right, so let's flesh out this example, and then we'll call it a day. If we have a form to create a User, it sounds like I want to track the name, and then when you submit the form, we fire off an AJAX request to create the User.

If we have a form to create a User, it sounds like I want to track the name, and then when you submit the form, we fire off an AJAX request to create the User. Okay. When I'm collecting form data, I could do things like this, maybe age, email, bio, you get the idea. But then when it comes time to submit the AJAX request, I sort of have to build up an object of all the related data. So instead, what I usually do is wrap it all in its own form object. And that way, when I do submit the AJAX request, I simply reference this object alone while knowing it has all the data we need.

And that way, when I do submit the AJAX request, I simply reference this object alone while knowing it has all the data we need. So we're just going to stick with name for now. But just keep in mind, because we've changed it, xModel is not name, it should be the form object and then the name property. And I can get rid of this. Okay, so on our form, we can listen for when you submit the form, again, by doing this. And we're going to talk about event listeners quite a bit, so don't worry about it for now. Listen for when you submit the form, prevent the default action of a form, which is to literally submit the form to the server.

Listen for when you submit the form, prevent the default action of a form, which is to literally submit the form to the server. We're not going to do that because we'll handle it with AJAX. But anyways, when we do, just to give you an idea, let's alert hello to prove that we can listen for that event. All right. One more time, John, I'll hit enter to submit the form, and we trigger the alert. Now alternatively, I can reference a method like submit, and then I can add it up here. Alert this works too. All right, one more time, submit it, and that works as well.

All right. So how do we submit the AJAX request? You can use libraries like Axios, or even Fetch would be fine, which is native to modern browsers. So why don't we take that approach? But real quick, I don't have any kind of local API set up. For tutorials and things like this, I will often use a fake API, like this one. Have a look. If we scroll down, we have all of these endpoints we can use, and in this case, if I want to create a User, I hit this endpoint, I send through the relevant data, and then it returns

If we scroll down, we have all of these endpoints we can use, and in this case, if I want to create a User, I hit this endpoint, I send through the relevant data, and then it returns to me a 201. Just think of it as a fake API that we can test with. So make a fetch request to this endpoint, /api/users, but do note it wants a POST request there. So with fetch, if you want to make a POST request, it's a little bit more wordy, but we would set the method here. We would set our headers. So we expect application/json.

We would set our headers. So we expect application/json. And then finally, what is the body of this request? Well, we already discussed it. It's the form. So I'm going to stringify that, JSON.stringify, and then pass it along with the request. So we're not doing anything with the response, but just to show you in the Network tab, if I run it, I'll take a look at the Request tab here, and here's the payload. And if you want to take a look at the resolved response, here's what they return to us. They basically return to you what you provided, along with an ID, or a fake ID, and a timestamp.

And if you want to take a look at the resolved response, here's what they return to us. They basically return to you what you provided, along with an ID, or a fake ID, and a timestamp. Okay, so why don't we grab that information, and here's how. fetch returns a promise, which basically translates to, hey, at the point you hit this code, I'm not done with the request, but I promise to let you know when I am done. So when you're done, then with that response, I want to grab the JSON results. And then, using that response, if I were to pass it, excuse me, to console.log, try it one more time, go to the Console tab, Jeffrey, here's what we get. We hit Submit, we intercepted that, we then fired off an AJAX request to this fake API, and then it returned to us the representation of a new User.

We hit Submit, we intercepted that, we then fired off an AJAX request to this fake API, and then it returned to us the representation of a new User. So why don't we store that? We'll just say, maybe right up here, maybe here. User will just be an empty object, or maybe null. And then, once we have our resolved user, just save it, this.user equals user. So now, if we scroll down to the bottom of the form, we'll just do it right here. Now I can use the template tag for this, and in fact, I should, because I'm going to say, well, if we have a user, only on that condition should I render this div here. So up until this point, you've learned about x-show.

well, if we have a User, only on that condition should I render this div here. So up until this point, you've learned about x-show. The difference is show refers to visibility. Is the display of this element visible or hidden on the page? x-if determines whether or not it exists at all. So here we're saying, only if a User actually was returned do I want to display this div. And what I'll do here is just say, the user, and then user.name was created at user.createdAt. All right. So are we all on the same page? Let's see it work, and then we'll do our final review.

So are we all on the same page? Let's see it work, and then we'll do our final review. John Doe, run it, and there we go. So now you're starting to understand why it's necessary to use X model. It's when we require two-way data binding. So to finish up our final review, one last time, we have a form, and we have an input that is bound to form.name. This object is going to be sent with our AJAX request to the server. Next, we listen for when the user submits the form, and when they do, we prevent the typical default action of the form and instead call a method of our own called submit.

Next, we listen for when the user submits the form, and when they do, we prevent the typical default action of the form and instead call a method of our own called submit. submit uses the JavaScript Fetch API. It's native to the browser. Anyways, we make a POST request while sending through the relevant data from the form that we have bound to this object. Then once it has resolved and we have a response, we save the user. Now down at the bottom, we check, well, if we have a user, if that's truthy, only on that condition should we display a div.

that condition should we display a div.