NgRx 22 lança Resource Extensions para evitar reset de estado no resource API do Angular

O NgRx, framework de gerenciamento de estado reativo para Angular↳Angular30 conteúdosCriando Micro Frontends Angular com Native FederationDev (Back & Front) · mar 2026Angular v21 e o Fim da Cobertura de Testes Exclusivamente em TypeScript: Por Que Precisamos Repensar os Testes de ComponentesDev (Back & Front) · jan 2026Angular 8 é lançado com builder APIs e suporte web workerDev (Back & Front) · mai 2019Ver tudo em Dev (Back & Front) →, lançou nesta semana a versão 22, trazendo utilitários para customizar o resource e o httpResource do próprio Angular, signals dinâmicos para tipos union, um novo helper de tipagem para o SignalStore e compatibilidade com o ESLint v10. A novidade central é um conjunto de extensões experimentais que mexe num comportamento que incomoda quem usa resource em produção: o reset do valor durante o reload.

O problema que o NgRx 22 resolve

As APIs resource e httpResource do Angular zeram o value() para undefined sempre que o recurso entra em estado de reload, e lançam uma exceção se o código tentar ler value() enquanto o resource está em estado de erro. Na prática, isso significa que uma tela que depende de value() para renderizar uma lista pisca em branco a cada atualização, e qualquer leitura de estado logo após um erro de rede derruba o fluxo.

No RFC original da funcionalidade, o mantenedor Marko Stanimirović explicou por que esse comportamento também travava a integração mais profunda com o SignalStore:

assim que um resource entra no estado de erro, qualquer chamada subsequente de patchState vai lançar uma exceção porque ela lê value() internamente

once a resource enters the error state, any subsequent patchState call will throw because it reads value() internallyMarko Stanimirović, mantenedor do NgRx

Resource extensions: patch sem perder o tipo

A solução chega por um novo ponto de entrada experimental, @ngrx/signals/resource. As extensões envolvem um resource já existente e corrigem só esses dois comportamentos (reset de valor e exceção em erro), preservando o tipo original do resource, inclusive a tipagem mais específica do httpResource. São quatro extensões nativas, e uma função provideResourceExtensions registra o comportamento padrão em nível de aplicação, rota ou componente, dando controle granular sobre onde o patch se aplica.

A proposta foi bem recebida na comunidade. Manfred Steyer, autor de referência em Angular, respondeu de forma entusiasmada e sugeriu a adição de um signal de ativação ao mecanismo; outro comentarista no RFC pediu paridade com o createResource do SolidJS, como acesso ao valor atual dentro do próprio loader. Um resumo publicado no DEV Community observou que já era possível reproduzir parte desse comportamento combinando o snapshot() do Angular com lógica extra de estado, mas destacou a vantagem da abordagem nova:

com as Resource Extensions, você continua no próprio resource

with Resource Extensions, you stay on the resource itselfComunidade DEV, resumo sobre o lançamento do NgRx 22

Isso significa manter o valor gravável e preservar o tipo mais específico do resource, em vez de criar uma camada paralela de estado por cima dele.

Quem já resolvia isso de outro jeito

Esse problema não é exclusivo do NgRx. O TanStack Query para Angular já oferece retenção do dado anterior ao trocar chaves de consulta através da opção placeholderData: keepPreviousData. Dentro do próprio ecossistema NgRx, o projeto comunitário NgRx Toolkit também já resolvia parte disso: o recurso withResource suporta valor anterior sem lançar exceção em estado de erro desde a versão 20.6.0. A diferença das Resource Extensions é trazer esse comportamento para o resource nativo do Angular, sem exigir uma camada de store adicional.

Deep signals dinâmicos para union types

A segunda mudança relevante da versão 22 mexe em como o SignalStore tipa estados modelados como union. Até então, uma fatia de estado tipada como union (o jeito natural de representar "ainda não carregou") colapsava num único Signal plano, perdendo a granularidade de acesso aos campos internos.

A partir da versão 22, cada membro de um object literal dentro da union recebe seu próprio DeepSignal, acessível depois de um narrowing com in. Para quem modela estados de carregamento como union de tipos (algo como { status: 'loading' } | { status: 'loaded', data: T }), isso elimina a necessidade de gambiarras de cast para acessar campos específicos depois de checar o status.

Outras mudanças na versão 22

Além das duas novidades principais, o release traz ajustes menores que afetam o dia a dia de quem mantém SignalStores maiores:

• Um novo utilitário SignalStoreFeatureType extrai o estado e os membros de uma feature factory, permitindo que features customizadas reutilizem esses tipos em vez de redeclará-los manualmente.
• O @ngrx/store-devtools ganhou uma opção actionCreators para disparar ações diretamente pelo Redux DevTools.
• O @ngrx/eslint-plugin passa a suportar o ESLint v10, derrubando o suporte ao ESLint v8 e ao formato legado .eslintrc.
• O site de documentação ganhou um tema claro.

Como atualizar sem dor

Para migrar, o projeto precisa estar em Angular 22, TypeScript 6.0 e RxJS na faixa ^6.5 ou ^7.5. A atualização roda com ng update @ngrx/store@22 para quem usa a store clássica, ou ng update @ngrx/signals@22 para projetos que usam só o SignalStore. A maior parte das breaking changes tem migração automatizada, detalhada no guia de migração e no changelog oficial do projeto.

Vale um alerta à parte: o Angular 22 mudou o timing do próprio resource, e um desenvolvedor relatou falhas de teste causadas por essa mudança, que acabou documentada como breaking change nas release notes do Angular. Quem atualiza para o NgRx 22 ao mesmo tempo em que sobe o Angular para a versão 22 deve revisar suítes de teste que dependem de timing de resource antes de assumir que a migração foi limpa.

O momento do NgRx dentro do Angular moderno

A discussão em torno do Angular 22 no Hacker News deu pistas sobre como parte da comunidade enxerga o papel do NgRx hoje. Um comentário resumiu a vantagem do SignalStore sobre a abordagem clássica de store com reducers:

NgRx Signals é o novo caminho e é uma delícia. Em vez de ter 5 arquivos para conectar o estado, geralmente é 1 arquivo só, com toda ou quase toda a funcionalidade coesa num lugar.

NGRX Signals is the new way and its lovely. Instead of having 5 files to get state hooked up, its usually 1 file and all/most functionality is co-located.Usuário do Hacker News, discussão sobre o Angular 22

Outro comentário colocou o próprio NgRx num contexto mais amplo de simplificação do framework:

O Angular moderno é muito mais agradável de usar do que nos tempos da v2 (ou mesmo da v4, quando comecei a trabalhar com ele). Boa parte do boilerplate obrigatório hoje é desnecessária. E até o RxJS e o NgRx estão ficando cada vez menos necessários, o que é ótimo.

Modern Angular is MUCH nicer to use than the v2 days (or even the v4 days when I first started working with it). A lot of the required boilerplate is unnecessary nowadays. And even RxJS and NgRX are becoming less and less necessary to use too, which is great.Usuário do Hacker News, discussão sobre o Angular 22

Para quem mantém SignalStores em produção, a leitura prática do release 22 é dupla: de um lado, o NgRx reduz atrito ao lidar com dados assíncronos via resource, algo que antes exigia estado paralelo e lógica de retenção de valor escrita à mão; de outro, o próprio ecossistema Angular segue reduzindo a área em que uma biblioteca de estado externa é indispensável, o que é um dado relevante para quem está decidindo a stack de um projeto novo hoje.

Fonte: InfoQ