Original subtitles

Before we declare this forum finished and move on to authentication, I would like to display a message

to the user to let them know their submission is currently in progress.

The validate doesn't provide anything to help us with this, but we can accomplish this with tailwind.

The goal for this lecture is to render a waiting message to the user.

Submitting a request can take a while.

We'll want to let the user know we're processing their request.

Alert boxes are a great way to communicate that.

Let's get started.

Open the authentication component file in your editor.

The first step is to create some data.

We want to be able to store the variant message and visibility of the alert box.

We can store this inside the state, but the data we're creating will be used in the authentication

component.

The data won't be used globally.

It's not something we need to clutter our state with.

If you prefer to define the data in the state, then that's fine.

Inside the data function, create a property called registration and submission with a value of false.

The first property we're creating will keep track of.

If the registration form is in submission, we'll want to disable the form if the request is still processing.

I'll expand on why this is important to keep track of later in the lecture.

Afterward, we'll create a property called Registration Show Alert with a value of false.

Initially, we will want to hide the alert box.

We will use this property to toggle its visibility by default.

We'll leave it at false.

The next property will create will be called registration alert variant with the value of BG Blue 500.

We are going to have different colors of the alert box.

We are going to be using the color blue to indicate the form submission is in progress.

You'll see how this class will affect our alert box in a moment.

Let's keep going.

The last property we're going to create is the message.

We'll call it registration alert message.

Set it to the following.

Please wait.

Your account is being created.

The message property will be used for the inner content of the alert box.

We'll be changing this to let the user know the status of their form submission.

The properties are ready.

The next step is to add an alert box to the template.

Scroll to the top of the registration form in the template.

We're going to add a div tag.

It'll have the following classes.

Text White Text center font bold p for rounded and B for.

You can refer to the Tailwind documentation for information about these classes.

It'll give us a box with spacing to display the alert message.

We're going to bind our properties to this element.

First, we're going to hide the element with the V.

If directive, the condition will be the registration show alert data property.

Next, we'll change the color of the background, color of the box.

We'll bind a class attribute to the registration alert variant data property.

Lastly, we'll output the message by adding an expression inside the div tag will output the registration

alert message data property.

We're finished prepping the component in the template.

The next thing we'll want to do is to disable the submit button if the form is currently in submission.

Scroll to the bottom of the form elements to find the submit button.

Will bind the disabled attribute to registration in submission.

It's crucial we do this.

One of the most overlooked steps for beginner developers is not to take into account of spam submissions.

They are users out there that will submit a form repeatedly, even if the first submission worked.

This behavior can turn out to be costly because more requests mean more resources are taken up, which

will result in higher production costs.

This may not seem like a big deal at first because it's one form.

Let me show you an example of how disastrous this can become in the resource section of this lecture.

I provide a link to an article about a company that spent $30,000 in 72 hours due to an error in their

code.

I recommend giving this a good read.

In summary, they didn't properly account for the number of requests made to their database.

By overlooking one small part of their code, they incurred large expenses.

The situation is different, but the overall lesson is still the same.

You always want to make sure that you never allow the user to make excessive requests.

One simple method of preventing excessive requests is by disabling the form until the submission is

complete.

It's not foolproof.

There are ways to bypass or override the behavior we created.

At this point, it's usually left to the server or back end developers to handle excessive requests.

This will stop the most basic types of attacks or accidents we may face when our application is deployed

to production.

By default, the in submission data property will be set to false.

This value will make the button clickable.

We're finished with modifying the template.

We have the data ready and the data is hooked up to the template.

The very last step is to update the data in the register function.

The register function is where the request will be handled.

Scroll to the register function and the component.

If there is any code in the register function, remove it.

We'll want to start with a clean slate.

Inside the function, we're going to set the registration show alert and registration in submission

properties to.

True.

The show Alert Property is responsible for toggling the alerts visibility, whereas the in submission

property will disable the form button.

Up next lets set the variant property to be G blue 500.

We're doing this because we need to reset the variation.

Wallet's in submission.

In some instances the user may have already submitted the form.

We'll change the variant depending on if the request was a success or not.

Either way, if they're submitting the form again, we'll need to reset it.

This same logic applies to the message.

We'll need to reset the message property.

We're done setting the initial state of the alert component.

The next step is to begin submitting the request.

We'll handle that in the next section.

There's one less thing I want to do.

I want to create a dummy response.

The code for submitting a request is something we'll write in the next section.

In the meantime, we're going to tell the user that the request was a success.

We'll set the registration alert variant property to be G Green 500.

Next, we'll set the message property to the following success.

Your account has been created.

We aren't going to enable the button again because we'll want to redirect the user after their account

has been created.

We'll worry about that later.

The last thing we'll do is log the values parameter.

Save your changes and view the app in the browser.

Open the console to inspect for any errors.

There shouldn't be any so far.

Try filling out the form and then submit it.

Will receive a success message after submitting the form, the button will remain disabled since we

didn't toggle the value back to false, we're finished to review everything.

All we did was use the alert component to render the status of the user's submission.

We created four properties for disabling the button, showing the alert, changing the variant and the

message inside.

Communicating the current status of the submission provides for a better user experience.

In the next lecture we'll start working on the login form.