Состояние vs props для сценария с отдельным представлением и моделью данных

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

В моей текущей реализации данные получаются при вызове веб-службы и сохраняются в state компонента App в App.js. Компонент App размещает (отображает) другой компонент, называемый StackEditor, который действует как представление для this.state.components в компоненте App.

Элементы пользовательского интерфейса, отображаемые с помощью StackEditor, можно перемещать, и для синхронизации state с App я делаю это, как показано ниже:

<StackEditor
  components = {this.state.components}
  onLocationChanged = {this.handleLocationChanged} />

В handleLocationChanged я обновляю state:

handleLocationChanged(e, data) {
    this.setState(prevState => {
        // event data copied to state here
        return {components: prevState.components};
    });
}

Поскольку state теперь обновляется, это заставляет снова визуализировать StackEditor, поскольку его свойство components привязано к state как components = {this.state.components} (см. Фрагмент кода выше).

Все это работает, но теперь я начал сомневаться, правильно ли я делаю.

В1: Следует ли мне использовать state вместо props?

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

Q2: Можно ли разделить часть состояния между двумя компонентами в React?

Если я каким-то образом конвертирую StackEditor из получения компонентов из state вместо props, получу ли я уведомление об изменении состояния дочерним компонентом (StackEditor) в моем родительском компоненте (App)?

Q3: Кроме того, props более удобен в использовании, чем state в целом?

Когда я создал другой компонент, следуя рекомендациям HOC (https://reactjs.org/docs/higher-order-components.html), я обнаружил, что props легко перенаправляются на «завернутый» компонент, но не state. Если я предоставлю функцию для обратного вызова через свойство (как я сделал выше), «завернутый» компонент может легко вызвать его, даже не заметив, что он «завернут». Я не понимаю, как я могу легко уведомить «завернутый» компонент об изменении state в «оболочке» без написания дополнительного кода.

Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Навигация по приложениям React: Исчерпывающее руководство по React Router
Навигация по приложениям React: Исчерпывающее руководство по React Router
React Router стала незаменимой библиотекой для создания одностраничных приложений с навигацией в React. В этой статье блога мы подробно рассмотрим...
Массив зависимостей в React
Массив зависимостей в React
Все о массиве Dependency и его связи с useEffect.
0
0
72
1

Ответы 1

Если вы представляете свое приложение в виде дерева компонентов в хорошо спроектированном приложении, оно обычно выглядит следующим образом:

  • листья - это компоненты без состояния. Они решают как данные отображаются.
  • узлы - это компоненты с отслеживанием состояния. Они решают какие компоненты и данные отображать.

Q1: Should I be using state instead of props?

Это зависит от того, какая у вас категория компонентов (узел или лист).

Q2: Is it possible to share part of the state between 2 components in React?

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

Q3: Also, are props more convenient to use than state in general?

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

Также прочтите Определите, где ваше государство должно жить и Когда использовать redux.

Все это лишь практическое правило. В большинстве случаев у вас будут компоненты, которые имеют как state, так и props, потому что они управляют частями вашего приложения, но делегируют другие части своим дочерним элементам.

This all works, but now I started questioning if I'm doing it right.

Насколько я могу судить из предоставленного вами кода, это выглядит примерно так, как должно.

для № 2 вам не обязательно требуется сокращение для передачи состояния между двумя компонентами. Я не думаю, что всегда рекомендуется рекомендовать сокращение для базовых приложений реагирования. # 3 компонент без состояния все еще может получать реквизиты и обработчики, такие как onlcick и onchange, чтобы они могли контролировать вещи.

Omar 17.04.2018 20:22

@ Омар Я согласен, тебе не нужно постоянно сокращать. Но если вы хотите разделить состояние между компонентами, вы должны поднять его. И если вы обнаружите, что у вас довольно много состояний в компоненте верхнего уровня, возможно, пришло время для редукции, поскольку это хорошо документировано и поддерживается. К вопросу №3: Конечно, они могут вызывать обработчик, но все, что происходит при вызове, полностью контролируется компонентом, реализующим обработчик (который обычно является компонентом с отслеживанием состояния). Они не могут сами изменить состояние, это то, что я имею в виду под «контролем».

trixn 17.04.2018 20:59

Другие вопросы по теме