Компоненты и контейнеры, что лучше прокидывать пропс или плодить больше контейнеров?
Всем привет.
Для себя определил стратегию использования чистых компонент реакт и контейнеров, которые линкуют редакс стейт.
В результате при развитии приложения получается , что я в одном контейнере могу группировать несколько компонент, которые в свою очередь могут использовать более простые компоненты, что по сути возвращает к ситуации с прокидыванием коллбеков в более простые дочерние компоненты сверху. Все бы ничего, но я начал задумываться, что это не самый лучший на мой взгляд вариант и стоит пока не поздно изменить архитектуру с (компонент1, компонент2... компонентН) -> контейнер1 -> слой1 , на (компонент1 -> контейнер1), (компонент2 -> контейнер2) (компонентН -> контейнерН) -> слой1 (где группируются уже все контейнеры)
что меня тревожит, уже сейчас я занимаюсь component should update оптимизацией и заставляю компоненты ререндериться только тогда когда это действительно нужно, и будет ли плюсом, если я буду использовать существенно больше коннектов к стору через контейнеры. Будут ли в этом плюсы или минусы.
Мой вопрос очень сильно субъективен, термины могут не соответствовать их документальному соответствию, готов детализировать информацию для тех, кто может помочь дельным советом.
Заранее благодарен участвующим.
в свое время тоже задался этим вопросом - большая часть туторилаов приводит пример похожий на то что описали вы, это прекрасно работает на todolist но в реальном проекте оборачивается контейрнером который прокидывает 20-30 пропсов
redux использует context то есть от большего числа connect вы ни в чем не проиграете
понятно что с рядом оговорок и опытов которые покажут как удобнее, но огромное дерево проекта мне однозначно не нравится, архитектура умный контейнер - глупый компонент однозначно да, но структура проекта которая хороша для todolist и которую очень многие копируют мне не нравится, точнее даже не она а ее слепое копирование
Олег Гамега: я для себя еще более глубокую структуру определил, названия возможно не столь актуальны, как то что я за ними преследую:
components - простые компоненты, элементы отрисовки, их комбинации
containers - обертка для компонента комбинации
layouts - слой на странице, его можно считать чем-то в виде набора контейнеров, предположим локальное меню страницы, настройки, контент
compositions - собственно страница, которая в себя включает хедер футтер и боди, которые сформированы в слоях (в некоторых реализациях я видел это как routes, а layouts подппапку routes)
На самом деле все просто: все что должно просто отображать данные(всякие инпуты тоже к этому относятся) - выносим в компоненты, все что должно получать, изменять данные - выносим в контейнеры.
таким макаром любой элемент не в его базовом состоянии будет контейтером. А компонентами останутся лишь абстракции типа <Button> которые ждут из стейта свое состояние, имя , экшены. Выглядит монструозно как-то.
davidnum95: у меня все редьюсоры мелкие, управляются через комбайнредьюсор
я просто делаю экшен, константы и редъюсоры под задачу, а потом нужные экшены передаю в компонент через редакс
Простой
