A lot of advanced features on our website depend upon the full canonical URL of your site, including the domain use for deployment. For this purpose, setting up a variable that gives you your site base, URL, can greatly simplify your code. Here are the requirements for this base URL. During development, we wanted to be HTT P local host 3000. For our preview environments, we want it to be HST PS, along with the generated preview URL. And for production we want it to be HST TPS, along with the domain where we are deploying our site. How you arrive at the final URL will depend upon how you are managing the environment variables

for your delivery pipeline. So let's demonstrate the process with versal. Versal automatically provides a number of variables to our application. The first one that we will use is versal N, which will either be production, preview, or development. If this value is development, it'll mean that we are running it locally and therefore we will use local host 3000. However, if it is preview, then we will use the generated URL that Versal provides in the environment variable called Versal, URL. And finally, if it is production, we can get the production configured URL by using Versal project production URL. Note that these environment variables can also be used

with the next underscore public prefix, allowing them to be used from the front end. To get access to these variables in our code, we go into the environment variable settings for our project, and ensure that it is automatically exposing system environment variables. We will export this base URL variable from its own module in the lib folder. First up, we check the CEL N and if it is not defined, it probably means that we haven't pulled down the environment variables and we assume that we are in development. Similarly, if it is explicitly marked as development, then of course we are in development

and in these cases we use http, local host 3000. Next up, if the environment is preview, then we use the Versa URL that is generated for that preview environment with HTT PS. And finally, we assume that we are in production and therefore we use HT DPS project production URL. And that's it. We have set up our base URL and you will be able to find this code in the lesson description as well. Let's prove that it's working as expected by displaying its value in a simple client page. We know that client components are initially render on the server and then also run on the client for hydration.

So if the variable is displayed correctly on our page, we know that it is working for both server and client code. We import the base URL variable, and then within our page we render a simple heading along with the value contained within the variable. First up, let's verify there's working correct locally, and as you can see, it's working as expected. Next up people code to GitHub, which will kick off a deployment. And once that is complete, let's visit our production website. And over here as well, you can see that it is working perfectly fine. The final thing that we have to test is a preview environment, and for that we create a pull request and wait for the preview environment to be created.

And once that is done, we visit that preview link. And here you can see the base URL is a generated URL that points to this preview environment.