Create 0005-fabric-elements-api.md

[BalbinaK]

Rendered markdown: https://github.com/fabric-ds/issues/blob/rfc/fabric-elements-api/rfcs/0005-fabric-elements-api.md

[digitalsadhu]

Couple things to think about that come to mind.

• web components differ from other components (react etc) in that they are actual elements once upgraded on the page. They aren’t simply forwarding mechanisms. This means that many attributes probably shouldn’t just be forwarded to child tags. Complex Component apis might benefit from a more designed approach
• with web components it’s possible to extend native elements such as buttons and links. This might be an appropriate way to properly support the various attributes for the 1-1 type components (f-button button) type. It's a bit of a fugly interface but since we control both the class and the definition, this isn't something the user would be exposed to.

Eg.

class FancyButton extends HTMLButtonElement {
    constructor() {
        super();
        this.addEventListener('click', e => this.innerHTML = "I was clicked");
    }
}

customElements.define('fancy-button', FancyButton, { extends: 'button' });

[digitalsadhu]

Scratch that last point. Safari does not support customising built in elements in this way.

[benja]

I believe it's helpful to maintain consistency by naming attributes the same as we do in the other libraries. I believe we used naming standards in those that are comparable to those in HTML.

I also think this consistency goes for the components as a whole. I think the components in @fabric-ds/elements should be as identical as possible to those in React and Vue, and any other library we decide to support in the future.

[vsandvold]

This is a bit on the side of your question, but I wonder if there's a minimal requirement for components we implement in Fabric. If a f-button web component only wraps a button element with a class attribute, does it add enough value to justify the added complexity?

The DOM is already capable of rendering <button class="button button--primary">, if that is all <f-button type="primary"> would do. Adding a layer of JS around this will complicate SSR or force client-side rendering for behaviour that already exist.

Many web components will probably implements some extra behaviour, like form validation for input fields, and custom styling for checkboxes. And I clearly see the usefulness of having web components for that.

I'm sorry if this is off topic, but I would like to hear your thoughts on this. My main concern is that we use web components (and components in general) where it makes sense to encapsulate specific behaviour, and I believe there is a lower and upper bounds on the complexity it makes sense to implement with web components.

WDYT?

[stigkj]

👍

[vsandvold]

From my limited experience with web components, I can only say that it looks like WC libs try to be as transparent as possible, mimicing the behaviour and attributes of native HTML elements. That could also be a good strategy for components in other frameworks, to expose eg. an onChange prop in a Combobox component where an change event would be expected in a conceptually related select element.