Проекция контента в Angular или затерянная документация по ng-content

[s1im]

Данная техника называется transclusion, в Angular.js присутствовало в следующем виде docs.angularjs.org/api/ng/directive/ngTransclude

[s1im]

Мне, кстати, тоже не совсем понятно было почему информация по данной фиче так слабо упоминается в официальной документации (фактически не упоминается). Я сделал вывод, что подобные махинации местами противоречат задуманной архитектуре современного Angular-приложения.

[ItNoN]

Может быть. Но можно же по чуть-чуть убирать эту фичу, а они просто игнорируют ее

[s1im]

А мне наоборот больше понравилось то, что они решили не убирать эту фичу совсем — для тех кто работал с первым Angular или другими фреймворками, где такое в ходу, возможность использовать есть без всяких deprecated warnings. Но и рекомендаций по использованию данной фичи от разработчиков нет.

Из подмеченных мною минусов использования transclusion, не получается использовать стандартную передачу данных из компонента в компонент через Input/Output, приходится использовать redux-архитектуру или завязываться на сервисы.

[MisterN]

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

[Xuxicheta]

Тут можно еще про ContentChild/ContentChildren добавить.

[ItNoN]

Вы правы. Наверное, можно было. Статья бы была более полная

[Xuxicheta]

c ними и директивами можно творить много всякого интересного, как в mat-table

[stantum]

Отличное описание! Я давно хотел в этом разобраться, но не находилось времени/мотивации исследовать. А у вас прямо справочник получился.

[ItNoN]

Спасибо!

[Anastasia-A-Zhivaeva]

Спасибо за статью! В документации и правда эта возможность не раскрыта должным образом. Благодаря вашему описанию я смогла ее понять и даже применить в деле!

[ItNoN]

Я рад, что вам понравилась статья

[LastDragon]

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

Всё-таки правильнее будет сказать "ущербный" или, если более политкорректно, "подходящий для совсем простых случаев", самый большой косяк в нем это что он наследует контекст того места где определен (т.е. AppComponent), что например не позволяет сделать вот так:

// app.html
<my-select>
    <option>...</option>
</my-select>

// my-select.html
<select>
   <ng-content><ng-content>
</select>

Прикол тут в том что визуально все как бы нормально, но на самом деле если посмотреть внутрь angular-а то можно заметить что optionы регистрируются вselecte, но тут этого не происходит по очевидной причине (другой контекст) и рождаются всякие баги https://github.com/angular/angular/issues/26273 (впрочем <select> сам по себе тоже довольно сильно баганый...).

А еще нет никакого способа задать содержимое по умолчанию, что довольно часто нужно (см https://github.com/angular/angular/issues/12530).

Поэтому по сути годится только для иконок :(

[ItNoN]

Интересная информация. Я не знал, что теряется контекст. Спасибо вам.
Насчет содержимого по дефолту согласен. Пару раз очень бы пригодилось.

Мы используем ng-content в основном для layout компонентов. Например, у нас есть хедер, в котором должны быть разные компоненты в зависимости от страницы, но позиция у них одинаковая. И тут идеально подходит ng-content для нас. Так что по поводу «ущебрный» я с вами не совсем согласен.