Okay, so we've got ourselves a nasty little warning and a problem to solve, but this one's pretty
straightforward.
As I mentioned, cause is a browser security policy.
And our server, our API server, needs to specify what is allowed to request data and cause effectively
means that our API server needs to return a header to our client to say that it's allowed to request
resources from the server, and the browser respects that header, and it will prevent the data from
being loaded if that header is not provided.
And we're coming from a different origin to where our API server is running from.
So this is running on localhost 5001 and this is running on localhost 3000.
Different origins means that we need to provide this cause header.
So let's go back to our API and do this.
And when I'm talking about the headers by the way if I take a look at the network request that's going
to our server, we can see that we've got and we've got two requests.
Actually, something else to discuss as well is the fact that we're making two identical requests to
our API server.
Now, this is a development feature, and I'll mention it now quite briefly, because it's something
that's going to or we'll see in the short term, but we won't be affected by it in the long term.
One of the things we looked at a little while ago is in our main.ts.
We've got strict mode enabled.
Now, one of the development tests that react does as we're writing our code, when we're using a Useeffect
to ensure the cleanup function, which we do not have inside here, is running effectively, then when
we're in strict mode, this useeffect is going to be called when our component first renders, but then
it's immediately going to execute inside here.
If we had, for instance, a return statement that did something after our component is dismounted or
disposed of, then that return statement would be called and any cleanup functions that we need in there
could be executed.
Now we don't have a return statement or a cleanup function.
So what's happening is in development mode, the use effect gets called the return statement.
If present gets executed, but then immediately it calls the use effect again.
So it looks like we're going out to get our data twice, which we are doing whilst in development.
But this doesn't persist in production.
In production mode, when in production mode, this is only executed once.
And the return statement if we provided it would be executed when the component is disposed of.
But it's not something that's causing us any problems or anything that we need to worry about right
now.
What I wanted to do was show you the network tab in Chrome development tools.
As a developer.
Now you're going to spend your time troubleshooting, possibly inside the console, to see what's going
on in the logs in terms of errors, and also the network tab to see what you are sending up to the API
server.
Please don't try and troubleshoot like this.
When you see a problem and you're expecting products to come back if you're refreshing your browser
and you're saying, hey, where's my products, then this is not good enough information to work with.
As a software developer, you're going to spend your time in developer tools, and these tools are the
console in Chrome developer tools, and also the network tab so that you can see what's going on with
the requests that are going to our API server.
And if we take a look at the products and we take a look at the headers, then we can see that we have
response headers.
This is what's coming back from our API as part of the response.
And then we've got our request headers.
What's going out from our react application to our API server.
So we're missing a header in the response.
Effectively that tells our browser that we're okay to get data from this location.
So we need to set that up inside our program classes where we're going to do this.
So back to Solution Explorer.
And we're going to go to our Program.cs as this is where we enable our Cors policies.
Now there's two parts to this.
We need to add Cors as a service inside the services container.
And we also need to add middleware.
Now middleware is something that affects our HTTP request or the HTTP response as it comes through the
pipeline.
Then we need a bit of middleware to do something with the request on its way out, so that we can add
the appropriate Cors header.
So the first part then we're going to say builder dot services.
And then we just use the add Cors to add the appropriate service.
And the next part is simply to add the Cors middleware.
Now ordering does become important in this part.
So there are occasions where if we get the ordering incorrect then that can cause us quite a confusing
problem to solve.
So whatever I'm doing now, all I'm suggesting is you put it in the same place that I'm going to put
it in, then you're setting yourself up for success.
And in fact, the appropriate place to add this particular header is at the top at the moment.
So we're going to say app.
And we use use Cors here.
And then we provide this with an expression.
We give it some options.
So I'm going to say opt add the arrow.
And then on the next line we add the options we want to add.
And by the way there's a slight difference in conventions between C sharp and JavaScript.
In JavaScript we typically start the curly bracket on the same line here like so.
But in C sharp world.
Then this is the convention.
We start the curly bracket for a code block on the next line.
I wish it was consistent across every language, but it isn't.
Each language has their own conventions, and it's just something that you will get used to as you write
more and more code.
So the options we need here I'm going to specify opt.
And I'm just going to say that we're going to allow any header.
Any header is allowed from our different origin.
We're also going to say allow any method.
So get post put etc..
But then we're going to specify with origins and we're going to specify https in this case colon forward
slash forward slash Local host colon 3000.
Now that's the address of our client application.
And look at this.
This is another string.
This is another opportunity to make a typo that your compiler is not going to tell you about.
So please be accurate when using strings.
Now while this has solved our problem, well, no, because we don't have our client application running
on Https just now.
But there's a very easy way to enable Https on our client application.
We can use a plugin for V8 that's going to use a utility called Make cert MQTT.
And this particular utility will effectively set up a local certificate authority on our own machine,
tell our computer to trust this local authority and then issue a certificate to our client application,
which will then be trusted by the browser.
So we don't need to do much to enable this, but we do need to open up the terminal.
And I'm just going to open up a new tab inside here to install things.
Please be inside your client folder at this stage because we need to install something into our client
project.
And I'm just going to check to see if I have the make cert utility on my computer already I do not.
Okay, so I'm starting from a clean place.
So I'm going to say npm install.
And we need Veet dash plugin dash mk cert.
And we want this as a developer dependency.
So we're going to say dash D.
And this will ensure that this package gets located in our developer dependencies, which means it's
not going to be compiled into our production version of the application because it's not needed in production.
So I'm going to press return to get that installed.
And great, that has now been installed.
So how do we use this then.
Well we need to go to our Veet configuration.
So let's go back to the file and folder Explorer view.
And we'll open up our config TS.
And inside here we need to add an import.
And we're going to say import MQTT from and we're going to get it from Veet plugin make assert.
And then we can add this as an additional plugin.
So I'm going to say make certs and execute this with parentheses.
Now we're going to need to restart our server.
And we'll probably need to get past a little bit of security here.
Because what we're doing is going to affect our authority inside our local machine.
So I'm just going to open up the terminal, go to where our client app is.
And it says that the V config has changed restarting server.
And I'm surprised I wasn't asked for any security there.
So I'm just going to stop this and rerun npm run dev.
That looks fine.
It looks like I'm running on https now, and if I copy this URL, go back to my browser and paste in
this and press return.
Then it looks like I have access in a way, because I've got the connection is secure.
So the certificate is working, but the course configuration is not yet working.
So sometimes, and this catches me out quite frequently, is the hot reload in our API side of things
is not as effective as the hot reload on the client side of things.
So inside the API server, let's just use controller to restart the API server.
And this should resolve our problem when we make a change to our middleware.
Then typically that requires a server restart.
And it looks like that is the case in this case.
And I've given this a few seconds and not much is happening.
It still says building.
I'm going to use the control C approach, I think, and shut this down and restart it.
It wasn't happy with my use of controller there.
Okay.
So let's give this or let's use dotnet watch to restart this.
I was hoping that hot reload would be a better experience in dotnet nine, but, um, it doesn't appear
to be the way yet.
Maybe dot net ten.
Let's look forward to dot net ten and an improved hot reloading experience anyway.
Now let's restart it if I do refresh the page now.
Now we're getting our products from the API.
And if I do take a look at one of the requests to go to our API and we do take a look at the headers,
then we can see that we've got the appropriate response header here.
The access control allow origin for the address that our client application is running on.
So that's what we're looking for.
We're looking for our list of products being returned from our server.
Marvellous.
So we've been writing our application using TypeScript but we haven't really talked about it yet and
why we're using it in this project rather than just using plain old JavaScript.
And in the next lesson, I just want to give you a few reasons why we're using TypeScript, because
I think most developers now have accepted TypeScript as the way forward, rather than just using JavaScript.
So in the next lesson, we're going to start talking about TypeScript and how we implement that into
our application.