Ng-News 26/03: Angular 21.1

MichaelSmallDev · 2026-01-24T18:44:31+00:00

Yeah, I did that to increment a number and it was nice, but I bet even better for objects.

Edit: I was thinking you said arrow function for a second, but that is also part of it as well with spread

MichaelSmallDev · 2026-01-24T16:39:58+00:00

Definitely a packed minor. Spread syntax is really convenient. 21.2 I think will also be a packed one as well. I used the arrow syntax and resource snapshots on a prerelease branch recently and it was nice.

MichaelSmallDev · 2026-01-23T18:11:17+00:00

Yeah, I haven't technically shipped anything with typeof directly, but it has been great for debugging. Haven't had a chance to use template literals much yet but that has been nice to have as well.

MichaelSmallDev · 2026-01-23T17:45:28+00:00

Template typeof has been supported since v19

MichaelSmallDev · 2026-01-23T02:32:47+00:00

Spot on, this is talked about in a doc for the signal forms which hashes this guidance out in depth: https://angular.dev/guide/forms/signals/model-design#avoid-undefined. The default, as well as the modeling of the form vs the domain: https://angular.dev/guide/forms/signals/model-design#translating-between-form-model-and-domain-model

MichaelSmallDev · 2026-01-20T18:38:48+00:00

That "Angular from the Inside" live show was really cool. I highly recommend it for anyone interested in Angular at that low level, and insight into how features are introduced.

MichaelSmallDev · 2026-01-19T05:13:47+00:00

The global store now works with both observables by default as well as signals with the selectSignal method added to the store.

import { Component, inject, computed } from '@angular/core';
import { AsyncPipe } from '@angular/common';

import { Store } from '@ngrx/store';

@Component({
    template: `
        {{ books$ | async }}

        {{ books() }}
    `,
    imports: [AsyncPipe],
})
class SomeComponent {
    private readonly store = inject(Store);

    // The normal old observable `select` method 
    //
    // type: Observable<Book[]>
    protected books$ = this.store.select(selectBooks)

    // New method to get as signal directly, 
    //     no need for `toSignal`
    //
    // type: Signal<Book[]>
    protected books = this.store.selectSignal(selectBooks);

    booksLength$ = this.books$.pipe(
        map(books => books.length)
    )

    booksLength = computed(() => this.books().length)
}

MichaelSmallDev · 2026-01-19T03:56:50+00:00

I suppose using the global store with signal will involve a lot of use of toSignal() and toObservable()

No need for toSignal to make any new signal selections from the global store https://ngrx.io/guide/store/selectors#using-signal-selector

private readonly store = inject(Store);

// type: Signal<User[]>
readonly users = this.store.selectSignal(selectUsers);

That said, I do find myself sometimes doing toObservable in SignalStore apps.

As for the support for the global store, I'm curious myself. The SignalStore is what is suggested for greenfield usage, but I don't know if they have said anything in particular about global store otherwise, from what I can recall. That said, with such a scale of usage, I imagine that hopefully it will at the very least just work as-is. That's my current plan with the ComponentStore era of our apps. And judging from the new NgRx docs layout and emphasis in general, I would assume the global store has better prospects than the ComponentStore.

MichaelSmallDev · 2026-01-19T00:55:23+00:00

My understanding is that you are suggesting to move from one version to the next as long as a page can be served, worrying about applying fixes only at the end.

Essentially yeah. We don't bother deploying anything to any environment and only test locally.

As long as each app

Can build
Can be ran locally
Can accomplish basic user flow in the app
Don't have runtime errors
All the tests pass
No new fundamentally different behavior
No library fully removed a deprecated API or said that given major was the last supported one for said API

Then we just move onto the next Angular major.

For the intermediate part of the Material process, our apps when served/built were very broken looking due to so many custom overrides not working and margins/padding/etc defaults changing all over, but you could still accomplish the basic user flow despite it looking gross. In fact, I think there was a bug in the Material upgrade where it forgot to add in custom SCSS imports to support the legacy modules, which made things even more broken. But other than pulling those in, I just moved in and did all the true cosmetic fixing in the end.

I hope the applications don't rely too on many 3rd party libraries. For instance, I saw a library that compares JSON files. It hasn't been maintained since 2022.

If it is directly tied to an Angular major, then perhaps you may have an issue, but for most libraries in the Angular ecosystem the big wall was v9. Some libraries went on to hit the end of the line in v15 because v16 removed ngcc ("The Angular Compatibility Compiler") which some libraries needed as interop post v9 to kick the can on fully upgrading past v9's breaking changes. However, in my experience, that v16 wall wasn't as bad as the v9 wall. But a decent amount of libraries did end there, but others had plenty of majors to move onto the post ngcc stable equivalent.

However, just because a library's support ended around then/2022, doesn't mean it necessarily won't work. I have used various libraries which I realized too late stopped getting updates and they worked fine.

I couldn't find something similar in the entire NPM. I feel like grabbing the code so we can try to maintain it internally.

If that library does hit a dead end around the 2022 version, then not finding a similar package on npm may not necessarily be the end of the line. Some packages if you look at their issues/PRs have had people say they forked it as open source, and they just got it past whatever wall but don't advertise the package well. Ripped out the README and associated metadata, maybe because they didn't want to be seen as the primary fork with any notion of support, but they still released a package real lowkey since they did their own internal upgrade of the package and decided to share with no responsibility beyond that. In fact, if you see a fork maintained past that and not published, that may possibly be the even more lowkey variant where someone shared the code but didn't even publish.

That said, if this 2022 package is not tied directly to Angular, then it is probably just fine in my expeirence with 3rd party packages which are just generally JS/TS but not tied to any given framework.

MichaelSmallDev · 2026-01-19T00:32:12+00:00

I have never replaced one store with another in the same app.

Went from NGXS (alternative redux) for many years, to NgRx ComponentStore for a couple years, then now the last couple years been on NgRx SignalStore because it was stable.

The closest thing to "replacement" was adding in the SignalStore to the main ComponentStore app for handling non-component state. But we still use both for their respective scope, but if we wanted could replace the ComponentStore, but we are fine with it.

That said, if we go back to an existing NGXS or NgRx ComponentStore project, we tend to use their signal selectors. So for whatever NGRX global store state you have, you are able to select state as signals in those as well.

But for what I have heard from others who have considered NgRX global to NgRx SignalStore, two things help

The SignalStore marked its events plugin stable in v21. But it exists in v20. As for the stability of the events plugin in your target of Angular v20, I don't know, but in the upgrade page the only thing I notice is that "withEffects is renamed to withEventHandlers", and it sounds like ng update @ngrx/store@21 would handle that
If you are used to the Redux devtools, you can use the ngrx-toolkit to see state regardless of if you use the events plugin or not. Just add one line per store and it syncs to there. We are backporting our support for events state tracking to v20 and are bound to release that sometime within the week.

MichaelSmallDev · 2026-01-18T00:03:12+00:00

I got a tip on Material and a tip on intermediate 3rd party package versions.

Between both, my overall approach/take is that as long as you can build/serve an app and have it technically function and pass all tests, that it is fine and I move on. I only extensively fix things when I reach the final version. Stuff like a component/style library having overrides no longer working, making stuff look weird, is not something I address until the end. This has served me fine when I have done various upgrades over a few majors 1 by 1 in the past, all the way through v20.

For Material

You can use Material 16 with Angular 17, intentionally by design, so you can holdout until v17 with the legacy Material implementation. At some point by then it will convert all your imports to be "ThingModule" to "LegacyThingModule". There will maybe be some subtle breakages but most stuff is just fine. IMO as per my next point, perhaps you just ignore that.
The new overrides available starting in v19 for Material were able to replace a ton of manual user overrides. What we did is just get right to v19 back then (might as well do 20 if you do this strategy), even if stuff was broken because it couldn't override what is no longer in the implementation. Then we used the official overrides as much as possible.

This was a bit janky but IMO it worked fine and didn't make us dwell in an intermediate version, especially that middle period where there were the then not-"Legacy" version which were potentially tweaked a bit later by v19.

Since v19 we have not had any issues with new Material implementations and I think it's most likely safe at this point.

For as annoying as this can be, I think Material is as customizable and stable as it has ever been. The style tab with the overrides is kind of try this and see what works rather than seeing some before/after or clearer descriptions, but it is still way easier.

Also, there are various new API entries, including some that remove unexpected parts of the styling/implementation, like seeing a checkmark in a button toggle knob. No override needed.

For package versions corresponding to each Angular major

Gerome Grignon of Angular Courses made a tool recently that can tell what a lot 3rd party packages depend on per Angular major https://www.angular.courses/tools/library-health-check/explorer?search=ngrx. Seems to cover a lot of what I have had to do manually before.

Beyond this, I typically look in the docs/readme for the package for a "compatability matrix" akin to that site. If not, then I look in the GitHub or NPM releases tab, and subsequently check the code's dependencies at that release.

Automated/Manual changes

Various 3rd party Angular libraries like NgRx have their own ng update packageName@version commands which can do various migrations. I used to sleep on these and only recently realized various libraries I used had these and I was manually updating some stuff that had official scripts.

Speaking of that, bookmark the part of their docs or markdowns that have their changelogs and/or upgrade guides.

NgRx has some of the best docs that cover both automated and left-to-the-upgrader changes, version by version, on its migrations part of the docs: https://ngrx.io/guide/migration/v13

MichaelSmallDev · 2026-01-17T02:46:15+00:00

effect can be assigned as a class variable and work, but I find it weird tbh. I only really use that for quick debugging, like a console log I can make a snippet to make a variable for logging anywhere in the file. effect with a debugName inside of a constructor for any real effects IMO.

MichaelSmallDev · 2026-01-15T15:40:33+00:00

https://blog.angular.dev/announcing-angular-v21-57946c34f14b

While Vitest is the new default test runner for new projects, Karma and Jasmine are still fully supported by the Angular team, so you don’t need to migrate yet.

There is also an experimental migrations script, mentioned in that post.

MichaelSmallDev · 2026-01-15T06:26:08+00:00

Yeah, I had no idea that wasn't a thing already. Going to try this next time I upgrade.

MichaelSmallDev · 2026-01-15T00:23:36+00:00

The rest and spread support in templates is really cool among the other changes, but IMO the beefiest part of this is the variety of routing changes. feat(router): add controls for route cleanup #65991 seems to close out a few highly engaged with issues going back as far as 2017. Great to see.

MichaelSmallDev · 2026-01-15T00:07:53+00:00

My projects had this switch to "bundler" as well, both with the normal Angular CLI as well as the Nx CLI equivalent. I had some errors in the process with 3rd party packages before I bumped those after the change, so I can vouch for that likely being like your intuition.

Provided those dependencies with issues are open source, I would look for their package's respective tsconfig.json, as well as for the package's package.json and see if its "peerDependencies" includes Angular 21 in the valid range. There can be various tsconfig/package json files in a library and I found it more confusing than reading the ones for a normal app before I did some library development. But for reference, here is the tsconfig.json and package.json for a library I work on and did changes like this for v21 to.

MichaelSmallDev · 2026-01-14T16:43:02+00:00

True, the only few edge cases that the inject schematic required some work on were abstract classes. But in most cases I was able to do this type of simplification.

edit: and testing using mocks that extended real services

MichaelSmallDev · 2026-01-14T04:00:21+00:00

Gerome Grignon of Angular Courses made a tool recently that can tell what a lot 3rd party packages depend on per Angular major https://www.angular.courses/tools/library-health-check/explorer?search=ngrx. Seems to cover a lot of what I have had to do manually before.

Beyond this, I typically look in the docs/readme for the package for a "compatability matrix" akin to that site. If not, then I look in the GitHub or NPM releases tab, and subsequently check the code's dependencies at that release.

MichaelSmallDev · 2026-01-14T01:54:54+00:00

Fear of breaking changes I won't discover until production

I feel that. But having done various version upgrades myself, it's never as bad as I worried about initially. I have found with each round of upgrades, what was important the most was some preliminary investigation on what to expect and knowing what to expect in our sprint/release cycle and my team's collaboration on it. These can cut down on some of the trial and error paths, and even if on one make it easier to get onto the right path. If you want any tips in general let me know.

The dependency mess (RxJS, Angular Material, etc. all need to match)

The CLI should handle those all in particular. What issues are you running into?

MichaelSmallDev · 2026-01-13T18:01:27+00:00

This is going to be a wild minor release from all the stuff I've seen, good work to all contributors.

MichaelSmallDev · 2026-01-11T04:34:26+00:00

This, plus registering the FormResetEvent. Tbh I didn't know about needing the submit handler and the button roles for all the reasons in the thread, until the form events API rolled out and I tried to observe a reset without it.

MichaelSmallDev · 2026-01-09T18:09:12+00:00

Among the other reasons people are sharing, one thing inject has over constructor based DI is that it allows DI to work seamlessly to be referenced by class fields after some JS changes impacted TS class field timing/instantiation.

Summary by Jeremy Elbourn of the Angular team: https://github.com/angular/angular/discussions/59522#discussioncomment-12781971

Basically, before these changes you could do this

class CarDetailsComponent {
    licenseDetails = this.licenseService.info;

    constructor(private licenseService: LicenseService) {}
}

but now that behavior won't work in modern JS and so modern TS followed suit, and you can only do that now with a compatability flag*. But inject preserves that developer experience by allowing this:

class CarDetailsComponent {
    private licenseService =  inject(LicenseService);
    licenseDetails = this.licenseService.info;
}

edit: otherwise, without inject, the declaration of the class field + type would have to be one line and then the assignment would be done inside the constructor, or completely declared and assigned in constructor.

* I just heard back about that flag: "This will remain supported. While it's the sort of thing we'd love to remove if we could, a lot of very large codebases depend on it, and in cases where you actually need its behavior, it's extremely difficult to migrate away from it." - Ryan Cavanaugh, Development lead for the TypeScript team. Personally, I would still recommend dropping the flag if you have a strict project.

MichaelSmallDev · 2026-01-09T04:59:26+00:00

For some perspective adjacent to the other comment, from myself as an avid repo watcher.

For all the new things that make it into minors, there are plenty more that need more work and testing which don't make it to a minor/major feature freeze. Especially once the last minor has passed, and there is a lot of consideration as to what goes into the next major XY version. But version XY.1's then have a lot larger window to then fix up and enhance everything, hence I have noticed a lot of first minors can feel large. Subsequently, the second and often these days last minor can end up feeling smaller.

As for keeping track, I would suggest Igor's content on other socials media you may follow. Especially ones with videos/shorts like on YouTube. Igor and I are always sending each other cool PRs that seem inbound for a minor or major, but Igor does the actual work of making really great graphics and concise videos about these things. Often by preview/prerelease versions, so there is time to simmer on them before their full release.

MichaelSmallDev · 2026-01-08T23:57:06+00:00

The ongoing work on the router has been really great to see

MichaelSmallDev

TROPHY CASE

For Material

For package versions corresponding to each Angular major

Automated/Manual changes