[docs-infra] Let a headless host edit through its controller alone - #1785
[docs-infra] Let a headless host edit through its controller alone#1785brijeshb42 wants to merge 1 commit into
Conversation
brijeshb42
added
the
scope: docs-infra
Deploy previewBundle sizeTotal Size Change: 🔺+1.25KB(+0.04%) - Total Gzip Change: 🔺+545B(+0.06%) Show details for 73 more bundles@mui/internal-docs-infra/useCode parsed: 🔺+572B(+0.52%) gzip: 🔺+186B(+0.51%) PerformanceTotal duration: 20.53 ms 🔺+3.68 ms(+21.8%) | Renders: 5 (+0) | Paint: 76.43 ms 🔺+15.37 ms(+25.2%)
6 tests within noise — details Metric alarms
Check out the code infra dashboard for more information about this PR. |
A headless host wires editing through `LiveDemoProvider`, which installs a `CodeControllerContext` and nothing else. `useCode` read the reader's edits and its `setCode` from the `CodeHighlighterContext` instead, which only `CodeHighlighter` publishes — so a host that renders the source itself got a controller its edits never reached, and had to hand-assemble a highlighter context to work around it. `useCode` now falls back to the controller for both. The controlled code holds only the variants that were edited, so it is merged over the build-time map rather than replacing it; otherwise the first edit would drop every untouched variant. A highlighter context still wins where one exists, since it does this merging itself.
5ed9f0e to
c19fef3
Compare
dd7ba7f to
52efcfa
Compare
1 participant
Eleventh in the docs-infra migration stack, on top of #1784. It closes the two gaps Material UI hit while adopting the headless API for live editing.
A headless host had no way to receive edits.
LiveDemoProviderinstalls aCodeControllerContextand nothing else, butuseCoderead both the reader's edits and itssetCodefromCodeHighlighterContext, which onlyCodeHighlighterpublishes. A host that renders the source panel itself got a controller its edits never reached, and had to hand-assemble a highlighter context to work around it — using an unexported internal.useCodenow falls back to the controller for both. The controlled code holds only the variants that were edited, so it is merged over the build-time map rather than replacing it; otherwise the first edit would drop every untouched variant. A highlighter context still wins where one exists, since it does this merging itself.A projected edit needed bookkeeping every host would repeat. While a block is collapsed, a headless host's editor holds only the projected slice. Sending that slice as the source produces a file with no imports — it does not run — and, once patched, the projection's offsets are stale for the next edit.
setProjectedSource(slice)does whatCodeEditoralready does for the internal editor: patches the slice back into the complete source with its hidden indentation restored, and moves the projection's end to match. It falls back to replacing the whole file when there is no projection.Both were found by wiring Material UI's experiment fixture to live editing, where the symptoms were
ReferenceError: Stack is not definedon the first preview edit and a second edit splicing at the wrong offset.Gate: 51 browser tests across chromium, firefox, and webkit — 6 new, covering editing with a controller and no highlighter, and two successive projected edits landing correctly — plus a clean typecheck, lint, and
docs:validate. The 41user.spec.tsfailures are the pre-existing ones.