Client Variables and State Management

Quick Answer: Client Variables are reactive-specific, per-user, browser-side storage that persist values across screen navigations and page refreshes. They are stored in the browser (similar to localStorage), so they are visible and modifiable by the end user — never store sensitive data in them. Session Variables are server-side per-user storage; Site Properties are server-side configuration shared across all users; Local Variables exist only within a single screen instance.

Client Variables: Reactive-Specific Browser Storage

Client Variables are a state management mechanism unique to Reactive Web Apps — they do not exist in Traditional Web Apps. A Client Variable stores a value on the client side (in the browser) and that value persists across screen navigations and even across browser refreshes within the same browser session. Each user has their own independent copy of every Client Variable; they are never shared between users.

Key properties of Client Variables:

Typical use cases for Client Variables include remembering a user's last-selected filter or sort order, storing UI preferences (collapsed/expanded panels, theme choice), keeping a last-visited screen identifier, or caching a non-sensitive user setting that should persist across navigations without a server round-trip. Because they live in the browser, reading and writing Client Variables is fast — no server request is needed.

When NOT to Use Client Variables

The critical exam trap is security. Because Client Variables are stored in the browser, the end user can inspect and modify them using browser developer tools. Never store passwords, session tokens, API keys, or any sensitive data in a Client Variable. Sensitive state belongs on the server — use Session Variables or server-side logic for anything that must not be tampered with.

Client Variables are also not appropriate for data that must be consistent across devices — if a user switches from laptop to phone, the Client Variable stored in the laptop browser is not available on the phone. For cross-device consistency, use server-side storage.

Session Variables, Site Properties, and Local Variables

OutSystems provides several other state mechanisms, each with a different scope and lifetime:

Session Variables are server-side and per-user. They are appropriate for storing authentication state, user profile data fetched once per login, or other values the server needs to access across multiple screens within a user's session. Because they live on the server, they are not visible to the client and are secure for sensitive data within the session lifetime.

Site Properties are server-side configuration values shared across all users. They have a default value set at design time, and that default can only be changed by republishing the module. However, the runtime value can be overridden in Service Center without republishing — making them useful for environment-specific configuration like API endpoints or feature flags that an administrator can toggle without a code deploy.

Local Variables exist only within a single screen instance in a reactive app. They are initialized in the OnInitialize event and destroyed when the user navigates away from the screen. Use Local Variables for screen-level working state: form input values, toggle states, computed display values, or counters that are only relevant while the user is on that screen.

Choosing the Right State Mechanism

The exam tests your ability to select the correct state mechanism for a given scenario. Use this decision flow:

1. Is the value passed from another screen via Navigate? Use a Screen Input Parameter — it arrives on load and is bound to the navigation.
2. Must the value persist across multiple navigations within the same browser session? Use a Client Variable (if non-sensitive) or a Session Variable (if sensitive or server-needed).
3. Is the value a global configuration shared by all users? Use a Site Property.
4. Is the value only relevant to the current screen? Use a Local Variable, initialized in OnInitialize.

A common exam pattern contrasts Input Parameters with Client Variables: Input Parameters receive values via the Navigate action and arrive when the screen loads; Client Variables persist across multiple navigations and are read independently of any single navigation. If a value must survive the user navigating to a different screen and back, it must be a Client Variable (or Session Variable), not an Input Parameter — Input Parameters only exist for the duration of that screen instance.

State Management in the Reactive Event Model

In reactive apps, state changes trigger automatic UI re-rendering. When a Local Variable bound to a widget changes, the widget updates without a server round-trip. When a Client Variable changes, any widget or logic referencing it also updates. This reactive binding is what makes Client Variables powerful for UI state — changing a filter Client Variable can instantly re-filter a list without a full page reload. Session Variables, by contrast, require a server action to read or write, so changes to them are not instant on the client without an explicit refresh.