I just published an Angular library focused on server-state management with Signals and would love technical feedback from experienced Angular devs.
Links:
-
npm:
-
repo:
What this library targets
-
Signal-native query state in Angular apps
-
Type-safe query/mutation APIs
-
Minimal mental overhead for common async data flows
-
Lightweight alternative for teams that want tighter Angular integration
Current feature set
-
createQuery
-
createSignalQuery
-
createInfiniteQuery
-
createMutation
-
Query cache + invalidation
-
Devtools component
-
SSR hydration support
-
RxJS adapter support
Design choices
-
Signal-based state exposure instead of observable-heavy public API
-
Explicit query keys for deterministic cache identity
-
Cache-first reads with invalidation-driven refresh
-
Optional infinite-query pagination model with getNextPageParam
Open technical questions I want feedback on
-
Query key hashing/serialization strategy:
-
deterministic enough across nested objects?
-
edge cases you’ve seen break cache identity?
-
-
Invalidation granularity:
-
prefix matching defaults vs exact-only defaults?
-
-
Retry/backoff policy:
-
should retry be built-in at core level or adapter/plugin level?
-
-
Cancellation model:
-
should AbortController be first-class in queryFn context?
-
-
SSR hydration contract:
-
preferred API for serializing/dehydrating cache in Angular SSR pipelines?
-
-
Devtools:
-
Which metrics are most useful in real teams (cache hit rate, staleness windows, observer count, etc.)?
-
If you evaluate it, I’d really value:
-
API critiques
-
performance concerns
-
failure-mode reports
-
comparisons against your current stack (TanStack Query Angular, custom stores, plain services)
I’m actively iterating and will prioritize issues with concrete repros.