This section was mainly about
how to fetch data in a Next.js application.
But I also want to mention
something about configuration.
When we call the CMS for example,
we defined a "CMS_URL" property in this file.
But this is currently pointing to "localhost"
because we're running our Strapi server locally.
When we run our app in production
we may want the Next.js app to connect
to a different "CMS_URL",
pointing to a production instance of Strapi.
Using different configuration for different environments
is a very common requirement.
And Next.js provides support for that
using environment variables.
We can use ".env" files
to define variables, such as this "DB_HOST",
and then in our JavaScript code
we can get the value of that environment variable
as "process.env.DB_HOST".
"process.env" in Node.js gives us access
to all the environment variables.
So in our app we can start by creating
a new file at the top-level,
called ".env".
And here we can write variables,
using a simple "NAME=value" syntax.
For the CMS_URL we can simply copy
the existing address.
And that's it. We can now read
that environment variable in our code
as "process.env.CMS_URL".
We're actually getting an error now,
and that's because
that environment variable will not be defined yet.
".env" files are not reloaded automatically,
so every time we change our configuration
we need to manually restart the dev server.
You can see that our app is now working again.
Now, if you prefer you can also use
the object destructuring syntax here.
It's the same thing of course.
So this is how we can define an environment variable.
But what about having different configuration
in different environments?
Let's say that we only want to use this
"localhost" URL when running the app locally.
But when running in production
our app should connect to "api.example.com".
Now, that's just an example of course.
If we restart our dev server
our app will not work
because "api.example.com" doesn't exist.
But we can tell from the error
that our app is trying to connect to that URL.
Now, if we want a different configuration
for when we run the app locally
we can create another file called ".env.local".
And whatever we put in here will override
the values defined in the default ".env" file.
So I'm going to paste our original CMS_URL here.
And if we restart the dev server again,
so it will read the new configuration files,
our app is working again,
which means it's connecting to the "localhost" URL.
Because what we have in ".env.local"
overrides what's in ".env".
Now, another thing we may want to make configurable
is the "revalidate" time we set in the HomePage,
and also in the ProductPage, in "getStaticProps".
If we extract this into an environment variable
we can also be sure that
we use the same setting in all the pages.
And by default we can set it to 300 seconds,
which means 5 minutes.
So that's what will be used in production.
But we can override this locally
and set it to 30 seconds for testing.
Now we need to actually use
that environment variable in our code.
So that's "process.env.REVALIDATE_SECONDS".
But there's something we need to be careful about:
this value is a "string".
However Next.js expects "revalidate" to be a number,
so we need to parse the string into an integer.
Remember that environment variables
are always string values,
so you need to convert them when necessary.
Now, let's use the same in our ProductPage as well.
And this should do.
To test it we'll need to run a production build.
If we look at the output
it does show "30 Seconds" as the ISR setting.
So that's working fine.
30 seconds is what we defined in ".env.local".
Let me restart the dev server,
and check that the app is still working.
Ok. So what's in ".env" gets overriden
by what's in ".env.local".
But we don't have to redefine all variables here.
If we don't want to override the CMS_URL for example
we can just remove it from here,
and let me put the value that works in ".env".
If I restart the dev server now
it will use the value in ".env" of course.
The final thing I want to mention is that
you should check this ".env" file
into version control.
Because it contains the default settings
that should be used in most environments.
But you should not keep your
".env.local" in version control,
because these settings should only be used
on your local machine.
You don't want them to be included
when you deploy to production.
If you use Git, this means ".env.local"
should be in your ".gitignore" file,
while ".env" should not be in ".gitignore".
When you generate a project with Create Next App
it already includes a ".gitignore" file
with the right rules,
so you don't have to worry about that.