ASP.NET CORE Application using some Angular 4 pages (--> ASP.NET CORE routing)

1
votes

We have an existing ASP.NET CORE App with lots of controllers and views (with knockout for 2-way-binding). Now the requirement is to build new pages (views) with Angular 4 but the rest of the App should stay unchanged.

The management says it should be made like previous knockout extensions which integrate seamlessly in ASP.NET CORE views. This means each page should be a seperate Angular 4 SPA. This requires that routing has to be done with ASP.NET CORE and not Angular 4.

  1. Question: Is this feasible? If yes, how?
  2. Question: Are there better strategies to extend an existing ASP.NET CORE App with Angular 4 parts than this approach?

EDIT: What I don't understand so far is how to provide routing by ASP.NET CORE in combination with Angular4. In ASP.NET we use _Layout.cshtml for common layout code including a @Html.Partial("_Navigation") for navigation and @RenderBody() for rendering the views. We want to use razor partial views as for the Angular templates. This excellent article describes how. But how can this be done with ASP.NET routing?

2
asp.netangular
You bind routes to components in angular4, but the routing itself can be done by ASP.NET Core, as Angular4 is going to map your URL to the component in question, so it doesn't matter how you change the route. - TanguyB

2 Answers

2
votes

I have found a solution that works for our requirements. For each "mini SPA" I created the necessary files (NgModule, main.ts) to bootstrap them. Then I add a Controller that delivers cshtml-views that contains the load command for the different "mini SPAs". Referencing them in ASP.NET navigation worked like a charm!

1
votes

One of the key purposes of Angular is to write single page applications (or SPAs). And that does NOT mean what it sounds like. The idea is that the user can seamlessly move from "page" to "page" in the Angular app without hitting the server to ask for the next page. So from the servers perspective, it is providing a single page down to the client ... and then Angular takes over and displays all 10, 50, or 100's of views.

Retaining the ASP.NET routing and rewriting each page in Angular would be pointless.

For a more concrete example, say you have a Product Management application. In Angular you would write every view: Product List, Product Detail, Product Edit, Product History, etc. When the user accesses the app ... all views are downloaded. Then the Angular routing moves the user between these views without needing to hit the server again for another page.

If each of these was an ASP.NET view, then ASP.NET would serve the Product List page. Then if the user moves to view details, they'd have to wait for the server to serve the Product Detail page. Then if the user returns to the Product List page, the user would have to wait for the server to serve the Product List page again.

So my advice is to tell management to take an Angular course (I have one if they are interested) or leave it to the developers to make the appropriate architectural choices. :-)

Seriously though ... it seems like there would be a large expense for very little benefit if you were still planning to serve every individual page from ASP.NET.

And maybe that's the answer here ... ask them what they are truly trying to achieve with a move to Angular.