Custom elements

Five more short essays, part 4 of 5.

reference/svelte-v2.16.1/test/custom-elements

fixtures cover a real Svelte v2 compile target: a component can be built so it registers itself as a native custom element, usable in any page regardless of whether that page was built with Svelte at all.

ARKlight has no equivalent target. An

@component

is validated and expanded entirely within one build of one site --

state model

already covers how its state is scoped to that one call -- and nothing about it is designed to be registered as a standalone element another, unrelated page could import.

Why that's a fairly deliberate gap, not an oversight

A custom element has to carry its own runtime wiring wherever it's dropped in; ARKlight's one shared arklight.js is built for the one site that declares it, not for distribution to pages it never built.
None of the seven registered experimental features targets this either -- see experimental APIs for the full list.
The closest ARKlight gets to sharing a component across projects is sharing the Python function that builds it, the same plain-function reuse nav() demonstrates in hello site.

If a project genuinely needs a widget usable outside any one ARKlight build, that's a case for hand-written JS behind

script-extension

, not for stretching

@component

past the one build it belongs to.

Styling model

No component-scoped stylesheet pass, because no component boundary survives into the output.

Open

Preprocessing

No pipeline stage for a second authoring language, because the entry file is already plain Python.

Open

Sourcemaps and debugging

Nothing transformed to map back to, so --debug prints a real Python traceback instead.

Open

Build tooling

One CLI invocation instead of a bundler configuration, with sbom.txt standing in for build stats.

Open