Angular 17 was released, what does that mean for you?
Angular version 17 released on November 8, 2023 and the hype is real! There are so many things to talk about and get your head around to create modern web apps and updating your existing Angular apps. You can read about the details of each of the new changes on the Angular blog post, but lets talk about why these changes are important to you as an Angular developer.
Before diving in, lets take a look at all the new things in v17…
- logo redesign
- website moving from angular.io to angular.dev
- standalone applications are now the default for new applications
- signals are out of dev preview and are now stable
- server-side rendering improvements
- hydration is out of dev preview and is now stable
- control flow (
@if,@for,@switch) *developer preview - defer (just going to leave this here because justice can not be paid this briefly) *developer preview
Logo Redesign & New Website
While there is a lot to go in to about how much better the new website is, I think the bigger takeaway is that they represent a beacon to the ongoing Angular Revolution. A lot of effort by the team and community has led to some rather large changes in the Angular ecosystem, many of which you can read more about below. The overarching takeaway is that Angular is getting easier… easier to learn, easier to code, easier to debug and easier to find answers to your questions on the new website.
Standalone
The recently introduced standalone project structure is now the default for new applications which may not contain NgModules. With a this new structure there are fewer concepts to understand and keep in mind as you build out an application. As a developer you can focus on creating a component tree that covers the needed features. Without standalone the focus of structuring/organizing an application was based upon NgModules, which also caused a disconnect from what a component needed in order to work (dependencies). With the dependencies being specified where they are needed refactors are cleaner. Why? because you know what dependencies are being used at that location with no guessing if something else in an NgModule requires that dependency. The other major benefit is that the structure of both a browser and server application share more code and organization. The bootstrap methods are slightly different in that a browser application calls the bootstrapApplication while the server application exports a function that calls bootstrapApplication. While they are slightly differentc all of the configuration is shared in a src/app/app.config.ts file, which means that changes to one are automatically included in the other. The app.config.ts file is where you will set up your external dependencies, like the Angular router, by calling provideRouter(routes) in the providers array. By standing firmly on the standalone application concept, the Angular team has really underscored the idea that standalone is the suggested way to build Angular applications and the team provided schematics to help you migrate your existing applications to standalone, you can learn more about them here.
Signals
Signals are intended to be a more ergonomic means of handling application state. The values of signals can be read in your template by calling the function.
Here’s a very small example:
import { Component, signal } from '@angular/core';
@Component({
selector: 'app-signal',
standalone: true,
template: `<p>The count is: {{ count() }}</p>
<button (click)="increment()">+1</button>`
})
export class SignalComponent {
count = signal(1);
increment() {
this.count.update((c) => {
return c + 1;
});
}
}What does this mean to you?
Signals are a means for Angular to understand when and where your application values are changed.
“Yeah, so?”
This means that if you are using signals to represent all values in templates that may update, you can potentially remove the dependency on zone.js. The other thing that could be applied with teh move to signals is fine-grained updates to templates. So the entire component may not need to be re-rendered upon update, just the portion(s) that need to be updated.
That short little paragraph packs a HUGE PUNCH for performance because not only will Angular be able to make more granular DOM updates, change detection will run only when needed throughout your application.
Server-Side Rendering Improvements
An introduction of a new application builder, aptly named “application” the process of setting up a local dev environment is streamlined; it’s now a single command. This means no more starting the server and then having to go start the client in a separate process! 🎉🎉🎉 “But I thought that Angular did SSR with Angular Universal?” GREAT QUESTION! This used to be true, but the logic and power of Angular Universal is now part of the SSR libraries offered directly from the Angular team. With the new performance boosts and single dev command creating SSR Angular apps is easier than ever so consider SSR enabling your application today!
Hydration
If you are not familiar, hydration is an improvement for SSR applications that allows the client application to not re-render components upon application-start in the browser... NO FLICKER! This feature was introduced in an earlier version as a developer preview, but with v17 the hydration API is now stable. If you have been on the fence about trying out SSR in Angular, v17 brings some very compelling reasons to the table.
Control Flow (@if, @for, @switch) *Developer Preview
New syntax! With the move towards the Standalone API, you can now specify your dependencies for anything your component needs including NgIf and NgFor, which the vast majority of components use. This can be redundant to have the same code throughout your application. Recognizing this potential pitfall, the Angular team introduced Control Flow; a new syntax built in to the framework for specifying logic within a component’s template.
The new syntax is well thought-out and matches well with their TypeScript counterparts so they will feel familiar to you. As a result of this logic being built in to the framework, as opposed to the structural directives built with the framework, the performance is much faster.
Defer
@defer is such a small marker in regards to the number of characters, but a MASSIVE feature with the given power it provides. The API is vast and powerful. You can read about it on angular.dev and also Netanel Basal’s amazing blog post. What makes this feature so powerful is the ability to defer (great naming here) the loading of parts, or all, of a component’s template. But it is not just “hey, load this part later” it gives you the control to determine when to load it based upon the when conditional. Want to load something after the user scrolls to that part of a component, you can do that! Want to load something later, but only when the browser is idle, you can do that! Want to load something when the user takes some action or when a value satisfies some condition, you can do that!
Want to handle different states like a default placeholder, for before the defer conditional is met, you can do that! Or when the deferred content is loading, you can do that! Want to handle the scenario when an error occurs, you can do that!
So whether you’re deferring the content of some content that may not be needed, like a dialog or some compute-heavy component the defer block makes it seamless to implement!
* Developer Preview means that functionality has been added but the API may change in the future prior to it being declared stable. Use at your own risk in production, but certainly feel free to play with and investigate these features.
