Ti
Просто модуль(и) лежит(ат) в фиче и редьюсеры с экншами экспортируются, редьюсеры собираются в рут редьюсере, а экшны импортируются там где надо, по-моему близко к эффекторовской модели, правда пожирнее по понятной причине)
Size: a a a
2020 June 11
Ti
Но место в структуре практически то же самое
P
1. при иморте редюсеров ломается сплит бандла
ну или это решается через динамическое добавление редюсеров, но как по мне костыль
2. селекторы должны знать о состоянии всего стора, это нарушает модульность
ну или это решается через динамическое добавление редюсеров, но как по мне костыль
2. селекторы должны знать о состоянии всего стора, это нарушает модульность
P
3. компоненты внутри фич мне надо привязывать к редаксу, это опять же привязанность к глобальному стору
P
Можно конечно создавать несколько редакс-сторов и в целом в этом нет ничего плохого
просто с эффектором это делается чуть проще, меньше кода в итоге
просто с эффектором это делается чуть проще, меньше кода в итоге
P
если бы не эффектор, я бы сделал мультистор на редаксе
написать фабрику которая запускает переданные ей эпики с нужными обертками не проблема
написать фабрику которая запускает переданные ей эпики с нужными обертками не проблема
P
Сейчас у меня в фичах vue-компоненты тупо импортируют нужные сторы, некоторые параметры они конечно через пропсы получают
P
Типа у меня есть фича заявки
там всякие сторы и эффекты для загрузки и обработки заявок и компоненты которые отображают список заявок и конкретную заявку
там всякие сторы и эффекты для загрузки и обработки заявок и компоненты которые отображают список заявок и конкретную заявку
P
Вне фич у меня есть компонент который подключает эту фичу и передает активную заявку в компонент заявки через просы
этот компонент находит заявку из стора заявок в зависимости от пропа через useStoreMap
этот компонент находит заявку из стора заявок в зависимости от пропа через useStoreMap
AI
1. при иморте редюсеров ломается сплит бандла
ну или это решается через динамическое добавление редюсеров, но как по мне костыль
2. селекторы должны знать о состоянии всего стора, это нарушает модульность
ну или это решается через динамическое добавление редюсеров, но как по мне костыль
2. селекторы должны знать о состоянии всего стора, это нарушает модульность
2) селекторы скорее знают, по какому пути находятся данные в объекте. они не знают, что это весь или не весь стор
AI
3. компоненты внутри фич мне надо привязывать к редаксу, это опять же привязанность к глобальному стору
аналогично и с эффектором
P
Это да, можно фабрику селекторов сделать, которая получает селектор для нужной фичи и уже оттуда берет стейт
P
Но опять же, это лишний код кмк
Ti
1. при иморте редюсеров ломается сплит бандла
ну или это решается через динамическое добавление редюсеров, но как по мне костыль
2. селекторы должны знать о состоянии всего стора, это нарушает модульность
ну или это решается через динамическое добавление редюсеров, но как по мне костыль
2. селекторы должны знать о состоянии всего стора, это нарушает модульность
1) Да, редьюсеры все подтянутся, с ними еще типы экшнов, а остальное то как в бандл попадет?
2) Во-первых, у фичи свои селекторы, во-вторых в каждом селекторе инкапсулируется часть пути по стейту, то есть каждый из них о цельной структуре и о самом сторе не знают
2) Во-первых, у фичи свои селекторы, во-вторых в каждом селекторе инкапсулируется часть пути по стейту, то есть каждый из них о цельной структуре и о самом сторе не знают
AI
Это да, можно фабрику селекторов сделать, которая получает селектор для нужной фичи и уже оттуда берет стейт
звучит как переусложнение
Ti
А в чем смысл фабрики такой?
P
А в чем смысл фабрики такой?
что бы в каждом компоненте не писать useSelector(state => mySelector(state.myFeature))
Ti
Если у тебя есть комбинированные фичи, ты вероятнее всего туда импортируешь сторы из соседних фич, чем это отличается от прямого импорта селекторов
P
в случае UI-слоя еще жить можно
Но часто стейт нужен в эпиках
Но часто стейт нужен в эпиках
P
опять же , с редаксом все это работает, но мне не нравится писать много кода )