Angular - Когда я должен использовать дочерние компоненты при передаче @input - PullRequest
0 голосов
/ 29 января 2020

Моя команда и я в настоящее время создаем библиотеку компонентов, используя Angular (v8.x). Мы хотим установить sh некоторые правила ведения домашнего хозяйства и сделать наши интерфейсы компонентов интуитивно понятными (ie. Согласованное именование входов и использование шаблонов).

Мы нашли между собой две школы мысли об использовании @ Входные и вложенные компоненты.

Наше делема может быть описано с использованием следующих (разбавленных) примеров

Пример компонента 1:

<our-component [hideChild]="childHidden"></our-component>

Пример компонента 2:

<our-component>
  <our-child-component></our-child-component>
</our-component>

В примере 1 компонент имеет @Input, который показывает и скрывает дочерний компонент, жестко запрограммированный в шаблоне.

В примере 2 , компонент добавляется (или нет) как дочерний (через ngContent).

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

Я проверил руководство по стилю angular, но ничего не могу найти укажите c на эту проблему.

Кто-нибудь знает о каких-либо ресурсах или имел опыт проведения этого различия? Я хотел бы услышать, как и почему вы реализовали это так или иначе.


Редактировать: В частности, я хотел бы окончания следующих утверждений:

" Использовать @Inputs над вложенными компонентами, когда ... " и " Использовать вложенные компоненты над @Inputs, когда ... "


Редактировать 2: Оценить я не могу выражая себя правильно. Вместе с нашей библиотекой компонентов мы упаковываем существующие angular компоненты материала, такие как mat-input. У нас есть компонент, который оборачивает компоненты mat-form-field, mat-hint и mat-input в наш шаблон. Наш компонент выглядит следующим образом:

<our-input
 [hideAssistiveText]="hideAssistiveText"
 [type]="inputType"
 [hint]="hint"
 [label]="label"
 [control]="control"
 ... and so on
 ></our-input>

Существуют варианты использования для этого компонента, в которых мы не хотим показывать подсказку. Таким образом, до тех пор, пока вы предоставите строку подсказки, our-input будет показывать компонент our-hint (который вложен в шаблон).

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

<our-input
 [hideAssistiveText]="hideAssistiveText"
 [type]="inputType"
 [label]="label"
 [control]="control"
 ... and so on
 >
   <our-hint label="{{hint}}"></our-hint>
</our-input>

И разработчик мог бы просто пропустить компонент our-hint, чтобы добиться того же.

Что мне нужно, так это какие-то четкие ресурсы о передовой практике, когда нужно использовать один метод над другим (если есть), или причины, по которым вы выбрали этот метод.

Ответы [ 2 ]

0 голосов
/ 29 января 2020

Из моего опыта есть пара случаев, когда я рекомендовал бы Пример компонента 1 сверх Пример компонента 2 .

  1. Существуют и другие входы и выводит, что родитель передаст ребенку (или может произойти в будущем).
  2. Как вы упоминали в своем посте, когда родитель всегда будет иметь один и тот же дочерний компонент и не предназначен для поддержка других типов детей.

Пример компонента 2 лучше в тех случаях, когда родитель должен быть родовым c и может иметь множество детей (или может в какой-то момент в будущем).

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

0 голосов
/ 29 января 2020

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...