Комментарии 11
НЛО прилетело и опубликовало эту надпись здесь
правильно я понимаю что state — это [условно] глобальная переменная из которой достаются собственно эти юзеры итп?
Да, верно. Redux он про то, что есть огромный объект, который хранит абсолютно все данные вашего приложения и он иммутабелен. Ну, там потом вариации с multi-store есть, но общий смысл именно таков. Главные бонусы redux — это изменение стейта через маленькие редьюсеры и EventSourcing.
В вашем примере кажется все примерно то же самое, только в другой форме и другими словами :)
и вот и для выборки и для изменений хранилища не лучше ли использовать паттерн
Это похоже на линзу. А линза — это селектор + установка значения. Т.е. похоже )
подписать заинтересованные стороны на изменение
это то, что в redux делать mapStateToProps — эта функция создает компонент-обертку над вашим компонентом, в которой каждый раз когда стейт меняется — она достает из него нужные данные и перерисовывает с ними компонент. Изменился стейт, redux знает все места, где был mapStateToProps, вызывает эти места.
а state снаружи — это какая-то внутренняя кухня видная пользователю. Нет?
Не понял вопрос…
От себя добавлю, что мы в отличии от автора оригинальной статьи у себя вообще не используем Redux, обходимся выделением предметных областей и в них в соответствии с заветами DDD уже делаем хранение, предметные службы, прикладные службы, вот это все. А с JS/TS/React это подружить уже дело техники. У нас для передачи данных из домена в компоненты работает RxJS.
НЛО прилетело и опубликовало эту надпись здесь
Теперь понял :)
Да, подход, который вы предлагаете — хорош, и мы подобным как раз пользуемся(только не в самом UI, а в службах), и конечно этот storage должен быть инкапсулирован внутри домена, чтоб coupling не повышать.
Т.е. у нас есть слой хранения данных, он доступен только слою бизнес-логики, а слой бизнес-логики уже имеет порты для того, чтобы с ним UI связался. Упрощенная схема, в жизни чуть посложнее :)
Да, подход, который вы предлагаете — хорош, и мы подобным как раз пользуемся(только не в самом UI, а в службах), и конечно этот storage должен быть инкапсулирован внутри домена, чтоб coupling не повышать.
Т.е. у нас есть слой хранения данных, он доступен только слою бизнес-логики, а слой бизнес-логики уже имеет порты для того, чтобы с ним UI связался. Упрощенная схема, в жизни чуть посложнее :)
Более того, react-redux подход практически так и работает.
источник: redux.js.org/basics/usage-with-react
Есть некий глобальный Store (со своим глобальным State), а есть локальные State внутри каждого конкретного компонента. Глобальный State инкапсулирован в компоненте Provider, а все остальные компоненты добавляются как дочерние по отношению к Provider.
Компонент Provider подписывается на изменение внутри Store/State и отвечает за обновление всех подписанных (через high order component react-redux: connect()) компонентов.
Селектор – это маппер данных из глобального State в локальный State конкретного компонента (добавляется обычно через ту же функцию connect()).
При необходимости изменить глобальный State, кидается событие (event) с конкретным типом (action: redux.js.org/basics/actions). Это событие обрабатывается, изменяет глобальный State и приводят к оповещению всех подписанных на изменения и вызову селекторов (см. выше).
// глобальный Store (State)
const store = createStore(todoApp)
render(
<Provider store={store}>
<App /> <-- все дочерние компоненты, которые зависят от Store
</Provider>,
document.getElementById('root')
)
источник: redux.js.org/basics/usage-with-react
Есть некий глобальный Store (со своим глобальным State), а есть локальные State внутри каждого конкретного компонента. Глобальный State инкапсулирован в компоненте Provider, а все остальные компоненты добавляются как дочерние по отношению к Provider.
Компонент Provider подписывается на изменение внутри Store/State и отвечает за обновление всех подписанных (через high order component react-redux: connect()) компонентов.
Селектор – это маппер данных из глобального State в локальный State конкретного компонента (добавляется обычно через ту же функцию connect()).
При необходимости изменить глобальный State, кидается событие (event) с конкретным типом (action: redux.js.org/basics/actions). Это событие обрабатывается, изменяет глобальный State и приводят к оповещению всех подписанных на изменения и вызову селекторов (см. выше).
правильно я понимаю что state — это [условно] глобальная переменная из которой достаются собственно эти юзеры итп?
В оригинальной концепции используется понятие Store, у которого уже есть текущий State.
Этот Store создается в точности как Вы описали: let store = createStore(counter)
и на него вешается подписчик изменений: store.subscribe(() => console.log(store.getState()))
в первом же примере это показано: redux.js.org/introduction/getting-started
Но так как State внутри Store – неизменяемый, то при необходимости изменить какое-то значение внутри State создается новый объект State, соответственно подписчик (listener) вешается на изменение всего State.
А селекторы уже приводят текущий State к необходимой модели конкретного компонента.
В статье описан и осуждается оверинжениринг при описании мапперов(селекторов) для приведения одной модели к другой.
Если честно, уже давно не хватает статей с заголовками:
Мы слишком много используем redux
Почему не написано ничего про useSelector? Это же гораздо проще
Нормально проектировать модель — это супер идея! Я в восторге, автору респект.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Мы слишком много используем redux-селекторы