This edition of Ng-News spans a two-week window.
An engaging Q&A session sparked discussions on Angular Server Components and future DI enhancements. Alex Rickabaugh unveiled "Plan 2" for Signals, designed to support incremental adoption. NgRx rolled out a SignalStore where Signals are treated as first-class citizens.
NgRx Signal Store
NgRx, the go-to suite for state management, shipped version 17, now fully aligned with Angular 17. The library collection primarily revolves around global and component stores.
Version 17 introduces a fresh third option, the SignalStore. This store is built entirely on Signals and serves as a replacement for both the global and component stores.
Its API is minimal, relying on a handful of functions, with SignalStore at the core. That is the standout feature. We assemble the store by chaining function calls like withMethods, withState, or withComputed, and these generate the actual class or service.
Marko Staminirovic, the mind behind the SignalStore, cites four reasons for this new approach:
- Tree-Shaking: Classes resist tree-shaking; every method ends up in the final bundle regardless of usage.
- Typing: TypeScript does not allow dynamic property additions to a class.
- Extensibility: The design should allow multiple extensions to operate together seamlessly.
- Scalability: Classes bloat as features grow; functions fare better since each can reside in its own file.
Why add a third store? Because overhauling the existing ones would trigger a wave of breaking changes, something the NgRx team is keen to steer clear of.
TypeScript 5.3
On top of that, TypeScript launched version 5.3 with subtle refinements—like improved type narrowing through the switch(true) pattern or import attributes. With import attributes, you can specify that an import expects JSON format, meaning JavaScript content will not be executed.
Q&A with the Angular Team
The most recent Q&A session with the Angular team has wrapped up. Here are the key highlights:
If you are still anticipating first-class support from Google's Bazel, prepare for letdown. It is not coming. The developer experience simply does not measure up. For the full explanation, check out Jeremy's comments:
On the SSR front, internal conversations are underway that could even lead to ServerComponents akin to React:
Regarding the choice between constructor and inject-based dependency injection, Jeremy Elbourn hinted that something may be on the horizon. Historically, the inject function was favored, but time will tell:
"Plan 2" for Signals
Alex Rickabaugh, Angular Core lead, took the stage at ngGlühwein in Vienna. He laid out a revamped Plan v2 for Signals. The original roadmap aimed to ship Signal components swiftly, even as early as Angular 17.
The Angular team decided that could be too ambitious, especially for applications heavily dependent on libraries that would all require migration.
The revised strategy breaks things into smaller, digestible steps. Angular 17 might already bring Signal-based inputs to standard components; next up is the potential for a partial zoneless component with OnPush Change Detection. Then come Signal Components, and finally, the eagerly awaited high-performance Signal Change Detection.
NgGlühwein 2023 - Rethinking Reactivity - Google Slides
docs.google.com
ngRome
The Angular conference ngRome also took place, featuring a keynote from Alex Rickabaugh and Pawel Koszlowski of the Angular team. They outlined the framework's future direction and the strategy for getting there.
A top priority for the Angular team is ensuring that no one gets left behind as new features roll out, allowing everyone to upgrade at their own comfort level.
This means a cautious approach with minimal breakage, prioritizing backward compatibility.