ngx-json-render 0.7.7 → 0.7.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ngx-json-render",
-  "version": "0.7.7",
+  "version": "0.7.8",
   "description": "Angular renderer for json-render — stream AI-generated JSON specs into real Angular components with signals.",
   "keywords": [
     "angular",

package/types/ngx-json-render.d.ts

@@ -628,7 +628,16 @@ declare class JrElement {
     private readonly repeatScope;
     private readonly parentPath;
     private readonly devtoolsActive;
-    /** The raw (unresolved) element from the spec. */
+    /**
+     * The raw (unresolved) element from the spec.
+     *
+     * Compared by content, not identity. A streamed patch shares every element
+     * it did not touch, and the identity check settles those at once; but a
+     * spec can also arrive as all-new objects — a whole-spec part, a host that
+     * fetches it again, `buildSpecFromParts` replaying a message — and then an
+     * element whose content is unchanged would resolve, and every container
+     * with a fresh `children` array re-render, for nothing.
+     */
     readonly rawElement: Signal<UIElement<string, Record<string, unknown>> | undefined>;
     /**
      * The state paths this element's expressions can read, or null when the
@@ -662,21 +671,30 @@ declare class JrElement {
     private readonly resolutionCtx;
     protected readonly visible: Signal<boolean>;
     /**
-     * The element with all prop expressions resolved.
+     * How many state writes have touched a path this element is two-way bound
+     * to. See {@link resolution} for why those writes count on their own.
+     */
+    private readonly boundWrites;
+    /**
+     * The element with all prop expressions resolved, and the bound writes it
+     * was resolved after.
      *
-     * Resolving builds a new props object on every state write, whatever the
-     * write touched. Handing that on as a change would re-run every catalog
-     * template in the tree for one keystroke, so a result that holds the same
-     * values as the last one counts as unchanged and keeps the old object.
+     * Resolving builds a new props object every time, so a result that holds
+     * the same values as the last one counts as unchanged and keeps the old
+     * object; otherwise one keystroke would re-run every catalog template that
+     * happened to resolve.
      *
-     * Two-way bound elements are the exception, and keep treating every
-     * resolution as a change. Their component writes the user's input into the
-     * DOM before it reaches state, so the DOM can differ from a prop whose
-     * value never did: typing and a `clearStatePath` in the same turn take
-     * the prop from '' through 'milk' back to '' with nobody reading 'milk'.
-     * The README tells catalog authors to sync such inputs with an effect on
-     * props, and that effect only gets to put the DOM right if it runs.
+     * A write to a path the element is bound to always counts, though. Its
+     * component writes the user's input into the DOM before it reaches state,
+     * so the DOM can differ from a prop whose value never did: typing and a
+     * `clearStatePath` in the same turn take the prop from '' through 'milk'
+     * back to '' with nobody reading 'milk'. The README tells catalog authors
+     * to sync such inputs with an effect on props, and that effect only gets to
+     * put the DOM right if it runs. Writes anywhere else compare by value, like
+     * any element's.
      */
+    private readonly resolution;
+    /** The element with all prop expressions resolved. */
     readonly resolvedElement: Signal<UIElement<string, Record<string, unknown>> | undefined>;
     /** Two-way binding paths ($bindState / $bindItem) by prop name. */
     readonly bindings: Signal<Record<string, string> | undefined>;