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

Question

Каков современный уровень в React для реализации шаблона на основе событий (Publisher / Subscriber).

С одной стороны, у нас есть компоненты, которые прослушивают эти события.Некоторые из этих компонентов являются визуальными, например, диаграмма, которая рисует результат запроса, другие могут не быть визуальными, например, если мы хотим иметь компоненты, которые управляют запросами и результатами.

Из другого, любой компонент может генерироватьevents.

Наша первая идея - добавить в Redux полный список событий и их значений, а на каждом компоненте внедрить в shouldComponentUpdate () умный код, который останавливается, если компонент не прослушивает измененные события.

Это выглядит не очень элегантно, так как все компоненты слушают все события.Есть ли более элегантное решение (своего рода современное состояние)?

Конечно, мы хотим иметь возможность вернуться назад, перенести, сохранить состояние и все эти мелкие детали :-)

Answer 1

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

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

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

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

Answer 2

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

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, поскольку ваш компонент не должен прослушивать весь магазин, он получит только ту часть магазина, которую вы определили в селекторе.