Comments 11
Удивительно, как в реакте ты все время думаешь про то, чтобы ни дай бог не вызвать рендер лишний раз, в то время как в Ангуляре надеешься чтобы хоть как-то заработало и ты при этом не помер от вязанки rx-потоков.
Связные списки для зависимостей - это крайне не эффективно, так как требует много памяти, которая ещё и сильно фрагментируется. Надеюсь ещё лет через 10 они додумаются и до чего-то типа парных массивов:
Объясните, пожалуйста, в чем концептуально состоит разница между BehaviorSubject той же рыксы и новоиспеченными сигналами?
Во-первых я хочу поблагодарить автора за статью. Было приложено много труда и это заметно.
Когда сигналы только появились, мне предоставилась возможность сделать некий анализ и презентацию по этой теме, поэтому ниже тезисы, к котором привел этот анализ. Но даже тогда, по исходному коду были координальные изменения - видно команда angular сама еще эксперементировала. Если информация будет дублироваться со статьей - то извините за повтор.
----
По мне основная проблема сигналов в том - что они претворяются легкими с виду, но только, когда ты уже сам поэксперементировал, то понимаешь, что есть подводные камни
1. toObservable внутри использует тот же механизм, что в effect, который использует оптимизации соответствующие - поэтому идет пропуск одинаковых значений
если хочется отслеживать все изменения - то уже нельзя провести такую параллель - что этот тот же observable и поведение такое же как ожидается с subject.next() - который спокойно позволяет эмитить и получать одинаковые данные;
2. разделять, что signal используются больше для хранения данных и работы с ними и удобного перерендера в шаблоне, а события по системе все еще в зоне ответственности observable;
поэтому какие-то сложные цепочки данных по мне лучше писать в observable и потом уже переводить в сигналы непосредственно рядом в шаблонами;
3. то, что вызывается внутри effect - вызовы функций - могут внутри своих вызовов содержать другие вызовы которые в себе содержат например чтения какого-нибудь сигнала;
и поэтому effect -> функция 1 -> функция 2 -> функция 3 (где есть сигнал A) - построит зависимость этого effect от A;
поэтому нужно знать о такой особенности и в качестве рекомендаций всегда выносить все зависимости effect'а вверх, а все остальное оборачивать в untracked, даже если функции вызываемые сейчас не используют сигналов - нет гарантий, что потом они не будут читать значения (кто-нибудь придет и добавит это в одну из функций и не посмотрит, что далеко по цепочке вверх она уже используется в effect, что теперь будет триггерить этот effect) - поэтому лучше озаботиться об untracked заранее
4. проблема с отладкой (сложно понять где значения были измененены) - решение: лучше иметь одну точку изменения данных сигнала - сигнал можно сделать readonly, и сделать например set функцию которая бы только могла мутировать значения снаружи, чтобы было меньше путаницы, где значения меняются (туда же можно и добавить логгирование)
----
Я хочу поинтересоваться насчет 3 вещей, которые на момент когда мне довелось рассматривать эту тему, были еще до конца нерешенными. Может быть
@AlekseyVYвы знаете как это решилось:
1. есть ли какие-то инструменты, чтобы отследить случаи некорректного получения значения сигнала (без скобок)
2. раньше у команды angular была рекомендация не мутировать данные сигналов в effect - осталась ли такая рекомендация?
3. как отслеживать изменения input() сигнала ? (например старый аналог OnChanges, или просто геттер) - какая рекомендация сейчас существует?)
если какая-то информация повторяется, еще раз приношу извинения
спасибо за статью!
Спасибо за развёрнутый комментарий, отличное дополнение к теме.
Полностью согласен с вашими замечаниями насчёт effect и untracked и подхода к мутациям.
Сейчас как раз собираю похожие вопросы и кейсы от читателей и планирую отдельную статью с разбором подводных камней Angular Signals и рекомендациями по реальным сценариям использования.
Подписывайтесь, если интересно следить за продолжением, там будут примеры с input() сигналами, логированием мутаций и подходами к дебагу.
Спасибо, что делитесь опытом! Такие обсуждения сильно повышают качество контента.
Выглядит как-будто неплохо, но много типов, много конструкторов, в целом выглядит сложно еще до написания кода. Вот зачем отдельный тип ModelSignal, WritableSignal ничем не хуже, почему не протянуть его автоматом?
Форсят реактивные формы (теперь уже сигнальные), для декларативных форм удобства не завезли (есть сигнал со сложным объектом внутри - как раскидать его по writable сигналам на каждое поле?). Я вижу реактивные формы скорее как костыль из-за отсутствия каких-либо механизмов в шаблонах для сигналов или RxJs. А между тем, проблемы с типизацией control value accessor так и не решены, то есть проверка типов в форме не работает, инпут ждет число - мы даем строку и ничего - скомпилируется. А что есть важнее форм в вебе? Далее, ngModel принимает сигнал как функцию, в других местах шаблона надо явно вызывать, странно это, выглядит как-будто компилятор мог бы сам сгенерировать вызов там где надо, а нас избавить от шума скобок. Да и в целом эти модули форм надо бы выкинуть и переписать по-человечески.
Ситуация та же, что и с RxJs, интеграция с фреймворком минимальная, самая базовая. Почти десять лет понадобилось, чтобы в дополненение к async пайпу они добавили такой мизер как let в шаблоны, хотя у них в руках все возможности. В итоге, если кто-то использовал RxJs по максимуму - получал кучу приседаний, бойлерплейт, и вынужден был юзать сторонние либы и странные решения, чтобы как-то с этим бороться.
Взять такую банальную вещь, как ViewChild или сигнал viewChild, почему бы не прокинуть автоматически ссылку в класс компонента в виде поля (причем можно даже понять когда нужен массив), когда в шаблоне проставили # ? Зачем писать этот сигнал или декоратор руками каждый раз, импорты, да еще думать, когда его можно юзать, а когда еще рано? Если надо прям какой-то специфический селектор - тогда только определять руками. Аналогично можно было бы прокидывать эмиттер/сигнал из любого компонента шаблона в класс компонента (ну например #click="loginClick" и все, можно юзать в коде сигнал или емиттер this.loginClick, я даже колхозил нечто подобное, но без поддержки компилятора - не то). Это минус миллиарды строк кода.
Angular signals 101