Summary
Actions.tsx currently mixes notebook mutation concerns, output presentation policy, terminal-console rendering, and legacy renderer registration. The recent getAllRenderersRef bug exposed one concrete failure mode, but it also points to a broader design problem in how terminal-oriented outputs are represented and rendered.
Problems
Actions.updateCellLocal(...) still calls renderer hooks as part of local notebook mutation.
StatefulRunmeTerminal is used as both a rendering hint and a control marker in notebook outputs.
- Terminal rendering decisions are split across multiple signals:
- output MIME markers
- active stream presence
- runner / execution state
Actions.tsx currently owns both output rendering policy and UI implementation details for CellConsole.
- The renderer registry appears to be mostly legacy, but parts of the output path still depend on it indirectly.
Why This Matters
The notebook architecture is model/view:
- mutate
NotebookData
- emit model changes
- let React subscribers re-render from model state
The current output path makes it hard to preserve that boundary cleanly. It also makes it unclear whether terminal presentation should be:
- inferred directly from model + run state
- represented explicitly in notebook state
- or derived from a renderer abstraction
That ambiguity is what led to renderer callbacks participating in mutation semantics.
Refactor Goals
- Remove any renderer callback from notebook mutation paths.
- Clarify the single source of truth for terminal-style rendering.
- Decide whether
StatefulRunmeTerminal remains a real model concept or should be removed.
- Split
Actions.tsx responsibilities so output policy is easier to reason about and test.
- Reduce special-case coupling between notebook outputs, stream state, and
CellConsole.
Candidate Work
- Audit all remaining uses of
StatefulRunmeTerminal.
- Decide whether terminal rendering should be inferred from run metadata / stream state instead of seeded outputs.
- Extract output rendering policy from
Actions.tsx into smaller helpers or components.
- Remove legacy renderer-registration paths if no longer needed.
- Add tests that cover:
- live terminal rendering
- rerender after stream attach/detach
- persisted output replay
- stdout/stderr display rules for terminal vs non-terminal cells
Relationship To The Immediate Bug Fix
The immediate getAllRenderersRef fix should remove renderer callbacks from mutation paths first. That change does not need to block on a larger Actions.tsx refactor, but the refactor should be tracked separately because the current output architecture still carries avoidable complexity.
Summary
Actions.tsxcurrently mixes notebook mutation concerns, output presentation policy, terminal-console rendering, and legacy renderer registration. The recentgetAllRenderersRefbug exposed one concrete failure mode, but it also points to a broader design problem in how terminal-oriented outputs are represented and rendered.Problems
Actions.updateCellLocal(...)still calls renderer hooks as part of local notebook mutation.StatefulRunmeTerminalis used as both a rendering hint and a control marker in notebook outputs.Actions.tsxcurrently owns both output rendering policy and UI implementation details forCellConsole.Why This Matters
The notebook architecture is model/view:
NotebookDataThe current output path makes it hard to preserve that boundary cleanly. It also makes it unclear whether terminal presentation should be:
That ambiguity is what led to renderer callbacks participating in mutation semantics.
Refactor Goals
StatefulRunmeTerminalremains a real model concept or should be removed.Actions.tsxresponsibilities so output policy is easier to reason about and test.CellConsole.Candidate Work
StatefulRunmeTerminal.Actions.tsxinto smaller helpers or components.Relationship To The Immediate Bug Fix
The immediate
getAllRenderersReffix should remove renderer callbacks from mutation paths first. That change does not need to block on a largerActions.tsxrefactor, but the refactor should be tracked separately because the current output architecture still carries avoidable complexity.