Comments 2
Спасибо за статью, подход интересен и реализация такой штуки весьма увлекательное занятие, обязательно поползаю по исходникам. Однако не вижу большого преимущества перед rxjs, а дополнительные байты тащить надо.
Плюс будет много копипасты чтобы, все онпуши заработали. У меня например все компоненты на онпуше и это будет неприятно.
Преимущество перед RxJ здесь в том, что тут гораздо меньше сущностей и как результат — это проще освоить, и по опыту – проще использовать в каких-то базовых сценариях, которые и составляют 90% всех случаев. Хотя может это именно у меня не заладилось с rxJs и всё время какой-то "write only" код выходит.
На самом деле создавать, альтернативу rxJs планов не было, а основным мотивом к созданию этой библиотеки был поиск простого способа реакции на изменения входных параметров компонента так, чтобы поведение компонента всегда им соответствовало например:
<greeter [userName]=”userName” [template]=”template”> </greeter>Здесь greeting=f(userName, template), и приветствие надо переделывать каждый раз, когда меняется один или несколько входных параметров.
Когда количество параметров растет, то такие зависимости ускользают из вида и получаются баги.
Конечно, можно было бы и rxJs здесь использовать, но это бы неоправданно усложнило код.
По поводу OnPush, явный changeDetection, нужен только если в компоненте есть асинхронное поведение, в синхронных компонентах все будет работать и с OnPush без явного detectChanges если включить immediateEvaluation.
Я так и не придумал способа того, как можно было бы получить доступ к changeDetector из библиотеки, что конечно бы упростило ситуацию.
Зато change detection вообще можно теперь отключить (.detach()) и всегда явно детектить изменения.
Отслеживание состояния компонентов в Angular c помощью ng-set-state