Now that our project has been created, it's time to take a quick look around and try to understand some of the hard work that the .NET and Angular SPA template has done to make it work.

...Hey, wait a minute! Shouldn't we skip all these setup technicalities and just jump into coding?

As a matter of fact, yes, we'll definitely be doing that in a little while. However, before doing that, it's wise to highlight a couple of aspects of the code that have been put in place already so that we'll know how to move effectively within our project in advance: where to find the server-side and client-side code, where to put new content, how to change our initialization parameters, and so on. It will also be a good chance to review our basic knowledge of the Visual Studio environment and the packages we will need.

That's precisely what we're going to do in this chapter. More precisely, the following are the main topics we&apos...

In this chapter, all of the previous technical requirements listed in Chapter 1, Getting Ready, will apply, with no additional resources, libraries, or packages.

The code files for this chapter can be found here: https://github.com/PacktPublishing/ASP.NET-Core-5-and-Angular/tree/main/Chapter_02/

The first thing that catches the eye is that, as we've already mentioned, the layout of a standard ASP.NET Core solution is quite different from what it used to be in ASP.NET 4 and earlier versions. However, provided that we already have some ASP.NET MVC experience, we should be able to distinguish the ASP.NET back-end part from the Angular front-end part, and also figure out how these two aspects can interact.

The ASP.NET back-end stack is contained in the following folders:

• The Dependencies virtual folder, which basically replaces the old References folder and contains all the internal, external, and third-party references required to build and run our project. All the references to the NuGet packages that we'll add to our project will also be put there.
• The /Controllers/ folder, which has been shipped with any MVC-based ASP.NET application since the preceding release of the MVC framework.
• The /Pages/ folder, which contains...

If you hail from the ASP.NET MVC framework(s), you might want to know why this template doesn't contain a /Views/ folder: where did our Razor views go?

As a matter of fact, this template doesn't make use of views. If we think about it, the reason is quite obvious: a Single-Page Application (SPA) might as well get rid of them since they are meant to operate within a single HTML page that gets served only once. In this template, such a page is the /ClientApp/src/folder/index.html file—and, as we can clearly see, it's also a static page. The only server-side-rendered HTML page provided by this template is the /Pages/Error.cshtml Razor Page, which is used to handle runtime and/or server errors that could happen before the Angular bootstrap phase.

Razor Pages

Those who have never heard of Razor Pages should spend 5-10 minutes taking a look at the following guide, which explains what they are and how they work: https://docs.microsoft...

The front-end part of the template will probably be seen as more complex to understand, because Angular—just like most client-side frameworks—has evolved at a dramatic pace, thus experiencing many breaking changes in its core architecture, toolchain management, coding syntax, template, and setup.

For this very reason, it's very important to take our time understanding the role of the various files shipped with the template. This brief overview will start with root-level configuration files, which will also be updated with the latest versions of the Angular packages (and their dependencies) that we'll need to use.

Workspace

The Angular workspace is the filesystem place containing the Angular files: a collection of application files, libraries, assets, and so on. In our template, as in most ASP.NET Core and Angular projects, the workspace is located within the /ClientApp/ folder, which is defined as the workspace root.

In the previous sections, we've spent a good amount of time reviewing and learning the structure of the sample Angular app created by Visual Studio's ASP.NET and Angular default template. However, there are other – and arguably even better – ways to create a sample Angular app from scratch; as a matter of fact, the approach recommended by the Angular development team is entirely based on creating the app through the Angular Command-Line Interface, better known as the Angular CLI.

In this paragraph, we'll see how to take this alternative route, so that we can compare the resulting apps and highlight their similarities and differences...

Now that we've got a general picture of our new project, it's time to do something. Let's start with two simple exercises that will also come in handy in the future. The first of these will involve the server-side aspects of our application, while the second will be performed on the client side. Both will help us discover whether we have really understood everything there is to know before proceeding to subsequent chapters.

Static file caching

Let's start with the server-side task. Do you remember the /wwwroot/test.html file we added when we wanted to check how the StaticFiles middleware works? We will use it to do a quick demonstration of how our application will internally cache static files.

The first thing we have to do is to run the application in debug mode (by clicking on the Run button or pressing the F5 key). When the app is fully loaded, press CTRL+SHIFT+J to open the Developer tools bar and navigate to the Network...

In this second chapter, we spent some valuable time exploring and understanding our sample project's core components, how they work together, and their distinctive roles. For the sake of simplicity, we split the analysis into two parts: the .NET back-end ecosystem and the Angular front-end architecture, each with its own configuration files, folder structure, naming conventions, and overall scope.

At the end of the day, we can definitely say that we met the end goal of this chapter and learned a fair number of useful things: we know the location and purpose of both server-side and client-side source code files, we are able to remove existing content and insert new stuff, we are aware of the caching system and other setup parameters, and so on.

A relevant part of the chapter was dedicated to the Angular CLI: we've spent a good amount of time learning how to create a sample app using the ng new command and to understand the similarities and the differences...

Razor Pages, separation of concerns, the single responsibility principle, JSON, web hosts, Kestrel, ASP.NET middlewares, Dependency Injection, the Angular workspace, Jasmine, Karma, unit tests, Server-Side Rendering (SSR), TypeScript, Angular architecture, the Angular initialization cycle, browser cache, and client cache.

• Introduction to ASP.NET Core: https://docs.microsoft.com/en-us/aspnet/core/
• Angular: Setting Up the Local Environment and Workspace: https://angular.io/guide/setup-local
• Angular Architecture Overview: https://angular.io/guide/architecture
• Angular Upgrade Guide: https://update.angular.io/
• npmJS: https://docs.npmjs.com/files/package.json
• Yarn Package Manager: https://yarnpkg.com/
• TypeScript – Modules: https://www.typescriptlang.org/docs/handbook/modules.html
• TypeScript – Module Resolution: https://www.typescriptlang.org/docs/handbook/module-resolution.html
• TypeScript Configuration: https://angular.io/config/tsconfig
• TSLint: https://palantir.github.io/tslint/
• Angular AoT Compiler: https://angular.io/guide/aot-compiler
• Karma: https://karma-runner.github.io/
• Jasmine: https://jasmine.github.io/
• Angular – Testing: https://angular.io/guide/testing
• ETag HTTP Header: https...