Д
у меня по итогу придет мессадж топ уровня, который предполагает изменение состояние компонента, как дальше этот мессадж должен быть обработан?
Size: a a a
2020 August 15
AD
имхо, у тебя сейчас реализация предполагает вкладывание одного стейта в другой - ок, но так не построить изоляцию
Д
понимаю, потому и спрашиваю возможно ли ее построить в принципе?
Д
когда мы имеем возможность на лету менять логику компонента, не очень мне это нравится, если это норм то ок
AI
AI
Msg это внутренний класс в модуле компонента. Input это публичное API компонента.
Д
но мы все еще вручную должны определить куда этот msg передать на обработку?
AI
но мы все еще вручную должны определить куда этот msg передать на обработку?
Так это же часть архитектуры. Если используете MVICore то в фичу опютправлять.
AI
Или какой-то свой Store
Д
но нет никакой защиты от того чтоб подменить обработку мессаджа?
AI
Зачем защита? Это же всё детали реализации компонента. Они все internal.
AD
но нет никакой защиты от того чтоб подменить обработку мессаджа?
конечно, открываешь IDE и меняешь реализацию)
Д
Зачем защита? Это же всё детали реализации компонента. Они все internal.
если Msg компонента будет internal то как я буду мапить input->msg?
AI
если Msg компонента будет internal то как я буду мапить input->msg?
Функцией, которая тоже internal и лежит в модуле
AI
internal val inputToMsg: (Input) -> Msg = { when(input) ... }
Д
Функцией, которая тоже internal и лежит в модуле
смысл в том, что вызывать редусер компонента или какой то другой редусер остается на совести у разработчика?
AI
смысл в том, что вызывать редусер компонента или какой то другой редусер остается на совести у разработчика?
Конечно
AD
смысл в том, что вызывать редусер компонента или какой то другой редусер остается на совести у разработчика?
нет!
AD
на совести автора компонента
разработчик извне не может подсунуть свой редьюсер
разработчик извне не может подсунуть свой редьюсер
AI
Ну и если добавить новый вариант Input то модуль не скомпилируется, если все when в мапперах exhaustive