lego-dom 0.0.8 → 1.0.0

package/docs/contributing/13-directives.md

@@ -0,0 +1,225 @@
+# You know C++, I know Web Components++
+
+Let's break down the two simplest yet most vital directives in the library: b-if and b-text. These are the "workhorses" that handle visibility and data display without you having to write manual DOM manipulation code.
+
+## Conditional Directives `b-if` & `b-show`
+
+Directives like `b-if`, `b-text`, and `b-for` are the "Instructions" that bridge the gap between your JavaScript state and the DOM. Without them, your state would just be numbers and strings sitting in memory with no way to manifest on the screen.
+
+### 1. Conditional Visibility (`b-show`)
+
+The `b-show` directive is used to show or hide elements based on a truthy or falsy value in your state.
+
+-   **How it works**: During the `render()` cycle, the library executes `safeEval(b.expr, { state, self: b.node })`.
+    
+-   **The Implementation**:
+
+    
+    ```js
+    if (b.type === 'b-show') b.node.style.display = safeEval(b.expr, { state, self: b.node }) ? '' : 'none';
+    ```
+    
+    -   LegoDOM does not physically remove the element from the DOM (which is expensive), this library uses `display: none`.
+    
+    -   This means **b-show** is incredibly fast because the browser doesn't have to recalculate the entire DOM tree.
+        
+    -  It however also means the element still exists in memory and its `mounted` hook remains active even when hidden.
+
+
+### 2. Alternating Visibility (`b-if`)
+
+#### 1. The "Place in Line" Problem
+
+When an element has `b-if="false"`, we want it to disappear. If we simply remove it (`node.remove()`), the browser "forgets" where that element was supposed to live.
+
+-   **The Risk:** If that element was originally between a `<h1>` and a `<footer>`, and the condition turns `true` later, how does the library know exactly where to put it back?
+    
+-   **The Solution:** We leave a "bookmark" or an **Anchor** (a tiny, invisible `Comment` node) exactly where the element used to be.
+
+```js
+if (node.hasAttribute('b-if')) {
+    const expr = node.getAttribute('b-if');
+    // Create an anchor point to keep track of where the element belongs in the DOM
+    const anchor = document.createComment(`b-if: ${expr}`);
+    const data = getPrivateData(node);
+    data.anchor = anchor;
+    bindings.push({ type: 'b-if', node, anchor, expr });
+}
+```
+    
+
+### 2. Why use a Comment Node?
+
+We use `document.createComment()` because:
+
+-   It is a valid DOM node that occupies a specific position in the `childNodes` list.
+    
+-   It is completely invisible to the user and doesn't affect CSS layouts or accessibility.
+    
+-   It acts as a permanent reference point for the `replaceChild` operation.
+    
+
+### 3. Why store it in `getPrivateData`?
+
+LegoDOM was designed in a way that the `render()` function runs every time state changes.
+
+-   **Consistency:** By storing the anchor in the element's `privateData` (via `WeakMap`), we ensure that the same specific element is always paired with the same specific anchor.
+    
+-   **The Swap Logic:**
+    
+    -   **Condition becomes `false`:** We find the element in the DOM and replace it with its stored anchor: `parent.replaceChild(anchor, node)`.
+        
+    -   **Condition becomes `true`:** We find the anchor in the DOM and replace it with the element: `parent.replaceChild(node, anchor)`.
+        
+
+### 4. Memory Safety
+
+By using `getPrivateData` (which is a `WeakMap`), we ensure that if the component is destroyed, the reference to the `anchor` is garbage collected. If we didn't store it here, we would have to scan the entire DOM or maintain complex external maps to find where to re-insert hidden elements, which would be a massive performance hit.
+
+**In short:** The anchor is the "Reserved Seat" sign at a theater. `getPrivateData` is the list that remembers which seat belongs to which person while they are out in the lobby.
+
+
+## Simple Text Interpolation (`b-text`)
+
+While you can use <code v-pre>{{mustaches}}</code>, `b-text` is the "cleaner" way to bind the entire content of an element to a single variable.
+
+-   **The Logic**: It uses the `resolve()` helper to walk through your state object based on a string path.
+    
+    -   Example: `<span b-text="user.profile.name"></span>`.
+        
+-   **The Implementation**:
+    
+    ```js
+    if (b.type === 'b-text') b.node.textContent = escapeHTML(resolve(b.path, state));
+    ```
+
+-   **Security**: Note the use of `escapeHTML()`. This is a critical security feature that prevents **XSS (Cross-Site Scripting) attacks** by turning characters like `<` into `&lt;`, ensuring that user-provided data cannot execute malicious scripts in your app.
+
+
+### 3. Efficiency in the Render Loop
+
+Because both of these were "mapped" during the `scanForBindings` phase (Topic 11), the `render` engine holds a direct reference to the DOM `node`.
+
+-   It doesn't have to look for the element by ID or class.
+    
+-   It just goes: "Variable X changed -> Go to memory address for Node Y -> Update `.style.display` or `.textContent`".
+
+
+## Iterative Directive: `b-for` & The Pool
+
+The library looks for the pattern `item in list` (e.g., `user in users`).
+
+-   **Capture**: During the scanning phase, it saves the inner HTML of the element as a "template string" and then empties the element so it can be filled dynamically.
+    
+
+### The Concept of "The Pool" (`forPools`)
+
+To prevent "DOM Thrashing" (constantly creating and deleting elements), the library uses a `WeakMap` called `forPools`.
+
+-   **The Cache**: Each `b-for` node has its own `Map` inside the pool.
+    
+-   **The Key**: It identifies each item in your array. If the item is an object, it assigns a hidden `__id`. If it's a primitive (like a string), it combines the index and the value.
+    
+-   **Why?**: If you re-order a list of 100 items, the library doesn't create 100 new elements. it finds the existing elements in the "pool" by their key and simply moves them to the new position.
+    
+
+### 3. The Local Scope Injection
+
+This is a brilliant piece of JavaScript engineering. When rendering a list item, the library needs the item (e.g., `user`) to be available, but it also needs the parent component's data to be available.
+
+
+```js
+const localScope = Object.assign(Object.create(state), { [b.itemName]: item });
+
+```
+
+-   **Prototype Inheritance**: It creates a new object where the **prototype** is the component's state (`_studs`).
+    
+- **The Result**: Inside the loop, if you reference <code v-pre>{{user.name}}</code>, it finds it on the `localScope`. If you reference <code v-pre>{{globalTitle}}</code> (defined in the parent), it doesn't find it on `localScope`, so it automatically looks up the prototype chain to find it in the parent `state`.
+    
+
+### 4. Updating and Pruning
+
+-   **Update**: For every item in the current array, it calls `updateNodeBindings(child, localScope)` to fill in the mustaches for that specific row.
+    
+-   **Surgical Sync**: It specifically looks for `b-sync` inputs inside the loop to ensure two-way binding works correctly for individual list items.
+    
+-   **Prune**: After the loop finishes, any element left in the "pool" that wasn't used in the current render (meaning it was deleted from your data array) is physically removed from the DOM.
+
+## Directive: `b-sync` (Two-Way Binding)
+
+The `b-sync` directive is designed to keep an `<input>`, `<textarea>`, or `<select>` element in perfect synchronization with a specific variable in your state.
+
+```js
+if (child.hasAttribute('b-sync')) {
+    const prop = child.getAttribute('b-sync');
+    const updateState = () => {
+        let target, last;
+        if (loopCtx && prop.startsWith(loopCtx.name + '.')) {
+        const list = safeEval(loopCtx.listName, { state, global: Lego.globals, self: componentRoot });
+        const item = list[loopCtx.index];
+        if (!item) return;
+        const subPath = prop.split('.').slice(1);
+        last = subPath.pop();
+        target = subPath.reduce((o, k) => o[k], item);
+        } else {
+        const keys = prop.split('.');
+        last = keys.pop();
+        target = keys.reduce((o, k) => o[k], state);
+        }
+        const newVal = child.type === 'checkbox' ? child.checked : child.value;
+        if (target && target[last] !== newVal) target[last] = newVal;
+    };
+    child.addEventListener('input', updateState);
+    child.addEventListener('change', updateState);
+}
+```
+
+### 1. The Setup: Listening for Changes
+
+When the `scanForBindings` function encounters a `b-sync="somePath"` attribute, it doesn't just record it for rendering; it attaches an **event listener** to the element.
+
+-   **The Event**: It listens for the `input` event (which fires every time a character is typed).
+    
+-   **The Logic**: When the event fires, the library captures the `event.target.value`.
+    
+-   **The Update**: It uses the internal `set()` helper to reach into your component's `_studs` and update the value at the path you specified (e.g., `user.name`).
+    
+
+### 2. The Implementation: Multi-Type Support
+
+The library is smart enough to handle different types of inputs automatically:
+
+-   **Checkboxes**: It looks at `.checked` instead of `.value`.
+    
+-   **Numbers**: If the input `type` is "number" or "range", it automatically converts the string from the DOM into a real JavaScript `Number` before saving it to your state.
+    
+
+### 3. Preventing the "Echo" Effect
+
+A common problem in two-way binding is the "Infinite Update Loop":
+
+1.  You type "A".
+    
+2.  `b-sync` updates the state to "A".
+    
+3.  The state change triggers a `render()`.
+    
+4.  `render()` updates the input value to "A".
+    
+5.  The cursor jumps to the end of the input or triggers another event.
+    
+
+**How Lego solves it**: During the `render()` phase for a `b-sync` binding, the library checks if the element is currently the `document.activeElement` (the thing you are typing in). If it is, and the value hasn't changed from what's already there, it skips the update to avoid disturbing your typing flow.
+
+### 4. The `b-sync` inside `b-for` loops
+
+As mentioned in Topic 14, `b-sync` works inside loops. If you have a list of inputs generated by a `b-for`, each input is synced to its specific item in the array. The library uses the `localScope` (with its prototype chain) to ensure that typing in the 3rd input only updates the 3rd item in your data list.
+
+----------
+
+**Summary**: `b-if` manages visibility via CSS, and `b-text` manages safe text updates via property resolution.
+
+`b-for` is a "Reconciliation Engine". It uses a memory pool to recycle DOM nodes and clever prototype inheritance to give each row access to both its own data and the parent's data.
+
+`b-sync` automates the "Boilerplate" of web development. You no longer have to write `onchange` handlers for every input; you just name the variable, and the library handles the rest.

package/docs/contributing/14-events.md

@@ -0,0 +1,57 @@
+# Lights, Camera, Action
+
+This is how LegoDOM makes your components interactive by connecting DOM events (clicks, keypresses, submits) directly to the methods you wrote in
+your **SFC** (Single File Component) autodiscovered **.lego** file, `<template />` tag or Lego.define call.
+
+## Event Handling (The `@event` Syntax)
+
+The library uses a shorthand syntax for event listeners: `@event-name="methodName"`. For example, `@click="increment"` or `@submit="saveUser"`.
+
+### 1. The `bind(container, el)` Phase
+
+During the `snap()` process, after the Shadow DOM is attached, the library calls `bind(container, el)`.
+
+-   **Scanning for Attributes**: It looks through all elements in the Shadow DOM for any attribute starting with `@`.
+    
+-   **The Match**: If it finds `@click="toggle"`, it identifies `click` as the event and `toggle` as the function name to look for in `_studs`.
+    
+
+### 2. Context Preservation (`.bind`)
+
+This is a critical "under the hood" step. When you click a button, the browser usually sets the keyword `this` to the button itself. However, in Lego, you want `this` to be your **reactive state**.
+
+-   **The Implementation**:
+    
+    ```js
+    const handler = state[methodName].bind(state);
+    node.addEventListener(eventName, handler);
+    ```
+    
+-   By using `.bind(state)`, the library ensures that when your `toggle()` function runs, `this.show = true` actually updates the proxy state, not the HTML button.
+    
+
+### 3. Argument Support
+
+The library is flexible with how you call these methods:
+
+-   **Standard Call**: `@click="doSomething"` passes the native `Event` object as the first argument.
+    
+-   **Parameterized Call**: `@click="deleteItem(5)"`. The library uses a regex to check if there are parentheses. If it finds them, it parses the arguments (like `5`) and passes them to your function.
+    
+-   **The "Magic" `$event`**: If you write `@click="move($event, 10)"`, the library intelligently injects the native browser event object into that specific slot.
+    
+
+### 4. Event Modifiers
+
+Lego includes built-in modifiers to handle common web patterns without writing extra JS:
+
+-   **`.prevent`**: Automatically calls `event.preventDefault()`. Great for `@submit.prevent="save"`.
+    
+-   **`.stop`**: Calls `event.stopPropagation()` to stop the event from bubbling up to parent elements.
+    
+-   **`.enter`**: Only triggers the method if the "Enter" key was pressed (perfect for search bars).
+    
+
+----------
+
+**Summary**: The `@` syntax automates `addEventListener`, ensures the correct `this` context for your methods, and provides powerful modifiers to keep your component logic clean.

package/docs/contributing/15-router.md

@@ -0,0 +1,9 @@
+# Where do you want to go?
+
+The true power of the Lego router isn't just changing the URL; it's the **targeted DOM injection** that allows you to swap _any_ part of the page with _any_ component, without writing a single line of `fetch` or `innerHTML` logic.
+
+
+## LegoDOM Router
+
+
+

package/docs/contributing/16-state.md

@@ -0,0 +1,48 @@
+# Lego and the Brain
+In Lego, the code is designed to allow a component in the footer to talk to a component in the header without them ever being "parents" or "children" of each other.
+
+## Global State (`Lego.globals`) & The Observer Pattern
+
+
+
+### 1. The "Why": Decoupling the Hierarchy
+
+In most frameworks, data flows down like a waterfall. If a deeply nested component needs a piece of data, every parent above it must "pass it down." The code in `main.js` avoids this by creating a centralized, reactive hub.
+
+### 2. The Implementation: The "Universal Proxy"
+
+When you define `Lego.globals`, the library doesn't just store your object. It wraps the entire thing in the same `reactive()` proxy used for individual components.
+
+-   **The Code**: `Lego.globals = reactive(userDefinedGlobals, null)`.
+    
+-   **The Magic of `null`**: Notice that when a component's state is made reactive, we pass the `el` (the element) so it knows what to render. When we create `Lego.globals`, we pass `null`. This tells the proxy: "You don't belong to one element; you belong to everyone".
+    
+
+### 3. The `$global` Prefix and Subscriptions
+
+The library uses a specific naming convention to trigger its "Global Watcher" logic. Whenever the `render()` engine or a `b-sync` sees a variable starting with `$`, it knows to ignore the local component state (`_studs`) and look into `Lego.globals` instead.
+
+-   **The Subscription Logic**: In the `render()` function, if a global is accessed, the code automatically adds that component to a "Global Subscribers" list.
+    
+-   **The Update Loop**: When you change a global (e.g., `Lego.globals.theme = 'dark'`), the Proxy's `set` trap fires. Because this proxy is global, it iterates through **every single component** currently on the page and tells them to check if they need a re-render.
+    
+
+### 4. Why `Object.defineProperty` is avoided for Globals
+
+The library sticks to **Proxy** for globals because it allows for **dynamic property addition**.
+
+-   In older libraries, you had to declare all your global variables upfront.
+    
+-   Because Lego uses a Proxy, you can do `Lego.globals.newVar = 'surprise'` at runtime, and the library will immediately catch that "set" operation and notify all components, even though `newVar` didn't exist when the app started.
+    
+
+### 5. The `$go` and Globals Synergy
+
+This is where the code becomes a "system." When you use `$go` to swap a component (Topic 17), the new component is born, it scans its HTML, sees a `$user` variable, and "subscribes" to the global state.
+
+-   This allows for **Persistent Identity**: The user's name stays in the header because the header is subscribed to `Lego.globals.user`, even as the rest of the page is being torn down and rebuilt by the router.
+    
+
+----------
+
+**Summary**: The code uses a "Centralized Proxy" to bypass the DOM hierarchy, ensuring that data is shared via subscription rather than inheritance.

package/docs/contributing/17-legodom.md

@@ -0,0 +1,55 @@
+# Mama "We Made It!"
+Everything we’ve discussed i.e. the Scanner, the Registry, the Router, and the Snap etc. "Everything" stays dormant until `Lego.init()` is called. This function is not just a starter; it’s an orchestrator that synchronizes the JavaScript environment with the existing HTML on the page.
+
+## The Lego Initializer
+
+The code for `init()` is deceptively small because its primary job is to flip the switches on the systems we've already built.
+
+### 1. The Singleton Guard
+
+The very first thing `init()` does is check a internal flag: `if (initialized) return;`.
+
+-   **The Why**: In a complex app, you might accidentally call `init()` multiple times. Without this guard, you would attach multiple `MutationObservers` to the body, causing every component to "snap" and "render" twice for every single change.
+    
+
+### 2. Bootstrapping the Watchdog
+
+The core of the initialization is setting up the `MutationObserver` we discussed in Topic 7.
+
+-   **The Target**: It targets `document.body`.
+    
+-   **The Configuration**: It uses `{ childList: true, subtree: true }`.
+    
+-   **The Why**: By starting the observer _before_ the first render, the library ensures that any elements it creates during the initial startup are also caught and "snapped" into life.
+    
+
+### 3. The "Initial Snap" (The Recursive Wake-up)
+
+Once the observer is live, the code calls `snap(document.body)`.
+
+-   **The Why**: The `MutationObserver` only sees _new_ changes. It cannot see the HTML that was already there when the page loaded.
+    
+-   **The Logic**: By manually calling `snap` on the body, the library recursively walks through your entire server-rendered HTML. It finds every custom tag (e.g., `<user-card>`) and "upgrades" them into components.
+    
+
+### 4. Activating the Global Listener
+
+This is where the **Router Hijack** (Topic 17) is installed.
+
+-   The code adds a single click listener to the `window`.
+    
+-   **The Why**: Instead of attaching listeners to every individual `<a>` tag (which would be slow and break when new links are added), it uses **Event Delegation**. It waits for clicks to bubble up to the window, checks if they are `b-link` clicks, and then decides whether to trigger the router.
+    
+
+### 5. The First Route Check
+
+Finally, `init()` calls `router()` manually for the first time.
+
+-   **The Why**: If a user navigates directly to `mysite.com/dashboard`, the browser loads the page, but the JavaScript needs to know which component to put into the `router-view` immediately. This manual call ensures the UI matches the URL on the very first frame.
+    
+
+----------
+
+**The Architecture "Why"**: Lego is designed to be **Zero-Config**. By putting all these steps into `init()`, the developer only has to care about one thing: "When is my DOM ready?" The code handles the complex timing of making sure the Watchdog is looking while the Router is switching and the Snap is initializing.
+
+**Summary**: `Lego.init()` is the bridge. It turns a static document into a reactive application by starting the observer, snapping the existing HTML, and hijacking the navigation.

package/docs/contributing/index.md

@@ -0,0 +1,5 @@
+# Welcome to the LegoDOM Source Code Explainer Series ;-)
+
+Here I will give a sneak peek into my brain and thinking when designing the LegoDOM library. Some
+decisions might suck to you - I am happy to hear your honest feedback on the
+[community chat](https://github.com/rayattack/lego-dom/discussions).

package/docs/examples/form.md

@@ -1,6 +1,6 @@
 # Form Example
 
-Handling forms in LegoJS.
+Handling forms in Lego.
 
 ## Live Demo
 
@@ -17,7 +17,7 @@ Handling forms in LegoJS.
       <input type="password" b-sync="password">
     </div>
     
-    <p b-if="error" style="color: red">{{ error }}</p>
+    <p b-show="error" style="color: red">{{ error }}</p>
     
     <button type="submit">Login</button>
   </form>

package/docs/examples/index.md

@@ -1,6 +1,6 @@
 # Examples
 
-Explore these hands-on examples to learn LegoJS patterns and best practices.
+Explore these hands-on examples to learn Lego patterns and best practices.
 
 ## Quick Examples
 
@@ -27,7 +27,7 @@ Two-way data binding with `b-sync`.
 ```html
 <template b-id="name-input">
   <input b-sync="name" placeholder="Enter your name">
-  <p b-if="name">Hello, {{ name }}!</p>
+  <p b-show="name">Hello, {{ name }}!</p>
 </template>
 
 <name-input b-data="{ name: '' }"></name-input>
@@ -49,7 +49,7 @@ Lists with `b-for`.
 
 <todo-list b-data="{
   todos: [
-    { text: 'Learn LegoJS', done: true },
+    { text: 'Learn Lego', done: true },
     { text: 'Build an app', done: false }
   ]
 }"></todo-list>
@@ -101,4 +101,4 @@ Try these examples directly in your browser:
 
 - Check the [API Reference](/api/)
 - Read the [Guide](/guide/)
-- View the [source code](https://github.com/rayattack/LegoJS)
+- View the [source code](https://github.com/rayattack/Lego)

package/docs/examples/routing.md

@@ -10,7 +10,7 @@ A multi-page application demonstrating client-side routing.
 <head>
   <meta charset="UTF-8">
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>Routing Demo - LegoJS</title>
+  <title>Routing Demo - Lego</title>
   <style>
     body {
       font-family: system-ui, sans-serif;
@@ -87,7 +87,7 @@ A multi-page application demonstrating client-side routing.
     </style>
     
     <div class="hero">
-      <h1>Welcome to LegoJS Routing Demo</h1>
+      <h1>Welcome to Lego Routing Demo</h1>
       <p>Navigate between pages using client-side routing</p>
     </div>
     
@@ -113,8 +113,8 @@ A multi-page application demonstrating client-side routing.
       self { display: block; }
     </style>
     
-    <h1>About LegoJS</h1>
-    <p>LegoJS is a tiny, zero-dependency JavaScript library for building reactive Web Components.</p>
+    <h1>About Lego</h1>
+    <p>Lego is a tiny, zero-dependency JavaScript library for building reactive Web Components.</p>
     
     <h2>Features</h2>
     <ul>
@@ -176,11 +176,11 @@ A multi-page application demonstrating client-side routing.
       }
     </style>
     
-    <div b-if="loading" class="loading">
+    <div b-show="loading" class="loading">
       Loading user...
     </div>
     
-    <div b-if="!loading && user" class="profile">
+    <div b-show="!loading && user" class="profile">
       <h1>{{ user.name }}</h1>
       <p><strong>Email:</strong> {{ user.email }}</p>
       <p><strong>Phone:</strong> {{ user.phone }}</p>
@@ -243,7 +243,7 @@ A multi-page application demonstrating client-side routing.
     
     <h1>Contact Us</h1>
     
-    <form b-if="!submitted" @submit="handleSubmit(event)">
+    <form b-show="!submitted" @submit="handleSubmit(event)">
       <div class="form-group">
         <label>Name</label>
         <input b-sync="form.name" required>
@@ -262,7 +262,7 @@ A multi-page application demonstrating client-side routing.
       <button type="submit">Send Message</button>
     </form>
     
-    <div b-if="submitted" class="success">
+    <div b-show="submitted" class="success">
       <h3>✅ Message Sent!</h3>
       <p>Thank you for contacting us, {{ form.name }}. We'll respond to {{ form.email }} soon.</p>
       <button @click="submitted = false">Send Another</button>

package/docs/examples/sfc-showcase.md

@@ -7,13 +7,13 @@ Using `.lego` files with Vite.
 **Counter.lego**
 ```html
 <template>
-  <style>
-    button { color: red; }
-  </style>
-  
   <button @click="count++">Count: {{ count }}</button>
 </template>
 
+<style>
+  button { color: red; }
+</style>
+
 <script>
   export default {
     count: 0

package/docs/examples/todo-app.md

@@ -1,6 +1,6 @@
 # Todo App Example
 
-A complete todo application demonstrating LegoJS features.
+A complete todo application demonstrating Lego features.
 
 ## Live Demo
 
@@ -14,7 +14,7 @@ A complete todo application demonstrating LegoJS features.
 <head>
   <meta charset="UTF-8">
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>Todo App - LegoJS</title>
+  <title>Todo App - Lego</title>
   <style>
     body {
       font-family: system-ui, -apple-system, sans-serif;
@@ -212,7 +212,7 @@ A complete todo application demonstrating LegoJS features.
       <span>{{ remaining() }} item{{ remaining() === 1 ? '' : 's' }} left</span>
       <button 
         class="clear-completed" 
-        b-if="completedCount() > 0"
+        b-show="completedCount() > 0"
         @click="clearCompleted()">
         Clear completed ({{ completedCount() }})
       </button>

package/docs/guide/cdn-usage.md

@@ -1,6 +1,6 @@
 # CDN Usage
 
-LegoJS works perfectly without any build tools. Just include it via CDN and start building!
+Lego works perfectly without any build tools. Just include it via CDN and start building!
 
 ## Quick Start
 
@@ -19,8 +19,11 @@ LegoJS works perfectly without any build tools. Just include it via CDN and star
   <!-- Use it -->
   <hello-world b-data="{ message: 'Hello from CDN!' }"></hello-world>
   
-  <!-- Include LegoJS -->
+  <!-- Include Lego -->
   <script src="https://unpkg.com/lego-dom/main.js"></script>
+  <script>
+    Lego.init();
+  </script>
 </body>
 </html>
 ```
@@ -65,7 +68,7 @@ Here's a full working application using only CDN:
 <head>
   <meta charset="UTF-8">
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>Todo App - LegoJS</title>
+  <title>Todo App - Lego</title>
   <style>
     body {
       font-family: system-ui, sans-serif;
@@ -146,7 +149,7 @@ Here's a full working application using only CDN:
     Lego.define('todo-app', Lego.registry['todo-app'].innerHTML, {
       newTodo: '',
       todos: [
-        { text: 'Learn LegoJS', done: true },
+        { text: 'Learn Lego', done: true },
         { text: 'Build something awesome', done: false }
       ],
       addTodo() {
@@ -162,6 +165,9 @@ Here's a full working application using only CDN:
         return this.todos.filter(t => !t.done).length;
       }
     });
+
+    // Don't forget to init!
+    Lego.init();
   </script>
 </body>
 </html>
@@ -169,7 +175,7 @@ Here's a full working application using only CDN:
 
 ## Progressive Enhancement
 
-LegoJS is perfect for progressively enhancing existing sites:
+Lego is perfect for progressively enhancing existing sites:
 
 ```html
 <!-- Your existing page -->
@@ -208,19 +214,21 @@ LegoJS is perfect for progressively enhancing existing sites:
       window.location.href = '/logout';
     }
   });
+
+  Lego.init();
 </script>
 ```
 
 ## Embedding in Existing Apps
 
-LegoJS components work alongside other frameworks:
+Lego components work alongside other frameworks:
 
 ```html
 <!-- Works fine with jQuery, Bootstrap, etc. -->
 <script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>
 <script src="https://unpkg.com/lego-dom/main.js"></script>
 
-<!-- Your LegoJS component -->
+<!-- Your Lego component -->
 <my-component></my-component>
 
 <!-- Your jQuery code -->
@@ -271,7 +279,7 @@ For maximum security:
 
 ## Browser Compatibility
 
-LegoJS works in all modern browsers:
+Lego works in all modern browsers:
 
 - ✅ Chrome 63+
 - ✅ Firefox 63+