RFC: Split saveStageData into granular save operations

[wyuc]

Background

When a user views a classroom, every small state change (switching scenes, chat updates during playback) triggers saveStageData() which writes the entire stage to storage — all scenes, all chat sessions, all metadata — regardless of what actually changed.

For IndexedDB this is fine (fast local write), but the interface design makes it hard to optimize for any scenario where writes have real cost.

Why now

There have been several community discussions around adding persistent storage options (cloud sync, database backends, etc.). If we're going to support pluggable storage, the current all-or-nothing saveStageData interface will become a bottleneck — every backend would need to handle redundant full-state writes, or build its own diffing layer on top.

Splitting the save interface before those features land means storage backends can be implemented cleanly from the start, rather than retrofitting dedup/diff logic later.

Idea

Split saveStageData into focused operations:

saveStageMetadata(stageId, stage)
saveScenes(stageId, scenes)
saveChatSessions(stageId, chats)
saveCurrentSceneId(stageId, sceneId)

Each store action calls only the relevant save — setScenes() → saveScenes(), setChats() → saveChatSessions(), etc.

The IndexedDB implementation could batch these into a single transaction internally, so no behavior change for self-hosted users.

Trade-offs

Pros:

• Clearer contract — callers express what changed
• Storage backends only write what's dirty
• Easier foundation for sync, collab, undo/redo
• Unblocks pluggable storage without per-backend workarounds

Cons:

• More functions to maintain
• Need to handle atomicity if multiple saves should be transactional
• Migration effort for existing callers

Curious what others think — especially anyone working on persistent storage features.