State Management в Angular 19+: карта принятия решений
На мою мою прошлую публикацию о формах на Хабре был дан всего один комментарий, но зато какой!
Отличный материал! Что бы быстро вникнуть в суть после легаси )
Броооо! Ты не представляешь, до какой степени ты прав. Это действительно взгляд на ситуацию со стороны человека, который два года провел на легасевом необитаемом острове и теперь обозревает окрестности.
Поэтому сегодня карта. Не та, что с сокровищами и крестиками, а та, что помогает не заблудиться в выборе стейт-менеджмента в Angular 19+.
Потому что если раньше выбор был простым RxJS + Services, NgRx с его бочками бойлерплейта, NGXS или свежий ветер Akita то сейчас все сложнее. И одновременно проще.
Коротко по берегам.
- Тихие воды Service + BehaviorSubject. Все просто, понятно, под контролем. Из минусов нужно помнить про отписки, а при разрастании сторы могут стать лапшеобразными. Хотя, справедливости ради, лапша появляется независимо от технологии, если за архитектурой не смотреть. - NgRx. Красный паттерн, единый стор, DevTools все это реально помогает на больших проектах. Но цена высокая: action → reducer → effect → selector → компонент. Пять файлов на одну сущность. Джуниоры падают в обморок, опытные вспоминают Redux-Saga и понимают, что могло быть и хуже. - NGXS. Та же идея, но меньше шаблонного кода. Асинхронность из коробки, привычный setState, куча плагинов. Хороший выбор, если не лежит душа к NgRx. - Akita. Когда-то обещала сократить код на 60%. Но официальный репозиторий заархивирован. Корабль больших надежд ушел на дно. - Elf. Тот же автор, что у Akita, построенный на RxJS. Модульный, гибкий, с плагинами под любой запрос. Если вам нравился подход Observable смотрите в сторону Elf. Но увы, тоже разработка прекращена.
А теперь главное сокровище. NgRx Signal Store. Еще в июле 2024 года библиотека вышла из стадии developer preview и делала 50 тысяч загрузок в неделю. В 2026 году уже под 800 тысяч. Это не просто модный тренд. Это официальная эволюция управления состоянием в Angular, построенная на нативных сигналах. Минимум бойлерплейта. Интуитивно понятный API. Фичи, которые подключаются как конструктор. withState, withComputed, withMethods, withHooks, withEntities собираешь стор как конструктор, используешь только то, что нужно.
И главное: сигналы не убивают RxJS. Они забирают себе хранение текущего состояния, а RxJS оставляют для работы с потоками, временем и асинхронностью. Это не война. Это правильное разделение ответственности.
Реальный пример: переход на сигналы в одном проекте (22k строк) дал сокращение кода по управлению состоянием на 63%, уменьшение бандла с 38 до 18 KB, а количество перерендеров при вводе упало с 47 до 3.
Итог: в 2026 году у нас нет одной правильной библиотеки. У нас есть набор инструментов. И выбор зависит не от того, что модно, а от того, какая задача перед тобой стоит. Если у тебя проект на классическом NgRx не надо переписывать все с нуля. Новые фичи пиши на SignalStore. Старые переписывай постепенно, когда они все равно меняются. Глобальное состояние оставляй на чем есть или переводи на Service + Observable.
Полный текст тут: https://habr.com/p/1050992/
· 26.06
Так эльф же тоже все. Базаль порубал в капусту буквально все
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 26.06
Эва как. Вообще да, последний комит 2 года назад. Что то я пропустил. Но ещё пока качают.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён