[FAST] Investigate new way of defining custom elements

[thepassle]

import { DesignSystem } from "@microsoft/fast-foundation"
import { fastAnchor } from '@microsoft/fast-components';

DesignSystem.getOrCreate().register(
    fastAnchor()
);

import { DesignSystem } from "@microsoft/fast-foundation"
import { allComponents } from '@microsoft/fast-components';

DesignSystem.getOrCreate().register(
    Object.values(allComponents).map(definition => definition())
);

export const fastAnchor = Anchor.compose({
    baseName: "anchor",
    template,
    styles,
    shadowOptions: {
        delegatesFocus: true,
    },
});

DesignSystem.getOrCreate().register(fastAnchor({prefix: "fluent"})) defines the anchor as <fluent-anchor></fluent-anchor>

[fredvisser]

Hey @thepassle - If someone was interested in helping with the above, do you have a particular approach in mind? Any gotchas or strategies to evaluate before jumping straight in?

[thepassle]

I don't have a particular approach in mind, no. The 'problem' with the way FAST now registers components, is that it's really hard to statically analyze, because they're just functions. They can be passed around, used in iterations/loops with different names, etc etc. I think we should first support a basic subset of possibilities before trying to catch all the ways to call a function. We can support more advanced usage later.

[bashmish]

There is another complexity to take into account - withElementDisambiguation. Given FAST is by nature very dynamic, I don't think the current static format of Custom Elements Manifest can be used to describe all FAST features, but maybe it's not really needed.

E.g. in our FAST starter-kit all things are pretty static, because they are just configured once and that's sufficient to ensure same prefix everywhere, while we don't use withElementDisambiguation as of now. But yeah, you still need to analyze all files where provideDesignSystem is called (fast-component package has a similar method provideFASTDesignSystem) and which components are registered. My experience with static code analyses is very little to see how complex that is, but looks doable.

[KingOfTac]

cc/ @EisenbergEffect In V2 of fast-element the method of registration is changing. I think the new way will lend itself better to static analysis, but I'm also not fully up to speed on the new API.