Version 17 of Angular, the popular JavaScript framework, is arriving. There’s a lot going on with Angular. Some people can lose track of things, or even become scared of getting overwhelmed. This article examines if this concern is justified or if the Angular team’s plan to usher in an Angular renaissance can succeed.

First of all: Anyone who has been putting off Angular upgrades or is only planning to update at the end of an LTS cycle should closely watch current developments and evaluate if incremental updates in small steps instead of a large leaps makes more sense in terms of effort and risk.

Of course, we’ll take a look at the Angular Core changes as well as TypeScript and Angular Material.

TypeScript

The new Angular version also supports a new version of TypeScript. In Angular 17, TypeScript version 5.2 or higher must be used. Since Angular 16 still required TypeScript 5.0, let’s take a look at some interesting new features from both TypeScript 5.1 and TypeScript 5.2.

Implicit “return“ when “undefined“ is returned

If a JavaScript function doesn’t contain a "return" statement, it still always implicitly has "undefined" as its return value. This fact wasn’t reflected in TypeScript yet. If "undefined" was specified as the return type for a function, a "return" statement always had to be used explicitly too. Additionally, a function that explicitly returned "undefined" wasn’t compatible with a "void" function. See Listing 1.

---

declare function onEvent(f: () => undefined): undefined;

  

onEvent(function f() { })

// Argument of type '() => void' is not assignable to parameter of type '() => undefined'.

---

Listing 1: “undefined” and “void” were previously incompatible in TypeScript

This is now improved in TypeScript 5.1, so the above example no longer throws compiler errors. A function with "undefined" as the return type also no longer requires an explicit "return", similar to the "demo1()" function in Listing 2. Alternatively, an explicit but "empty" return can also be used, as in the "demo2()" function.

---

function demo1(): undefined {

// no returns

}

function demo2(): undefined {

return;

}

---

Listing 2: No more return needed for the “undefined” return type

Independent getter and setter types

Previously, TypeScript get and set functions that belonged together (for example, if they had the same name) had to have compatible types. For a setter that can be given the type "string|number|boolean", previously you could only specify a subtype like "string" as the corresponding getter. In TypeScript 5.1, these types can be assigned completely independently, but they must be assigned explicitly. See Listing 3.

---

interface MyElementStyling {

set style(newValue: string);

get style(): CSSStyleDeclaration;

}

---

Listing 3: Independent getter and setter types.

Decorator Metadata

In TypeScript, a decorator is a function that is given a class, property, or method in order to extend the passed entity’s behavior. TypeScript 5.2 adds an exciting feature specifically for the Angular framework: the ability to add metadata to a decorator. This feature was already in the "Experimental Decorators" originally used by Angular, but now it’s also in the stable TypeScript specification. For example, in Listing 4, the decorator "setMetadata" is defined. A decorator is a function that’s given the decorated entity as a "target" and the associated "context". The "metadata" property was added to this context object in TypeScript 5.2. The metadata can be understood as a key-value store. Its corresponding TypeScript type is called "record". The metadata key is the name of the decorated entity; in Listing 4, for example, the property "demoAmount" is decorated. Therefore, it becomes a metadata key. Listing 4 shows how metadata can be written by accessing "context.metadata". The decorated entity’s name is in "context.name". In Listing 4, the string "Demo data" is stored in the metadata for each property decorated with "@setMetadata".

Stored metadata can be read from the class with the TypeScript metadata symbol ("Symbol.metadata").

---

interface Context {

name: string;

metadata: Record<PropertyKey, unknown>;

}

function setMetadata(_target: any, context: Context) {

context.metadata[context.name] = 'Demo-Data';

}

class MyClass {

@setMetadata

demoAmount = 123;

@setMetadata

demoAction() { }

}

  

const ourMetadata = MyClass[Symbol.metadata];

console.log(JSON.stringify(ourMetadata));

// { "demoAmount": "Demo-Data", "demoAction": "Demo-Data" }

---

Listing 4: Set and read metadata in TypeScript

To better configure a decorator, you can implement a decorator factory. It will then return the actual decorator. This is shown in Listing 5 using the "DemoMeta" decorator factory, which receives the metadata key to be set and the associated metadata value as parameters and returns the configured decorator. The "DemoMeta" factory is used in Listing 5 to add the metadata entry "'entity'" with the value "'3270'" to the "DemoClass" class. The metadata entry "'demo'" with the value "'42'" is added to the "demoMethod()" method. Then, the class metadata is accessed again with "Symbol.metadata".

---

function DemoMeta(key: string, value: string) {

return (_: any, context: Context) => {

context.metadata[key] = value;

};

}

  

@DemoMeta('entity', '3270')

class DemoClass {

@DemoMeta('demo', '42')

demoMethod() {}

}

  

DemoClass[Symbol.metadata].entity; // '3270'

DemoClass[Symbol.metadata].demo; // '42'

---

Listing 5: Example Decorator Factory in TypeScript

After our look at TypeScript, next we will turn to the Angular CLI. This is typically used to build Angular applications.

Angular CLI

The Angular team provides the Angular CLI for developers to manage Angular projects. An important step in Angular CLI 17 is the Angular build system update. In Angular CLI 17, newly created projects are now built with the new build system based on "esbuild" as the standard for the first time. This is primarily meant to speed up the build and optimize the build result or make it smaller.

The new name "Vite" (pronounced like the French. "vite" = "fast") based live development server promises a better, faster development cycle. For example, Vite lets you apply changes to the global CSS without needing a live reload.

For apps to be built entirely with the esbuild-based build system in the future, the esbuild builder needed some enhancements. For example, basic support for checking Angular CLI bundle budgets was added to help developers keep track of the size of JavaScript and CSS files generated in the build. Basic support for building WebWorkers has also been added. These are a browser-native feature, but still must be considered in the Angular build, since worker scripts are typically written with TypeScript. The old builder was already able to do this, and now the new esbuild builder follows suit.

Since they’re built in Angular, SPAs have one disadvantage. Once the initial web page has loaded, some scripts must first be loaded, which start the application. Depending on the internet connection and the page size, this takes a moment. Along with the fact that scripts have to be executed in order to display the content of the page, this is bad for the page’s SEO ranking.

Previously, the "@nguniversal" package could be used to make an Angular application SEO-fit. "@nguniversal" can (pre-)render an Angular application on the server side. The page content is visible immediately after the HTML has been loaded, since it no longer has to be generated dynamically in the client. This leads to a fast page load, better usability, and a better SEO ranking. Previously, the pre-rendering packages were in a separate namespace "@nguniversal", although these packages were also maintained by the Angular team. In Angular 17, most of the code has been moved from "@nguniversal" to the "@angular/ssr" package in the "@angular" namespace. However, apart from renaming, the functionality is essentially the same.

The topic of SSR (Server Side (pre-) Rendering) has become more important to the Angular team, as can be seen from the above change and the fact that it has become easier to integrate packages. When creating a new Angular 17 project, you’ll be asked if server-side rendering should be activated. Alternatively, the new option "ng new --ssr" can be used to generate a project with preconfigured SSR. In this project, Angular 16’s hydration is also directly activated. This will ensure a seamless transition from the server-side generated page to the fully functional Angular app without flickering.

Breaking Changes in Angular CLI 17

Angular 17 keeps its own dependencies up to date. At least TypeScript version 5.2 and zone.js version 0.14.0 must now be used for Angular and Angular CLI. The minimum required node.js version is upgraded to 18.13.0.

Some defaults have also been replaced in Angular CLI. For example, when a new application is generated, the Angular router is now initialized by default. This wasn’t previously the case. If no routing is needed, the command line option "--no-routing" must be specified.

As of Angular CLI 17, all applications are generated as "standalone" applications by default, such as an application without "@NgModule()".

Another changed default value concerns the Angular interceptors. Angular HTTP interceptors can be generated with the "ng g interceptor" command. Previously, class-based interceptors were generated with this command. In Angular CLI 17, functional interceptors are generated instead. If a class-based interceptor is generated, the "--no-functional" option must be added to the command.

Figure 1: Old Angular-Logo on the left and new Angular-Logo on the right.

Angular

Angular 17 comes with a lot of new features. The Angular team calls it one of the "biggest" releases in its history. Besides the version updates for zone.js and TypeScript, it also offers many smaller and larger innovations. Two innovations related to the new APIs regarding Signals have already been added in Angular 16.2.0. Namely, it adds two new component lifecycle hooks. These are special because they don’t have to be implemented with an interface like conventional lifecycle hooks. They can be called as a callback function. This is similar to the "computed()" function in Signals. Listing 6 shows an example with the new hooks. The two hooks are called "afterRender()" and "afterNextRender()" and are executed, according to their name, after Angular renders the respective component. The difference between the two hooks is that "afterNextRender()" is only called once, after the next rendering process, while "afterRender()" remains active as long as the component is active. However, these two hooks are still listed as "Developer Preview" and are subject to change.

@Component({})

export class DemoComponent {

val = 42;

constructor() {

afterRender(() => {

console.log('afterRender', this.val);

});

afterNextRender(() => {

console.log('afterNextRender', this.val);

});

}

}

---

Listing 6: Implementing the new lifecycle hooks

Signals

An important detail in Angular 17 is that the signals introduced in Angular 16 are now stable. The goal of introducing Signals was to make zone.js optional by introducing a new, signal-based change detection mechanism. In Angular 17, the team has come a step closer to this goal. Signals enable "local change detection", a change detection process that only refers to the components that have changed (signal) values. Figure 1 shows an example of the difference between the change detection mechanisms. In the standard case, the complete component graph is checked for each asynchronous event. With OnPush-ChangeDetection, components that triggered the change detection or have changed "@Input()" values and their respective parent components (up to the AppComponent) are checked. With Signals, you can now check only the components that have changed signal values.

Figure 2: Comparing change detection mechanisms

Animations

Animations can be reloaded in Angular 17 with lazy loading. The browser must first load smaller bundles, making the initial application smaller, leading to shorter application loading and start times. To activate lazy loading for animations, the "provideAnimationsAsync()" function must be used. Here, the "BrowserAnimationModule" should no longer be imported...