Web reactive components

Documentation status: guide — see Maturity and evidence.

A web component is the web incarnation of a declared UXfc/functional component. It should preserve the same boundaries as other view implementations: bind to page data surfaces, emit local semantic events, and cross provider/server boundaries only through declared escalation rules.

Contract

Document each reusable component with: functional name; inputs and bound data surfaces; local state; emitted events; escalation rules; loading/error/offline states; and the actions it may request. This contract should remain stable even if the concrete rendering implementation changes.

Data flow

provider / collection
 -> DataSet cache
 -> DataSource or DataCursor
 -> reactive props/view state
 -> component render

The component should subscribe to the page data surface, not directly own the provider protocol or persistence transaction.

Local state versus model state

Selected tab, expanded panel, temporary filter text, pending autocomplete text, dropdown state, local loading state and similar values are local UI state. They must not silently become conceptual attributes or persisted model changes.

Escalation examples

TabSelected normally stays local. CurrentRowChanged normally updates the local view context. FilterTextChanged may be debounced before a lookup. SearchRequested may query a provider. SaveRequested should invoke an application/published action or provider update. ValidationRequested may trigger a business action or process.

Performance discipline

Debounce and batch high-frequency visual interactions. Remote commands should be idempotent where possible. The page model, not the component, decides when an event must cross the Runtime or service boundary.