a
Что бы контейнер не создавать отдельно, компонент отдельно
Size: a a a
2020 October 22
c
Что бы контейнер не создавать отдельно, компонент отдельно
А ну хз
c
Можно же styled(MyComp)
Я так делаю
IA
Тут появляется проблема что все компоненты которые используются внутри придётся объявлять ДО. Хотя если это основной компонент а файле то значительно лучше если он идёт первый
2020 October 23
OR
а это ведь не ок, когда ui знает о данных в ридаксе? кейс - тема приходит с сервера, и нужно из этого ответа, который в ридакс записывается взять цвет. как быть?
c
а это ведь не ок, когда ui знает о данных в ридаксе? кейс - тема приходит с сервера, и нужно из этого ответа, который в ридакс записывается взять цвет. как быть?
это ж просто стм
c
юзай подход глупых-умных компонентов
и вроде ок
и вроде ок
OR
это ж просто стм
не понял, о чём ты. просто всегда передавать color пропом в ui?
a
можно селектнуть данные из редакса в ThemeContext
OR
ну да
везде будет <TextField color={tenantTheme.themeColor} />
в принципе, вроде и не зло, менять если что в одном месте.
в принципе, вроде и не зло, менять если что в одном месте.
OR
можно селектнуть данные из редакса в ThemeContext
хм... это разумно?
a
почему нет?)
OR
ну это по сути тот же селект, просто в другой обёртке.
OR
контекст-то он тоже должен будет взять откудато
a
нам нужно просто какой-то мост / слой / прослойку между стором и тупыми компонентами создать, что бы зоны ответственности разграничить
a
Плохо - не смешивать технологие, а доменные области
a
Технический интерфейс получения данных может быть любой, главное что бы использующие его домены имели явно выраженные границы
🦜
нам нужно просто какой-то мост / слой / прослойку между стором и тупыми компонентами создать, что бы зоны ответственности разграничить
контейнеры
🦜
хочется без контейнеров и чтобы не пихать внутрь компонента