Comments 9
Удивительно, как в реакте ты все время думаешь про то, чтобы ни дай бог не вызвать рендер лишний раз, в то время как в Ангуляре надеешься чтобы хоть как-то заработало и ты при этом не помер от вязанки 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() сигналами, логированием мутаций и подходами к дебагу.
Спасибо, что делитесь опытом! Такие обсуждения сильно повышают качество контента.
Angular signals 101