Measure whether sharing text styles is worth the indirection
A generated 20,000-paragraph fixture repeats twelve formatting combinations. A proposed style pool reduces duplicate objects, but its mutable shared entries can change many paragraphs when one is edited.
- Focused work estimate
- 3h 30m + prerequisites
- Priority in the scenario
- Low
- Engineering practice
- Memory profiling · Immutability · Performance experiments
Estimated field mix
- Performance engineering60%
- Frontend40%
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
- FlyweightCompare
Measure immutable sharing of repeated formatting against plain values, while excluding mutable per-paragraph state from the shared objects.
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
- Compare plain immutable style values with Flyweight style identities using the same declared fixture and measurement procedure.
- If pooling is retained, intrinsic styles are immutable and per-paragraph selection or editing state stays outside the pool.
- Report memory observations and edit/undo latency across five runs, including environment and variance; retain the simpler representation if benefits are inconclusive.
Implementation constraints
- Measure the model separately from DOM rendering and keep the fixture size fixed; do not claim production performance from one browser snapshot.
Verification to include
- Change one paragraph's style and undo it without changing any other paragraph.
- Attempt to mutate an interned style and verify prevention; repeat opening and closing documents to check that unused pools are released.
Deliverables
- Reproducible comparison, isolation tests, and keep-or-remove decision
Rollout and recovery
Keep style pooling behind a local representation switch until correctness and measurements support it; preserve a conversion back to plain values.
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.