Skip to main content

State structure

Presentum manages state as a map of slots, where each slot represents one surface in your app.

Visual representation

Imagine three surfaces with different presentations:

State object

Here’s the actual state object:

Slots

Each slot is a container for one surface:

Active item

The active item is what’s currently displayed. Only one item can be active per surface.

Queue

The queue is a FIFO (First In, First Out) list of items waiting their turn. When the active item is dismissed, the first queued item automatically becomes active: Before dismiss:
After dismiss:
This happens automatically via state.clearActive(surface) or presentum.markDismissed(item).

State intentions

Every state change has an intention controlling history management:

Usage in guards

State queries

Access and query state:

Mutable vs Immutable

Presentum uses two state types:
Read-only snapshot exposed to widgets and observers.
Benefits:
  • Predictable - never changes unexpectedly
  • Testable - compare with ==
  • Debuggable - inspect snapshots

State mutations

Inside guards, use these methods:

Serialization

State can be serialized for persistence or debugging:
Result:

History

Presentum tracks all state changes:
Enable time-travel debugging, analytics, or restoration after login.

Next steps

State management guide

Direct state manipulation

Guards

Mutate state in guards