WEBVTT 00:00.350 --> 00:04.520 Okay, so we've got ourselves a nasty little warning and a problem to solve, but this one's pretty 00:04.550 --> 00:05.210 straightforward. 00:05.210 --> 00:08.870 As I mentioned, cause is a browser security policy. 00:08.870 --> 00:20.570 And our server, our API server, needs to specify what is allowed to request data and cause effectively 00:20.570 --> 00:28.220 means that our API server needs to return a header to our client to say that it's allowed to request 00:28.220 --> 00:33.500 resources from the server, and the browser respects that header, and it will prevent the data from 00:33.500 --> 00:36.410 being loaded if that header is not provided. 00:36.410 --> 00:41.390 And we're coming from a different origin to where our API server is running from. 00:41.390 --> 00:46.850 So this is running on localhost 5001 and this is running on localhost 3000. 00:46.880 --> 00:50.570 Different origins means that we need to provide this cause header. 00:50.570 --> 00:53.900 So let's go back to our API and do this. 00:53.900 --> 00:59.120 And when I'm talking about the headers by the way if I take a look at the network request that's going 00:59.120 --> 01:03.130 to our server, we can see that we've got and we've got two requests. 01:03.160 --> 01:11.170 Actually, something else to discuss as well is the fact that we're making two identical requests to 01:11.200 --> 01:12.790 our API server. 01:12.820 --> 01:18.400 Now, this is a development feature, and I'll mention it now quite briefly, because it's something 01:18.400 --> 01:23.890 that's going to or we'll see in the short term, but we won't be affected by it in the long term. 01:23.890 --> 01:29.260 One of the things we looked at a little while ago is in our main.ts. 01:29.470 --> 01:31.180 We've got strict mode enabled. 01:31.240 --> 01:38.380 Now, one of the development tests that react does as we're writing our code, when we're using a Useeffect 01:38.410 --> 01:44.650 to ensure the cleanup function, which we do not have inside here, is running effectively, then when 01:44.650 --> 01:49.690 we're in strict mode, this useeffect is going to be called when our component first renders, but then 01:49.690 --> 01:52.990 it's immediately going to execute inside here. 01:52.990 --> 02:00.820 If we had, for instance, a return statement that did something after our component is dismounted or 02:00.820 --> 02:06.090 disposed of, then that return statement would be called and any cleanup functions that we need in there 02:06.090 --> 02:07.470 could be executed. 02:07.500 --> 02:10.320 Now we don't have a return statement or a cleanup function. 02:10.320 --> 02:16.170 So what's happening is in development mode, the use effect gets called the return statement. 02:16.170 --> 02:20.280 If present gets executed, but then immediately it calls the use effect again. 02:20.280 --> 02:25.290 So it looks like we're going out to get our data twice, which we are doing whilst in development. 02:25.290 --> 02:27.000 But this doesn't persist in production. 02:27.000 --> 02:31.800 In production mode, when in production mode, this is only executed once. 02:32.100 --> 02:37.680 And the return statement if we provided it would be executed when the component is disposed of. 02:37.710 --> 02:41.490 But it's not something that's causing us any problems or anything that we need to worry about right 02:41.490 --> 02:41.970 now. 02:41.970 --> 02:46.350 What I wanted to do was show you the network tab in Chrome development tools. 02:46.350 --> 02:47.100 As a developer. 02:47.130 --> 02:53.430 Now you're going to spend your time troubleshooting, possibly inside the console, to see what's going 02:53.430 --> 02:58.860 on in the logs in terms of errors, and also the network tab to see what you are sending up to the API 02:58.890 --> 02:59.550 server. 02:59.580 --> 03:01.620 Please don't try and troubleshoot like this. 03:01.620 --> 03:06.860 When you see a problem and you're expecting products to come back if you're refreshing your browser 03:06.860 --> 03:11.210 and you're saying, hey, where's my products, then this is not good enough information to work with. 03:11.240 --> 03:16.790 As a software developer, you're going to spend your time in developer tools, and these tools are the 03:16.790 --> 03:23.090 console in Chrome developer tools, and also the network tab so that you can see what's going on with 03:23.090 --> 03:25.310 the requests that are going to our API server. 03:25.310 --> 03:29.930 And if we take a look at the products and we take a look at the headers, then we can see that we have 03:29.930 --> 03:30.740 response headers. 03:30.740 --> 03:34.400 This is what's coming back from our API as part of the response. 03:34.400 --> 03:36.080 And then we've got our request headers. 03:36.080 --> 03:40.130 What's going out from our react application to our API server. 03:40.130 --> 03:42.590 So we're missing a header in the response. 03:42.590 --> 03:49.280 Effectively that tells our browser that we're okay to get data from this location. 03:49.280 --> 03:54.500 So we need to set that up inside our program classes where we're going to do this. 03:54.500 --> 03:56.480 So back to Solution Explorer. 03:56.480 --> 04:02.060 And we're going to go to our Program.cs as this is where we enable our Cors policies. 04:02.060 --> 04:03.920 Now there's two parts to this. 04:03.920 --> 04:08.290 We need to add Cors as a service inside the services container. 04:08.290 --> 04:10.420 And we also need to add middleware. 04:10.450 --> 04:17.740 Now middleware is something that affects our HTTP request or the HTTP response as it comes through the 04:17.740 --> 04:18.340 pipeline. 04:18.340 --> 04:23.800 Then we need a bit of middleware to do something with the request on its way out, so that we can add 04:23.800 --> 04:25.390 the appropriate Cors header. 04:25.420 --> 04:29.200 So the first part then we're going to say builder dot services. 04:29.200 --> 04:33.910 And then we just use the add Cors to add the appropriate service. 04:33.910 --> 04:38.140 And the next part is simply to add the Cors middleware. 04:38.170 --> 04:42.010 Now ordering does become important in this part. 04:42.040 --> 04:46.810 So there are occasions where if we get the ordering incorrect then that can cause us quite a confusing 04:46.810 --> 04:47.980 problem to solve. 04:47.980 --> 04:52.720 So whatever I'm doing now, all I'm suggesting is you put it in the same place that I'm going to put 04:52.720 --> 04:55.990 it in, then you're setting yourself up for success. 04:55.990 --> 05:01.450 And in fact, the appropriate place to add this particular header is at the top at the moment. 05:01.450 --> 05:02.560 So we're going to say app. 05:02.590 --> 05:06.550 And we use use Cors here. 05:07.120 --> 05:10.110 And then we provide this with an expression. 05:10.110 --> 05:11.190 We give it some options. 05:11.190 --> 05:13.680 So I'm going to say opt add the arrow. 05:13.680 --> 05:17.670 And then on the next line we add the options we want to add. 05:17.670 --> 05:24.660 And by the way there's a slight difference in conventions between C sharp and JavaScript. 05:24.660 --> 05:30.120 In JavaScript we typically start the curly bracket on the same line here like so. 05:30.120 --> 05:31.860 But in C sharp world. 05:31.860 --> 05:33.420 Then this is the convention. 05:33.420 --> 05:38.070 We start the curly bracket for a code block on the next line. 05:38.100 --> 05:41.580 I wish it was consistent across every language, but it isn't. 05:41.610 --> 05:46.410 Each language has their own conventions, and it's just something that you will get used to as you write 05:46.410 --> 05:47.310 more and more code. 05:47.310 --> 05:50.040 So the options we need here I'm going to specify opt. 05:50.070 --> 05:52.470 And I'm just going to say that we're going to allow any header. 05:52.500 --> 05:57.090 Any header is allowed from our different origin. 05:57.090 --> 05:59.220 We're also going to say allow any method. 05:59.220 --> 06:01.560 So get post put etc.. 06:01.560 --> 06:08.730 But then we're going to specify with origins and we're going to specify https in this case colon forward 06:08.730 --> 06:13.970 slash forward slash Local host colon 3000. 06:14.000 --> 06:16.880 Now that's the address of our client application. 06:16.880 --> 06:17.840 And look at this. 06:17.840 --> 06:19.130 This is another string. 06:19.190 --> 06:24.530 This is another opportunity to make a typo that your compiler is not going to tell you about. 06:24.530 --> 06:27.650 So please be accurate when using strings. 06:27.680 --> 06:33.080 Now while this has solved our problem, well, no, because we don't have our client application running 06:33.080 --> 06:34.940 on Https just now. 06:34.940 --> 06:39.350 But there's a very easy way to enable Https on our client application. 06:39.350 --> 06:46.190 We can use a plugin for V8 that's going to use a utility called Make cert MQTT. 06:46.820 --> 06:54.620 And this particular utility will effectively set up a local certificate authority on our own machine, 06:54.650 --> 07:01.040 tell our computer to trust this local authority and then issue a certificate to our client application, 07:01.040 --> 07:03.440 which will then be trusted by the browser. 07:03.440 --> 07:07.850 So we don't need to do much to enable this, but we do need to open up the terminal. 07:08.360 --> 07:13.060 And I'm just going to open up a new tab inside here to install things. 07:13.060 --> 07:18.820 Please be inside your client folder at this stage because we need to install something into our client 07:18.820 --> 07:19.900 project. 07:19.900 --> 07:25.420 And I'm just going to check to see if I have the make cert utility on my computer already I do not. 07:25.450 --> 07:27.940 Okay, so I'm starting from a clean place. 07:28.090 --> 07:30.520 So I'm going to say npm install. 07:30.730 --> 07:36.190 And we need Veet dash plugin dash mk cert. 07:36.220 --> 07:39.370 And we want this as a developer dependency. 07:39.370 --> 07:41.290 So we're going to say dash D. 07:41.290 --> 07:47.440 And this will ensure that this package gets located in our developer dependencies, which means it's 07:47.440 --> 07:53.650 not going to be compiled into our production version of the application because it's not needed in production. 07:53.650 --> 07:56.560 So I'm going to press return to get that installed. 07:56.560 --> 07:59.350 And great, that has now been installed. 07:59.350 --> 08:00.940 So how do we use this then. 08:00.970 --> 08:03.340 Well we need to go to our Veet configuration. 08:03.340 --> 08:06.430 So let's go back to the file and folder Explorer view. 08:06.670 --> 08:11.440 And we'll open up our config TS. 08:11.590 --> 08:14.890 And inside here we need to add an import. 08:14.890 --> 08:22.570 And we're going to say import MQTT from and we're going to get it from Veet plugin make assert. 08:23.080 --> 08:26.980 And then we can add this as an additional plugin. 08:27.010 --> 08:31.150 So I'm going to say make certs and execute this with parentheses. 08:31.210 --> 08:33.250 Now we're going to need to restart our server. 08:33.250 --> 08:36.190 And we'll probably need to get past a little bit of security here. 08:36.190 --> 08:42.040 Because what we're doing is going to affect our authority inside our local machine. 08:42.040 --> 08:46.660 So I'm just going to open up the terminal, go to where our client app is. 08:46.690 --> 08:52.660 And it says that the V config has changed restarting server. 08:53.140 --> 08:56.770 And I'm surprised I wasn't asked for any security there. 08:56.770 --> 09:00.520 So I'm just going to stop this and rerun npm run dev. 09:00.550 --> 09:01.540 That looks fine. 09:01.540 --> 09:08.110 It looks like I'm running on https now, and if I copy this URL, go back to my browser and paste in 09:08.110 --> 09:10.810 this and press return. 09:11.050 --> 09:18.800 Then it looks like I have access in a way, because I've got the connection is secure. 09:18.800 --> 09:23.360 So the certificate is working, but the course configuration is not yet working. 09:23.360 --> 09:31.760 So sometimes, and this catches me out quite frequently, is the hot reload in our API side of things 09:31.790 --> 09:35.630 is not as effective as the hot reload on the client side of things. 09:35.630 --> 09:42.950 So inside the API server, let's just use controller to restart the API server. 09:43.250 --> 09:47.300 And this should resolve our problem when we make a change to our middleware. 09:47.330 --> 09:49.850 Then typically that requires a server restart. 09:49.850 --> 09:53.390 And it looks like that is the case in this case. 09:53.420 --> 09:56.750 And I've given this a few seconds and not much is happening. 09:56.750 --> 09:57.770 It still says building. 09:57.770 --> 10:03.680 I'm going to use the control C approach, I think, and shut this down and restart it. 10:03.680 --> 10:07.280 It wasn't happy with my use of controller there. 10:07.310 --> 10:07.820 Okay. 10:07.850 --> 10:12.170 So let's give this or let's use dotnet watch to restart this. 10:12.170 --> 10:17.620 I was hoping that hot reload would be a better experience in dotnet nine, but, um, it doesn't appear 10:17.620 --> 10:19.240 to be the way yet. 10:19.270 --> 10:20.440 Maybe dot net ten. 10:20.470 --> 10:25.720 Let's look forward to dot net ten and an improved hot reloading experience anyway. 10:25.750 --> 10:28.540 Now let's restart it if I do refresh the page now. 10:28.780 --> 10:30.880 Now we're getting our products from the API. 10:30.910 --> 10:36.310 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, 10:36.340 --> 10:39.340 then we can see that we've got the appropriate response header here. 10:39.340 --> 10:47.170 The access control allow origin for the address that our client application is running on. 10:47.170 --> 10:48.430 So that's what we're looking for. 10:48.430 --> 10:51.850 We're looking for our list of products being returned from our server. 10:51.880 --> 10:53.050 Marvellous. 10:53.080 --> 10:58.600 So we've been writing our application using TypeScript but we haven't really talked about it yet and 10:58.600 --> 11:03.340 why we're using it in this project rather than just using plain old JavaScript. 11:03.340 --> 11:08.470 And in the next lesson, I just want to give you a few reasons why we're using TypeScript, because 11:08.470 --> 11:13.930 I think most developers now have accepted TypeScript as the way forward, rather than just using JavaScript. 11:13.960 --> 11:18.550 So in the next lesson, we're going to start talking about TypeScript and how we implement that into 11:18.550 --> 11:19.780 our application.