A View file renders full-model detail UI. It is usually used by detail pages or Zone wrappers that already have full view data from the server.
View components are presentation components. They may compose Unit, Util, Zone, and local subcomponents, but mutation and business decisions should stay outside the View.
View vs Unit
The main distinction is data size and page role. View is for full detail, while Unit is for repeated summary UI.
Comparison
Description
Example
Model.View
Renders the full model. Use it for detail pages and sections that need body content, histories, logs, or full nested data.
Model.Unit
Renders the light model. Use it for list rows, cards, table items, and compact summaries.
Model.View
Renders the full model. Use it for detail pages and sections that need body content, histories, logs, or full nested data.
Model.Unit
Renders the light model. Use it for list rows, cards, table items, and compact summaries.
Standard View Shape
A standard View exports General, accepts className and a full model prop, then uses dictionary labels for field names and statuses.
Ticket.View.tsx
Full Model Detail Patterns
A View can render every field defined on the constant full model because it receives the full model shape, not the light summary shape.
Article.View.tsx
Order.View.tsx
Using View In Pages
A server page usually fetches full view data, then passes the view object to a Zone wrapper or directly into Load.View.
detail page
Load.View And Store Hydration
Load.View safely hydrates server-provided full model data into the client store. It sets the model, loading state, modal state, and view timestamp before rendering your View.
Use this wrapper when rendering server-fetched view data inside client Zones, tab layouts, or reusable sections.
field
Description
Example
<model>
Stores the hydrated full model instance from the server view object.
<model>Loading
Marks the full model as ready so the View can render without showing loading UI.
<model>Modal
Marks the current model state as view mode. Other model wrappers can distinguish view/edit/new flows.
<model>ViewAt
Stores the server view timestamp so Load.View can avoid replacing newer client state with older view data.
<model>
Stores the hydrated full model instance from the server view object.
<model>Loading
Marks the full model as ready so the View can render without showing loading UI.
<model>Modal
Marks the current model state as view mode. Other model wrappers can distinguish view/edit/new flows.
<model>ViewAt
Practical Rules
Accept full model props in View components. Use Unit for light list or card summaries.
Use dictionary labels for field names, statuses, and headings.
Split large Views into named section components instead of one giant General component.
Keep mutations in Util, Store, Signal, or Service. View should mostly render the current full model.
Use Load.View when server-fetched view data must hydrate into client store state.
