Ответ 1
Документация React-Native содержит краткий раздел о подходах к общении между компонентами.
Когда вы пытаетесь сделать что-то более сложное, чем родительское отношение parent- > child или child- > , существует несколько вариантов:
-
Шаблон диспетчера. Для истинной связи между братьями и сестрами (т.е. Когда два брата и сестры совместно используют родителя через композицию), вы можете иметь родительское управление в состоянии. Например, у вас может быть виджет
<MyConsole>
с<TextInput>
и<ListView>
, содержащий предыдущие входы пользователя, оба являются дочерними элементами виджета<Console>
.- Здесь
<Console>
может выступать в качестве менеджера. Когда значение<TextInput>
изменит его значение, вы можете использовать событиеonChangeText
, чтобы передать новое значение до родительского компонента<MyConsole>
, который затем обновляет свое состояние и передает его своим дочерним элементам.
- Здесь
-
Шаблон события (публикация-подписка). Помните, что компоненты - это просто объекты, поэтому вы можете использовать объектно-ориентированные подходы к общению между компонентами. В документах React указано, что:
Для связи между двумя компонентами, не имеющими отношения родитель-потомок, вы можете настроить свою собственную глобальную систему событий. Подпишитесь на события в компонентеDidMount(), отмените подписку на componentWillUnmount() и вызовите setState(), когда вы получаете событие.
- Здесь вы можете использовать обычную библиотеку публикации-подписки, такую как pubsub.js, чтобы при изменении одного компонента она только публиковала изменения и другие связанные компоненты могут прослушивать событие и обновлять себя. Это может быть очень эффективным подходом для небольших приложений.
-
Образец потока. Одним из недостатков чистой системы публикации/подписания является то, что отслеживать состояние становится сложно. Например, если у вас есть 2 компонента (например, EditTitle, EditBody), которые могут обновлять некоторые состояния, такие как сообщение электронной почты, тогда чистая eventing-система заканчивает передачу разных версий состояния, вокруг которых может возникнуть беспорядок с конфликтами, потому что нет "единого версии правды". Здесь происходит React подход к потоку. С потоком компоненты обновляют хранилище данных, которое отвечает за обновление и согласование данных (например,
EmailDataStore
), и затем магазин уведомляет компоненты обновленного состояния.- Итак, в вашем примере представление задачи выдало бы обновление (например, через публикацию или прямой вызов функции) в
TasksDataStore
, которое затем могло бы опубликовать событие, подобноеtasks-updated
его подписчикам. Панель задач и панель результатов подписываются на хранилище данных.
- Итак, в вашем примере представление задачи выдало бы обновление (например, через публикацию или прямой вызов функции) в
При настройке подписки лучше добавлять подписки после монтирования компонентов и, безусловно, удалять их перед отключением компонента (в противном случае у вас много сиротских подписчиков).