Мы слишком много используем redux-селекторы

[@KwI]

правильно я понимаю что state — это [условно] глобальная переменная из которой достаются собственно эти юзеры итп?

Да, верно. Redux он про то, что есть огромный объект, который хранит абсолютно все данные вашего приложения и он иммутабелен. Ну, там потом вариации с multi-store есть, но общий смысл именно таков. Главные бонусы redux — это изменение стейта через маленькие редьюсеры и EventSourcing.

В вашем примере кажется все примерно то же самое, только в другой форме и другими словами :)

и вот и для выборки и для изменений хранилища не лучше ли использовать паттерн

Это похоже на линзу. А линза — это селектор + установка значения. Т.е. похоже )

подписать заинтересованные стороны на изменение

это то, что в redux делать mapStateToProps — эта функция создает компонент-обертку над вашим компонентом, в которой каждый раз когда стейт меняется — она достает из него нужные данные и перерисовывает с ними компонент. Изменился стейт, redux знает все места, где был mapStateToProps, вызывает эти места.

а state снаружи — это какая-то внутренняя кухня видная пользователю. Нет?

Не понял вопрос…

От себя добавлю, что мы в отличии от автора оригинальной статьи у себя вообще не используем Redux, обходимся выделением предметных областей и в них в соответствии с заветами DDD уже делаем хранение, предметные службы, прикладные службы, вот это все. А с JS/TS/React это подружить уже дело техники. У нас для передачи данных из домена в компоненты работает RxJS.

[@KwI]

Теперь понял :)

Да, подход, который вы предлагаете — хорош, и мы подобным как раз пользуемся(только не в самом UI, а в службах), и конечно этот storage должен быть инкапсулирован внутри домена, чтоб coupling не повышать.

Т.е. у нас есть слой хранения данных, он доступен только слою бизнес-логики, а слой бизнес-логики уже имеет порты для того, чтобы с ним UI связался. Упрощенная схема, в жизни чуть посложнее :)

[@AndreyRubankov]

Более того, react-redux подход практически так и работает.

// глобальный 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 и приводят к оповещению всех подписанных на изменения и вызову селекторов (см. выше).

[@AndreyRubankov]

правильно я понимаю что 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 к необходимой модели конкретного компонента.

В статье описан и осуждается оверинжениринг при описании мапперов(селекторов) для приведения одной модели к другой.

[@Staltec]

Если честно, уже давно не хватает статей с заголовками:

Мы слишком много используем redux

[@KwI]

Согласен, согласен :) Но это всего-лишь перевод, который мне захотелось сделать из-за момента, в котором автор приходит к DDD и надеюсь приходит к пониманию, что инструмент(в данном случае redux) вторичен.

[@777Polar_Fox777]

Почему не написано ничего про useSelector? Это же гораздо проще

[@KwI]

Ну, потому что автор оригинальной статьи не написал про useSelector :)
От себя добавлю — потому что статья не про инструмент, а про идею.

[@OldVitus]

Нормально проектировать модель — это супер идея! Я в восторге, автору респект.