Подключение дочерних компонентов для хранения против подключения родительского компонента для хранения и передачи реквизита

Question

После долгих поисков и работы с React и React Native. У меня все еще есть довольно смутное мнение, по которому лучше всего использовать и в каких ситуациях

1. Подключение родительского компонента к хранилищу и передача всех данных дочерним функциональным компонентам в качестве реквизита. Это то, что я сначала использовал, хотя и был «React», но довольно скоро я увидел, что по мере роста приложения количество логики, обрабатываемой этим родительским компонентом, начинает становиться слишком большим и грязным. Также дочерние компоненты начинают иметь своих собственных детей и так и пр.

2. Наличие родительского компонента (например, Screen), который будет работать, и каждый дочерний элемент, которому нужна информация из хранилища, будет подключен к нему. Это гораздо более «чистое» решение, но создаст много «дубликатов» подключений к магазину, которые не нужны.

Использование магазина Redux

Мой вопрос в целом, какой шаблон рекомендуется использовать и в каких случаях использовать, также было бы неплохо узнать, какова цена наличия большого количества подключенных (контейнерных) компонентов

Answer 1

Не уверен, что могу дать правильный или неправильный ответ на этот вопрос, так как у каждого есть свои плюсы и минусы.
Мое эмпирическое правило - подключать глубоко вложенные компоненты только тогда, когда их родители являются «доверенными лицами реквизита».То есть они принимают реквизиты только для того, чтобы передать их своим детям.

Если я могу цитировать (себя) из этот ответ :

Избегайте подключения компонентов, когдаВы можете и передать реквизиты детям, главная причина этого состоит в том, чтобы предотвратить зависимость от редукса.Я предпочитаю держать мои компоненты "тупыми", как я могу, и пусть они заботятся только о том, как все должно выглядеть.У меня есть некоторые компоненты, которые касаются того, как все должно работать, и эти компоненты в основном имеют дело с логикой и передачей данных дочерним элементам, это компоненты, которые я часто подключаю.

Когда я замечаю, что мое приложение масштабируетсяи некоторые из моих компонентов действуют как прокси-сервер реквизитов (я даже получил слово для этого! "Propxy"), то есть они получают реквизиты от своего родителя и передают их, не используя их, я обычно внедряю связанный компонент всередина дерева компонентов, поэтому я могу позволить компонентам «пропси» вниз по потоку дерева быть более легкими и тонкими

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

Что касается подключения компонента, то вы, вероятно, уже это понимаете.вы получаете быстрый доступ к состоянию Provider через контекст реагирования.

Редактировать
В продолжение вашего комментария:

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

Ну и оболочка connect HOCне будет вызывать повторную визуализацию, если предыдущий объект mapStateToProps совпадает с текущим возвращаемым объектом.так что никаких ненужных повторных визуализаций для вашего подключенного компонента не будет.
Более подробно о том, как он работает и как развивалась логика, вы можете прочитать в этой статье

Answer 2

Я использую первый вариант. Минусы, которые вы написали, верны, но я думаю, что таким образом легче отладить и понять поток данных.

Answer 3

Эффективно соединить несколько компонентов с помощью connect быстрее, чем получить все данные в одном контейнере и затем передать их дочерним элементам через props.Цитирую Дана Абрамова (создателя избыточности):

Оба подхода передачи реквизитов дочерним элементам или их подключения к хранилищу уместны, однако наличие вложенных компонентов connect () на самом деле даст вам большую производительность.Недостатком является то, что они немного более привязаны к приложению и немного сложнее в тестировании, но это не может быть большой проблемой.

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

Итак, окончательное решениележит на вас, если у вас есть несколько вложенных компонентов, тогда более читабельно и тестируемо иметь некоторые контейнеры, извлекающие данные и распространяющие их через props, но если производительность - это все, что имеет значение, тогда продолжайте и используйте connect во всех компонентах statefull.

Есть несколько ссылок, которые могут оказаться полезными:

• Это сообщение Reddit о подкомпонентах
• Это здоровостатья о том, как работает Redux