kopular 0.21.3 → 0.21.4

package/LLM.md

@@ -300,12 +300,12 @@ w.Bump();                // re-render + diff + patch
     now returns (see `kopscript`'s own `LLM.md`) for a subscription made in the constructor.
     A component built once at app startup and never removed (every `Router` page, most real
     apps' top-level structure) never needs this at all.
-  - `Router`'s own outlet still uses the older `AfterRender` pattern above — a single,
-    always-present slot has nothing to reorder or remove, so this mechanism wouldn't add
-    anything there. Reach for `VElement.Mount` for anything genuinely dynamic: a list of
-    components, a modal that comes and goes.
-  - Hand-written `Render()` only — there's no template (`.html`) syntax yet for embedding a
-    child component the way `*if`/`*for` embed structural logic.
+  - `Router`'s own outlet uses this mechanism too — `Render()` embeds the matched page via
+    `VElement.Mount`, not the older `AfterRender` pattern above (that migration landed once
+    this existed; a single, always-present slot never needed the reordering/removal part,
+    but there was no reason not to use the same real mechanism everywhere).
+  - Templates get the same capability via `*mount="expr"` — see `kopscript`'s own `LLM.md`
+    for the syntax; it desugars to exactly this `VElement.Mount` call.
 - **Content projection (React's `children`/Angular's `<ng-content>`) needs no separate
   mechanism** — pass a `() => VElement` into a child's constructor and call it from inside
   its own `Render()`; it's invoked fresh every render and closes over the parent's `this`,
@@ -766,12 +766,14 @@ class CounterService {
   of the tree's own data, not wired against a live DOM node until `Materialize`/`Patch`
   runs) — an event Kopular doesn't have a named field for isn't reachable from `Render()`
   at all yet.
-- **A `Component` embedded via `AfterRender`/`Mount()` (imperative, `Router`'s own outlet
-  pattern) is NOT the same as one embedded via `VElement.Mount()` (declarative, part of
-  the tree)** — only the latter gets real reconciliation (patch in place, reorder, tear
-  down). If you find yourself calling `.Mount()`/`.Update()` on a child by hand from
-  `AfterRender` for anything that needs to be added, removed, or reordered, use
-  `VElement.Mount(component)` in `Render()` instead — see "Component" above.
+- **A `Component` embedded via `AfterRender`/`Mount()` (imperative) is NOT the same as one
+  embedded via `VElement.Mount()` (declarative, part of the tree)** — only the latter gets
+  real reconciliation (patch in place, reorder, tear down); this includes `Router`'s own
+  outlet, which uses `VElement.Mount` internally, not the older `AfterRender` pattern. If
+  you find yourself calling `.Mount()`/`.Update()` on a child by hand from `AfterRender`
+  for anything that needs to be added, removed, or reordered, use
+  `VElement.Mount(component)` in `Render()` (or `*mount="expr"` in a template) instead —
+  see "Component" above.
 
 ## Does not exist
 

package/README.md

@@ -188,11 +188,12 @@ class RoutedApp : Component {
     return VElement.Create("div");
   }
 
-  // Mounting the Router — a live, nested Component — isn't something a
-  // VElement tree can express as data (see "Component" above). AfterRender
-  // is called with the real DOM node Render()'s tree just became, once
-  // Mount()/Update() has actually materialized/patched it — here, that's
-  // the container itself.
+  // VElement.Mount(this.Nav) in Render() (see "Nested component composition"
+  // below) would work here too, but a single, always-present root slot has
+  // no reordering or removal to get right, so the older, simpler
+  // AfterRender is just as correct — it's called with the real DOM node
+  // Render()'s tree just became, once Mount()/Update() has actually
+  // materialized/patched it, here that's the container itself.
   protected override void AfterRender(Element root) {
     this.Nav.Mount(root);
   }
@@ -245,10 +246,10 @@ nav.AddRoute("/dogs/:id", new DogPage(nav));
 el.TextContent = "Dog #" + this.Nav.Param;
 ```
 
-`Param` is a plain `string`, deliberately not `state<T>` — Router's own `AfterRender`
-already re-`Mount()`s the matched page into its outlet on every `Navigate()`/`popstate`,
-which re-runs that page's `Render()` (reading the fresh `Param`) with no extra step. No
-`Subscribe()` needed on it.
+`Param` is a plain `string`, deliberately not `state<T>` — `Router`'s own `Render()` already
+re-embeds the matched page into its outlet (via `VElement.Mount`) on every
+`Navigate()`/`popstate`, which re-runs that page's `Render()` (reading the fresh `Param`)
+with no extra step. No `Subscribe()` needed on it.
 
 **More than one dynamic segment**, and a trailing **wildcard** segment, both work too —
 read each by name via `Router.Params(name)` instead (`Param` above still holds the
@@ -493,11 +494,14 @@ must stop, not just outlive an app that was going to unload anyway. Removing a c
 that itself mounted further children tears the *whole* subtree down, however many levels
 deep — a middle component overriding its own `OnUnmount()` doesn't skip its children's.
 
-`Router`'s own outlet still uses the older `AfterRender`-based pattern (see "Router, and
-deploying it" below) rather than this — a single, always-present slot has no reordering or
-removal to get right, so there's nothing this mechanism would add there. Reach for
+`Router`'s own outlet uses this mechanism too — its `Render()` embeds the matched page via
+`VElement.Mount`, not the older `AfterRender`-based pattern still shown in "Router, and
+deploying it" below for mounting the `Router` itself into an app's root container (a
+single, always-present slot, where there's nothing this mechanism would add). Reach for
 `VElement.Mount` for anything with real add/remove/reorder: a list of components, a modal
-that comes and goes, anything genuinely dynamic.
+that comes and goes, anything genuinely dynamic. A template gets the same capability via
+`*mount="expr"` — see "Templates" in `kopscript`'s own README/LLM.md for the syntax; it
+desugars to exactly this call.
 
 ## Content projection — a parent giving a child what to render
 
@@ -863,10 +867,10 @@ v1 / hobby-project scope, same as KopScript itself. `Update()` diffs and patches
 live child Component can be embedded directly in a parent's own tree via
 `VElement.Mount(child)` — see "Nested component composition" above — so a parent's
 re-render really can create/patch/reorder/tear down nested children declaratively now,
-closing what used to be documented here as the framework's biggest reconciliation gap.
-The one real limit that remains: this only works from a hand-written `Render()` today —
-there's no template (`.html`) syntax yet for embedding a child component the way `*if`/
-`*for` embed structural logic. A list child (`Mounted` or plain) without a stable
+closing what used to be documented here as the framework's biggest reconciliation gap. A
+template (`.html`) embeds one too, via `*mount="expr"` (`kopscript@0.25.0`+), the same way
+`*if`/`*for` embed structural logic — see "Templates" in `kopscript`'s own docs. A list
+child (`Mounted` or plain) without a stable
 `VElement.Id` still renders correctly across a reorder, but isn't guaranteed to keep the
 same real DOM node (see "Structural directives" above). `Update()` called before `Mount()`
 is a safe no-op — see `LLM.md`'s `Component` section for exactly when that happens

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kopular",
-  "version": "0.21.3",
+  "version": "0.21.4",
   "description": "Kopular: a small component framework for KopScript — components, reactive state, constructor-injected services, routing, real compiled templates, and HTTP, with no DI container",
   "type": "module",
   "license": "MIT",
@@ -62,7 +62,7 @@
     "@types/jsdom": "^30.0.0",
     "@types/node": "^20.14.0",
     "jsdom": "^25.0.1",
-    "kopscript": "^0.24.0",
+    "kopscript": "^0.25.0",
     "typescript": "^5.5.0",
     "vitest": "^4.1.11"
   },