Feature/stevesa/spaservices extensions package #336

New Issue

fergalmoran · 2025-08-09T17:15:54Z

fergalmoran commented

2025-08-09 17:15:54 +00:00

Originally created by @SteveSandersonMS on 11/1/2017

Our next update to the Angular template changes it substantially so that it's entirely based around Angular CLI. This much better matches the desired usage patterns. The community has welcomed this proposed change. We will very likely do the same thing for the React template, basing an updated template around the create-react-app tool.

The core implementation idea is to stop coupling the SPA APIs to MVC concepts (e.g., before, the routing was integrated with MVC routing, and prerendering was implemented as a tag helper), and instead have a set of middleware APIs that handle:

serving the SPA default page (e.g., index.html), thereby making client-side routing work
launching a development server (e.g., Angular CLI) and passing through requests to it
performing server-side prerendering of complete HTML pages

All of these new middleware APIs work equally well in MVC applications as in Razor Pages applications. For an example of their usage, please see https://github.com/aspnet/templating/blob/feature/stevesa/angular-cli-template/src/Microsoft.DotNet.Web.Spa.ProjectTemplates/content/Angular-CSharp/Startup.cs#L43

To support all this, we need some new runtime pieces. To allow for the possibility of shipping this out-of-band before the 2.1 release, 100% of the new runtime code is in a new package, Microsoft.AspNetCore.SpaServices.Extensions. This can ship with a dependency on SpaServices version 2.0.0, without any loss of back-compatibility (since SpaServices itself doesn't need to change). Later, we'll migrate the new functionality into SpaServices, and reduce SpaServices.Extensions to a set of type forwarders that exists only for back-compatibility (and at that point, the templates will no longer reference it for new applications).

As you'll see, the majority of code here is purely internal so we reserve the option to change implementation details pretty broadly once we get some preview feedback (and even after RTM). So for this review, I'm mostly keen on getting feedback on the public API design choices, though of course feel free to review whatever aspects of it you want.

*Originally created by @SteveSandersonMS on 11/1/2017* Our [next update to the Angular template](https://github.com/aspnet/JavaScriptServices/issues/1288) changes it substantially so that it's entirely based around Angular CLI. This much better matches the desired usage patterns. The community has welcomed this proposed change. We will very likely do the same thing for the React template, basing an updated template around the `create-react-app` tool. The core implementation idea is to stop coupling the SPA APIs to MVC concepts (e.g., before, the routing was integrated with MVC routing, and prerendering was implemented as a tag helper), and instead have a set of middleware APIs that handle: * serving the SPA default page (e.g., `index.html`), thereby making client-side routing work * launching a development server (e.g., Angular CLI) and passing through requests to it * performing server-side prerendering of complete HTML pages All of these new middleware APIs work equally well in MVC applications as in Razor Pages applications. For an example of their usage, please see https://github.com/aspnet/templating/blob/feature/stevesa/angular-cli-template/src/Microsoft.DotNet.Web.Spa.ProjectTemplates/content/Angular-CSharp/Startup.cs#L43 To support all this, we need some new runtime pieces. To allow for the possibility of shipping this out-of-band before the 2.1 release, 100% of the new runtime code is in a new package, `Microsoft.AspNetCore.SpaServices.Extensions`. This can ship with a dependency on `SpaServices` version 2.0.0, without any loss of back-compatibility (since `SpaServices` itself doesn't need to change). Later, we'll migrate the new functionality into `SpaServices`, and reduce `SpaServices.Extensions` to a set of type forwarders that exists only for back-compatibility (and at that point, the templates will no longer reference it for new applications). As you'll see, the majority of code here is purely `internal` so we reserve the option to change implementation details pretty broadly once we get some preview feedback (and even after RTM). So for this review, I'm mostly keen on getting feedback on the public API design choices, though of course feel free to review whatever aspects of it you want.

fergalmoran closed this issue

2025-08-09 17:15:54 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/JavaScriptServices#336