Архитектура угловых интеллектуальных (контейнерных) / немых (презентационных) компонентов, условная логика и распространяющиеся входные данные

Question

Рассмотрим два тупых компонента, A и B. Один из A ИЛИ B будет показан компонентом C, который используется в интеллектуальном компоненте D.

  D (smart)
  |
  C (dumb)
 / \
A   B (both dumb)

A иB оба имеют 10 входов каждый.Я вижу, по крайней мере, несколько способов справиться с этим:

1. Пусть C возьмет 20 входов, которые будут объединением входов компонентов A и B, хотя я использую только половинуиз этих входных данных

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

3. "Спроецировать" компоненты A и B, используя C для выбора TemplateRef или аналогичного, а затем связать только входы в D и дать D решить, какой из них показать

4. Попробуйте объединить части входов в более крупные «объекты ввода».Кажется, что это усложнит привязку данных, поскольку A и B будут уведомлены только об изменении «объекта ввода» и не будут знать специфику того, что изменилось, если у меня не будет другой логики внутри этих компонентов.

Существует ли передовая практика или обычная практика обращения с этой ситуацией?Аналогичная проблема возникает для выходов A и B, и обе ситуации возникают при использовании любого двухстороннего связывания данных!

Я пробовал искать все вокруг и даже пытался искать рекомендации для React вместо Angular,но безрезультатно.

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

Answer 1

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

Если компоненту "C" не требуется какая-либо информация, связанная с "A" или "B", то он вообще не должен обрабатывать ее.

Общая службаможет иметь около 20 элементов данных, а также Subject или BehaviorSubject для «A» и «B» для передачи изменений обратно на «D».

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

В последнее время я начал использовать Redux с большим успехом,когда простая привязка слишком проста.Я нашел ngrx / store немного суетливым, сложным в использовании и плохо документированным, несмотря на то, что он получал много прессы, и обнаружил, что angular-redux (тонкая оболочка Angular поверх реальной библиотеки Redux) проще в использовании, и он имеетлучшая документация.