Трафарет: Пространство имен имен пользовательских элементов, чтобы избежать коллизий - PullRequest
2 голосов
/ 13 января 2020

Наша платформа построена на архитектуре микро-интерфейса с веб-компонентами. Для некоторых из них мы используем Stencil, это означает, что у нас есть несколько приложений Stencil на одной веб-странице. Кроме того, у нас есть библиотека пользовательского интерфейса, также построенная с использованием Stencil, которую мы хотим использовать в этих компонентах микро-интерфейса.

Мы хотели бы использовать библиотеку пользовательского интерфейса Stencil в качестве зависимости во время сборки от компонентов микро-интерфейса Stencil. , Но это в настоящее время невозможно из-за коллизий имен тегов:

Теоретически, два микро-интерфейса могут поставлять две разные версии библиотеки пользовательского интерфейса. Однако во время выполнения они будут сталкиваться, так как они оба пытаются зарегистрировать свои элементы пользовательского интерфейса с customElements.define. Конечно, этого не происходит, поскольку Stencil проверяет существующие имена перед регистрацией нового, но результат так же плох: первый загруженный компонент всегда побеждает, а если это более старая версия или другой API, другие компоненты сломается.

Решением будет размещение имен / префиксов имен тегов во время сборки или выполнения, но в веб-стандартах для этого нет ничего ( пока ). И хотя в Stencil есть опция конфигурации namespace, похоже, это не решает проблему такого рода.

С чистым ES6 мы могли бы по крайней мере сделать следующее (т.е. зарегистрировать пользовательский элемент с динамическим именем тега c):

export class InnerComponent extends HTMLElement
{
    static register(prefix) {
        customElements.define(`my-${prefix}-inner-component`, InnerComponent)
    }

    constructor() {
        super()
        this.shadow = this.attachShadow({ mode: "open" })
    }

    connectedCallback() {
        this.shadow.innerHTML = `<span>this is some UI component</span>`
    }
}

И я уверен, что мы могли бы использовать какое-то решение во время сборки с Webpack et c. чтобы достичь того же.

Но возможно ли что-то подобное с трафаретом? Или как еще это можно решить?

1 Ответ

1 голос
/ 17 января 2020

Мы сталкиваемся с подобной проблемой. Нашим решением было избежать связывания зависимостей и развертывать их как отдельные библиотеки. Поэтому, если A и B зависят от C, ни A, ни B не имеют компонентов C, и C включается в интерфейс как собственный ресурс сценария.

...