Now that we bound the form field values
to component state variables,
it's time to actually call the API
when the form is submitted.
Let's quickly remind ourselves
of how a Strapi login request works.
We need to send a POST request to "/auth/local"
sending "identifier" and "password" in the body,
and we get back a response
that includes a JSON web token.
We basically need to do the same
but in JavaScript code.
So let's copy this URL,
and, to make an HTTP request
remember that we already wrote a "fetchJson" function
that takes care of checking for errors
and parsing the JSON response.
So when the user clicks "Sign In"
we can call "fetchJson",
that should be imported,
with the URL we copied earlier.
Now, the problem is that in this case
we're not making a simple GET request.
We need to make a POST request,
set the "Content-Type" header,
and send some JSON in the body.
Our "fetchJson" function currently
doesn't allow us to do that.
But that's easy to change.
When we call "fetch" we can pass
an optional second argument
that here is called "init",
but is basically the request options.
So we could simply accept a second parameter here,
that I'll call "options",
and pass it straight to "fetch".
This way when we call "fetchJson"
we can pass any options supported by the Fetch API.
In this object we can set the HTTP method
to be "POST".
Then we need to set some "headers",
or in fact just one header
that is the 'Content-Type',
with a value of "application/json".
Finally we want to pass a "body"
that should be a JSON string,
so we can call "JSON.stringify()".
Here we can pass an object
with the properties expected by Strapi,
that are "identifier" and "password".
Where the "identifier" can be the email.
So let's set "identifier" to the value
of our "email" state variable,
and then for the "password"
we can use the short-hand property syntax,
since it has the same name as our existing variable.
Ok. Now, "fetchJson" is "async"
so we can get the "response" by "awaiting".
And for now let's just log the response,
so we can see it in the browser console.
Good. We're ready to test this API request.
Let's enter "alice@example.com" as the email,
and "Alice123" (with a capital A) as the password,
click "Sign In",
and we can see the response logged in the console.
It has a token and the user details
as we expected.
So this is working fine,
as long as we enter the right credentials.
Now, some of you may be thinking
we defined a CMS_URL environment variable
earlier in the course.
Why don't we use that variable here,
instead of hard-coding the full URL?
The problem is that this code runs on the client side,
and environment variables by default
are only visible to server side code.
If we try logging that CMS_URL variable
when we trigger a form submission,
you can see that its value is "undefined".
Now, Next.js does provide a way
to make environment variables available
to client side code as well,
and that is to prefix them with "NEXT_PUBLIC".
So if we called this "NEXT_PUBLIC_CMS_URL"
then it would work in this code.
But I'm not actually going to do that because
(spoiler alert) later on we're going to
change this code anyway.
So we'll leave the URL
hard-coded to "localhost" for now.
Ok. Now, the next thing we need to think about
is: what happens if the user types the wrong password?
I entered "x" as the password.
And what happens is that we see
an "Unhandled Runtime Error".
Which is of course not something
we want to show to our users.
We'll want to handle this case better,
and display some nicer error message in our page.
We'll take care of that in the next video.