Привет, паттерны и структуры данных нельзя натягивать на любой кейс.
Описанный в статье подход предназначен для атомарных, независимых действий: лайк, каунтер, тоггл, добавление в корзину. Там, где UX требует мгновенного отклика и блокировать интерфейс нельзя.
Твой пример это форма со связанным состоянием, где валидация одного поля зависит от другого. В таком сценарии Optimistic UI в принципе противопоказан. Здесь достаточно стандартной обработки ошибки без компенсаций.
Не стоит забивать гвозди микроскопом. Статья решает проблему Race Conditions именно для потока атомарных событий.
Привет! Спасибо огромное за советы. Попробую их применить. Что касается трёх пунктов, то тут пока нет очевидных ответов - всё на этапе внедрения и экспериментов.
Спасибо за развёрнутый комментарий, отличное дополнение к теме. Полностью согласен с вашими замечаниями насчёт effect и untracked и подхода к мутациям.
Сейчас как раз собираю похожие вопросы и кейсы от читателей и планирую отдельную статью с разбором подводных камней Angular Signals и рекомендациями по реальным сценариям использования.
Подписывайтесь, если интересно следить за продолжением, там будут примеры с input() сигналами, логированием мутаций и подходами к дебагу.
Спасибо, что делитесь опытом! Такие обсуждения сильно повышают качество контента.
Отличный вопрос, спасибо, что обратили на это внимание.
Вы абсолютно правы в 99% случаев markForCheck является предпочтительным и более правильным выбором. Мое решение использовать detectChanges в этом конкретном примере было осознанным и использовалось скорее как упрощенный пример.
Хотелось максимально наглядно и синхронно показать прямую связь: вот мы изменили данные -> вот мы вызвали метод -> вот DOM немедленно обновился. Это самый простой способ продемонстрировать сам факт ручного управления в Zoneless мире, не усложняя первый пример объяснением про следующий тик и асинхронную природу markForCheck.
Так что да, полностью согласен с вами, markForCheck это основной инструмент для OnPush компонентов, а detectChanges это скорее для особых случаев, вроде полностью отсоединенных от дерева CD компонентов или для синхронных проверок в unit тестах.
@radtie, спасибо за подробный и полезный комментарий! Очень признателен за конкретный отзыв.
Вы совершенно правы, это важные замечания. Функциональные резолверы (в v14) и прямой байдинг на инпуты (из v16) заметно упрощают код в Angular.
В статье я намеренно использовал более старый подход с классами, чтобы понятнее показать, как работает резолвер для начинающих. Но для современных проектов ваш пример - лучшее решение.
Полностью согласен с вами и по поводу лоадера. Ваш способ с отдельной функцией и toSignal чище, реактивнее и лучше. Спасибо за замечание про ngOnDestroy в AppComponent - об этом часто забывают. Еще раз спасибо! Ваш комментарий отлично дополняет статью.
Привет, паттерны и структуры данных нельзя натягивать на любой кейс.
Описанный в статье подход предназначен для атомарных, независимых действий: лайк, каунтер, тоггл, добавление в корзину. Там, где UX требует мгновенного отклика и блокировать интерфейс нельзя.
Твой пример это форма со связанным состоянием, где валидация одного поля зависит от другого. В таком сценарии Optimistic UI в принципе противопоказан. Здесь достаточно стандартной обработки ошибки без компенсаций.
Не стоит забивать гвозди микроскопом. Статья решает проблему Race Conditions именно для потока атомарных событий.
Привет! Спасибо огромное за советы. Попробую их применить. Что касается трёх пунктов, то тут пока нет очевидных ответов - всё на этапе внедрения и экспериментов.
qwen3-coder
На работе у нас на внутреннем контуре висит модель для таких кейсов. А для демо я использовал свой личный GitHub и бесплатные модели с OpenRouter.
Спасибо за развёрнутый комментарий, отличное дополнение к теме.
Полностью согласен с вашими замечаниями насчёт effect и untracked и подхода к мутациям.
Сейчас как раз собираю похожие вопросы и кейсы от читателей и планирую отдельную статью с разбором подводных камней Angular Signals и рекомендациями по реальным сценариям использования.
Подписывайтесь, если интересно следить за продолжением, там будут примеры с input() сигналами, логированием мутаций и подходами к дебагу.
Спасибо, что делитесь опытом! Такие обсуждения сильно повышают качество контента.
Отличный вопрос, как раз добавлю его в список тем для следующей статьи по Signals. Спасибо!
Спасибо
Отличный вопрос, спасибо, что обратили на это внимание.
Вы абсолютно правы в 99% случаев markForCheck является предпочтительным и более правильным выбором. Мое решение использовать detectChanges в этом конкретном примере было осознанным и использовалось скорее как упрощенный пример.
Хотелось максимально наглядно и синхронно показать прямую связь: вот мы изменили данные -> вот мы вызвали метод -> вот DOM немедленно обновился. Это самый простой способ продемонстрировать сам факт ручного управления в Zoneless мире, не усложняя первый пример объяснением про следующий тик и асинхронную природу markForCheck.
Так что да, полностью согласен с вами, markForCheck это основной инструмент для OnPush компонентов, а detectChanges это скорее для особых случаев, вроде полностью отсоединенных от дерева CD компонентов или для синхронных проверок в unit тестах.
@radtie, спасибо за подробный и полезный комментарий! Очень признателен за конкретный отзыв.
Вы совершенно правы, это важные замечания. Функциональные резолверы (в v14) и прямой байдинг на инпуты (из v16) заметно упрощают код в Angular.
В статье я намеренно использовал более старый подход с классами, чтобы понятнее показать, как работает резолвер для начинающих. Но для современных проектов ваш пример - лучшее решение.
Полностью согласен с вами и по поводу лоадера. Ваш способ с отдельной функцией и toSignal чище, реактивнее и лучше. Спасибо за замечание про ngOnDestroy в AppComponent - об этом часто забывают. Еще раз спасибо! Ваш комментарий отлично дополняет статью.