T
Потому что он воспринимается, как бойлерплейт
Size: a a a
2021 April 23
AN
в дашбит пошли дальше и отказались от контроллера в live_view )
T
Так рендерить json
AB
дальше, у нас почему-то есть разница - я не рассматриваю Phoenix.View как что-то локализованное и отвечающее исключительно за рендеринг.
если бы это было так - никакой put_view не был бы нужен.
если бы это было так - никакой put_view не был бы нужен.
T
LL
А как ты его будешь рендерить?
Вот тебе нужно вернуть по пути
Вот тебе нужно вернуть по пути
/user/1 объект юзера. Вызовешь Jason.encode(%User{}) просто?T
render_json(Jason.encode(...))
LL
В
MVC, контроллер владеет вьюхой и моделью, и их определяет.T
Или, опять же, как в рельсе, указать, на что отвечает контроллер, и просто по схожему пути положить .json файл, который автоматом рендерится.
T
По аналогии с jbuilder
AB
я вообще вырос на django, где никакой mvc не ставился в абсолют, а был просто
handler :: Req -> Resp, а дальше - что навертишь, то и будет.AB
какие контроллеры, зачем
T
Потому что куча одинаковых файлов SomethingView с одинаковым пустым бойлерплейтом
T
Это очень странно выглядит
T
Зачем...
AB
кстати, это реально интересная разница
AB
вот это
LL
Ну вот ты и обосрался, потому что любое новое поле в структуре
Или, например, у вас там на бэке произошло что-то, и теперь
Если бы у тебя была вьюха, которая рендерит
User сломает твоё апиИли, например, у вас там на бэке произошло что-то, и теперь
firstname и lastname лежат в одном поле nameЕсли бы у тебя была вьюха, которая рендерит
json с юзером, ты бы с лёгкостью смог бы сплитнуть name и не сломать старый апи. Без вьюхи у тебя это окажется либо в контроллере, либо в модуле User, что в любом случае протекание абстракцииT
Как мертвые души
T
Так а в чем проблема рендерить Presenter? И поправить Presenter