Working with Arrays in Browser State

Working with Arrays in Browser State

This tour helps you decide where array-like client-side data belongs in Wappler. Arrays are useful when the browser needs to remember a selection, a temporary working set, or a client-side collection before anything is sent to the server.

Use arrays for active working sets

Arrays are a good fit when the user is building up a list: selected items, temporary rows, filters, favorites, or cart-like state. The key is to decide whether that list belongs in a dedicated Data Store, in temporary session state, or in persistent local storage.

Data Store

Best when the array behaves like a real client-side collection with insert, update, and delete actions.

Session state

Best when the array is temporary and tied to one tab or workflow.

Local state

Best when the array represents preferences or remembered client-side choices.

Use Data Store for structured client-side collections

Use session storage for temporary lists

Use local storage only for non-sensitive remembered data

Keep the data shape intentional

Browser-state arrays are easiest to work with when every item has a predictable shape. If you find yourself storing a loose mix of values, it becomes harder to bind, update, and debug the UI later.

tip: Prefer predictable objects over anonymous mixed values so bindings and actions stay readable.

Define the fields you need early

Prefer stable keys for updates and deletes

Treat client-side collections like real data models

Common array patterns

Most array workflows in Wappler fall into a few repeatable patterns.

Pattern: selected items list

Use an array when users need to build a temporary selection before acting on it, such as choosing products, files, or records. A Data Store is usually the clearest fit when the list needs add/remove/update behavior in the UI.

Use add/remove actions predictably

Keep a stable key for each item

Show the current selection clearly in the UI

Pattern: cart or staged collection

When the array behaves like a client-side cart or staged edit set, treat it as its own collection. That makes it easier to compute totals, bind repeat regions, and eventually hand the final payload off to the server.

Model the collection explicitly

Use computed values from the collection

Send to the server only when the draft is ready

Pattern: decide whether the list should survive

Before you persist an array, ask whether the user expects it to come back later. If yes, local or cookie state may be appropriate. If not, let it stay session-scoped or in a temporary Data Store-backed workflow.

Persist only when users benefit from continuity

Keep sensitive or authoritative data on the server

Clear temporary arrays when the task ends

Wrap-up

Continue into Data Store or the broader state-management branch from here.

Next steps

Choose a related state-management tour to continue.