In my previous article, I showed how we could easily create an Angular 5 CLI app inside of an ASP.NET Core application. There was one big thing that bugged me about that approach though: our ASP.NET Core application and our Angular CLI application were hosted separately during local development. After spending some time with the ASP.NET 2.1 Preview Angular template, I found a solution.
Hot Reloading Fail
One of the things I liked from the ASP.NET Core 2.1 Preview templates over my approach is that hot reloading worked seamlessly for both Angular and ASP.NET Core.
Make a change in the Angular app? Everything reloads automatically.
Make a change in the ASP.NET Core app though? Nothing. You have to manually refresh.
But no more.
Enabling Hot Reloading for Both Angular and ASP.NET Core
Just like we did with the ASP.NET Core 2.1 Preview, we can use the SPA Services extensions for ASP.NET Core to proxy requests to our Angular CLI app.
The first thing we need to do is add the required NuGet package: microsoft.aspnetcore.spaservices.extensions
.
Now we can configure our app as a SPA, and tell it to act as a proxy to our Angular CLI-hosted app during development.
In Startup.cs
:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
//snip
app.UseSpa(spa =>
{
if (env.IsDevelopment())
{
spa.UseProxyToSpaDevelopmentServer("http://localhost:4200");
}
});
}
That’s almost it. There are a few other things we’ll want to adjust just to streamline the development experience further.
First, let’s reconfigure our npm start
task so that it won’t open our Angular application when we open our solution.
In package.json
, remove the --open
flag from the npm start
task:
{
//snip!
"scripts": {
//snip!
"start": "ng serve",
//snip!
},
//snip!
}
Instead, we’ll run our Angular app by pressing F5 (or ctrl+F5 if you don’t want the debugger).
Let’s make one final change before we call it a day.
If we press F5 now, Visual Studio will launch our application and take us to the /api/values
endpoint, because that’s what our launchSettings.json
file tells it do.
We don’t want it to do that.
We just want it to serve the root of our application, which will be proxied to our Angular application.
So, in launchSettings.json
, just remove the two launchUrl
settings completely.
And that’s it!
Wrapping Up
With those simple changes, our ASP.NET Core + Angular CLI application will now hot reload no matter what we change: TypeScript, CSS, or C#.
I’ve updated the sample application on Github, too. You can check it out here.
Want to see more examples of Angular and ASP.NET Core? Stay tuned! I’ve got a lot of great content lined up! And if you have specific topics or scenarios you’d like to see, let me know in the comments!
Hi Matt, thanks for the blog post. Looking at your sample I had a question. Do you find passing in models into angular works just as well as you did in your angularjs with mvc course on pluralsight?
I ask this because, most people do angular apps talking to a web api right, which is my traditional approach, but I found this to be a bit slow and required writing a lot of plumbing I didn’t care for, so I found your course on pluralsight really interesting.
I know a lot of people these days like to build SPAs leveraging apis, and initially when I first got into programming, I was convinced this was the ONLY way to go.
As I got involved from a professional level especially working with other devs I began to change my mind. Although I think SPAs are really great, I see the benefit of breaking down a project into a series of mini spa’s, so that developers can work on features independently, and deploy for testing regularly without worrying about their fellow developers are doing and things breaking. Before angularjs got typescript support, your course on pluralsight really made sense because it kind of sorted out one of the biggest pain points for angularjs devs.
With Angular however, since we do get Strongly Typed objects thanks to TypeScript, is there still a need to nest Angular apps within MVC pages?
Do you still do this, or have you moved to a pure SPA Angular front end just leverating a web api now?
Im curious to know what you are doing for real projects and your reasoning on this.
Kind Regards
Nigel
Hi Nigel,
Angular 2+ does not really work for silo’d SPA apps the same way AngularJS 1.x did, that’s true. Angular 2+ is heavy enough that it’s more of an all or nothing thing.
I build the vast majority of my new apps using Angular exclusively, with no MVC or Razor. I do use web API for the backend, but no Razor, just straight Angular on the frontend.
Just because Angular 2+ is based on TypeScript doesn’t mean it is truly type-safe though. There’s still a disconnect between your Web API, .NET-based endpoints, and the TypeScript code you write on the front-end. This disconnect can lead to friction and errors.
That’s why I actually *generate* my TypeScript definitions from my C# models.
I have more posts in the works that will cover this in the future, so stay tuned.
All that said, I wouldn’t rule Razor or ASP.NET Core with MVC out completely. For teams that aren’t comfortable with Angular or other, similar JavaScript frameworks, MVC can still be quite useful.
It’s all about what enables you, and your team, to deliver value the most quickly. That isn’t going to be the same for every developer and every team.
I hope that helps, and thanks for reading!
Hi Matt, Sorry I took so long to reply. Thanks very much for your response I really appreciate this.
Yes I know what you mean with Angular 2+, it pretty much is an all or nothing thing. That said, the course you produced on pluralsight for strongly typed angularjs was really really cool, I loved how you used serverside code to inspect the models and use this to dynamically create form controls, validation and all.
I’ve built a few smaller apps using Angular 2+ using web api (no razor) and for that it seems fine.
However I recently started up with a company who has a very large and complex medical product. Is a beast of a monolith to say the least. I’m about the start helping out the team with some front end stuff (they using angular 5), and on initial look, it too is turning out to be a beast of a SPA, and this is only with a limited subset of features compared to the current thick client.
I get that Angular 2+ helps you modularize your apps really well, and with lazy loading on routes it certainly cuts down on the need to load one MASSIVE heap of JS into the users browser, but for development sakes in a team I’m not so sure how this is going to work out as the front end gets bigger and bigger. I mean as the complexity grows, it would feel like your building a monolith, but a front end version.
On the subject of testing, I feel it could simplify things to break the SPA into several mini spas, that interact respectively with their backend components/APIs ( Im thinking microservices of course ), and hence hopefully this would facilitate the testing. In this case of course, MVC would fill the gaps into the routing area where it would be broken by splitting the SPA into smaller and seperate mini SPAs. And testing of individual components along with integration testing accross the application including UI testing with something like Selenium could still take place with not too much hassle. I have not tried this of course, but these are just thoughts.
In a very large project, do you think my thoughts on this still have merit? I know its hard to say because complexity is a matter of opinion, but I thought worth asking because certainly it must still factor in the minds of those looking to use Angular with very large projects, whether to break SPAs down into smaller parts and house within MVC pages, and get some MVC goodness, or just have a massive super SPA?.
Sounds like im talking about swimming pools now hahah.
Anyways Matt, would be interested to hear your thoughts as to how you would attack architecture when it comes to very big Angular projects.
Cheers again
Nigel