a588ed42ce
mara: 'wait the common styles is literally just the button stuff? pls make a button component now as part of this pr and replace the usage in the modal. replacing all usages and finally removing the btn styles from common css is a follow up then.' <hive-btn> (hive-btn.js) is a customized built-in <button is="hive-btn"> with its own shadow root -- extending HTMLButtonElement keeps every native button behaviour (click/keyboard activation, :disabled, form participation) instead of re-implementing it on a generic wrapper. Shadow root holds only an adopted stylesheet + a <slot>, so the button's light-DOM content (label, or asyncBtn's swapped-in spinner span) renders through unchanged -- slotted content stays styled by the light-DOM cascade, so the global .spinner class still applies. Variants (cancel/confirm/danger) are a 'variant' attribute, not a CSS class, since they're a semantic prop of the component. Customized built-ins aren't supported in Safari/WebKit -- fine here, the project targets recent Firefox only (same reasoning as the original custom-elements pilot). Wired into modal.js: HiveDialog's buttons now render as <button is="hive-btn" variant="...">, replacing the old component-common.css .btn copy -- deleted that file + component- styles.js entirely (their sole purpose was giving dialog buttons a .btn look, which hive-btn now owns properly). dom.js's el() gained support so it can create customized built-ins the same way it creates everything else. hive-dialog.css dropped the now-dead .cancel/.confirm/.confirm.danger rules. Per mara's scoping: NOT touching the other .btn consumers across the app (dashboard/agent submit buttons, form() helper, etc.) or removing .btn from dashboard/common.css / agent/agent.css in this PR -- that migration + cleanup is an explicit follow-up. Verified with a full frontend build (grepped bundled JS for hive-btn/ variant to confirm it inlines); nix fmt clean.
29 lines
1.4 KiB
JavaScript
29 lines
1.4 KiB
JavaScript
// Tiny DOM-builder helper shared by the dashboard and the per-agent UI —
|
|
// both packages built their own copy independently; this is the merged
|
|
// canonical version (dashboard's, which had the extra `data-` branch;
|
|
// functionally identical to the `class`/`html` handling either package
|
|
// used).
|
|
//
|
|
// `el(tag, attrs, ...children)` creates an element, applying `attrs` as
|
|
// either the `class`/`html`/`is` special cases or plain attributes, and
|
|
// appending `children` (strings become text nodes, `null`/`undefined`
|
|
// entries are skipped so callers can inline conditional children).
|
|
// `is: 'custom-name'` creates a customized built-in element (e.g.
|
|
// `el('button', { is: 'hive-btn' }, 'label')` → `<button is="hive-btn">`)
|
|
// — passed to `document.createElement` itself, since a customized
|
|
// built-in has to be created with its `is` option up front, not upgraded
|
|
// after the fact via `setAttribute`.
|
|
export const el = (tag, attrs = {}, ...children) => {
|
|
const e = attrs.is ? document.createElement(tag, { is: attrs.is }) : document.createElement(tag);
|
|
for (const [k, v] of Object.entries(attrs)) {
|
|
if (k === 'is') continue;
|
|
if (k === 'class') e.className = v;
|
|
else if (k === 'html') e.innerHTML = v;
|
|
else e.setAttribute(k, v);
|
|
}
|
|
for (const c of children) {
|
|
if (c == null) continue;
|
|
e.append(c.nodeType ? c : document.createTextNode(c));
|
|
}
|
|
return e;
|
|
};
|