Hierarchical Family Map

recursive ownership, key-aware batch hydration, and parent/depth/path invariants

Hierarchical Family Map recursive ownership, key-aware batch hydration, and parent/depth/path invariants Hierarchical Family Map recursive ownership, key-aware batch hydration, and parent/depth/path invariants Recursive node contract Materialization, batch hydration, and mutation Traversal and host rendering HierarchicalVM<TModel, TVM> modeled recursive node children are same VM family root and leaf semantics Structural metadata Parent Depth / Path IsRoot / IsLeaf Children cache lazy by default eager option invalidate subtree Cycle protection reject ancestor cycles reject parent-key cycles stable parent links Materialize children factory resolves child models TVM node projection lazy boundary stays explicit attachMany / attach_many consumer key selectors stable fixpoint + dedupe park or reject orphans TreeStructureChangedMessage add/remove/reparent each successful attach recursive observers Lifecycle cascade eager subtree participates lazy subtree waits disposed nodes stop mutating Explorer trees folders notebooks taxonomies Walk utilities walk() walk_expanded() flattened views Adapters tree widgets outline views virtualized renderers Decision rule Use HierarchicalVM when recursive structure is part of the VM contract; attachMany centralizes streamed-tree ordering, dedupe, and orphan policy. exposes owns guards materialize materialized index publish structure cascade resolve render

Recursive contract

  • Each node owns its model and same-family child nodes.
  • Parent, depth, path, root, and leaf facts are built into the primitive.
  • Cycle protection keeps tree mutation safe.

Materialization

  • Children are lazy unless eager construction is requested.
  • Invalidation and structural changes publish explicit tree messages.
  • Lazy subtrees do not participate in lifecycle until materialized.

Batch hydration

  • Consumer selectors keep domain identity outside VMx.
  • Fixpoint scans resolve child-before-parent windows in stable sibling order.
  • Only missing-parent nodes park; duplicates and cycles are terminal results.

Best fit

  • Use it for explorer trees, notebooks, outlines, and taxonomies.
  • Pair with ExpandableState and walk utilities for renderable flattened views.
  • Use CompositeVM only when the domain is a list, not a recursive tree.