Demo data and services

Demo fixtures make the pages immediately useful to explore. They are initial data, not an API, account system, or persistence layer.

Understand the current state boundary

A page can clone fixtures into React state, update its current view, and show feedback. Navigating away or reloading may reset those changes. Related pages sharing one fixture file does not mean edits automatically synchronize between them.

Theme and layout preferences are a separate exception: they use browser local storage. Do not use that preference behavior as evidence that business records are saved.

Start with one feature

Choose a small read-and-edit flow before replacing every fixture. For Projects, begin with projects.data.ts and follow ProjectList.tsx, ProjectOverview.tsx, or ProjectFormPage.tsx according to the page you need.

Keep IDs stable across list links, detail lookup, selection, and updates. Preserve the expected status and date formats until you have deliberately adapted their consumers. Changing an ID in one fixture but not a related route can produce a convincing list with a broken detail page.

Avoid mutating imported fixture arrays as your application store. Put fetched records and mutations under an application-owned state or query layer that fits your product.

Define your service boundary

Totems does not prescribe a generated API client. In your application, define how each page loads records, submits changes, and receives the authoritative result.

A practical sequence is:

1. Map a service response to the page's expected data shape
2. Add loading, empty, and error states to the page
3. Replace a local mutation with an authenticated service request
4. Update or refetch the displayed record after success
5. Handle failure and stale responses without silently discarding user work

For a table backed by a server, move filtering, sorting, and pagination together when the API owns them. Do not present a page of server results as though client filtering searches the entire dataset.

Add production responsibilities

The application must authenticate users and authorize each read or write on the server. Hidden navigation and disabled buttons help the interface; they do not secure an endpoint.

Keep secrets out of the frontend bundle. Browser-delivered configuration is visible to visitors. Add server validation for forms, uploads, and rich text, and choose a deliberate policy for logging sensitive data.

Uploads need durable storage and access checks. Chat needs actual delivery and conversation permissions. Calendar needs an explicit date/time and synchronization policy if it connects to another service.

Verify what users will experience

Test slow requests, rejected changes, empty results, missing records, and reload after a successful save. Open the same record through a direct link and confirm it loads independently of prior navigation.

Keep demo-only success copy honest until the corresponding service exists. See Adapt an app example for the specific boundaries of four useful examples.