Okay, now let's take a look at creating a production build of our react application.
And our goal of this is we're going to effectively build and compile our application into physical files.
And where we're going to output these files to is actually our API folder.
We're going to use our dotnet kestrel server, the web API server to host our client application.
And when I say host, what this is effectively going to do is when our client browser goes to localhost
5001, we're going to configure our API to return the contents of a root folder.
And the client will effectively download our react application and then use that downloaded code.
So to accomplish this we need to go to inside our client folder.
We need to go to our vite config dot js.
And inside our config we can specify a build property open curly brackets and add the comma layer.
And we can specify an output directory.
And we're going to output this to period.
Period.
Forward slash API forward slash ww w root.
So that's fairly straight forward.
What we also want because we've got an.
Dot e env file that we're using for certain configuration.
The API URL and the white stripe publishable key will also have a production version of this configuration
as well.
So I'm just going to right click the client folder say new file and say dot env dot production.
And this production version of this file will be used when we're running our application in production
mode.
And because this is a client side app, whether or not we add this to git, ignore doesn't particularly
matter for this application, but we can always add it if we want to.
We might as well we've added our developer configuration there, so we can just go to our Source control
tab and we can add this to git ignore.
So it's not going to be stored in with our other files inside GitHub.
So back to Folder Explorer and back to our env dot production.
Let's just open up the dot env file as well because we might as well copy what we currently have here.
So I'm just going to control a control C and paste this into env production.
We'll keep the stripe publishable key as it is.
We don't have a different one for production for that.
And we can effectively take out https localhost 5001 here.
So our production API url is simply forward slash API, because our client application is going to be
hosted with the API.
The.
Net API.
Then all we need to do is go to it's relative path when we make a request to our API from the client.
Another thing we want to look at if we go to our base API, then inside here we have a delay, which
of course is fine whilst we're developing our application, but we don't really want that to happen
when we're running in production.
So we can check to see which mode we're running in and if we're running in production, then we will
not add a fake delay.
So we're going to check and we're going to say if import dot meta dot EMV dot.
And then we can choose dev.
Then we will sleep effectively.
And of course when we're in production we're not going to see that fake delay.
So our application, especially when running locally is going to be pretty fast.
So let's take a look at what's going to happen if we build our application.
So I'm just going to open up the terminal.
And I've left this for a while.
So I'm going to stop the stripe client for the time being.
And I'm going to go to our tab where we've got our client, and I'm just going to stop this application.
Looks like plenty of logs have been going on there, so I'm just going to Ctrl C and stop this.
And what we're going to run to effectively build our application.
If we go to package.json then we have a number of scripts and inside our build scripts then it's going
to use the V8 build command, as well as use the TypeScript compiler to effectively compile our application
into JavaScript, use the V8 build command, and then it's going to output these files into our API
folder.
So let's go take a look and see what happens when we run npm run build.
And I'll press return.
And okay, so it looks like we've got our files built here.
And if we take a look we can see what's been created inside the API root folder.
And all of the files that make up our client side application, we've got a warning about some chunks
are larger than 500kB after minification.
Consider using dynamic import, etc. and or.
We could also adjust the chunk size limit to effectively remove this warning.
Now after gzipping, this is going to be output as 237kB, which is fine for a client side application,
so I'm not going to worry about it being slightly higher than the 500 kilobyte warning.
But I will actually turn off that warning because I'm not a big fan of warnings that I'm not going to
do anything to fix.
And also, we've got this use empty output directory to override because of the location of where we're
outputting these files.
So a couple of tweaks that we're going to make to our configuration.
If we go back to the vets config file then inside our build section here we'll add a chunk size warning
limit.
And I'm going to set this to 102 for for a megabyte.
And I'm also going to use the empty output directory and specify this is true.
And if we go, take a look.
In fact, before we run that command again I just want to demonstrate what happened inside our API folder.
We've now got a root folder.
Inside here is an assets folder with all of our different assets that the client will download.
We've got our images that are literally copied as are from the public folder.
And we've got our index.html.
And because it's a single page application, this is the single page that the client would request.
And we've got our assets and index.js effectively.
And our CSS.
And what we have here is referred to as output hashing.
So when we rebuild our application we'll have a different hash for our JavaScript file.
And what that means is that the browser would typically try and cache any static assets that it receives.
And JavaScript and CSS, they're static assets.
So if we do update our Data application, then we would like a different hash so that the browser,
when requesting this index.html file will say aha, I don't have that JavaScript file in my cache because
it's going to have a different name because of this output hashing.
And it would go and fetch the updated version of that JavaScript file and then cache that in the browser.
So we've made a couple of changes to our config.
So let's go and rerun the build command.
And I'll just use npm run build again.
And this time we should get our output clean without any warnings.
And sure enough that is the case.
And if we had any code changes then the JavaScript file would be updated.
But because we haven't actually made any code changes, then it's using the same JavaScript file.
So that's fine.
Great.
So now we have our react application effectively published to our API.
Next we'll take a look at how we can run that application from our API.