This tutorial presents a series of articles focused on building an effective Angular application architecture, based on best practices used at Ekobit.
In this part of the Angular architecture tutorial, you would be introduced with an initial structure of an Angular application, together with a process of building and preparing your first Angular application for deployment.
As an Angular project evolves, in the Angular architecture tutorial II we would create modules, load them dynamically, share their data, and start to build modular architecture.
Prerequisites
It’s assumed that you’re familiar with the basics of NuGet packages and the Single-Page Application (SPA) paradigm, that is used when building client-side web applications. It’s also assumed that you’re familiar with TypeScript, and that you have at least some experience in building Angular applications.
Initial Structure of an Angular Application
As a default project organization (from Angular version 2 onward), there’s an src folder created for you when you execute the following command of Angular CLI:
ng new <project-name>
‘Angular application’ means that the Angular can be launched directly on a browser by using webpack-live-server (by default, running on http://localhost:4200):
ng serve
It’s easy to work with the Angular framework by using Visual Studio Code because it’s the most popular web development IDE, and has a lot of useful tooling for writing code, debugging and source control.
Here’s a list of the most important files on the root folder, created by Angular CLI:
– package.json – containing all the packages needed for development and production
– tsconfig.json – containing TypeScript transpilation configuration
– tslint.json – containing all the rules for TypeScript static code analysis (ie. linting)
– angular.json – containing options for building and configuring Angular projects
Everything else is located on the src folder, including the following:
– index.html – as a single entry point for serving the Angular application
– main.ts – representing the main TypeScript file for bootstrapping the application
– styles.scss – as a globally defined cascading stylesheets (CSS) file (or any other CSS compiler file supported by the configuration)
– app folder – containing all the Angular code
– assets folder – containing static files (eg. images, fonts, JSON files)
– environments folder – containing different environments used when deploying or testing the application
Here’s how this default Angular application structure looks like in Visual Studio Code:
Process of Building an Angular Application
It’s important to note how an Angular application is constructed, as well as when its life cycle has been run. When preparing an application for launch (ie. the building process), Angular CLI uses the WebPack tool to build a bundle of all the data that will be served on a host. That data includes:
– transpiling the TypeScript code to a plain JavaScript code (because JavaScript is the only language a web browser can understand)
– bundling the assets into a single file to optimize the performance
– bundling the styles into a single file (also for the load optimization).
Angular CLI uses output hashing to generate uniquely-named resulting files in order to refresh them on every build. This may be changed in the angular.json configuration file. (We’ll come to this later in this series.)
The resulting JavaScript code is further separated by its purpose and origin, having:
– main.js – containing the application-based transpiled code (what we made by ourselves)
– polyfills.js – containing the additional code logic for supporting versions of older browsers
– runtime.js – containing the plumbing code of Angular to run the application
-scripts. js – with all the script code required for support styles and custom JavaScript libraries
– styles.js – containing styles, defined by the application and from the third-party UX libraries (such as Bootstrap)
– vendor.ts – the code that’s coming from the node_modules folder (ie. third-party libraries, including Angular itself).
You may ask why such separation in the construction process is necessary. Angular CLI builds these files in such a manner in order to gain the initial load time as soon as possible. It also operates in this manner so that it can load some of the unnecessary files later on when they’re needed (ie. lazy loading).
Building for Production
From the screenshot above, it’s clear how these files are named and how big they are. You can imagine the importance of separating the code into smaller chunks if they exceed several MBs.
To test and prepare the resulting code for production, you should run the following command on a terminal:
ng build --prod
This produces the files in the dist folder, with the output hashing turned on:
To further optimize the bundle size, from the Angular 8 application CLI produces two sorts of files: one for supporting the ES5 (for older browsers), and one for supporting the ES2015 standard (forversions of modern browser versions) – as seen in the above screenshot. This means that, if you’re certain that the newest EcmaScript standard is supported by your target browsers, you can spare some kilobytes – even MBs – on size, and load your application faster.
For more detailed information about your application size, refer to the Webpack Bundle Analyzer Tool, which gives a graphical overview of the expenditure of the different sizes of bundle files.
____________________________________________________________
Note: All of the source codes used in these articles are available here.
