What is Angular?
Angular is a Typescript-based front-end web framework with a focus on creating single-page applications. Unlike other frameworks Angular comes with a lot of built in functionality without requiring additional packages to be added. This often means people see Angular as being heavyweight out of the box. While this may be true for smaller applications that don’t utilise many of the available features, it can often be a benefit once an application grows as much of the functionality is already in place.
A distinction needs to be made between AngularJS and the current version of Angular (sometimes referred to as Angular 2+). The release of Angular 2 brought large scale changes to the way the framework functions.
Requirements
To get started creating Angular applications there are a few things you will need to install to get started. I’ll briefly cover the requirements and then list the versions used for this guide.
IDE
A good IDE (Integrated Development Environment) is the backbone of any good development effort. Granted it would possible to develop using just Notepad and CLI, and I’m sure there are some people masochistic enough to try, but you will make life much easier for yourself by using an IDE.
There are plenty of IDEs to choose from, and while some are geared towards particular languages or frameworks there are many that will work across the board. My preference is to use VS Code for front-end development, so that’s what I’ll be using as part of this guide. If you prefer to use something else then go for it. It doesn’t make a difference to the end result.
Node.js
The version you will need is dependent on the version of Angular you’re developing for. If you’re using the latest version of Angular then the latest LTS version of Node.js will work. If you’re working with an older version of Angular you can find the requirements on UNPKG. The latest LTS version can be found on the Node.js website.
The Node.js install includes installing npm on the system. npm is used to install packages on your system and will be required for installing our other dependencies, so make sure Node.js is installed first.
Angular CLI
This is a tool that enables you to work with Angular from the command line. There are plenty of commands you can use this for, allowing you to do things like:
Scaffold new applications
Generate content (components, directives, pipes, etc)
Serve your application locally
These are just a few examples. We will be using the Angular CLI throughout this guide, but if you want more information on everything it can do you can check out the official reference (Angular CLI).
To install the latest version of the Angular CLI you can run:
npm install -g @angular/cli
If you need a specific version you can append it to the end:
npm install -g @angular/cli@15.0.0
The -g flag will install the Angular CLI globally on your system. This allows the ng commands to be run from anywhere. You can check that this has been installed correctly by running:
ng version
Versions used in this guide
These are the versions I’ll be using:
Node.js 18.15.0
Angular CLI 16.0.3
So we’ve got our dependencies installed. The next section will cover getting a project up and running.
Setting up a project
Creating the project
We’ll use the Angular CLI to create our first application. The simplest way to do this is to run:
ng new
This will then ask a series of questions to set up the workspace and project, including:
A name for your workspace and initial project
Whether you want to add routing
Which stylesheet format to use
It doesn’t matter if you’re not sure on any of these options to begin with, it can all be changed later. This will create all the required folders and trigger an install of all the dependencies. To see the application move you command line in to the new folder with:
cd {ProjectName}
and then run:
ng s -o
If all went well this should have built the project, started serving it (on http://localhost:4200 by default), and opened it in your systems default browser. If you want to just serve the application without it automatically opening then omit the -o flag from the command.
A tour of your new project
So we’ve got a project and we can see it running. That’s great, but what do we actually have. If you open the folder in your IDE you should see a solution like this:
There’s a lot going on there. Not all of it is important to understand right now, so we’ll just cover a few important parts.
angular.json
This file provides the configuration so the Angular knows how to work with you application. If you open it up you can see there’s a lot going on in here. The part we’re going to focus on is the architect section that looks something like this:
{
...
"projects": {
"getting-started-with-angular": {
...
"architect": {
"build": ...,
"serve": ...,
"extract-i18n": ...,
"test": ...
}
}
}
}
}
This section configures what happens when you run the commands by the same name. So if you run ng serve, that will be affected by the configurations under the architect/serve section of this file.
At the start of a project the defaults are likely to serve you fine. However, as a project progresses you may find you need additional configurations when running your builds. Maybe you want to define separate environment files when you’re running it locally vs running it in production. This can be achieved by defining separate build configurations and using the fileReplacements option to replace the standard environment file as appropriate. The new configuration can then be run by using the configuration flag:
ng serve --configuration production
tsconfig.json
This is a standard configuration file for Typescript. This configuration controls how strictly Typescript acts in your project. This control can be the difference between using the features of Typescript vs just using Javascript with a transpilation overhead. You may be familiar with this if you’ve Typescript previously, but there are a couple of interesting parts to cover.
First, the Angular specific configurations. The default for these looks like this:
"angularCompilerOptions": {
"enableI18nLegacyMessageIdFormat": false,
"strictInjectionParameters": true,
"strictInputAccessModifiers": true,
"strictTemplates": true
}
These apply additional rules to your Angular specific components. For example, strictTemplate will ensure that anything used in one of your template files is actually accessible to it from the code. Without this bugs would only be found at runtime, and once a project gets big enough it means subtle bugs are easy to miss.
The Angular CLI generates new projects with these strict rules enabled. I suggest you leave them that way. It’s much easier to follow these rules as you go along rather than enable the rules later and fix the errors. Trust me.
tsconfig.*.json
These files inherit from the base tsconfig.json file, but provide additional configuration for where to output files when building and which files need to be included in the build. This enables multiple configurations to be provided for different scenarios, which can be configured in the angular.json file discussed earlier. A good example of this is building to run the application or run the tests. To run the application we don’t need to include all the test files, so a separate configuration is used to ensure we don’t have them.
src/ folder
This folder is where the source code and assets for your application resides. The app folder contains the initial module, component, and routing file for the application. These will all be covered in later posts, but if you change the content of app.component.html and wait for the application to rebuild you will see your changes being applied.
In the next post we’ll be covering modules.