ETS-backed registry mapping canvas_id -> canvas metadata.

Canvases are independently scoped. A user can have multiple canvases. Each canvas has its own item arrangement, its own PubSub topic, and is completely independent of whatever content an application chooses to render inside it.

This module is responsible for persisting canvas layout only: which items exist, where they are, and the layout codec fields needed to reopen them. What runs inside content-bearing items is tracked elsewhere.

LayoutStore

This module implements LivePanels.Canvas.LayoutStore and is the default persistence backend used by LivePanels.Canvas. Layout data is stored in an ETS table and survives LiveView process restarts, but is lost when the server node restarts.

For durable cross-restart persistence, use LivePanels.Canvas.LayoutStore.Ecto or another durable LivePanels.Canvas.LayoutStore and pass your module via the session: [layout_store: ...] option on use LivePanels.Canvas.

TTL configuration

LivePanels.Canvas.LayoutStore.Registry is a single process-level layout store. use LivePanels.Canvas selects the store module, but it does not configure this registry's TTL on a per-canvas basis.

To change the default 24-hour TTL or the cleanup cadence, start the registry with explicit opts in your supervision tree:

children = [
  {LivePanels.Canvas.LayoutStore.Registry,
   ttl_ms: :timer.hours(1),
   cleanup_interval_ms: :timer.minutes(10)}
]

The package child list uses the bare LivePanels.Canvas.LayoutStore.Registry child by default, which makes custom TTL policy an explicit supervision decision.