Define typed shared client state in a Storage file, choose how each schema persists, mount it in a Component, and verify both default and restored values. Storage can also expose an API loader's request state.
Coverage: UI + MCP. Clearing saved browser values is a runtime/browser effect, not a project definition edit.
Driver: Memory · Lifetime: current runtime only · Typical use: temporary UI/session state that should disappear on reload
Driver: Session · Lifetime: current browser session · Typical use: multi-page state that should end with the session
Driver: Local · Lifetime: retained by the browser · Typical use: user preference or draft state that should survive reopening
Persist only values suitable for the browser. Storage is not a secure secret vault.
Create or open a Storage file below Storage.
Add a named storage schema.
Add typed fields and intentional defaults.
Choose Memory, Session, or Local persistence for the schema.
Check that schema names are unique because generated state keys must be unambiguous.
If the schema loads an API, add the API file in API Loader and configure the request.
Persistence keys combine the Storage file identity and schema name. Moving or renaming the file alone does not change that identity. Schema fingerprints let runtime persistence reconcile changed fields, but incompatible field changes can reset the changed portion.
Open the consumer Component and switch to Logic.
Mount the Storage data source.
Bind schema values to the intended text, inputs, conditions, or behavior.
Add explicit state actions for values the Component is allowed to change.
If using an API loader, handle request, response, loading, and error states.
Preview the default state, update it, and reload or reopen as appropriate for the selected driver.
In the
Websiteproject, inspect<Storage file reference>and<Component reference>. Add or reuse schema<name>with fields<typed fields and defaults>and persistence<Memory|Session|Local>. Mount it in the Component and bind<fields>to<targets>. Preserve every other schema, field, API loader, and Component mount. Verify the stored definition, default state, one update, and the expected reload/session behavior. Do not put credentials or sensitive data in browser storage.
MCP can read Storage, add/rename/delete schemas, set persistence, manage fields, and add/delete API loaders. Component logic mounts the Storage file and addresses the resulting value paths.
Use Forget saved value when old browser-persisted authoring data masks new defaults or makes a test non-repeatable. This clears runtime saved data and reloads declared defaults; it does not edit the Storage file and cannot be restored with design-file undo.
Record which browser/profile and schema you cleared. Do not use this action as a substitute for a migration strategy in a shipped application.
read the schema names, field types, defaults, and persistence modes;
confirm the Component mount resolves to the intended Storage file;
test a value update and the visible binding;
reload or restart only as required by the selected driver;
test schema evolution against representative saved data;
inspect generated state keys and consumer dependencies.
Storage definitions and Component mounts belong to separate project files and histories. Clearing Session or Local saved values changes browser runtime state and is not reversed by file undo. An API loader request can also have external effects depending on its endpoint.
Schema names must stay unique.
API loader references must point to a compatible current API file.
Incompatible schema edits can reset changed persisted fields.
Browser persistence is origin/profile specific and is not a server database.
Sensitive values need a server-side security design, not Local or Session storage.