Different js scripts for different ASP.NET core environments
September 19, 2018 · 3 minute read · Tags: react
When you reference a .js framework or library from your ASP.NET application, it makes sense to use the development version when you’re working on your own machine.
For example, if you bring React.js into your MVC app, you’d want these references…
<script src="https://unpkg.com/react@16/umd/react.development.js" crossorigin></script>
<script src="https://unpkg.com/react-dom@16/umd/react-dom.development.js" crossorigin></script>
Referencing the development versions brings more useful error messages and integration with the React Developer tools.
But, you wouldn’t want to use these in production for performance reasons.
When you run the site in production, you’d want to reference the minified production versions of the React scripts.
<script src="https://unpkg.com/react@16/umd/react.production.min.js" crossorigin></script>
<script src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js" crossorigin></script>
ASP.NET Core Environments to the rescue
ASP.NET Core introduced the concept of “environments”.
You can have different application settings for different environments…
appsettings.json
appsettings.development.json
appsettings.staging.json
This is handy as you can define different connection strings etc. for each one.
Generally speaking, your ASP.NET Core projects will run on your local machine using the Development environment.
You can see this for yourself if you take a look at your project’s launchSettings.json file (in the Properties folder).
"Backend": {
"ASPNETCORE_ENVIRONMENT": "Development"
},
These settings are used when launching your app on your machine (during development).
In production (unless otherwise specified) your apps will run in… yep, the Production environment.
Varying scripts by environment
You can check the current environment in your own c# code and execute different logic accordingly.
The boilerplate startup.cs file that came with your ASP.NET Core app may include an example along these lines…
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseHsts();
}
Turns out, you can use similar checks in your cshtml files.
<head>
<environment include="Development">
<script src="https://unpkg.com/react@16/umd/react.development.js" crossorigin></script>
<script src="https://unpkg.com/react-dom@16/umd/react-dom.development.js" crossorigin></script>
</environment>
<environment exclude="Development">
<script src="https://unpkg.com/react@16/umd/react.production.min.js" crossorigin></script>
<script src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js" crossorigin></script>
</environment>
</head>
The environment tag here is an example of a Tag Helper (new in ASP.NET Core).
Tag Helpers provide a handy way to generate html markup using resources on the server.
The environment tag helper may look like html, but it’s actually executed on the server, where it can check the environment, before the html is generated and returned to the browser.
So, when you inspect the resulting source in the browser, you’ll only see the relevant script references for your environment.
<head>
<script src="https://unpkg.com/react@16/umd/react.development.js" crossorigin></script>
<script src="https://unpkg.com/react-dom@16/umd/react-dom.development.js" crossorigin></script>
</head>
Summary
Now there’s no excuse for inflicting massive unminified .js libraries on your users!
Use the environment tag helper to load small(er) .js files and save everyone’s bandwidth.