@scoped-vaadin/web-components

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.

Challenges

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:

• lit
• open-wc

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.

• Some Vaadin components teleport to a different DocumentOrShadowRoot, for example to document.body
  • vaadin-combobox-overlay
  • vaadin-dialog-overlay
• Some Vaadin components dynamically create elements, for example
  • document.createElement('vaadin-text-field')
  • This would need to be created via the shadowRoot containing a scoped registry
• Would need to come up with some meta-data around which elements should be scoped on a per-package-level
  • This could be done relatively easily, but would need to happen

Goals

For these reasons note above, the repository has the following goals:

Immediate

• Register alternative tag names which contain Vaadin's major version identifier
  • Registrations are performed conditionally, with the intent of not crashing the app
  • This still allows multiple versions of a given component to exist, but they should at least be compatible

Near term

• Introduce index.js as the bare module entry-point
• Separate side-effects from exports

Long term

• Create scoped registries in each shadow root

Usage

A typical vaadin usage would look like this:

1npm i @vaadin/button

1import '@vaadin/button';
2
3render() {
4  return html`<vaadin-button></vaadin-button>`;
5}

@scoped-vaadin elements, instead, have this pattern:

1npm i @scoped-vaadin/button

1import '@scoped-vaadin/button';
2
3render() {
4  return html`<vaadin24-button></vaadin24-button>`;
5}

Version Matrix

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