Reactive desktop frames

Documentation status: guide — see Maturity and evidence.

A reactive desktop frame is not merely a layout container. It is a local reactive boundary that can host child views, receive context, route events, react to DataSet state, update previews, and coordinate a workflow shell.

Roles

A reactive frame may act as a dynamic host, context boundary, event sink, event router, DataSet-aware coordinator, preview surface, or workflow shell. It receives context such as an input cursor but does not own the business object.

Host pattern

Use a named frame region to load or switch child views while the rest of the page remains stable. The application expresses an intention such as ShowView and carries the target frame/view/context as parameters; the component that emitted the event does not need to know how the frame is rendered.

Parent/child routing

For downward coordination, let the frame notify children with a semantic visual event. For upward coordination, let a child dispatch to the parent PageControler. Avoid direct hard references between child components and parent implementation objects.

DataSet-aware reaction

A DataSet event can update local frame state, status surfaces, visibility, action availability, or child refreshes. This is view-state logic. The business rule should already be represented in the model or in a computed data surface.

Refresh and recompute

A useful advanced pattern is:

child interaction
 -> parent visual event
 -> notify affected children
 -> refresh computed DataSet
 -> update page/frame state

This gives live behavior without rebuilding the whole page.

Event-loop protection

Guard reactive chains: check the sender before refreshing, avoid refreshing the same DataSet in response to itself, distinguish refresh requested/completed, allow children to stop propagation, debounce high-frequency events, and keep application events idempotent when possible.