Д
то есть у нас есть модели которые entity, а есть модели которые состояния экранов?
Size: a a a
2020 August 13
Д
и все это domain модели?
Д
а как быть с мапингом domain моделей в ui модели? будет domain модель состояния экрана которая мапится в ui модель состояния экрана?
ML
а как быть с мапингом domain моделей в ui модели? будет domain модель состояния экрана которая мапится в ui модель состояния экрана?
она может мапиться, но уже на presentation слое - в функциях вьюшек
ML
как правило, там есть корневая функция, которая умеет рендерить экран - она будет использовать доменную модель и конвертировать в UI модели для тех подфункций, которые переиспользуются на других экранах
ML
либо отбирать куски доменной модели. для тайтла там, например
Д
а есть где то описание как mvu соотносится с clean?
ML
так вот же
ML
Переслано от Mikhail Levchenko
State и Reducer это ± domain слой
ML
Переслано от Mikhail Levchenko
presentation слой - это view (у меня функции, оканчивающиеся на Screen)
ML
Д
+- это как?
AM
состояние экрана это domain?
В чае ж нет разделения между стейтом экрана и остальным стейтом.
ML
В чае ж нет разделения между стейтом экрана и остальным стейтом.
для clean этого не нужно
Д
В чае ж нет разделения между стейтом экрана и остальным стейтом.
не суть
AM
Я не вижу, чтобы чай ложился хорошо как презентейшн слой в клин
ML
+- это как?
это значит "можно на это ориентироваться, но не стоит тащить свои clean привычки кроме dependency rule"
AM
для clean этого не нужно
Ну как сказать, обычно есть стейтфул презентер / вм / etc, и есть стейтфул репозитории.
ML
Ну как сказать, обычно есть стейтфул презентер / вм / etc, и есть стейтфул репозитории.
но это не обязательно =)
ML
скорее издержки сложившихся обстоятельств