Комментарии 2
В rxjs есть два способа управления потоком - императивный через подписки и субьекты, и декларативный через pipe и разные операторы. Когда эти два подхода смешиваются, то получается нечитаемая лапша, подписки в подписках, подписки, в которых делают next субъекты и прочее непотребство.
Особенно много боли возникает, когда из сервиса торчит публичный behaviorSubject. Проблема behSubject в том, что у него есть несколько способов записи значения (initial и next), а так же несколько способов чтения. И при развитии кода он становится мини god-объектом, на котором все завязывается. Половина проекта в него пишет, а другая половина читает. Дебажить и рефакторить это невозможно.
Когда только появились сигналы и было запрещено в effect и compute делать next, то я очень обрадовался. Это бывало неудобно, но принуждало писать хороший незапутанный код.
А linkedSignal - ещё хуже, чем behSubject. Потому что он кроме initial и set имеет ещё один источник изменений. С linkedSignal - мы вообще рехнёмся, потому что там никаких концов уже не сыщешь. В этом графе всё будет переплетаться.
Спасёт ситуацию только если они какой-нибудь крутой дебагер для этого дела напишут.
Я бы забанил linkedSignal линтером на первое время.
Ангуляр пытается внутри сигналов решить многие проблемы. Чтобы наружу торчало простое api. Если им удастся реализовать всю эту машинерию так, чтобы это было безопасно использовать, без мучительно отладки, то сигналы - это, конечно, очень удобно. И linkedSignal тоже. Но я пока не понимаю, как его дебажить.
Он очень удобен. Но это удобство такого же рода, как и глобальные переменные, например. Это очень удобно, пока тебе не надо понимать, что вообще тут происходит.
Судя по всему данный механизм введён просто из-за проблем реакции на изменения в effect, который вызывается не синхронно и пропускает все установленные значения в рамках одного синхронного куска кода и соответственно не обновляет зависимый сигнал (в примерах выше мы видим, что теперь такой проблемы нет). В общем расписать связку значений становится довольно мучительно. Мы в своём проекте решили, что signal будем использовать исключительно для тех данных, которые выводятся в шаблон. Но и это на самом деле не совсем решает проблему, т.к. приведение потоков к сигналами тоже работает не всегда как ожидается, т.е. например значение в сигнал может не попасть 1 раз 100 или вообще поток может преобразоваться в сигнал так, что значения не идут совсем. В таких случаях приходится переходить на новые решения, т.к. обернуть старое в toSignal = сломать.
linkedSignal: управлять связанным состоянием теперь ещё проще