React + Redux Container / Component: зависает от имени или отсутствует что-то основное. отношение?

zanerock спросил: 28 марта 2018 в 02:55 в: react-redux

Я пишу приложение React + Redux и разделяю свои контейнеры и компоненты таким образом, что все мои "простые" компоненты состоят из одной функции рендеринга со стилем.

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

Насколько я понимаю теорию здесь, это неудивительно, но с точки зрения стиля, мне кажется, что я нарушаю (по крайней мере, то, что понимаю), как конвенции. Даже конкретный пример кода Redux + React with Container / Component, по-видимому, только когда-либо импортирует, по-видимому, "простые" компоненты.

То, что я действительно хочу сделать, это что-то вроде: См. И организуйте основную точку входа объекты как "компоненты", поэтому import Foo from './components/Foo. Откажитесь от немого, отрисуйте только компоненты с классификатором типа "view", поэтому FooView, views/Foo или или что-то в этом роде.

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

Как самый простой пример, скажем, у нас есть Component components/views/Foo,

// src/components/Foo.js
import React from 'react';const Foo = (props) =>
   <div>
    Hello {props.userName}!
  </div>export default Foo

и связанный с ним контейнер Foo:

// src/containers/FooContainer.js
import { connect } from 'react-redux';
import Foo from '../components/Foo';const mapStateToProps = (state) => ({
  userName: state.sessionState.userName,
});export default connect(mapStateToProps)(Foo);

Затем выключить все:

import React from 'react';
import {render } from 'react-dom';
import AppContainer from './containers/AppContainer'render(
  <AppContainer />,
  document.getElementById('root')
);

Вопрос 1) В основном, я что-то пропускаю, импортируя и использую Container-Components всюду (в отличие от "Компонентов")?

Если это так, для работы, то именование всего, кажется, не работает ... Я видел несколько примеров, когда разработчики называют простые контейнеры и компоненты-контейнеры одинаковыми, и это нормально, но я все равно в конечном итоге ссылаюсь на FooContainer вместо ./containers, и все примеры всегда импортируют компоненты исключительно из ./components без суффикса базового имени (например, это всегда ./components, даже когда они ссылаются с использованием шаблона Container / Component и в других местах, давая явные примеры использования суффикса import Foo from './components/Foo или Container.

Вопрос 2) Итак, если я не неправильно понимаю основы здесь, то как все примеры всегда выглядят как ./containers? Есть ли какой-то шаг, который они не показывают, или я просто слишком висел в идее, что я должен (как соглашение) импортировать из import Foo from ./components/Foo?

Опять же, если Я до сих пор не отслежен, то, что я действительно хотел бы сделать, это обратиться к Container-Components как к самому основному компоненту и организовать их в ./components без суффикса. Например, components будет Container-Component, а затем простой компонент stateless будет находиться в каталоге components/Foo или что-то в этом роде, поэтому views или FooView был бы немым, компонентом только для визуализации.

Мое мышление заключается в том, что если компонент Container действительно является основной точкой входа, которая используется в 95% случаев, то это то, что я хочу скорее всего, вызовите "Компонент" и используйте специальный дискриминатор для того, что я фактически не использую.

Но я никогда не видел примера ничего, кроме вызова простых компонентов без учета состояния 'и сдержанный, способный "Контейнеры".


1 ответ

Есть решение
zanerock ответил: 20 мая 2018 в 10:21

После пары месяцев работы над итерациями этого, вот что я выбрал в качестве своего идеального соглашения об именовании:

  1. Компоненты представления, которые фактически делают рендеринг, становятся понятными имена. Например, UserDetail, UsersList, TodoDetail, TodoList и т. Д. Это идеально "чистые" компоненты, которые получают все данные через реквизиты, хотя они могут иметь некоторое внутреннее состояние, связанное с визуальным рендерингом (например, открыт ли рендеринг компонента или закрыт). Они должны быть самодостаточными и никогда не инициировать сетевые вызовы или касаться состояния избыточности (и, следовательно, не должны быть "чистыми", хотя это приятно). Компоненты представления могут составлять другие компоненты представления.

  2. Предоставляющие данные "контейнеры" реализуются через "компоненты более высокого порядка" (HOC). Например, пользовательские данные будут предоставляться через HOC withUser, который будет извлекать пользователя и устанавливать свойство user для UserDetail. Они содержат логику для выполнения сетевых вызовов, извлечения из избыточности или собственного состояния или сопоставления других данных контекста со свойствами для использования содержащимися компонентами.