We love @vaadin/web-components, but have some challenges within a large enterprise. Different teams, invitably, are using different versions of these components and these cannot be deduplicated.
The Scoped Custom Element Registry proposal aims to solve this problem. The community has created some functional user-land solutions which are based on this proposal:
An expirimental Polymer-based mixin has been created here: robrez/scoped-registry-polymer
However, there are a few finer details within vaadin-components which may elude scoped-registries.
DocumentOrShadowRoot
, for example to document.body
vaadin-combobox-overlay
vaadin-dialog-overlay
document.createElement('vaadin-text-field')
For these reasons note above, the repository has the following goals:
index.js
as the bare module entry-pointA typical vaadin usage would look like this:
npm i @vaadin/button
import '@vaadin/button';
render() {
return html`<vaadin-button></vaadin-button>`;
}
@scoped-vaadin
elements, instead, have this pattern:
npm i @scoped-vaadin/button
import '@scoped-vaadin/button';
render() {
return html`<vaadin24-button></vaadin24-button>`;
}
This repository is not mature. Ideally, versions here would align 1:1 w/ the underlying vaadin versions. There are unfilfilled goals herein; It is likely that changes need to take place when there may not be any underlying vaadin changes.
Below, you can find which underlying vaadin version is used
local version | vaadin version |
---|---|
v24.3.7-alpha.1 |
24.3.7 |
v24.0.0-alpha.1 |
24.0.0 |
v23.0.1 |
~23.3.8 |
v23.0.0 |
~23.3.8 |
v0.2.0 |
~23.3.8 |
v0.1.0 |
^23.3.7 |