The editor and cuesheet had three overlapping notions of which rundown
they were showing: loaded-only data hooks, a prop-drilled RundownSource,
and a selection store which read the loaded rundown out of the query
cache. Rendering two rundowns at once was not possible.
Introduce a rundown scope: a context carrying the rundown identity
(id, isLoaded and a selection store) which the utility hooks read from.
useRundown, useEntry and friends keep their signatures and call sites,
they simply resolve their rundown from the enclosing scope. The app
mounts a scope at the root which follows the loaded rundown, so runtime
views are unaffected; the editor and cuesheet mount an editable scope
which also binds entry actions to the same rundown.
- useEventSelection becomes a per-scope store factory, so panels hold
independent cursors and the store is handed its rundown instead of
reaching for the loaded one
- the cuesheet selection is generalised to useRundownSelection with a
namespace, so each surface persists its own choice
- the clipboard records the rundown an entry was copied from, leaving
room for pasting across rundowns
- removes useScopedRundown and the prop-drilled RundownSource
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011a5cbVjNC5XXF88b2PkUCa
Claude
Carlos Valente
Alex Christoffer Rasmussen