v0.7.8

A spec that arrives again, or a form full of bound fields, now costs only what actually changed.

Two cases still made the renderer redo work across the whole tree. A spec handed over as all-new objects (a whole-spec part, a host that fetches the spec again, buildSpecFromParts replaying a message) made every element resolve its props, and every container re-render. And every element with a $bindState or $bindItem prop resolved and re-rendered on every state write, whatever path the write touched. On a tree of 1,001 elements, an identical spec now resolves nothing instead of 1,000 elements, and one keystroke in a 500-field form re-renders one field instead of 500.

What changes for your app

• Spec elements compare by content. An element whose content did not change keeps its resolved props and its template does not re-run, however the spec object was built. Streamed patches already shared unchanged elements and behave as before.
• spec.state no longer overwrites the user's edits when the same spec arrives again. In uncontrolled mode, only leaves whose content changed are written to the store. Before, arrays compared by reference, so re-sending an unchanged spec wrote every array back and discarded edits made inside it, such as text typed into a field bound with $bindItem. A spec whose state really changed still writes the new value.
• Two-way bound elements follow only their own paths. They resolve when a path they read is written, like any other element. A write that touches the bound path (the path itself, a container above it, or a path inside it) still always reaches the component, so the README's input pattern keeps putting the DOM right when the value returns to what it was.

Upgrading

npm i ngx-json-render@0.7.8 — no API changes, and ngx-json-render-material@^0.3.8 works with it unchanged. If an app relied on re-sending the same spec to reset its state, write that state explicitly instead, for example with a setState action.

Full Changelog: v0.7.7...v0.7.8