Eh bien, c'est un peu la belle chose sur les composants web. Si le navigateur les prend en charge de manière native, ils fonctionneront de manière native dans n'importe quel framework. Ce serait la même chose que d'utiliser un <input> dans Angular. C'est le navigateur qui en assure le rendu, pas le framework.
Il vous suffit d'indiquer à Angular que vous utilisez des éléments personnalisés qu'il ne connaît pas avec CUSTOM_ELEMENTS_SCHEMA .
Lorsqu'il s'agit de bibliothèques de composants Web comme Polymer, c'est une autre histoire.
Polymer 1.x utilise la spécification v0 de l'élément personnalisé, et s'appuie sur une logique personnalisée pour manipuler le DOM par le biais de Polymer.dom() . Il n'est pas compatible avec Angular sans l'aide d'un tiers, car Angular utilise des méthodes natives de manipulation du DOM au lieu de celles de Polymer. Il sera jamais être pris en charge par Angular, car la spécification v0 ne correspond pas à ce que les navigateurs mettent en œuvre.
Polymer 2.x utilise la spécification v1 des éléments personnalisés, que les navigateurs mettent en œuvre (ou ont déjà mis en œuvre). Il se comporte exactement comme les éléments ordinaires, et est donc naturellement pris en charge par Angular.
Tout ce que les bibliothèques telles que Polymer offrent en plus, comme l'estampillage de modèles et la liaison de données, peut ne pas fonctionner en mode natif.
TL;DR ;
Angular prend en charge de manière native les composants web conformément à la spécification v1.
Les bibliothèques (telles que Polymer) qui reposent sur des composants Web peuvent offrir des fonctionnalités qui ne fonctionnent pas dans Angular.
Si vous souhaitez utiliser Polymer et Angular ensemble, concentrez-vous sur Polymer 2.x, qui met en œuvre la spécification v1.
