ngx-json-render 0.5.0 → 0.5.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ngx-json-render",
-  "version": "0.5.0",
+  "version": "0.5.1",
   "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

@@ -604,7 +604,22 @@ declare class JrElement {
     /** Prop/visibility resolution context (state + repeat scope + extensions). */
     private readonly resolutionCtx;
     protected readonly visible: Signal<boolean>;
-    /** The element with all prop expressions resolved. */
+    /**
+     * The element with all prop expressions resolved.
+     *
+     * 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.
+     *
+     * 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.
+     */
     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>;