AP
В таких случая точно лучше барьер абстрации ввести и вложенную сущность функциями нормально названными менять, не?
{ foo | bar = { foo.bar | baz = False } }
хуже, чем{ foo | bar = Bar.toggle foo.bar }Size: a a a
2019 October 30
AP
SG
согласен
MP
@maxfarseer
На примере модулей можно рассмотреть:
у вас есть App(у него model, update, view, subscribes, e.t.c.)
В рамках этого приложения есть условно Навигация Nav(со своими: model, update, view, subscribes).
Область видимости Nav только ее model, .. e.t.c.
И порядок действий приблизительно следующий:
1. Произошел update App, внутри него вы поняли, что надо обновить навигацию, и вызвали Nav.update и передали параметры Nav.Model, Nav.Msg
На примере модулей можно рассмотреть:
у вас есть App(у него model, update, view, subscribes, e.t.c.)
В рамках этого приложения есть условно Навигация Nav(со своими: model, update, view, subscribes).
Область видимости Nav только ее model, .. e.t.c.
И порядок действий приблизительно следующий:
1. Произошел update App, внутри него вы поняли, что надо обновить навигацию, и вызвали Nav.update и передали параметры Nav.Model, Nav.Msg
спасибо, попробую.
MP
@maxfarseer
На примере модулей можно рассмотреть:
у вас есть App(у него model, update, view, subscribes, e.t.c.)
В рамках этого приложения есть условно Навигация Nav(со своими: model, update, view, subscribes).
Область видимости Nav только ее model, .. e.t.c.
И порядок действий приблизительно следующий:
1. Произошел update App, внутри него вы поняли, что надо обновить навигацию, и вызвали Nav.update и передали параметры Nav.Model, Nav.Msg
На примере модулей можно рассмотреть:
у вас есть App(у него model, update, view, subscribes, e.t.c.)
В рамках этого приложения есть условно Навигация Nav(со своими: model, update, view, subscribes).
Область видимости Nav только ее model, .. e.t.c.
И порядок действий приблизительно следующий:
1. Произошел update App, внутри него вы поняли, что надо обновить навигацию, и вызвали Nav.update и передали параметры Nav.Model, Nav.Msg
я пока не вижу разделения на отдельные view в своем фрагменте, поэтому подумаю, если получится сформировать более точный вопрос - напишу
MP
то что в туториалах, где у нас, например, три страницы, у каждой свои view и update и model - понятно. А тут модель одна, в ней модалка (record), и в этой модалке нужно изменить значение поля.
AP
Поэтому не один update, а несколько осмысленно названых функций.
2019 October 31
MP
@erwert и @astynax я сделал пример с апдейтом "подмодели", кастомный тип Short / Detailed и type alias Submodel я здесь добавил для эмуляции рабочего кода (будем считать это условиями задачи). Это похоже на правду, или должно быть иначе? https://ellie-app.com/75cpwdtHn9Da1
MP
мне кажется, что что-то не так) много копипасты и мусора добавилось 🙁
AP
AP
Так. updateSubModel не должен принимать тот же Msg
AP
У подмодели свои сообщения
AP
Да и updateSubModel у вас принимает AppSubModel, а должен бы только SubModel!
MP
У подмодели свои сообщения
ок, взял в работу)
MP
У подмодели свои сообщения
но как потом в сообщение с кнопки модель родителя узнать? не могу уловить идею
AP
Э... зачем?
AP
Это же протечка абстракции!
AP
Если вложенный элемент должен что-то сообщить родителю — возвращайте из update
AP
update
: msg -> model
-> (model, Cmd msg, Maybe msgToParent)MP
так, об этом не думал. Спасибо за идею