KN
Size: a a a
2019 November 22
KN
1) Можно и не пересылать, есть же подписки
KN
2) А зачем сверять? Оно и так в памяти висит
KN
Ну а если хочется нормальных апдейтов, то есть и обсерверы, и передача по ссылке, и медиатор, и куча других паттернов и конструкций языков
KN
3) Опять же, либо подписки, либо апдейт данных в ответе
DT
есть ощущение, что мы убираем бойлерплейт в одном месте и получаем в другом 🙂
KN
есть ощущение, что мы убираем бойлерплейт в одном месте и получаем в другом 🙂
Вот тут согласен
DT
у меня к примеру на проекте нет особо пересечения между input или output type
KN
Но задача не столько в убирании бойлерплейта, сколько в снятии ограничений
DT
если делать админку с формами new/update – конечно он будет, и еще какой
KN
Всё же не везде они нужны
KN
у меня к примеру на проекте нет особо пересечения между input или output type
А у меня 3 разных способа апдейта одно и того же как раз из-за этого))))
KN
Потому что есть создание, когда удобно через input передать
KN
Есть апдейт по кнопке, когда нужно вычислать diff у инпута
KN
А есть действия (отдельные кнопочки) в интерфесе, которые уже отдельными методами
KN
И в итоге получается 3-4 разных дефинишена, которые отвечают семантически за одно и тоже
DT
В некоторых случаях это хорошо: допустим у пользователя есть email, и он может его поменять. При этом, если он делает это сам – то мы отправляем ему письмо-подтверждение, если же это делается через админку – то ничего подтверждать не надо. Выходит, что поле мы меняем одно и то же, но по разому, и хорошо, что для этого есть две разные мутации
KN
Как и в обычном ПО - это два разных контроллера
DT
.. две разных мутации, да 🙂
DT
сложно конечно без контекста сравнивать опыт на разных проектах