A Twitter Space hosted by Daniel Glejzner sparked a lively conversation about TanStack's Query library for Angular, covering everything from server-state management to broader questions about Signals. Alex Rickabaugh also shared his take on input setters, change detection cycles, and the reasoning behind Signals.
TanStack Query
TanStack is a collection of libraries that gained popularity in the React ecosystem. Among them, Tan Query stands out as the most widely used and is now available for Angular in an experimental capacity.
Beyond just data fetching, Tan Query handles caching, synchronization, and similar concerns that arise with server data.
The Twitter Space, hosted by Daniel Glejzner, offered a first look at the library. A central debate emerged around whether Tan Query qualifies as a state management solution or sits in a category of its own.
Dominik Dorfmeister, co-maintainer of Tan Query, proposed a distinction between two kinds of state. There's the kind that exists solely on the client, and then there's server state.
Server state is asynchronous, requires constant synchronization, and the client never has full control over it.
Tan Query is built specifically for that server state. For client-side state, a established library like NgRx is usually the more fitting option.
Alex Rickabaugh at Angular Nation
Alex Rickabaugh, who leads the Angular framework team, appeared as a guest at AngularNation. His session was essential viewing, with a particularly valuable Q&A period following his talk.
During his presentation, Alex gave a thorough breakdown of why Signals were introduced, using a form example to illustrate his points. His key observation was that model updates often don't align with the top-down change detection flow.
This mismatch is what triggers the familiar "Expression has changed after it was checked" error. While asynchronous tasks can offer a workaround, issues persist, especially when dealing with OnPush.
Signals are intended to resolve this for good.
In the follow-up discussion, Alex advised against relying on input setters. His reasoning is that Angular provides no guarantee about the order of updates when several input properties change at once.
Instead, he continues to recommend using the ngOnChanges hook:
When it comes to performance, fine-grained change detection is often seen as the ideal approach. However, Alex's experience suggests that the act of running change detection is rarely the actual bottleneck. The real issue is usually that it runs unnecessarily often — a problem that Signals are well-positioned to solve: