React / Redux: События - современное состояние

Я думаю, что вам нужно знать не столько «Каково состояние дел», сколько «Каков канонический способ» публикации и подписки на React и Redux.

Короткий ответ: если у вас достаточно сложное приложение, вы должны организовать свой магазин таким образом, чтобы состояние приложения было разделено на срезов и использовать шаблон контейнера для разделения ответственность за публикацию и подписку. Таким образом вы избежите упомянутой проблемы, когда вы не знаете, что в кодовой базе меняет хранилище и что реагирует на изменения. Вы можете посмотреть на компонент контейнера и посмотреть, как он обрабатывает события пользовательского интерфейса от своих дочерних элементов и создает событие изменения состояния. Или вы можете увидеть, как контейнер обрабатывает изменение состояния, а затем развернуть иерархию. Если вы можете сделать так, чтобы срез Redux отвечал за один контейнер, гораздо проще думать о событиях. Все остальные компоненты не подписаны на события как таковые, вместо этого они получают изменения, которые им необходимо визуализировать, от реквизитов, происходящих из компонента контейнера. И они уведомляют компонент контейнера о своих собственных событиях через обратные вызовы, передаваемые через реквизиты, чтобы контейнер мог их опубликовать. Это может пройти долгий и долгий путь, и если вы чувствуете, что вам нужно передавать реквизиты слишком много уровней, вы можете использовать React.children, чтобы немного сгладить вложение, или в редких случаях контекст.

Более длинный ответ немного сложнее, поскольку публикация и подписка не имеют большого смысла, когда речь идет о React. React должен в конечном итоге отвечать за рендеринг. Как вы упомянули, не все события являются событиями пользовательского интерфейса. Но если вы моделируете вещи так, что все события, которые вы можете публиковать и подписывать, сводятся к смене магазина или реагированию на смену магазина, то вы можете создать свое приложение, ориентированное больше на Redux. Управление запросами и результатами, о которых вы говорите, должно осуществляться в простых модулях JavaScript без React. Затем вы можете использовать компонент контейнера, чтобы склеить хранилище с этим модулем.

Существуют дополнительные шаблоны, которые люди используют как создатели действий и селекторы. Это хорошо, потому что, по крайней мере, цель состоит в том, чтобы держать кодовые базы знакомыми. Но дела все еще движутся немного быстрее: React движется в сторону Hooks API и React-Redux , пытаясь наверстать упущенное . Но срезы и компоненты контейнера никуда не денутся, это естественный способ разделения проблем.

приставка для сохранения событий, повторный выбор / подключение для подписки на них ( https://github.com/reduxjs/reselect#connecting-a-selector-to-the-redux-store ) [112 ]

import { connect } from 'react-redux'
import { toggleTodo } from '../actions'
import TodoList from '../components/TodoList'
import { getVisibleTodos } from '../selectors'

const mapStateToProps = (state) => {
  return {
    todos: getVisibleTodos(state)
  }
}

const mapDispatchToProps = (dispatch) => {
  return {
    onTodoClick: (id) => {
      dispatch(toggleTodo(id))
    }
  }
}

const VisibleTodoList = connect(
  mapStateToProps,
  mapDispatchToProps
)(TodoList)

export default VisibleTodoList

Теперь у вас есть подписанное событие в качестве опоры в компоненте, компонент будет перерисовываться только при изменении опоры. Нет необходимости в mustComponentUpdate, поскольку ваш компонент не должен прослушивать весь магазин, он получит только ту часть магазина, которую вы определили в селекторе.