Презентационные компоненты Redux против компонента-контейнера

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

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

Компоненты контейнера

• Осознавая избыточность
• Состояние подписки на избыточность
• Отправка на редукс действия
• Сгенерировано реакцией-редукс
• Сосредоточьтесь на том, как все работает

Презентационные компоненты

• Не зная о редуксе
• Чтение данных из реквизита
• Вызывать обратные вызовы для реквизита
• Написано разработчиком
• Сосредоточьтесь на том, как все выглядит

Преимущества классификации компонентов

• Возможность повторного использования
• Разделение интересов

Подробнее читайте в этой статье.

Вот обобщенная версия различий, чтобы их было легко понять, хотя некоторые из них связаны с приведенным выше ответом,

Компоненты контейнера

• Обеспокоены тем, как все работает
• Отвечает за предоставление данных презентационным компонентам через свойства.
• Также отвечает за обработку изменений состояния, вызванных внутри компонента представления через свойства обратного вызова. Эти изменения состояния часто выполняются посредством отправки действия.

Пример:

class TodoApp extends Component {
 componentDidMount() {
 this.props.actions.getTodos();
 }
 render() {
 const { todos, actions } = this.props;
 return (
 <div>
 <Header addTodo={actions.addTodo} />
 <MainSection todos={todos} actions={actions} />
 </div>
 );
 }
}
function mapState(state) {
 return {
 todos: state.todos
 };
}
function mapDispatch(dispatch) {
 return {
 actions: bindActionCreators(TodoActions, dispatch)
 };
}
export default connect(mapState, mapDispatch)(TodoApp);

Компоненты презентации

• Обеспокоены тем, как все выглядит
• Используйте реквизит для отображения всего
• Не управлять состоянием вообще
• Не генерируйте действия, но можете принимать обратные вызовы, которые делают через реквизиты

Пример:

<MyComponent
 title=“No state, just props.”
 barLabels={["MD", "VA", "DE", "DC"]}
 barValues={[13.626332, 47.989636, 9.596008, 28.788024]}
/>

Вот как я это понимаю:

Компоненты презентации

заботиться о том, как все выглядит

Компоненты контейнера

компоненты с задействованной логикой

Однако после дальнейших исследований я понял, что такое разделение иногда не нужно, как упоминал Дэн Абрамов здесь: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

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

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

Поскольку в программировании нет жестких правил, библиотека компонентов пользовательского интерфейса React может иметь некоторую логику, тесно связанную с компонентом (то есть то, как он ведет себя, например, компонент ящика), и по-прежнему рассматриваться как компонент представления.