Builders, Collections & Tree Utilities¶
When To Use It¶
Use this area when the question is how to construct primitives, how to expose observable collections, or how to traverse an existing VM tree.
Shape And Ownership¶
Three groups live here:
- immutable fluent builders and additive
createhelpers - opt-in collection primitives such as
ServicedObservableCollection,ObservableList,ObservableDictionary,PagedComposition, andTokenPagedComposition - traversal helpers such as
walk,find, andwalk_expanded
These pieces are deliberately separate from the core hierarchy so you can opt into them only where they help.
Lifecycle And Messaging¶
The main operational rules:
- builders are immutable and reusable
- required fields validate on
Build() ObservableListand VM container batching are independent scopesServicedObservableCollectionpublishes local collection events before hub messages- tree utilities are pure reads; they do not trigger lifecycle transitions
Cross-Language Surface¶
| Primitive | Purpose |
|---|---|
| Builders | immutable fluent construction with validation |
ObservableList<T> |
granular per-mutation list events |
ObservableDictionary<K1, K2, V> |
dual-key observable lookup plus live key views |
PagedComposition<TVM> / TokenPagedComposition<TVM, TToken> |
paging helpers |
walk, find, walk_expanded |
tree traversal helpers |
Example¶
Representative traversal contract:
walk(root)yields root first, then descendants in depth-first pre-orderfind(root, predicate)returns the first match in walk orderwalk_expanded(root)respectsIExpandableboundaries
On the collection side, the Notes Workspace note lists and notifications layers are the practical references for observable-list and paging composition.
Common Pitfalls¶
- Mutating a builder and expecting in-place changes. Builder setters return new instances.
- Assuming
ObservableListbatch scopes also suppressCompositeVMorGroupVMcollection events. They do not. - Rewriting custom tree walkers when the built-in helpers already express the intended traversal semantics.