@ecoma-io/loom 0.2.0 → 0.3.0

package/dist/packages/labels/src/ancestor-disabled.js

@@ -0,0 +1,86 @@
+import { onScopeDispose, readonly, ref, watchPostEffect } from "vue";
+//#region packages/labels/src/ancestor-disabled.ts
+/**
+* Whether an enclosing `<fieldset disabled>` has made this control unavailable
+* — read off the element itself, not off anything a wrapper told us.
+*
+* The platform already answers this for `<input>`, `<button>`, `<select>` and
+* `<textarea>`: a disabled fieldset makes every such descendant *actually
+* disabled*, so `:disabled` matches, the tab stop goes and the control refuses
+* input. Nothing in Loom has to help. It stops at the boundary of that list,
+* and Reka builds several controls out of elements that are not on it — a
+* `<span role="slider">`, a `<div role="spinbutton">`. Those keep their
+* `tabindex="0"` and their arrow-key handlers inside a disabled group: measured
+* in jsdom, a Slider in a `<fieldset disabled>` still took Home/End and moved
+* its value, and a DatePicker segment still typed. A control that looks
+* unavailable and still answers the keyboard is worse than one that looks
+* available, so the appearance cannot be fixed on its own.
+*
+* **This is a read of the native attribute, not a second copy of it.**
+* `Fieldset.vue`'s docblock rules out publishing `disabled` through the Field
+* context, and the reason is precedence: a context is a claim a control may
+* beat with `:disabled="false"`, while the native attribute disables it anyway,
+* leaving a control that renders enabled and silently refuses input. Nothing
+* here can drift that way, because there is nothing to beat — the answer is
+* recomputed from the same DOM the browser is reading, so a control cannot
+* disagree with the fieldset it is standing in. It also needs no Loom wrapper
+* at all: a raw `<fieldset disabled>` a consumer wrote works exactly as one of
+* ours does.
+*
+* The result is `false` on the server and until the effect first runs, which is
+* deliberate. `watchPostEffect` does not run during SSR, so the markup a server
+* emits matches the markup the client hydrates and the state settles in the
+* same tick as mount — a hydration-time correction rather than a mismatch.
+*/
+function useAncestorDisabled(target) {
+	const disabled = ref(false);
+	let observer;
+	function sync() {
+		const start = target();
+		if (!start) {
+			observer?.disconnect();
+			disabled.value = false;
+			return;
+		}
+		const fieldsets = enclosingFieldsets(start);
+		observer ??= new MutationObserver(sync);
+		observer.disconnect();
+		for (const fieldset of fieldsets) observer.observe(fieldset, {
+			attributes: true,
+			attributeFilter: ["disabled"]
+		});
+		disabled.value = fieldsets.some((fieldset) => fieldset.disabled);
+	}
+	watchPostEffect(sync);
+	onScopeDispose(() => {
+		observer?.disconnect();
+	});
+	return readonly(disabled);
+}
+/**
+* The `<fieldset>` ancestors whose `disabled` would reach `start`, outermost
+* last, whether or not any of them currently carries the attribute — they are
+* what has to be watched for the attribute arriving.
+*
+* The walk climbs child-by-child rather than calling `closest("fieldset")`
+* because of the exemption in the "actually disabled" rule: controls inside a
+* disabled fieldset's **first** `<legend>` stay available, which is what makes
+* a switch in the legend that re-enables its own group possible. Reaching a
+* fieldset through that legend is reaching a fieldset that does not disable
+* you, so it is skipped — and the walk continues past it, since a fieldset
+* further out may still disable the legend itself.
+*/
+function enclosingFieldsets(start) {
+	const found = [];
+	let node = start;
+	while (node) {
+		const parent = node.parentElement;
+		if (parent instanceof HTMLFieldSetElement && node !== parent.querySelector(":scope > legend")) found.push(parent);
+		node = parent;
+	}
+	return found;
+}
+//#endregion
+export { useAncestorDisabled };
+
+//# sourceMappingURL=ancestor-disabled.js.map

package/dist/packages/labels/src/ancestor-disabled.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"ancestor-disabled.js","names":[],"sources":["../../../../packages/labels/src/ancestor-disabled.ts"],"sourcesContent":["import { onScopeDispose, readonly, ref, watchPostEffect, type Ref } from \"vue\";\n\n/**\n * Whether an enclosing `<fieldset disabled>` has made this control unavailable\n * — read off the element itself, not off anything a wrapper told us.\n *\n * The platform already answers this for `<input>`, `<button>`, `<select>` and\n * `<textarea>`: a disabled fieldset makes every such descendant *actually\n * disabled*, so `:disabled` matches, the tab stop goes and the control refuses\n * input. Nothing in Loom has to help. It stops at the boundary of that list,\n * and Reka builds several controls out of elements that are not on it — a\n * `<span role=\"slider\">`, a `<div role=\"spinbutton\">`. Those keep their\n * `tabindex=\"0\"` and their arrow-key handlers inside a disabled group: measured\n * in jsdom, a Slider in a `<fieldset disabled>` still took Home/End and moved\n * its value, and a DatePicker segment still typed. A control that looks\n * unavailable and still answers the keyboard is worse than one that looks\n * available, so the appearance cannot be fixed on its own.\n *\n * **This is a read of the native attribute, not a second copy of it.**\n * `Fieldset.vue`'s docblock rules out publishing `disabled` through the Field\n * context, and the reason is precedence: a context is a claim a control may\n * beat with `:disabled=\"false\"`, while the native attribute disables it anyway,\n * leaving a control that renders enabled and silently refuses input. Nothing\n * here can drift that way, because there is nothing to beat — the answer is\n * recomputed from the same DOM the browser is reading, so a control cannot\n * disagree with the fieldset it is standing in. It also needs no Loom wrapper\n * at all: a raw `<fieldset disabled>` a consumer wrote works exactly as one of\n * ours does.\n *\n * The result is `false` on the server and until the effect first runs, which is\n * deliberate. `watchPostEffect` does not run during SSR, so the markup a server\n * emits matches the markup the client hydrates and the state settles in the\n * same tick as mount — a hydration-time correction rather than a mismatch.\n */\nexport function useAncestorDisabled(\n  target: () => Element | null | undefined,\n): Readonly<Ref<boolean>> {\n  const disabled = ref(false);\n\n  // Kept rather than chained off the constructor: an observer holds a strong\n  // reference to everything it watches, and `disconnect()` is the only thing\n  // that releases them.\n  let observer: MutationObserver | undefined;\n\n  function sync(): void {\n    const start = target();\n    if (!start) {\n      observer?.disconnect();\n      disabled.value = false;\n      return;\n    }\n\n    const fieldsets = enclosingFieldsets(start);\n    observer ??= new MutationObserver(sync);\n    // Re-observed wholesale rather than diffed. The set is an element's\n    // ancestor fieldsets — one or two of them in any real form — and the\n    // attribute filter means nothing else in the document wakes this up.\n    observer.disconnect();\n    for (const fieldset of fieldsets) {\n      observer.observe(fieldset, { attributes: true, attributeFilter: [\"disabled\"] });\n    }\n\n    disabled.value = fieldsets.some((fieldset) => fieldset.disabled);\n  }\n\n  watchPostEffect(sync);\n  onScopeDispose(() => {\n    observer?.disconnect();\n  });\n\n  return readonly(disabled);\n}\n\n/**\n * The `<fieldset>` ancestors whose `disabled` would reach `start`, outermost\n * last, whether or not any of them currently carries the attribute — they are\n * what has to be watched for the attribute arriving.\n *\n * The walk climbs child-by-child rather than calling `closest(\"fieldset\")`\n * because of the exemption in the \"actually disabled\" rule: controls inside a\n * disabled fieldset's **first** `<legend>` stay available, which is what makes\n * a switch in the legend that re-enables its own group possible. Reaching a\n * fieldset through that legend is reaching a fieldset that does not disable\n * you, so it is skipped — and the walk continues past it, since a fieldset\n * further out may still disable the legend itself.\n */\nfunction enclosingFieldsets(start: Element): HTMLFieldSetElement[] {\n  const found: HTMLFieldSetElement[] = [];\n  let node: Element | null = start;\n\n  while (node) {\n    const parent: Element | null = node.parentElement;\n    if (parent instanceof HTMLFieldSetElement && node !== parent.querySelector(\":scope > legend\")) {\n      found.push(parent);\n    }\n    node = parent;\n  }\n\n  return found;\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAkCA,SAAgB,oBACd,QACwB;CACxB,MAAM,WAAW,IAAI,KAAK;CAK1B,IAAI;CAEJ,SAAS,OAAa;EACpB,MAAM,QAAQ,OAAO;EACrB,IAAI,CAAC,OAAO;GACV,UAAU,WAAW;GACrB,SAAS,QAAQ;GACjB;EACF;EAEA,MAAM,YAAY,mBAAmB,KAAK;EAC1C,aAAa,IAAI,iBAAiB,IAAI;EAItC,SAAS,WAAW;EACpB,KAAK,MAAM,YAAY,WACrB,SAAS,QAAQ,UAAU;GAAE,YAAY;GAAM,iBAAiB,CAAC,UAAU;EAAE,CAAC;EAGhF,SAAS,QAAQ,UAAU,MAAM,aAAa,SAAS,QAAQ;CACjE;CAEA,gBAAgB,IAAI;CACpB,qBAAqB;EACnB,UAAU,WAAW;CACvB,CAAC;CAED,OAAO,SAAS,QAAQ;AAC1B;;;;;;;;;;;;;;AAeA,SAAS,mBAAmB,OAAuC;CACjE,MAAM,QAA+B,CAAC;CACtC,IAAI,OAAuB;CAE3B,OAAO,MAAM;EACX,MAAM,SAAyB,KAAK;EACpC,IAAI,kBAAkB,uBAAuB,SAAS,OAAO,cAAc,iBAAiB,GAC1F,MAAM,KAAK,MAAM;EAEnB,OAAO;CACT;CAEA,OAAO;AACT"}