Блог

Есть ли в ReactJS способ для компонента выяснить, кто его родитель?

РЕДАКТИРОВАТЬ 1: Независимо от преимуществ этого, есть ли способ?

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

Я попытался установить свойство «owner», и эта идея, похоже, работает, но мне интересно, каков наилучший подход?

например

 <Parent>
  <Child owner={this}/>
</Parent>
  

Затем в дочернем компоненте я могу сделать owner.method , и, похоже, он работает нормально. Я знаю, что это не настоящие отношения родитель / потомок, но это самое близкое, что я нашел в своих тестах.

Некоторые могут сказать, что обратные вызовы — более чистый способ сделать это, но отношения родитель / потомок для некоторых вещей (например, RadioButtonGroup и RadioButton) кажутся естественными, и, на мой взгляд, знание этих отношений пошло бы на пользу.

РЕДАКТИРОВАТЬ 2: значит, это невозможно?

Что мне не нравится в идее, что она не поддерживается, так это то, что HTML может быть помечен нулевым javascript — и это подразумевает функциональность по умолчанию — некоторые элементы должны иметь родителей — они определяются как дочерние элементы других элементов (например, ul и li). Этого не может произойти в JSX, потому что, если есть взаимодействие между элементами — должны быть события javascript, которые связывают компоненты вместе — каждый раз, когда вы их используете. Дизайнеры не могут просто написать синтаксис, подобный HTML, — кто-то должен вмешаться и вставить туда некоторые привязки javascript, что усложняет обслуживание. Я думаю, что идея имеет смысл для переопределения поведения по умолчанию, но поведение по умолчанию должно поддерживаться. И по умолчанию потребуется знать либо вашего родителя, либо кто ваш владелец.

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

TL; DR вы, вероятно, никогда не захотите этого делать.

Допустим, наш RadioButton имеет этот общедоступный интерфейс:

 <RadioButton active={true} onSelect={function(event){}}>text</RadioButton>
  

Мы могли бы создать другой компонент с именем SuperRadioButton, который мог бы иметь другой способ представления, но при этом иметь тот же общедоступный API, что и RadioButton, поэтому он является допустимым дочерним элементом RadioButtonGroup .

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

Обратные вызовы. Свойства владельца. Передача событий для перехвата корнем в дереве. Передача корня вниз через контексты.

Да, есть способы, но они противоречат концептуальной модели react, которая всегда должна быть явно сверху вниз. Короткая версия: «вы можете, но не делайте этого».

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

Это означает, что единственным исключением из этого является корень дерева компонентов, поэтому вполне законно передавать элемент этого элемента управления вниз в реквизитах или контекстах, а затем «передавать вещи», сообщая корню, который затем может перерисовать себя.

Поток прикладного уровня делает что-то не сильно отличающееся от этого, но полностью передает вещи за пределы иерархии компонентов в хранилище данных, которое передает вещи обратно с событиями.