Local Manager (persistent settings)

Local Manager

This tour positions Local Manager as client-side persistence for everyday UX settings. You will look at what kinds of data belong here, how Wappler reads and writes those values in bindings and actions, and where the limits and security boundaries are.

When local storage is the right choice

You are not just learning that local storage persists data. You are learning the decision rule: use it for convenience settings and cached UI preferences that should remain on the same browser, but never for secrets or security-sensitive state.

Persistent settings

Theme, layout density, last selected view.

No server dependency

Stays in the browser until cleared.

Bigger than cookies

Typically larger capacity than cookies.

Survives browser restart

Good for preferences

Avoid sensitive data

Objects are supported

Local Manager can store complex objects; they’re serialized/deserialized automatically.

important: Local storage is readable by client-side code. Don’t store secrets or tokens here.

Prefer non-sensitive data

Keep payloads reasonable

Provide a “reset settings” action

Core workflow

Bind UI to local values, and update them on events.

Write local state

Use local.set(key, value) to persist a setting, and local.remove/removeAll to reset.

set(key, value)

Stores a persistent value.

remove(key)

Removes one setting.

removeAll()

Clears all stored settings.

Save user preference

Apply it via bindings

Offer reset button

Read local state in bindings

Use local.key in expressions to set classes, default values, and visibility.

Screenshot: Read local state in bindingsClick to open the larger image

Pattern: app settings form

Bind form controls to local values and save changes with a single submit action.

Controls read local.*

Submit writes local.set(...)

UI updates instantly

Wrap-up

Next, decide whether your state belongs in local/session/cookie or in the URL.

Next steps

Pick a related tour to continue.