This Ng-News edition covers two weeks.
We had an insightful Q&A session with speculations about Angular Server Components and future improvements for DI. Alex Rickabaugh introduced “Plan 2” for Signal which will allow an incremental migration. NgRx releases a SignalStore with Signals as first-class citizen.
NgRx Signal Store
NgRx, the most popular set of state management libraries, had its version 17 release, making it fully compatible with Angular 17. NgRx consists of many libraries that centre around global and component stores.
With version 17, there is a new third store, the SignalStore. It is entirely based on Signals and can be used instead of the global and component store.
The API is very small and contains just a bunch of functions, whereas the main one is the SignalStore. And that's what really stands out. We create the store by concatenating function calls withMethods, withState or withComputed. And they generate the actual class or service.
According to Marko Staminirovic, the creator of the SignalStore, this new style is necessary because of four reasons:
- Tree-Shaking: Classes are not tree-shakable. A class will have all its methods in the final bundle, even if we don't need them.
- Typing: With TypeScript, one cannot add properties dynamically to a Class.
- Extensibility: It should be possible to apply multiple extensions working together.
- Scalability: The more functionality we add, the more larger the classes. It is easier with functions because every function can be stored in a separate file.
Why a third store? Because that would have caused quite a lot of breaking changes for the existing ones. For obvious reasons, the NgRx team wants to avoid that scenario.
TypeScript 5.3
Additionally, TypeScript was released in 5.3 with subtle changes—for example, type narrowing with the switch(true) pattern or import attributes. With import attributes, we can define that an import should be in the JSON format. So, if it is JavaScript, it will not be executed.
Q&A with the Angular Team
The last Q&A Session with the Angular team took place. These are the main takeaways:
You will be disappointed if you still hope to get first-class support from Google's Bazel. It's not going to happen. In short, the developer experience is not really the best one. For more information, listen to Jeremy's statement:
In terms of better SSR, there are internal discussions which might even lead to ServerComponents like in React:
In terms of recommendations for constructor vs. inject-based dependency injection, Jeremy Elbourn mentioned that there might be something coming in the near future. In the past, it used to be a pro-inject function, but we will see:
“Plan 2” for Signals
Alex Rickabaugh, Angular Core lead, spoke at the ngGlühwein in Vienna. He presented a Plan v2 for the Signals. Initially, the plan was to come out with Signal components very quickly, actually already in Angular 17.
The Angular team realised that it might be a too huge step, especially if an Angular application comes with a lot of libraries that also have to be migrated.
So, the updated plan includes smaller steps. We might already get Angular 17 Signal-based inputs for the normal component; after that comes the possibility of a partial zoneless component with OnPush Change Detection strategy. Then, Signal Components and then finally, the long-awaited and high-performant Signal Change Detection.
NgGlühwein 2023 – Rethinking Reactivity – Google Slides
docs.google.com ngRome
ngRome, an Angular conference, also took place. Alex Rickabaugh and Pawel Koszlowski from the Angular team gave the keynote. They talked about Angular's future plans and also how they want to achieve their goals.
For the Angular team, it is extremely important that with all those new features, nobody is left behind and can upgrade at their own pace.
That means going slow and not breaking things, so backward compatibility.