React и Redux: есть ли проблемы с производительностью / возможные побочные эффекты при передаче родительского компонента в качестве поддержки его дочерним элементам?

Question

Я рассматриваю некоторый код в кодовой базе React-Redux, и довольно много случаев, когда родительский интеллектуальный компонент передается в качестве опоры дочернему компоненту:

import React from 'react';
import Child from '../components/Child';

export default class Parent extends React.Component {
    constructor(props) {
        super(props);
    }
    //...

    render() {
        return <Child parent={this}/>;
    }
}

На первый взгляд кажется, что цель здесь состоит в том, чтобы представить реквизиты / состояние / методы родителя дочернему компоненту. Этот вид идет вразрез со многими шаблонами проектирования, которые я использовал в прошлом с React, но я не уверен, стоит ли это упоминать в обзоре кода (он уже развернут в QA). Технически это работает (дочерний процесс может вызывать this.props.parent [метод] и т. Д.) И значительно сокращает количество строк кода, которые требуются в противном случае, если вы передаете отдельные обработчики / фрагменты состояния props / (local) дочернему элементу. Я знаю, что есть недостатки (в одном случае родительское свойство имеет то же имя, что и редуктор, поэтому в дочернем компоненте неясно, относится ли this.props ['reducerName'] к компоненту React или отображенному фрагменту состояние), но я не могу быть уверен, что недостатки это нечто большее, чем уровень поверхности.

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

Answer 1

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

• Это создает очень тесную связь между родителем и компонентом. Далее, мы должны попытаться предоставить минимальный объем данных для абстрактных модулей. Мы называем это принцип наименьших привилегий . Здесь, большая часть информации передается дочернему компоненту, который не будет использоваться и может даже злоупотребляться многими способами.

• Один случай, когда это может быть очень плохой идеей, это когда дочерний компонент что-то меняет в объекте даты: например:

  render() {
      return (
        <React.Fragment>
          <ChildOne parent={this}/>;
          <ChildTwo parent={this}/>;
        </React.Fragment>
     )
  }
  

  Теперь компонент ChildOne может делать что-то вроде:

this.props.parent.clickHandler = this.anotherHandler

Это нарушит ChildTwo функциональность.