AspNetCore.Docs/aspnetcore/client-side/spa-services.md

title	author	description	keywords	ms.author	manager	ms.date	ms.topic	ms.assetid	ms.technology	ms.prod	uid	ms.custom
Using JavaScriptServices for Creating Single Page Applications	scottaddie	Learn about the benefits of using JavaScriptServices to create a Single Page Application (SPA) backed by ASP.NET Core.	ASP.NET Core,Angular,SPA,JavaScriptServices,SpaServices	scaddie	wpickett	08/02/2017	article	4b30576b-2718-4c39-9253-a59966747893	aspnet	asp.net-core	client-side/spa-services	H1Hack27Feb2017

Using JavaScriptServices for Creating Single Page Applications with ASP.NET Core

By Scott Addie and Fiyaz Hasan

A Single Page Application (SPA) is a popular type of web application due to its inherent rich user experience. Integrating client-side SPA frameworks or libraries, such as Angular or React, with server-side frameworks like ASP.NET Core can be difficult. JavaScriptServices was developed to reduce friction in the integration process. It enables seamless operation between the different client and server technology stacks.

View or download sample code

What is JavaScriptServices?

JavaScriptServices is a collection of client-side technologies for ASP.NET Core. Its goal is to position ASP.NET Core as developers' preferred server-side platform for building SPAs.

JavaScriptServices consists of three distinct NuGet packages:

• Microsoft.AspNetCore.NodeServices (NodeServices)
• Microsoft.AspNetCore.SpaServices (SpaServices)
• Microsoft.AspNetCore.SpaTemplates (SpaTemplates)

These packages are useful if you:

• Run JavaScript on the server
• Use a SPA framework or library
• Build client-side assets with Webpack

Much of the focus in this article is placed on using the SpaServices package.

What is SpaServices?

SpaServices was created to position ASP.NET Core as developers' preferred server-side platform for building SPAs. SpaServices is not required to develop SPAs with ASP.NET Core, and it doesn't lock you into a particular client framework.

SpaServices provides useful infrastructure such as:

• Server-side prerendering
• Webpack Dev Middleware
• Hot Module Replacement
• Routing helpers

Collectively, these infrastructure components enhance both the development workflow and the runtime experience. The components can be adopted individually.

Prerequisites for using SpaServices

To work with SpaServices, install the following:

• Node.js (version 6 or later) with npm

  • To verify these components are installed and can be found, run the following from the command line:

  node -v && npm -v
  

Note: If you're deploying to an Azure web site, you don't need to do anything here — Node.js is installed and available in the server environments.

• .NET Core SDK 1.0 (or later)

  • If you're on Windows, this can be installed by selecting Visual Studio 2017's .NET Core cross-platform development workload.

• Microsoft.AspNetCore.SpaServices NuGet package

Server-side prerendering

A universal (also known as isomorphic) application is a JavaScript application capable of running both on the server and the client. Angular, React, and other popular frameworks provide a universal platform for this application development style. The idea is to first render the framework components on the server via Node.js, and then delegate further execution to the client.

ASP.NET Core Tag Helpers provided by SpaServices simplify the implementation of server-side prerendering by invoking the JavaScript functions on the server.

Prerequisites

Install the following:

• aspnet-prerendering npm package:

  npm i -S aspnet-prerendering
  

Configuration

The Tag Helpers are made discoverable via namespace registration in the project's _ViewImports.cshtml file:

[!code-csharpMain]

These Tag Helpers abstract away the intricacies of communicating directly with low-level APIs by leveraging an HTML-like syntax inside the Razor view:

[!code-htmlMain]

The asp-prerender-module Tag Helper

The asp-prerender-module Tag Helper, used in the preceding code example, executes ClientApp/dist/main-server.js on the server via Node.js. For clarity's sake, main-server.js file is an artifact of the TypeScript-to-JavaScript transpilation task in the Webpack build process. Webpack defines an entry point alias of main-server; and, traversal of the dependency graph for this alias begins at the ClientApp/boot-server.ts file:

[!code-javascriptMain]

In the following Angular example, the ClientApp/boot-server.ts file utilizes the createServerRenderer function and RenderResult type of the aspnet-prerendering npm package to configure server rendering via Node.js. The HTML markup destined for server-side rendering is passed to a resolve function call, which is wrapped in a strongly-typed JavaScript Promise object. The Promise object's significance is that it asynchronously supplies the HTML markup to the page for injection in the DOM's placeholder element.

[!code-typescriptMain]

The asp-prerender-data Tag Helper

When coupled with the asp-prerender-module Tag Helper, the asp-prerender-data Tag Helper can be used to pass contextual information from the Razor view to the server-side JavaScript. For example, the following markup passes user data to the main-server module:

[!code-htmlMain]

The received UserName argument is serialized using the built-in JSON serializer and is stored in the params.data object. In the following Angular example, the data is used to construct a personalized greeting within an h1 element:

[!code-typescriptMain]

Note: Property names passed in Tag Helpers are represented with PascalCase notation. Contrast that to JavaScript, where the same property names are represented with camelCase. The default JSON serialization configuration is responsible for this difference.

To expand upon the preceding code example, data can be passed from the server to the view by hydrating the globals property provided to the resolve function:

[!code-typescriptMain]

The postList array defined inside the globals object is attached to the browser's global window object. This variable hoisting to global scope eliminates duplication of effort, particularly as it pertains to loading the same data once on the server and again on the client.

Webpack Dev Middleware

Webpack Dev Middleware introduces a streamlined development workflow whereby Webpack builds resources on demand. The middleware automatically compiles and serves client-side resources when a page is reloaded in the browser. The alternate approach is to manually invoke Webpack via the project's npm build script when a third-party dependency or the custom code changes. An npm build script in the package.json file is shown in the following example:

[!code-jsonMain]

Prerequisites

Install the following:

• aspnet-webpack npm package:

  npm i -D aspnet-webpack
  

Configuration

Webpack Dev Middleware is registered into the HTTP request pipeline via the following code in the Startup.cs file's Configure method:

[!code-csharpMain]

The UseWebpackDevMiddleware extension method must be called before registering static file hosting via the UseStaticFiles extension method. For security reasons, register the middleware only when the app runs in development mode.

The webpack.config.js file's output.publicPath property tells the middleware to watch the dist folder for changes:

[!code-javascriptMain]

Hot Module Replacement

Think of Webpack's Hot Module Replacement (HMR) feature as an evolution of Webpack Dev Middleware. HMR introduces all the same benefits, but it further streamlines the development workflow by automatically updating page content after compiling the changes. Don't confuse this with a refresh of the browser, which would interfere with the current in-memory state and debugging session of the SPA. There is a live link between the Webpack Dev Middleware service and the browser, which means changes are ~simply another banned word~ pushed to the browser.

Prerequisites

Install the following:

• webpack-hot-middleware npm package:

  npm i -D webpack-hot-middleware
  

Configuration

The HMR component must be registered into MVC's HTTP request pipeline in the Configure method:

app.UseWebpackDevMiddleware(new WebpackDevMiddlewareOptions {
    HotModuleReplacement = true
});

As was true with Webpack Dev Middleware, the UseWebpackDevMiddleware extension method must be called before the UseStaticFiles extension method. For security reasons, register the middleware only when the app runs in development mode.

The webpack.config.js file must define a plugins array, even if it's left empty:

[!code-javascriptMain]

After loading the app in the browser, the developer tools' Console tab provides confirmation of HMR activation:

Routing helpers

In most ASP.NET Core-based SPAs, you'll want client-side routing in addition to server-side routing. The SPA and MVC routing systems can work independently without interference. There is, however, one edge case posing challenges: identifying 404 HTTP responses.

Consider the scenario in which an extensionless route of /some/page is used. Assume the request doesn't pattern-match a server-side route, but its pattern does match a client-side route. Now consider an incoming request for /images/user-512.png, which generally expects to find an image file on the server. If that requested resource path doesn't match any server-side route or static file, it's unlikely that the client-side application would handle it — you generally want to return a 404 HTTP status code.

Prerequisites

Install the following:

• The client-side routing npm package. Using Angular as an example:

  npm i -S @angular/router
  

Configuration

An extension method named MapSpaFallbackRoute is used in the Configure method:

[!code-csharpMain]

Tip: Routes are evaluated in the order in which they're configured. Consequently, the default route in the preceding code example is used first for pattern matching.

Creating a new project

JavaScriptServices provides pre-configured application templates. SpaServices is used in these templates, in conjunction with different frameworks and libraries such as Angular, Aurelia, Knockout, React, and Vue.

These templates can be installed via the .NET Core CLI by running the following command:

dotnet new --install Microsoft.AspNetCore.SpaTemplates::*

A list of available SPA templates is displayed:

Templates	Short Name	Language	Tags
MVC ASP.NET Core with Angular	angular	[C#]	Web/MVC/SPA
MVC ASP.NET Core with Aurelia	aurelia	[C#]	Web/MVC/SPA
MVC ASP.NET Core with Knockout.js	knockout	[C#]	Web/MVC/SPA
MVC ASP.NET Core with React.js	react	[C#]	Web/MVC/SPA
MVC ASP.NET Core with React.js and Redux	reactredux	[C#]	Web/MVC/SPA
MVC ASP.NET Core with Vue.js	vue	[C#]	Web/MVC/SPA

To create a new project using one of the SPA templates, include the Short Name of the template in the dotnet new command. The following command creates an Angular application with ASP.NET Core MVC configured for the server side:

dotnet new angular

Set the runtime configuration mode

Two primary runtime configuration modes exist:

• Development:
  • Includes source maps to ease debugging.
  • Doesn't optimize the client-side code for performance.
• Production:
  • Excludes source maps.
  • Optimizes the client-side code via bundling & minification.

ASP.NET Core uses an environment variable named ASPNETCORE_ENVIRONMENT to store the configuration mode. See Setting the environment for more information.

Running with .NET Core CLI

Restore the required NuGet and npm packages by running the following command at the project root:

dotnet restore && npm i

Build and run the application:

dotnet run

The application starts on localhost according to the runtime configuration mode. Navigating to http://localhost:5000 in the browser displays the landing page.

Running with Visual Studio 2017

Open the .csproj file generated by the dotnet new command. The required NuGet and npm packages are restored automatically upon project open. This restoration process may take up to a few minutes, and the application is ready to run when it completes. Click the green run button or press Ctrl + F5, and the browser opens to the application's landing page. The application runs on localhost according to the runtime configuration mode.

Testing the app

SpaServices templates are pre-configured to run client-side tests using Karma and Jasmine. Jasmine is a popular unit testing framework for JavaScript, whereas Karma is a test runner for those tests. Karma is configured to work with the Webpack Dev Middleware such that you don’t have to stop and run the test every time changes are made. Whether it's the code running against the test case or the test case itself, the test runs automatically.

Using the Angular application as an example, two Jasmine test cases are already provided for the CounterComponent in the counter.component.spec.ts file:

[!code-typescriptMain]

Open the command prompt at the project root, and run the following command:

npm test

The script launches the Karma test runner, which reads the settings defined in the karma.conf.js file. Among other settings, the karma.conf.js identifies the test files to be executed via its files array:

[!code-javascriptMain]

Publishing the application

Combining the generated client-side assets and the published ASP.NET Core artifacts into a ready-to-deploy package can be cumbersome. Thankfully, SpaServices orchestrates that entire publication process with a custom MSBuild target named RunWebpack:

[!code-xmlMain]

The MSBuild target has the following responsibilities:

1. Restore the npm packages
2. Create a production-grade build of the third-party, client-side assets
3. Create a production-grade build of the custom client-side assets
4. Copy the Webpack-generated assets to the publish folder

The MSBuild target is invoked when running:

dotnet publish -c Release

Additional resources

• Angular Docs