astroidjs 0.5.0 → 0.6.0

package/dist/components/sections.d.ts

@@ -43,7 +43,7 @@ export declare const SECTION_SETTINGS: Record<string, SectionField>;
  * array — `"2"` for a top-level section, `"2.blocks.0"` for a block inside it —
  * and every marker the component stamps is built from it. Passing it down (rather
  * than having each component work out its own depth) is what lets the exact same
- * component render as a section or as a block, and what keeps `data-louise-sfield`
+ * component render as a section or as a block, and what keeps `data-louise-node`
  * paths correct at any nesting depth.
  */
 export interface SectionRenderProps {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "astroidjs",
-  "version": "0.5.0",
+  "version": "0.6.0",
   "description": "Astroid — an opinionated meta-framework over Louise Toolkit and Astro for building editable, multi-editor sites on Cloudflare Workers.",
   "keywords": [
     "astro",
@@ -60,7 +60,7 @@
     "access": "public"
   },
   "dependencies": {
-    "louise-toolkit": "0.21.0"
+    "louise-toolkit": "0.22.0"
   },
   "devDependencies": {
     "@types/node": "^24.13.3",

package/src/components/Editable.astro

@@ -12,10 +12,16 @@
 //                   `data-louise-field="<collection>:<key>:<field>"` (saved as a
 //                   versioned draft when the page is mounted with `versionedPageId`).
 //   • SECTION field — pass `base` (this item's path, e.g. `"2"` or `"2.blocks.0"`)
-//                   plus `field`; emits `data-louise-sfield="<base>.<field>"`
-//                   (+ `data-louise-multiline`) for the on-canvas section editor.
-//                   `sfield` stays as the escape hatch for a path you build
-//                   yourself — an array entry: sfield={`${base}.items.${i}.title`}.
+//                   plus `field`; emits `data-louise-node="<base>.<field>"` for
+//                   the on-canvas section editor. `sfield` stays as the escape
+//                   hatch for a path you build yourself — an array entry:
+//                   sfield={`${base}.items.${i}.title`}.
+//
+//                   Since ADR 0010 A2 this is the SAME attribute the section
+//                   boundary carries, one path deeper. The catalog says whether a
+//                   field is edited in place and with which editor, so `type` and
+//                   `multiline` no longer affect a section field's markup — they
+//                   are accepted for compatibility and ignored.
 //
 // The `base` form is what ADR 0005 §2 asks for: "a site author writes `<Editable
 // field="heading">` and never hand-stamps the deeper path". `<Section>` supplies
@@ -76,20 +82,26 @@ const editing = edit ?? (Astro.locals as { editMode?: boolean }).editMode ?? fal
 // spreading that into `Record<string, string>` is a type error.
 const richText: Record<string, string> =
   type === "richtext" ? { "data-louise-type": "richtext" } : {};
-const multilineMarker: Record<string, string> = multiline ? { "data-louise-multiline": "" } : {};
 
 let markers: Record<string, string> = {};
 if (editing) {
   if (sectionPath) {
-    markers = {
-      "data-louise-sfield": sectionPath,
-      ...richText,
-      ...multilineMarker,
-    };
+    // ONE marker (ADR 0010 A2). This used to emit `data-louise-sfield` plus
+    // `data-louise-type="richtext"` plus `data-louise-multiline` — three
+    // attributes describing a field the catalog already fully describes. The
+    // editor now reads the field's type to know whether it's rich text and
+    // whether it holds more than one line, so `type` and `multiline` are inert
+    // here and kept only so an existing call site doesn't fail to compile.
+    markers = { "data-louise-node": sectionPath };
   } else if (collection && key !== undefined && field) {
+    // The PAGE-field contract is untouched: a collection row's field is not a
+    // node in a sections tree, so it keeps its own marker and its own type hint.
     markers = { "data-louise-field": `${collection}:${key}:${field}`, ...richText };
   }
 }
+// Referenced so the deprecated prop doesn't read as unused while it's still
+// accepted; it no longer affects the markup.
+void multiline;
 ---
 
 <Tag {...rest} {...markers}><slot /></Tag>

package/src/components/Section.astro

@@ -11,10 +11,11 @@
 // Two marker responsibilities:
 //   • the BOUNDARY (`data-louise-node="<path>"`, ADR 0010) is stamped here,
 //     because only the dispatcher knows an item's position;
-//   • the FIELDS (`data-louise-sfield`) are stamped by `<Editable base={base}
-//     field="…">` inside each component, because only the component knows which
-//     of its text nodes are editable. (ADR 0010 Phase A2 folds these into the node
-//     marker once the field registry can say which fields want chrome.)
+//   • the FIELDS are stamped by `<Editable base={base} field="…">` inside each
+//     component, because only the component knows which of its text nodes are
+//     editable. Since A2 those carry the SAME `data-louise-node` attribute, one
+//     path deeper — the catalog says whether a field is edited in place, so the
+//     marker no longer has to.
 //
 // Blocks recurse through this same component with a deeper `base`. That's the
 // whole trick: a component never learns its own depth, so a type that renders as

package/src/components/Sections.astro

@@ -53,7 +53,7 @@ const mediaMeta =
 
 {/*
   The host element. `mountSections(el, opts)` takes the element to scan for
-  `[data-louise-sfield]` markers and to hang on-canvas chrome off, so rendering
+  `[data-louise-node]` markers and to hang on-canvas chrome off, so rendering
   it here — rather than asking every page to remember a wrapper — is what makes
   `<Sections>` self-sufficient: drop it on a page and the editor can find it.
   A plain block wrapper, not `display: contents`, because the chrome positions

package/src/components/sections.ts

@@ -116,7 +116,7 @@ export const SECTION_SETTINGS: Record<string, SectionField> = {
  * array — `"2"` for a top-level section, `"2.blocks.0"` for a block inside it —
  * and every marker the component stamps is built from it. Passing it down (rather
  * than having each component work out its own depth) is what lets the exact same
- * component render as a section or as a block, and what keeps `data-louise-sfield`
+ * component render as a section or as a block, and what keeps `data-louise-node`
  * paths correct at any nesting depth.
  */
 export interface SectionRenderProps {