Комментарии 4
У вас проблема с инкапсуляцией поведения для состояний отдельных Car. Отсюда и костыль в виде протокола Namespacable. Раз уж вы знакомы с чуваками из Point Free и их библиотеками посмотрите блок видео о Composable Architecture по теме Derived Behavior. И уберите этот костыль.
Спасибо за комментарий! Derived Behavior конечно же смотрели :) Если вы конкретно про этот пример, то тут скорее про переиспользование favorites: Set<Int> в двух разных модулях. Этому случаю у нас посвящен раздел "У модуля несколько родителей", а такой подход описан в блоке Computed Module State.
Конкретно использование Namespacable не считаем костылем, а просто одним из вариантов решения проблемы, никого не заставляем так писать :) Вот и вот примеры использования такого подхода в редаксе. В The Composable Architecture другой подход и у нас он упоминается в разделе "Иерархия экшенов".
Про инкапсуляцию в смысле механизма скрытия для UDF писали в одной из прошлых статей.
ReduxJS плохой пример потому, что он используется в окружении где нет мощи типов или даже чего-то подобного на enum свифта. Если что, то и имена экшенов там тоже текстовые. Вот пример Point Free где ребята правильным образом подводят к тому как извлекать поведение для списка однородных сущностей. Без странных вещей типа primary-secondary car, firstDriver - secondDriver.
А Namespaceble костыль потому, что эта подкапотая инфраструктура начинает фигурировать в вызове из вьюшки:
store.dispatch(CarActions.breakDidPress("primary"))
Вы в ReduxJS где то видели в дисптаче явно переданный namespace? там такого нет и близко.
В иерархии экшенов та же проблема, вы рассматриваете сферического коня в вакууме и хардкодите элементы списов перечисляя их руками типа как здесь
enum AppActions: Action {
case primary(CarActions)
case secondary(CarActions)
// other actions
}
А когда вы пишите экстеншн на AppActions
static func toPrimaryCarActions(action: AppActions) -> CarActions?
Это ж совсем дичь. В функциональной композируемой архитектуре вы либо ищите решения из этого мира, либо возвращайтесь обратно в привычный императивный мир MV* архитектур. И не говорите что потом всё переписали с CasePaths только потому, что в итоге выдернули кусок кода из TCA (который не сочетается с примерами редьюсеров, что вы писали выше) вообще не раскрыв тему pullback и извечения значений из enum. Советую пересмотреть PointFree и научиться делать сначала правильно, а потом изобретать велосипеды.
PS: То что вы не заставляете его использовать других - плохой аргумент, вы ж тут туториалы пишите. Человек который не понимаем причин и следствий потащит эту дичь в свой проект.
В приведенном вами примере из Point Free говорится о коллекциях, я говорил о случае двух отдельных модулей. Но как случай обобщения на n модулей и хранение их в коллекции пример хороший, спасибо.
По поводу namespace во вью, конечно namespace всегда можно вынести из вью, в случае Redux например в Action Creator. Но тема статьи же не про вью.
Касательно строгости функциональной архитектуры и правильных и неправильных подходов я, пожалуй, не буду комментировать :)
Модуляризация доменного слоя в UDF. Часть II