Add text and outline export without teaching nodes about file formats
Every new export format adds another method to paragraph and section objects. The team needs plain text and a structured outline, and expects document node types to change less often than export formats.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Tree operations · Exhaustive handling · Serialization
Estimated field mix
- Frontend60%
- System design40%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics
- VisitorCompare
Separate growing export operations from relatively stable node types, comparing a Visitor with exhaustive functions and their cost when a new node type arrives.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional support team edits reusable troubleshooting documents with paragraphs, links, and nested sections. The browser prototype has separate toolbar and keyboard handlers, an unreliable undo stack, and mutable shared formatting objects. Create a local editor and synthetic documents; no starter assets, rich-text engine, collaborative backend, or production service is supplied.
Setup prerequisites
- Browser events
- Immutable updates
- Accessible form controls
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Both exporters handle every supported node type and preserve documented section order and paragraph boundaries.
- Keep export operations outside the document data model using a Visitor or exhaustive discriminated-union functions, with a written choice.
- An unknown node type fails with its identity and type instead of silently losing its content.
Implementation constraints
- Treat link labels as text and serialize structured output through a serializer; exporting must not mutate document state or trigger network requests.
Verification to include
- Export a nested fixture containing empty sections and links and compare explicit expected outputs.
- Introduce an unsupported node kind and assert both exporters fail visibly while leaving the input unchanged.
Deliverables
- Two export operations, exhaustive handling tests, and variation tradeoff note
Rollout and recovery
Add exports as local downloads after fixture comparison; disable one format independently if its contract changes.
Value of the work
For the engineer: Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs.
For the team: Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.