astroidjs 0.4.1 → 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/dist/map/scaffold.js

@@ -194,7 +194,13 @@ export function generateMapEmbedComponent(config) {
         "        for (const entry of entries) {",
         "          if (!entry.isIntersecting) continue;",
         "          obs.unobserve(entry.target);",
-        "          init(entry.target as HTMLElement);",
+        "          // `init` is async and nothing awaits it, so without this catch a",
+        "          // failed chunk fetch — a page load racing a deploy is enough — is a",
+        "          // silent unhandled rejection: the container just stays an empty",
+        "          // tinted box with nothing in the console to explain it.",
+        "          init(entry.target as HTMLElement).catch((err) => {",
+        '            console.error("[astroid:map] map failed to load", err);',
+        "          });",
         "        }",
         "      },",
         '      { rootMargin: "200px" },',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "astroidjs",
-  "version": "0.4.1",
+  "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.20.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

@@ -8,12 +8,14 @@
 // the page's `sections` column, not props a template hand-wrote, so what renders
 // is exactly what the on-canvas editor edits in place.
 //
-// Two marker responsibilities, split the way ADR 0005 §2 splits them:
-//   • the BOUNDARY (`data-louise-section` / `data-louise-block`) is stamped here,
+// 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.
+//   • 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
@@ -79,15 +81,16 @@ const type = String(item._type);
 // (`<i>.blocks.<j>`), which is what the client's depth-agnostic path parser walks.
 const blocks = Array.isArray(item.blocks) ? item.blocks : [];
 
-// The boundary marker the on-canvas chrome draws its ring on. `class="contents"`
-// keeps this wrapper out of layout entirely — the ring is drawn as a box-shadow
-// on the element itself (ADR 0005 §3), so an extra block box here would offset
+// The boundary marker the on-canvas chrome draws its ring on. It is the item's
+// path, verbatim — pre-0010 this line string-sniffed `base` for ".blocks." to pick
+// between two attribute names, which was the three-attribute editing model leaking
+// into an otherwise uniform recursive render (ADR 0010, Context). The editor
+// resolves what a path CAN do from the catalog; the render just says where it is.
+//
+// `class="contents"` keeps this wrapper out of layout entirely — the ring is drawn
+// as a box-shadow on the element itself, so an extra block box here would offset
 // every section's spacing for the sake of an attribute.
-const boundary = editing
-  ? base.includes(".blocks.")
-    ? { "data-louise-block": base }
-    : { "data-louise-section": base }
-  : {};
+const boundary = editing ? { "data-louise-node": base } : {};
 
 const shared = { item, base, edit: editing, mediaMeta };
 

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 {