Каковы различия между @customElement и определениями компонентов на основе композиции в FAST?

Question

Насколько я понимаю, существует два (+) способа определения компонентов в FAST.

На вопрос ниже я дам свой ответ, хочу проверить, правильно ли я понимаю различия и есть ли что добавить.

Что я узнал на данный момент:

Один — мгновенное разрешение шаблонов и стилей

• расширение определения классаFASTElementот
• использует декоратор из@microsoft/fast-element
• оно должно содержать в своем названии
• его шаблон и стиль (пропущенный через@customElementдекоратор) немедленно разрешаются
• он не может расширить свое PartialFASTElementDefinition
• он не может получить доступ к при определении своего шаблона и стиля.

Пример псевдокода ( ):

      const counterStyles = css`/* ... */`;

const counterTemplate = html<NameTag>`<!-- ... -->`;

@customElement({
    name: 'name-tag',
    counterTemplate,
    counterStyles,
    shadowOptions:
})
export class NameTag extends FASTElement {
    @attr name = "Sally";

}

Два — расширяемый и ленивый шаблон и разрешение стилей

• расширение определения классаFoundationelementот@microsoft/fast-foundation
• оно не обязательно должно содержать-в его имени (так как перед ним будет стоять префиксDesignSystemэто зарегистрирует его)
• его шаблон и стиль определяются черезcomposeметод, который доступен компоненту через егоFoundationElementбазовый класс
• и шаблон, и стиль могут быть решены лениво
  • Преимущество ленивого разрешения заключается в том, что вы получаете доступ как к ElementDefinitionContextElementDefinitionContext , так и к расширяемому

Пример псевдокода (части из официальной документациичасти из официальной документации ):

      export class Counter extends FoundationElement {
    @attr count = 0;

    increment() {
        this.count++;
    }
}

/* if CounterDefinition wouldny be defined then expressions below would use FoundationElementDefinition instead*/
interface CounterDefinition extends FoundationElementDefinition {
    defaultButtonContent?: string;
    defaultButtonColour?: string;
}

const counterStyles = (
    context: ElementDefinitionContext,
    definition: CounterDefinition
) => css`/* ... */`;

const counterTemplate = (
    context: ElementDefinitionContext,
    definition: CounterDefinition
) => html`<!-- ... -->`;

export const counter = Counter.compose<CounterDefinition>({
    baseName: 'counter',
    counterTemplate,
    counterStyles,
    defaultButtonContent: "Count!",
    defaultButtonColour: "pink"
});

FoundationElementDefinition.Три/Один+ — Вроде Один, но без декораторов?

• насколько я понимаю, это в основном похоже на методOneно без декораторов, то есть он не может лениво разрешать свои стили и шаблоны.

Answer 1

Различия, которые вы называете, по большей части верны.

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

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

Этот второй механизм устарел в предстоящем выпуске 2.0/3.0. Причинами этого являются:

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

Пожалуйста, позвольте мне призвать вас прочитать этот выпуск: https://github.com/microsoft/fast/issues/5901 . Я более подробно рассматриваю проблемы и мотивы, связанные с этим вопросом, а также рисую картину будущего, которым мы являемся. работа над предстоящими новыми версиями.

Что касается определения и регистрации компонентов, вам следует принять во внимание несколько соображений:

• Учитывайте, является ли компонент одноразовым или предназначен для повторного использования.
• Если компонент предназначен для повторного использования, будет ли он повторно использоваться за пределами текущего приложения? Если да, то нужно ли будет его настраивать?
• Подумайте, должен ли компонент немедленно зарегистрироваться на платформе или потребитель должен контролировать время регистрации. Вероятно, это связано с предыдущими соображениями.