lightview 2.2.1 → 2.3.4

package/cDOMIntro.md

@@ -0,0 +1,279 @@
+# The Future of AI-Generated UI: Why I Built cDOM and JPRX
+
+**A declarative, secure, and reactive approach to let both humans and LLMs build rich user interfaces.**
+
+---
+
+## The Problem with AI-Generated Interfaces
+
+We are at an inflection point in software development. Large Language Models (LLMs) are rapidly evolving from text-generation tools into full-fledged software agents capable of building applications, analyzing data, and interacting with users in real-time. But there's a critical bottleneck: **how do these agents communicate visually with humans?**
+
+The traditional options are bleak:
+1.  **Text-Only Responses**: The chatbot experience. Great for conversation, terrible for complex interactions. Ever tried to book a flight through a wall of text? It's exhausting.
+2.  **Raw Code Generation (HTML/JS/React)**: The agent spits out code, and you hope it works. This is a **massive security risk**. Arbitrary code execution is the original sin of computing—do you really want to `eval()` whatever a cloud-based AI model sends you? The answer is no. And, the flexibility of raw language generation can result in either too much brittle code or too much variance from UI exprience to UI experience, something humans do not handle well.
+The end states are far away:
+1. **Direct generation of images and video** with which users can interact in real-time is too expensive and slow.
+2. **Direct mind interfaces** are not yet possible except for the simplest of tasks.
+
+Google recognized the traditional options gap or and perhaps the distance to an ultimate end-state and introduced **A2UI (Agent-to-User Interface)** in late 2025. It's a declarative JSON format where agents describe UI components like `text_field` or `button`, and client applications render them natively. It's a solid approach with a security-first architecture.
+
+But I asked a additional questions:
+
+*   **Why just *describe* the UI? Why not make it *reactive* by design?**
+*   **Why limit this approach to LLMs?** Why not provide a reactive, cross-platform way for *human developers* to safely express UIs too?
+
+This is why I built **cDOM (Computational DOM)** and its expression language, **JPRX (JSON Pointer Reactive eXpressions)**.
+
+Let me show you how it works, step by step.
+
+---
+
+## Step 1: A Reactive UI with Zero Server Code or Custom JavaScript
+
+Consider a simple counter. In cDOM, you write this:
+
+```json
+{
+  "div": {
+    "onmount": "=state({ count: 0 }, { name: 'local', scope: $this })",
+    "children": [
+      { "p": ["Count: ", "=local/count"] },
+      { "button": { "onclick": "=local/count++", "children": ["+"] } }
+    ]
+  }
+}
+```
+
+That's it. No server. No round-trip. No JavaScript except the underlying cDOM library (which could be JavaScript, Dart or some other language).
+
+*   The `state` helper initializes reactive state (`{ count: 0 }`) scoped to this element.
+*   The `=local/count` expression is a **live binding**—the paragraph text updates automatically whenever `count` changes.
+*   The `=local/count++` operator is a direct increment.
+
+The entire UI is reactive, self-contained, and runs instantly in the browser.
+
+**This is the spreadsheet paradigm applied to UI**: you define the relationships, and the system handles the updates. JPRX has **over 100** helper functions, covering everything from math and string manipulation to complex array processing and lookup logic, e.g. sum, min, max, sort, filter, etc.
+
+---
+
+## Step 2: But What If You *Do* Want LLM Integration?
+
+The counter example is great for client-only interactions. But what if you want to notify an LLM (or any server) when the user clicks a button?
+
+Just swap the operator for a `=fetch` helper:
+
+```json
+{
+  "button": {
+    "onclick": "=fetch('/api/notify', { method: 'POST', body: $event })",
+    "children": ["Notify LLM"]
+  }
+}
+```
+
+When the button is clicked:
+1.  The `=fetch` helper sends a POST request to `/api/notify` with a JSON body.
+2.  Object bodies are automatically stringified, and `Content-Type: application/json` is set for you.
+3.  The LLM (or your backend) receives the event and can respond however it likes.
+
+This is the **event registration model**: the LLM doesn't need to be notified of *every* interaction. It only hears about the events that matter—the ones where you've wired up a `fetch`. Developers can wire up `fetch` to any event they want, or when LLMs generate a cDOM component, they can wire up `fetch` to notify them of specific user actions.
+
+This avoids the potential chatty nature of A2UI. Do you really want the LLM notified of every mouse move? Keyboard stroke? Scroll position? If it time and cost effective to have an LLM deal with things like sorting and filtering, or should you let the client handle it?
+
+---
+
+## Step 3: What If the LLM Wants to *Modify* the UI?
+
+Here's where cDOM gets truly powerful. What if the server (or LLM) wants to push a new component into the page?
+
+Enter `=mount`:
+
+```json
+{
+  "button": {
+    "onclick": "=mount('/api/get-widget')",
+    "children": ["Load Widget"]
+  }
+}
+```
+
+When clicked, `mount` fetches JSON from `/api/get-widget`, hydrates it as a reactive cDOM element, and **appends it to the document body**.
+
+But wait, what if the LLM wants to place that widget somewhere specific, like a sidebar? That's where `move` comes in.
+
+The LLM simply includes a `=move` directive in the component it returns:
+
+```json
+{
+  "div": {
+    "id": "weather-widget",
+    "onmount": "=move('#dashboard-sidebar', 'afterbegin')",
+    "children": ["Sunny, 75°F"]
+  }
+}
+```
+
+Here's what happens:
+1.  `mount` fetches the widget and appends it to the `body` (a "safe landing").
+2.  The moment the widget mounts, `move` **rips it out** and **teleports** it to `#dashboard-sidebar`.
+3.  If a widget with the same `id` already exists there, it's **replaced** - making the operation idempotent.
+
+**The LLM doesn't need to regenerate the entire page.** It just pushes components that know how to place themselves.
+
+---
+
+## The Full Picture: Three Levels of Power
+
+You've now seen the three core capabilities:
+
+| Level | Use Case                          | Helper               | Server Involved? |
+|-------|-----------------------------------|----------------------|------------------|
+| 1     | Client-only reactivity            | `=state`, `=++`, etc | ❌ No             |
+| 2     | Notify LLM of user actions        | `=fetch`             | ✅ Yes (one-way)  |
+| 3     | LLM pushes new UI to the client   | `=mount`, `=move`    | ✅ Yes (returns UI)|
+
+This layered approach means you can build:
+*   Fully offline-capable apps (Level 1)
+*   Hybrid apps where the LLM is notified selectively (Level 2)
+*   Agent-driven apps where the LLM controls the UI in real-time (Level 3)
+
+All with the same declarative JSON format.
+
+---
+
+## JPRX: The Expression Language Behind the Magic
+
+You've been looking at JPRX expressions this whole time. Let me explain what's under the hood.
+
+**JPRX (JSON Pointer Reactive eXpressions)** is an extension of RFC 6901 JSON Pointer. It adds:
+
+*   **Expressions**: Any path or function name beginning with `=` is an expression. Only the first expression of a nested expression needs to start with `=`.
+*   **Reactivity**: Any path starting with `=` (e.g., `=app/user/name`) creates a live subscription. When the data changes, so does the UI.
+*   **Operators**: Prefix and postfix mutation (`=++/count`, `=count--`, `=!!/enabled`).
+*   **Helper Functions**: Over 100 Excel-like functions (`sum`, `if`, `upper`, `filter`, `map`, `formatDate`) plus state-mutating helpers (`set`, `push`, `assign`), e.g. `=set(/app/user/name, 'John Doe')`.
+*   **Relative Paths**: Use `../` to navigate up context hierarchies, just like a file system.
+
+Why is this perfect for LLMs?
+1.  **Context-Free Grammar**: No closures, no callbacks. An LLM generates JPRX as easily as it generates a sentence.
+2.  **Safe by Design**: No access to `globalThis`, `eval`, or the DOM API outside registered helpers. The application developer controls the helper catalog.
+3.  **Streamable**: The LLM can stream components one by one. Each piece is self-describing and self-mounting.
+
+And why is it great for human developers? Because JPRX reads like a spreadsheet formula. If you can write `=SUM(A1:A10)`, you can write `=sum(/cart/items...price)`.
+
+---
+
+## The Chattiness Trade-Off
+
+A key difference between cDOM and A2UI is how user interactions are handled.
+
+In A2UI, the interaction follows a continuous loop:
+1.  **Agent emits** a UI description.
+2.  **Client renders** it.
+3.  **User interacts** (clicks a button).
+4.  **Client signals** the action back to the agent.
+5.  **Agent reasons** and emits a new UI.
+
+This is architecturally clean and ensures the agent is always the "brain" of the operation. However, it can become **chatty**. When every interaction requires a network round-trip, latency and bandwidth usage can accumulate, potentially affecting the user experience.
+
+More importantly, it creates an **over-reliance on the LLM for trivial tasks**. Does an agent really need to "reason" about how to sort a list of five items alphabetically? Or how to toggle a "Show Details" pane?
+
+cDOM flips this model. Event handlers are JPRX expressions that execute **client-side**. The user clicks "+", the count increments *locally*. The user clicks "Sort", the list reorders instantly in the browser.
+
+If the LLM *does* need to know about a significant interaction, you explicitly wire up a `fetch`. But routine UI logic stays where it belongs: on the client.
+
+**LLM-driven architecture. Native-like responsiveness.**
+
+---
+
+## Head-to-Head: cDOM vs. A2UI
+
+| Feature                        | cDOM/JPRX (Lightview)                                      | A2UI (Google)                                              |
+|--------------------------------|------------------------------------------------------------|-----------------------------------------------------------|
+| **Core Paradigm**              | Declarative + Reactive Computation                         | Declarative Description                                   |
+| **Client-Side Reactivity**     | ✅ Built-in via signals & computed expressions             | ❌ Requires server round-trip for state changes           |
+| **Interaction Model**          | ✅ Handlers execute client-side (low latency)              | ⚠️ Every interaction signals back to agent (chatty)       |
+| **Security Model**             | ✅ Sandboxed helper functions, no arbitrary code           | ✅ Sandboxed component catalog, no arbitrary code         |
+| **Expression Language**        | ✅ Full formula language with 100+ helpers                 | ❌ Data binding only, no computation in the format        |
+| **LLM Streaming**              | ✅ Components self-mount & teleport via `=move`            | ✅ Flat component list with IDs for incremental updates   |
+| **Two-Way Binding**            | ✅ `=bind(/path)` for inputs, selects, checkboxes          | ⚠️ Component-specific, varies by renderer                 |
+| **State Management**           | ✅ Scoped, schema-validated `state` objects                | ❌ External state managed by agent or backend             |
+| **Framework**                  | Lightview (Vanilla JS, ~5KB core)                          | Client-agnostic (Flutter, React, Angular renderers)       |
+
+A2UI is an excellent wire format for describing **static snapshots** of a UI. It fits neatly into enterprise ecosystems where Flutter or Angular applications render components.
+
+cDOM is designed for **dynamic, client-reactive applications** where the UI is a living computation. When your LLM generates a dashboard, you want it to *react* to user input—filter, sort, calculate—without a server round-trip for every interaction.
+
+And while the current reference implementation is in JavaScript, **nothing prevents cDOM and JPRX from being implemented in other languages like Dart or Swift**. The core concepts—reactive pointers, helper functions, and declarative structure—are universal. You could build a Flutter renderer for cDOM just as easily as Google built one for A2UI.
+
+---
+
+## Custom Components: Extending the Vocabulary
+
+A powerful feature of A2UI is **capability negotiation**: the agent queries the client's component catalog before generating UI. This ensures compatibility across different renderers.
+
+cDOM takes a different approach. There's no formal negotiation protocol, but the ecosystem makes **adding custom components trivial**.
+
+Libraries like **Lightview** and **Juris.js** allow you to define custom HTML elements declaratively:
+
+```javascript
+Lightview.define('my-widget', {
+  template: `<div><slot></slot> - Custom!</div>`,
+  state: { clicks: 0 }
+});
+```
+
+Once defined, these elements are immediately usable in cDOM:
+
+```json
+{ "my-widget": { "children": ["Hello"] } }
+```
+
+The philosophy: the **application developer controls the component catalog**, just as in A2UI. The difference is that cDOM skips the negotiation handshake—the LLM uses components it's been trained to expect for that application. If discovery is needed, a JSON manifest of available components can be provided to the LLM as context.
+
+This trade-off prioritizes **simplicity and low overhead** for applications where the component set is known in advance—which, in my experience, is most applications.
+
+---
+
+## Why This Matters for the Future of Agentic UI
+
+I believe the next wave of applications will be **agent-first**. Not chatbots with UI bolted on, but intelligent systems where conversation and application dissolve into one.
+
+A user might ask:
+> "Show me my sales performance for Q4, highlight anything below target, and let me drill down by region."
+
+An LLM should respond not with a paragraph, but with a **live dashboard**: a chart that filters, a table that sorts, a summary that recalculates. When the user says "focus on EMEA," the agent streams a UI patch that updates the view in place.
+
+cDOM and JPRX are the foundation for this vision:
+*   **For Developers**: Write less JavaScript, define relationships, let reactivity handle the rest.
+*   **For LLMs**: A safe, structured, computable expression language as easy to generate as natural text.
+*   **For Users**: Rich, instantly reactive interfaces without server round-trip latency.
+
+---
+
+## Get Started with Lightview
+
+cDOM and JPRX are part of **Lightview**, my lightweight (~5KB) reactive UI library. It's framework-agnostic, browser-native, and designed for both humans and machines.
+
+*   **Documentation**: [lightview.dev](https://lightview.dev) - Full guides and API reference
+*   **GitHub**: [github.com/anywhichway/lightview](https://github.com/anywhichway/lightview)
+*   **npm packages**:
+    *   Lightview (includes cDOM): [`npm install lightview`](https://www.npmjs.com/package/lightview)
+    *   JPRX (standalone parser): [`npm install jprx`](https://www.npmjs.com/package/jprx)
+
+cDOM is currently in **experimental preview**. I'm actively refining the expression language and helper library based on real-world use cases. I'd love your feedback.
+
+---
+
+## Conclusion: The Spreadsheet Moment for UI
+
+Spreadsheets democratized computation. You didn't need to be a programmer to define that `C3 = A1 + B2` and have it update forever.
+
+cDOM is designed to be that moment for user interfaces. A format where an LLM—or a human—can declare: *this text shows the count; this button increments it; this chart sums the sales*. And the system handles the rest.
+
+In a world where AI agents are becoming the new developers, the language they speak to the browser matters. I think that language should be safe, reactive, and computational from the ground up.
+
+**That's cDOM. Welcome to the Computational DOM.**
+
+---
+
+*Simon Y. Blackwell is the creator of Lightview, a lightweight reactive library for building web applications. He believes that the best code is the code you don't have to write, and that LLMs should be first-class citizens in the UI development process.*

package/docs/about.html

@@ -38,15 +38,15 @@
             something that felt more like regular HTML than even HTMX does.
             This would also require thorough and fully interactive documentation accessible via direct URLs and an SPA
             like experience.
-            This manadated a router with at least partial "automatic" SSR—where code could execute and replace itself on
+            This mandated a router with at least partial "automatic" SSR—where code could execute and replace itself on
             the server with a simple
-            DOM emulation and "have-your-cake-and-eat-it-too" single page apps that are SEO enabled without any extra
+            DOM emulation and "have-your-cake-and-eat-it-too" single page apps that are SEO-enabled without any extra
             work.
         </p>
 
         <p>
-            In today's age, the ability of an LLM to generate cohensive applications using the library is also important
-            to me. If figured that if an LLM generated it and it followed conventional patterns, it will be able to use
+            In today's age, the ability of an LLM to generate cohesive applications using the library is also important
+            to me. I figured that if an LLM generated it and it followed conventional patterns, it will be able to use
             it well and perhaps generate a little less slop.
         </p>
 
@@ -55,8 +55,8 @@
             combo of HTMX, Bau, and
             Juris with no special attribute names plus HTML template literals, and an SPA router. And, give me a UI
             component library like
-            Bau's with automatic custom elment creation but don't build it from scratch. Finally, make it possible to
-            create SEO enabled apps with no extra work" I also provied a few examples of the kind of code I wanted to
+            Bau's with automatic custom element creation but don't build it from scratch. Finally, make it possible to
+            create SEO-enabled apps with no extra work." I also provided a few examples of the kind of code I wanted to
             write
             using the library.
         </p>
@@ -64,16 +64,19 @@
         <p>
             Naturally, it took a little iterating, but the basic framework was in place after just a few hours of
             working with both Claude Opus 4.5 and Gemini 3 Pro. I then asked for
-            an extensive interactive website for documenting and promoting Lightview that also used Lightview, despsite
+            an extensive interactive website for documenting and promoting Lightview that also used Lightview, despite
             the fact that in the age of LLM code generation the need for extensive documentation websites is limited.
             This took a lot more work, 3
-            weeks in fact. Very little of this time was spent addressing issues with or enhancing Ligntview. Most of it
-            was spent adding, debugginng and testing all the UI components. The LLM would get locked in on a particular
-            approach that worked form simple components bu no more complex ones.
-            But, that is a story for another time. Here we are 3 weeks later with about 2,000 lines of code for
+            weeks in fact. Very little of this time was spent addressing issues with or enhancing Lightview. Most of it
+            was spent adding, debugging, and testing all the UI components. The LLM would get locked in on a particular
+            approach that worked for simple components but not more complex ones.
+            But, that is a story for another time. So, 3 weeks later I had about 2,000 lines of code for
             Lightview
             as a whole across three
-            files, 25,000 lines of component code, and 30,000 lines of documentation.
+            files, 25,000 lines of component code, and 30,000 lines of documentation. Lightview has grown a lot since
+            then! You can see my article about initial development after week 4 on <a
+                href="https://hackernoon.com/lightview-a-lightweight-javascript-framework-for-building-single-page-applications-1768144869105"
+                target="_blank">Hackernoon</a>.
         </p>
 
         <p>

package/docs/api/computed.html

@@ -2,7 +2,7 @@
 <script src="/lightview-router.js?base=/index.html"></script>
 
 <div class="docs-layout">
-    <aside class="docs-sidebar" src="./nav.html"></aside>
+    <aside class="docs-sidebar" src="./nav.html" data-preserve-scroll="docs-nav"></aside>
 
     <main class="docs-content">
         <h1>Computed</h1>

package/docs/api/effects.html

@@ -1,7 +1,7 @@
 <!-- SEO-friendly SPA Shim -->
 <script src="/lightview-router.js?base=/index.html"></script>
 <div class="docs-layout">
-    <aside class="docs-sidebar" src="./nav.html"></aside>
+    <aside class="docs-sidebar" src="./nav.html" data-preserve-scroll="docs-nav"></aside>
     <main class="docs-content">
         <h1>Effects</h1>
         <p>

package/docs/api/elements.html

@@ -4,7 +4,7 @@
 <link rel="stylesheet" href="../components/index.css">
 
 <div class="docs-layout">
-    <aside class="docs-sidebar" src="./nav.html"></aside>
+    <aside class="docs-sidebar" src="./nav.html" data-preserve-scroll="docs-nav"></aside>
 
     <main class="docs-content">
         <h1>Elements</h1>
@@ -119,9 +119,58 @@ $('#example').content(app);</code></pre>
 
         <h2 id="object-dom">Object DOM (oDOM)</h2>
         <p>
-            A more compact JSON representation provided by <strong>Lightview X</strong>. It uses the tag name as a key
-            to reduce verbosity.
+            A more compact JSON representation provided by <strong>Lightview X</strong>. In oDOM, an object with a
+            <strong>single key</strong> and an <strong>object value</strong> represents an element. The key is the
+            <strong>tag name</strong> (e.g., <code>"div"</code>, <code>"span"</code>) or a <strong>custom element
+                function name</strong>. The value object contains the element's attributes.
         </p>
+
+        <h3>Reserved Keys</h3>
+        <p>
+            Certain keys on the value object are reserved and have special meaning instead of being treated as
+            attributes:
+        </p>
+        <table class="api-table">
+            <thead>
+                <tr>
+                    <th>Key</th>
+                    <th>Purpose</th>
+                </tr>
+            </thead>
+            <tbody>
+                <tr>
+                    <td><code>children</code></td>
+                    <td>An array of child elements, strings, or reactive functions.</td>
+                </tr>
+                <tr>
+                    <td><code>attributes</code></td>
+                    <td>An explicit attributes object (not needed in oDOM since non-reserved keys are attributes). If
+                        you use this attribute, Lighview MAY assume you are trying to use vDOM not oDOM. Avoid its use
+                        except for vDOM.
+                    </td>
+                </tr>
+                <tr>
+                    <td><code>tag</code></td>
+                    <td>Explicitly sets the tag name. If you use this attribute, Lighview MAY assume you are trying to
+                        use vDOM not oDOM. Avoid its use except for vDOM.</td>
+                </tr>
+            </tbody>
+        </table>
+        <p>
+            All other keys on the value object are treated as <strong>attribute names</strong>. Keys starting with
+            <code>on</code> (like <code>onclick</code>, <code>onmouseenter</code>) are bound as event handlers.
+        </p>
+
+        <h3>Array Shorthand</h3>
+        <p>
+            If a tag key has an <strong>array</strong> as its value instead of an object, it is shorthand for
+            <code>{ &lt;key&gt;: { children: &lt;array&gt; } }</code>:
+        </p>
+        <pre><code>// These are equivalent:
+{ ul: [{ li: ['Item 1'] }, { li: ['Item 2'] }] }
+{ ul: { children: [{ li: { children: ['Item 1'] } }, { li: { children: ['Item 2'] } }] } }</code></pre>
+
+        <h3>Example</h3>
         <div id="syntax-object">
             <pre><script>
                 examplify(document.currentScript.nextElementSibling, {
@@ -134,7 +183,7 @@ $('#example').content(app);</code></pre>
             </script><code contenteditable="true">const { signal, tags, $ } = Lightview;
 const count = signal(0);
 const app = { div: { class: 'container', children: [
-    { h1: { children: ['Hello Lightview'] } },
+    { h1: ['Hello Lightview'] },
     { p: { children: [() => `Count: ${count.value}`] } },
     { button: { onclick: () => count.value++, children: ['Click me'] } }
 ]}};
@@ -197,27 +246,9 @@ const greeting = div(
 );
 // Initial result: <div>Hello, John Doe !</div></code></pre>
 
-        <h2 id="attributes-events">Attributes & Events</h2>
-        <p>
-            Pass attributes as the first argument (Tagged API) or in the attributes object (others):
-        </p>
-        <pre><code>// Standard attributes
-div({ 
-    id: 'my-div',
-    class: 'container active',
-    style: 'color: red;',
-    'data-value': '42'
-})
-
-// Reactive attributes - use functions!
-div({
-    class: () => isActive.value ? 'active' : 'inactive',
-    style: () => `opacity: ${visible.value ? 1 : 0}`,
-    disabled: () => isLoading.value
-})
-
-// Event handlers - use "on" prefix
-button({
+        <h2 id="attributes-events">Events</h2>
+        <p>Use standard event handlers prefixed with "on".</p>
+        <pre><code>button({
     onclick: (e) => handleClick(e),
     onmouseenter: () => setHovered(true),
     onmouseleave: () => setHovered(false)

package/docs/api/enhance.html

@@ -4,7 +4,7 @@
 <link rel="stylesheet" href="../components/index.css">
 
 <div class="docs-layout">
-    <aside class="docs-sidebar" src="./nav.html"></aside>
+    <aside class="docs-sidebar" src="./nav.html" data-preserve-scroll="docs-nav"></aside>
 
     <main class="docs-content">
         <h1>Enhance</h1>

package/docs/api/hypermedia.html

@@ -2,7 +2,7 @@
 <script src="/lightview-router.js?base=/index.html"></script>
 
 <div class="docs-layout">
-    <aside class="docs-sidebar" src="./nav.html"></aside>
+    <aside class="docs-sidebar" src="./nav.html" data-preserve-scroll="docs-nav"></aside>
 
     <main class="docs-content">
         <h1>Hypermedia</h1>

package/docs/api/index.html

@@ -4,7 +4,7 @@
 </script>
 
 <div class="docs-layout">
-    <aside class="docs-sidebar" src="./nav.html"></aside>
+    <aside class="docs-sidebar" src="./nav.html" data-preserve-scroll="docs-nav"></aside>
 
     <main class="docs-content">
         <h1>API Reference</h1>

package/docs/api/nav.html

@@ -1,4 +1,4 @@
-<nav class="docs-nav">
+<nav data-preserve-scroll="docs-nav" class="docs-nav">
     <div class="docs-nav-section">
         <div class="docs-nav-title">Elements</div>
         <a href="./elements.html" class="docs-nav-link">Comparison</a>
@@ -13,7 +13,7 @@
                 <a href="./elements.html#text" class="docs-nav-link" style="font-size: 0.85em;">text</a>
             </div>
         </div>
-        <a href="./elements.html#attributes-events" class="docs-nav-link">Attributes & Events</a>
+        <a href="./elements.html#attributes-events" class="docs-nav-link">Events</a>
         <a href="./elements.html#children" class="docs-nav-link">Children</a>
         <a href="./elements.html#dom-el" class="docs-nav-link">The domEl Property</a>
     </div>
@@ -28,7 +28,32 @@
     </div>
     <div class="docs-nav-section">
         <div class="docs-nav-title">Lightview X</div>
-        <a href="./state.html" class="docs-nav-link">State (Deep Reactivity)</a>
+        <div class="docs-nav-item">
+            <a href="./state.html" class="docs-nav-link">State (Deep Reactivity)</a>
+            <div class="docs-nav-subsection" style="margin-left: 1rem; border-left: 1px solid var(--site-border);">
+                <a href="./state.html#shortcomings" class="docs-nav-link" style="font-size: 0.85em;">Shortcomings of
+                    Signals</a>
+                <a href="./state.html#state-to-the-rescue" class="docs-nav-link" style="font-size: 0.85em;">State to the
+                    Rescue</a>
+                <a href="./state.html#state-function" class="docs-nav-link" style="font-size: 0.85em;">State
+                    Function</a>
+                <a href="./state.html#nested-objects" class="docs-nav-link" style="font-size: 0.85em;">Nested
+                    Objects</a>
+                <a href="./state.html#in-the-ui" class="docs-nav-link" style="font-size: 0.85em;">In the UI</a>
+                <a href="./state.html#array-methods" class="docs-nav-link" style="font-size: 0.85em;">Array Methods</a>
+                <a href="./state.html#date-methods" class="docs-nav-link" style="font-size: 0.85em;">Date Methods</a>
+                <a href="./state.html#named-state" class="docs-nav-link" style="font-size: 0.85em;">Named State</a>
+                <a href="./state.html#stored-state" class="docs-nav-link" style="font-size: 0.85em;">Stored State</a>
+                <a href="./state.html#schema-validation" class="docs-nav-link" style="font-size: 0.85em;">Schema
+                    Validation</a>
+                <a href="./state.html#json-schema-lite" class="docs-nav-link" style="font-size: 0.85em;">JSON Schema
+                    Lite</a>
+                <a href="./state.html#transformations" class="docs-nav-link"
+                    style="font-size: 0.85em;">Transformations</a>
+                <a href="./state.html#lite-vs-full" class="docs-nav-link" style="font-size: 0.85em;">Lite vs. Full
+                    Validators</a>
+            </div>
+        </div>
         <div class="docs-nav-item">
             <a href="./hypermedia.html" class="docs-nav-link">Hypermedia</a>
             <div class="docs-nav-subsection" style="margin-left: 1rem; border-left: 1px solid var(--site-border);">

package/docs/api/signals.html

@@ -2,7 +2,7 @@
 <script src="/lightview-router.js?base=/index.html"></script>
 
 <div class="docs-layout">
-    <aside class="docs-sidebar" src="./nav.html"></aside>
+    <aside class="docs-sidebar" src="./nav.html" data-preserve-scroll="docs-nav"></aside>
 
     <main class="docs-content">
         <h1>Signals</h1>