Лучше ли отправлять избыточное состояние детям в качестве реквизита или чтобы дети могли напрямую читать из избыточного состояния? - PullRequest
Новая
       6

Лучше ли отправлять избыточное состояние детям в качестве реквизита или чтобы дети могли напрямую читать из избыточного состояния?

0 голосов
/ 24 февраля 2019

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

Сценарий: Компонент панели мониторинга получает избыточное состояние через соединение.Некоторые данные передаются через панель управления и ее дочерние элементы.Некоторые данные относятся к дочерним элементам панели мониторинга.

Вопрос: Должен ли я всегда передавать реквизиты дочерним компонентам (что-то), как показано ниже, илия должен всегда подключать дочерние компоненты к редуксу и читать необходимые данные непосредственно из состояния редукции? 

import React, { Component } from "react";
import { connect } from "react-redux";
import ChildOne from ".ChildOne";
import ChildTwo from ".ChildTwo";

class DashboardExample extends Component {
  render() {
    const { sharedData, childOneData, childTwoData } = this.props
    return (
      <div>
        <h1>{sharedData.selectedDate}</h1>
        <ChildOne sharedData={sharedData} childOneData={childOneData} />
        <ChildTwo sharedData={sharedData} childTwoData={childTwoData} />
      </div>
    );
  }
}

const mapStateToProps = state => ({
  sharedData: state.dashboardData,
  childOneData: state.childOneSpecificData,
  childTwoData: state.childTwoSpecificData,
});

export default connect(mapStateToProps)(DashboardExample);

1 Ответ

0 голосов
/ 24 февраля 2019

Как сказал Дэн Абрамов, приятно иметь разделение между презентационными компонентами и компонентами контейнера.

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

  1. как все выглядит.

  2. Может содержать как презентационные, так и контейнерные компоненты ** внутри, и, как правило, иметь некоторую разметку DOM и свои собственные стили.

  3. Часто разрешать сдерживание через this.props.children.

  4. Не иметь зависимостей от остальной части приложения, например, от избыточных действий или хранилищ.

  5. Не указывайте, как данные загружаются или изменяются.

  6. Получайте данные и обратные вызовы исключительно через реквизиты.

  7. Редко имеют свои собственныесостояние (когда это происходит, это состояние пользовательского интерфейса, а не данные).

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

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

  1. Относится к тому, как все работает.
  2. Может содержать как презентационные, так и контейнерные компоненты ** внутри, но обычно не имеет собственной разметки DOM, за исключением некоторых упаковочных элементов div, и никогда не имеет стилей.
  3. Предоставление данных и поведения для презентационных или других контейнерных компонентов.
  4. Вызовите действия по редукции и предоставьте их как обратные вызовы для презентационных компонентов.
  5. Часто с состоянием, как онислужить источниками данных.
  6. Обычно генерируются с использованием компонентов более высокого порядка, таких как connect () из React Redux, createContainer () из Relay или Container.create () из Flux Utils, а не пишутся вручную.

исходное сообщение

————————————

Конкретный ответ на ваш вопрос:

Я считаю полезным придерживаться принципов, изложенных выше.Это упрощает анализ вашего кода и помогает разделить проблемы (Представления / Бизнес-логика).Но, если вы обнаружите, что пишете спагетти-реквизиты, чтобы придерживаться его, или если это не кажется естественным в определенном фрагменте кода, просто подключите ваш презентационный компонент.

...