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