One game concept can be projected into several Gameface surfaces with different models, filtering rules, update signals, and ownership. Extend the exact projection that renders the target UI instead of forcing one fabricated state into every view.
Map projections
Header cards, widgets, tooltips, and result rows may use different model shapes.
Find the model
Native state may appear under window.model, window.subViews, or
a child view.
Notify the host
Changing model entries is not enough when the owning presenter also exposes counts or update events.
Map every native projection
Related UI surfaces often transform the same source data differently.
| Surface | Typical contract | Common trap |
|---|---|---|
| Compact header | Filtered active-shaped entries in native order. | A valid inventory item is hidden because the projection expects future-dated active state. |
| Standalone widget | Collection plus visibility/count properties and an update event. | Appending an item does not update the host’s count or visibility. |
| Tooltip | Aggregated placeholders, depot totals, and expiry groups. | Appending creates duplicate cards instead of filling the native placeholder. |
| Battle result overview | Route-specific rows keyed by account, vehicle, or efficiency identity. | Mutating one tab’s row does not repair another tab with a different key. |
Document each surface separately: owner, model path, identifying key, filter, sort order, update signal, route, and teardown.
Attach to the root that owns the rendered DOM
Injecting a child into a nested presenter can expose data without placing CSS or JavaScript in the DOM tree that actually renders the target cards. Attach at the nearest stable root whose Gameface environment owns the target output.
- Trace the native Python view and its child-view graph.
- Verify where the resource carrier becomes part of the Gameface environment.
- Inspect both existing and newly created subviews.
- Make attachment idempotent and remove only the owned child during teardown.
Read by topic
Choose a focused chapter. Complete examples and reference details are preserved on their topic pages.
- Native model structure and lifecycle
- Model location: model , subViews , and children
- Replace placeholders instead of appending duplicates
- Match by stable identity, then use presentation fallbacks narrowly
- Preserve native ordering
- Preserve native collection ownership
- Update the model and notify the host
- Model readiness is not DOM readiness
- Route-specific repairs
- Presentation layers and pointer behavior
- Listener identity
- Diagnostics
- Verification checklist
- Handwritten models, commands and projections