> The important word here is Web Components, which is like React or Vue components but using only standard HTML and JavaScript (no frameworks).
I wouldn't say that - Web Components (by themselves) do not allow you to write your view as a function of application state, which is the main draw of at least React.
But the initial use case of Web Components is to create a standard that allows developers to iterate on the web's built-in components (inputs, date pickers, etc.) without having to wait on the standards track, and FAST appears to intend to provide a number of such components.
(And there is more to such components than just styling (which is what Bootstrap provides) - it's behaviour, usability by people reliant on e.g. screen readers, an API to access its data, etc.
Ionic Stencil let’s you wrap webcomponents and turn them into React, Vue, or Angular components. MS should use that or do something of a similar nature. Otherwise there is a impedance mismatch between this and what most or used to.
Not quite, Ionic Stencil is library to helps build webcomponents. Since fast.design are webcomponents, they can be used in any with any framework, no wrapping required.
Handling data
React passes all data to Custom Elements in the form of HTML attributes. For primitive data this is fine, but the system breaks down when passing rich data, like objects or arrays. In these instances you end up with stringified values like some-attr="[object Object]" which can't actually be used.
Handling events
Because React implements its own synthetic event system, it cannot listen for DOM events coming from Custom Elements without the use of a workaround. Developers will need to reference their Custom Elements using a ref and manually attach event listeners with addEventListener. This makes working with Custom Elements cumbersome.
This is a pain point of React + web components, but I’ve heard they’re trying to solve it in the next major version. In the meantime, I built a wrapper that lets you use custom elements as if they were React components. [1]
Ah, thanks for the clarification. I know the developer of Framework7.io has a tool to take his components (not webcomponents though) and make them into React/Svelte/Vue native ones. So I kinda mixed the two tools together in my head.
> they can be used in any with any framework, no wrapping required.
That's the selling point, but is not quite true. At least a while ago there was still some ceremony needed at least in React. You could say that that's React's fault, but it doesn't really matter whose fault it is - Web Components are different from standard DOM elements, and thus need special treatment from frameworks that interact with standard DOM elements.
They're not different from built-in elements and don't need special treatment.
The way that frameworks that work well with web components do it is be not giving special treatment to things. Vue, Angular, and lit-html all treat built-ins and custom elements then same, and they have different syntax for setting attributes and properties.
React treats elements different from components and sets properties on React components and attributes on HTML elements, with no syntax to set properties on elements. Then it special cases a list of attributes so that things like `class` map to `classList`.
So... remove special cases, add general abilities, and it all just works.
They're different from built-in elements at least in the fact that they're not built-in - that is the problem with React, which works with a list of built-in components that are treated differently from React components. Which means React needs special treatment for Web Components.
Whether React should or should not be doing that is irrelevant; what's relevant is that as a developer, you need to be aware that you can't "just" use Web Components in any framework.
That seems a rather silly distinction to me: "They're a special case because they're not on React's list of special cases".
You've correctly pointed out that the special cases are the problem, but are putting the blame on the things that are not special cases instead of the thing doing the special casing.
This is fundamentally React's problem. It's the only major framework to even have issues here.
Sure, but if your standard is "it can work in React, just with some more work and downsides", then technically you can use Angular components in React as well.
tl;dr you'll still be doing the wrapping in practice.
I wouldn't say that - Web Components (by themselves) do not allow you to write your view as a function of application state, which is the main draw of at least React.
But the initial use case of Web Components is to create a standard that allows developers to iterate on the web's built-in components (inputs, date pickers, etc.) without having to wait on the standards track, and FAST appears to intend to provide a number of such components.
(And there is more to such components than just styling (which is what Bootstrap provides) - it's behaviour, usability by people reliant on e.g. screen readers, an API to access its data, etc.