Redux: путеводитель по стилю при подключении дополнительных компонентов к магазину

Question

Согласно Redux Style Guide, настоятельно рекомендуется к подключать больше компонентов для чтения данных из хранилища .

Например, вместо просто подключив компонент <UserList> и прочитав весь массив пользователей, <UserList> получит список всех идентификаторов пользователей, отобразит элементы списка как <UserListItem userId={userId}>, подключит <UserListItem> и извлечет свою собственную запись пользователя из store.

Это звучит несколько противоречащим тому, что было поощрено ранее в разделе «Использование с React» для отдельных презентационных компонентов из контейнера компоненты , где презентационные компоненты предназначены для чтения данных из реквизита, а не из хранилища.

Означает ли это, что:

1. Рекомендуется сохранять количество компонентов представления к минимуму, следовательно, увеличение количества компонентов с состоянием?
2. Или подключенные компоненты также могут быть компонентами без сохранения состояния?

Answer 1

Я сопровождающий Redux, и я написал страницу Руководства по стилю.

Краткий ответ: документы Redux были написаны с течением времени, и поэтому некоторые из старых страниц документации устарели. .

Руководство по стилю - это наш последний и актуальный совет о том, как написать приложение.

Мы переписываем основные документы Redux. Именно эту страницу «Использование с React» я собираюсь переписать очень скоро, и когда я это сделаю, я полностью отброшу термины «презентация» и «контейнер».

Я также призываю вас чтобы прочитать мой пост Мысли о React Hooks, Redux и разделении проблем и посмотреть мой доклад React Boston 2019 о Hooks, HOCs и Tradeoffs , чтобы получить больше мыслей о том, как меняются хуки как мы думаем о написании компонентов.

Answer 2

Как и все в программировании, баланс существует.

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

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

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

Redux позаботится об этом за вас, поместив этот код в редуктор. Если вы используете компонент высшего порядка connect(), это именно то, что вы делаете: создаете компонент для преобразования состояния для базового компонента презентации. Хуки useSelector() и useDispatch() являются еще одним способом сокращения кода управления состоянием в вашем компоненте.

Redux подчеркивает второй пункт, потому что цель Redux - уменьшить беспорядок до такой степени, что вам не нужно разделять код на компоненты представления и бизнес-логики c. Вместо того, чтобы передавать несколько подпорок назад и вперед, вы можете передать один ключ, сделать простую функцию внутри компонента для извлечения данных и перейти непосредственно к презентации.

Люди, написавшие Redux, также хотят убедите людей, что Redux довольно быстрый, и не бояться использовать его щедро.

Мой собственный опыт заключается в том, что Redux достаточно хорошо управляет стороной бизнес-логики c, что мне редко нужно создавать отдельную компонент обертки для бизнес логи c. Код состояния - это несколько строк, вызывающих зацепки сверху, и все.

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