Если у тебя есть функции в html или форма, то будет дергать cd

Хотел бы задать немного холиварный вопрос, только тапками не закидайте :) конечно, это больше момент субьективный, может я это зря спрашиваю, знаю, рискую :) но все же:

Какой вид ангулярной архитектуры делает фичу быстрее по времени разработки и проще в поддержке - с сервисной архитектурой или с ивентно-стейтовой (ngrx- ной)? Ибо давно идет борьба за onPush в обоих подходах, но к второму вдогонку акита/ngrx/etc, имхо, это более хлопотная кухня, требующая больших слоев абстракции, когда вьюха уже ничего не содержит и все push based, но эффекты раздуты от 30 строк, редьюсеров мильон и тележка, и все это может циркулярно файриться, что часто оч сложно отследить в таких гордеевых узлах, что приводит к адовым усилиям/времязатратам и явно повышенной сложности как архитектуры таки ее сапорта/впиливания новых фич. Вижу, есть евангелисты редаксового подхода, пытаюсь понять, в чем выгода проекта, который заранее начинает писаться к примеру с ngrx+graphql (суть больше о ngrx, но тут graphql еще свои добавляет слои), если он за 6мес разработки, превращаясь в франкенштейна, заставляет выгорать любого кто пытается его рефакторить чтоб упростить и так сложную многослойность такого проекта? Множественные лейзи сторы, константы/редюсеры/еффекты/проч файлы для всего этого добра - может ли быть разработка с этим подходом удобнее/быстрее/упрощаться на дистанции в сравнении с сервисным подходом, ввиду ее активного продвигания? И какая превалирует архитектура/структура проекта в таком ключе? Может есть по ентерпрайзу статьи под такие кейсы обьясняющие что ивент-based решает все проблемы что не решает сервисная архитектура итп?

То что cd вызывается меня не смущает, смущает то что при cd вызывается ngOnChanges с инпутом который не поменялся с прошлого cd

Мне тоже не сильно заходит редакс, так-то презентационные компоненты в обеих архитектурах одинаковые, отличаются только смарт компоненты, их обычно не прям так много, редакс конечно норм имеет смысл если надо стейт уметь откатить, то там их просто хранишь и откатываешь, при ошибках на сервер можно слать стейт и четко понимать в какой ситуации че и почему крашится, но это все теория) мне ни одним из этих фич не приходилось пользоваться)

Может @AlexOkrushko что подскажет

Тут без кода на разберёшься )

Ого, ngrx+GraphQL это что новенькое )

Спасибо за таг @danilgudz . Подскажу, но уже завтра 😀

Mike Ryan сделал твич с перезнацией, где он использовал обе библиотеки.
Это почти как Firebase + NgRx тоже. В теории можно, но нужна очень хорошая дисциплина и понимание что отвечает за что

я на данный момент только изучаю NgRx но уже понял что многие выражают мнение что сервисный подход является низкоуровневым. Так как проблема в том что компоненты знают что то о фиче данных, либо о какой то бизнес логике и потом эту бизнес логику сложно переиспользовать между различными компонентами, поэтому и нужно тоже состояние которое не будет связано ,и тогда компоненты становятся очень легкими и они просто сообщают состоянию что что то поменялось или им что то нужно. Получается идея в том что есть глобальное состояние для всего приложения , и соответственно всегда знаю как оно происходит, как обновить , как получить оттуда данные - и это считается высокоуровневым подходом при работе с данными. Но все-равно получается что  NGRx это всего лишь еще один подход для написание приложений , которые очень легко переиспользовать и вынести всю бизнес логику с компонентов.

Заходил такой проект на полное переписывание, т.к. там никто уже не мог его скейлить, все было запутано нереально.

Увидеть бы эту дисциплину расграничений на практике

Я бы не начинал с ивент-модели, но к ней можно прийти, если она нужна. Обычно это оверинжиниринг и все решается на уровне ангуляра без больших вложенностей.

Да, все упускают глобальное разграничения, хотя бы на уровне nx.

Это все понятно, мой вопрос больше в скорости разработки и более простой механике. Думаю тут многие согласятся, что часто для кейсов связки нескольких компонентов хватает сабжекта, а если прям интернет пропал то сервис воркером можно хендлить такие вещи. Драфты сохранять можно туда же или в indexed db, к примеру, мой последний кейс был в том что люди в возрасте постоянно рефрешат страницу что не дает ngrx стейту быть сохраненным например. Было бы круто посмотреть на пример архитектуры с ивентовой моделью которая может быстро разрабатываться/скейлиться :)

Оверинжиниринг - я также думаю, но тем не менее очень распространенное применение, значит эти слои решают определенные траблы - значит чемто жертвуют - вопрос в каких именно кейсах? Раньше думал, что либо забавы ради, либо изза поиска привычного реакта в ангуляре, но ведь дураков в бизнесе же нет, если принесли стейт то значит он решает задачу. Но помогает ли он разрабатывать быстрее? Делает ли код декларативней? Не хейчу. Хочу понять

Просто мы смотрим на свершившиеся проекты, которые выросли и были переписаны на такой подход. А те, что которые разрабатывались с начала на ивентах, не факт что вообще было нужно применять такой подход.

бизнес принес стейт? это как?

Бизнес согласился на стейт

ну ок наверно на самом деле несуть, но какие задачи решает стейт - это компонент коммуникацию + косистент датафлов