State Lifecycle

The table can receive state from several places. It may have product defaults, saved views, persisted user state, and URL parameters all available at the same time.

The lifecycle exists so those sources produce one opening state, not a series of visible jumps.

The Startup Problem

On first load, these sources may all have an opinion:

• built-in defaults
• initialState
• workspace default view
• user default view
• persisted current state
• URL state from a shared link

If they apply one by one as they load, the table can briefly show the wrong filters, the wrong active view, or the wrong first server query.

The Startup Flow

The table uses a simple sequence:

load candidate state
        ↓
merge one initial state
        ↓
render the ready table
        ↓
start ongoing sync

The important part is that ongoing sync starts after the opening state is resolved. Persistence and URL sync should not write temporary mount state back into storage.

Priority

When multiple sources exist, later sources win:

defaults
  -> initialState
  -> workspace default view
  -> user default view
  -> persisted current state
  -> URL state

This priority keeps each source in its expected role.

Workspace defaults provide a team baseline. User defaults personalize that baseline. Persisted state restores where someone left off. URL state wins because opening a shared link is an explicit action.

Why Persisted State Beats Defaults

Defaults are starting points. Persisted state is recent work.

If a user already has remembered state for a table, reopening that table should continue from their last working setup instead of resetting to a default view.

Defaults matter most the first time someone opens a table, or after remembered state is cleared.

Why URL State Wins

A copied link should be predictable.

If a link says "show customers filtered by Enterprise and sorted by renewal date", the recipient should see that view even if they have their own stored table preferences.

That is why URL state is applied last during startup.

Online Data Depends on This

For online tables, opening state is also the first query.

The table should resolve state first, then ask the backend for rows. Otherwise the user can see a loading flash for a query that was never the intended view.

Use This Rule

Think of startup state as a coordinated handoff:

• collect all state sources
• choose one initial state
• render from that state
• then allow persistence, URL sync, and view dirty-state behavior to continue

Next Steps

• Learn how memory is divided in Persistence and Sharing.
• Add private state memory in Add current-view persistence.
• Add shareable links in Add URL sync.