Design an embeddable code editor

Requirements: what the host apps need from an editor

A code editor component is the box where you type code: colored text, line numbers, a blinking cursor, and keys like Tab and Ctrl+Z that behave the way programmers expect. It looks like a textarea with colors. It is not. A plain textarea cannot color parts of its text, cannot show a squiggly line under one word, and slows to a crawl when you paste in a 5 MB file.

This is a component question. The host app decides what the code is for: the codepen guide runs it in a sandboxed preview, the online-judge guide sends it to a test runner, and the code-review-diff guide shows two versions side by side. Those guides treat the editor as a part with a clear interface and pick a library.

This guide opens that part up. We design the internals the way the authors of the three libraries behind almost every web editor did: CodeMirror 6 (a modular 2022 rewrite by Marijn Haverbeke), Monaco (the editor of VS Code, packaged for the browser), and Ace (the older editor behind Cloud9). Each made a different bet on the hard parts, so we use them as worked examples and explain why they are built the way they are.

Questions that change the design

• Who edits, and on what? Desktop keyboards only, or phones too? Phone keyboards insert text through autocorrect and prediction, which breaks editors that listen only to key events. Assume desktop first, but phones must work for small edits.
• Which languages and scripts? Code is mostly ASCII, but comments and strings hold Chinese, Japanese, Arabic, and emoji. Typing Chinese needs an IME (input method editor: the small popup that turns keystrokes into characters). Assume full IME support; it is the bug users report most.
• How large can a file get? A LeetCode answer is 50 lines. A pull request may touch a 20,000 line generated file. A minified bundle is 2 MB on a single line. Assume smooth editing up to 100,000 lines and 10 MB, with features turned off above that.
• How smart must it be? Coloring only, or autocomplete, errors as you type, and go to definition? Smart features need a language engine, which may run in a worker or on a server. Assume coloring and bracket matching built in, smart features as optional extensions.
• One editor, or many on a page? A review page can show 30 small read-only editors. That makes startup cost and memory per instance matter more than peak features.
• Collaboration? Live multi-user editing is a layer on top. We only need a document model that can accept remote changes and map cursors through them.

Functional requirements

• Edit text with the keyboard, mouse, touch, paste, drag and drop, and any IME, with undo and redo.
• Multiple cursors and selections, rectangular selection, and the usual code keys: auto indent, bracket closing, comment toggle, move line up and down.
• Syntax highlighting that stays correct while you type, for 10 to 50 languages loaded on demand.
• A gutter with line numbers, fold markers, and lint markers; inline decorations such as squiggly underlines and widgets.
• Search and replace, including regular expressions, over the whole document.
• An extension system so each host app can add keymaps, languages, themes, and panels without forking the core.
• An embedding API: read and set the value, listen to changes, switch language, toggle read only.

Non-functional requirements, with numbers

Out of scope, and why

• Running the code and the preview iframe. The codepen and online-judge guides cover sandboxing and test runs.
• Rich text and prose. Bold, headings, and embedded images belong to the rich-text-editor guide, which uses a tree document model; the markdown-editor guide covers writing prose with a live preview. Code is plain text plus decorations.
• Collaboration algorithms, OT and CRDTs (the two families of merge algorithms for live editing). The google-docs guide and the crdts and collaboration-basics lessons cover them; we only keep the hooks they need.
• Terminal rendering. A terminal is a grid of cells fed by a byte stream; the web-terminal guide covers it.

What makes a code editor hard

Five properties of the problem drive every later decision. Name them early in an interview; each one maps to a chapter.

1. The browser wants to own text input, and we can't let it own the document. Only the browser knows how an IME, a phone keyboard, autocorrect, or dictation produce text. But if we let the browser edit our DOM freely, it inserts stray span and br elements and our model drifts away from what is on screen. We need a narrow channel: let the browser produce text, then take it back.
2. Documents are big and edits are tiny. A keystroke changes one character in a document that may hold 10 million. Any design that copies, re-splits, or re-renders the whole document per keystroke fails at size. Every structure must make an edit cost depend on the size of the edit, not of the file.
3. Positions move. A lint error at offset 5,000, a collaborator's cursor, a fold, a search match: all point into the text. When you type at offset 100, every one of them after 100 shifts. The editor needs one shared way to map any position through any change.
4. Highlighting needs the whole file but must not cost the whole file. Whether line 9,000 is inside a string depends on every quote before it. Yet a keystroke must repaint in one frame. That forces incremental parsing with a time budget.
5. Text must stay real for assistive tech. A canvas or a pile of absolutely placed spans looks fine but reads as nothing to a screen reader. Whatever trick we use to draw only 40 lines, the text under the cursor must be readable and announced.

A sixth, softer property: the editor is a platform. Each host wants its own keymap, languages, and panels, so the core must stay small and everything else must plug in.

The figure is the spine of this guide: input surface (chapter 3), immutable document and transactions (chapter 4), selection (chapter 5), the windowed view (chapter 6), highlighting that catches up after the paint (chapter 7), and extensions at every step (chapter 8).

The input surface: letting the browser type without letting it edit

The naive plan: put tabindex on a div, listen to keydown, and insert event.key. It works for an English keyboard. Then three bug reports arrive.

A Japanese user types "nihon" and gets the letters n, i, h, o, n instead of 日本, because the IME only works in editable elements. An Android user sees nothing at all, because phone keyboards often report every key as Unidentified with keyCode 229. A user pastes from Slack and nothing happens, because there is no paste target. The lesson: text input is an operating system service, and only real editable elements get it.

So the editor needs a real editable element somewhere. The design question is which one, and how much of the browser's editing we let through.

The events, in the order they arrive

Modern browsers fire beforeinput before they change the DOM, with an inputType that names the intent: insertText, deleteContentBackward, insertFromPaste, insertParagraph, historyUndo, and about 40 more. Most are cancelable, so the editor can call preventDefault() and apply the change to its own model instead. The big exception is text produced during IME composition: insertCompositionText cannot be canceled. The browser must draw it, and the editor reads it back afterwards.

Composition is the IME's in-progress state. It starts with compositionstart, sends compositionupdate each time the candidate text changes ("に", then "にほ", then "日本" after the user presses Space), and finishes with compositionend carrying the committed text.

Each update also fires beforeinput and input with the inputType insertCompositionText. Meanwhile keydown events still fire, with isComposing true and keyCode 229. Desktop Safari can even deliver the Enter that confirms a candidate just after compositionend, which is why guards check for 229 as well.

content.addEventListener("keydown", (event) => {
  // Keys pressed while an IME is open belong to the IME.
  if (event.isComposing || event.keyCode === 229) return;
  const command = keymap.lookup(event); // Mod-z, Tab, Enter...
  if (command && command(view)) event.preventDefault();
});

content.addEventListener("beforeinput", (event) => {
  if (event.inputType === "insertCompositionText") return; // browser draws it
  const change = changeFromInputEvent(event, view.state);
  if (!change) return; // unknown intent: let the DOM observer read it back
  event.preventDefault();
  view.dispatch({ changes: change, userEvent: "input.type" });
});

content.addEventListener("compositionend", () => {
  observer.flush(); // read the committed text from the DOM as one change
});

Phones, autocorrect, and the clipboard

• Phone keyboards often send keyCode 229 with key set to Unidentified for every key, compose even English words, and replace whole words on autocorrect. Chrome on Android may also ignore preventDefault() on beforeinput and report Enter or Backspace only as DOM changes. So the DOM observer, which diffs the changed DOM range against the model, is the path that must always work; beforeinput is a fast path on top of it.
• Autocorrect and spellcheck turn function into Function and paint red lines under every variable. Set spellcheck="false", autocorrect="off", and autocapitalize="off" on the content element. CodeMirror 6 sets these by default.
• Copy handles the copy event and writes text/plain to clipboardData, joining multiple selections with line breaks. With an empty selection, VS Code copies the whole line, a habit users expect.
• Paste reads text/plain only (never HTML, which brings fonts and colors), normalizes \r\n to \n, and, when the pasted text has exactly as many lines as there are cursors, puts one line at each cursor.

Document and state: immutable values, one path for every change

The naive model is one JavaScript string. Insert a character with doc.slice(0, pos) + ch + doc.slice(pos). For a 50 line answer this is perfect.

For a 10 MB file it builds a new 10 MB string per keystroke (engines can delay the copy, but the first read forces it), and finding line 80,000 means scanning for 79,999 line breaks. Both costs grow with the file, and the editor asks "where does line N start?" many times per frame for rendering, gutters, and cursor movement.

The next idea is an array of lines (string[]): line lookup is instant, and typing inside a line replaces one short string. VS Code used exactly this until 2018. Its team then wrote up why it failed: a user's 35 MB file had 13.7 million lines, each line object cost about 40 to 60 bytes, and the array alone used about 600 MB, roughly 20 times the file. Splitting a big file into millions of strings also made opening slow, and inserting a line in the middle shifts every later entry.

Positions and changes

A position is one number: the offset from the start of the document, counted in UTF-16 code units (the unit JavaScript strings use), with each line break counting as 1. CodeMirror 6 works this way and converts to line and column only for display. Monaco's API uses 1-based line and column pairs instead, with getOffsetAt and getPositionAt to convert. One number is easier to compare, sort, and store in a decoration.

An edit is not a new string. It is a change set: a value that says "keep 4 characters, insert alpha, keep the rest". Because the change is data, any part of the system can answer the question from chapter 2: where does my position go? This is position mapping, and it moves a lint marker at offset 15 to 20 when 5 characters are inserted before it.

A position exactly at the insertion point is ambiguous, so mapping takes a side: assoc = -1 stays before the new text, assoc = 1 moves after it. A marker at the start of a word should use 1, so it stays with the word when someone types in front of it. A marker at the end of a word should use -1, so text typed right after the word stays outside it.

import { ChangeSet, Text } from "@codemirror/state";

const doc = Text.of(["let a = 1;", "let b = 2;"]); // length 21
const change = ChangeSet.of({ from: 4, insert: "alpha" }, doc.length);

change.apply(doc).line(1).text; // "let alphaa = 1;"
change.mapPos(15);     // 20: the "b" on line 2 shifted by 5
change.mapPos(4, -1);  // 4: stays before the inserted text
change.mapPos(4, 1);   // 9: moves after the inserted text
doc.lineAt(15).number; // 2, found in O(log n)

State, transactions, and the view: one path for every change

The document is one part of the editor's state. The rest is the selection, folds, lint markers, and the data of every extension. The naive editor keeps all of it in one mutable object. Typing calls doc.insert(), which fires change listeners one by one.

The bracket matcher runs first and redraws. Then autocomplete runs and reads the selection, which has not moved yet because the selection listener comes later, so the popup opens at the wrong position. Undo is worse: it must know how to reverse each feature's side effects. Every bug comes from one root: features see the editor half updated.

One update cycle, step by step

1. The input layer turns a DOM event into a transaction spec: { changes, selection, userEvent }.
2. Filters run. A read-only facet or a change filter can drop or shrink the change, for example to protect a problem's starter code in the online judge.
3. Every state field computes its next value from the old value and the transaction: history records the inverse change, lint maps its markers, folds map their ranges.
4. The view gets a view update: the old state, the new state, the changes, and flags such as docChanged, selectionSet, and viewportChanged.
5. The view redraws only the lines whose content or decorations changed. It batches DOM reads (measuring line heights, cursor coordinates) and DOM writes into separate phases so the browser lays out once per frame, not once per read.
6. Update listeners, including the host's onChange, run last and see a consistent new state.

import { StateField } from "@codemirror/state";

const todoCount = StateField.define<number>({
  create: (state) => countTodos(state.doc.toString()),
  update(count, tr) {
    if (!tr.docChanged) return count; // most transactions: no work
    let delta = 0;
    tr.changes.iterChanges((fromA, toA, _fromB, _toB, inserted) => {
      delta -= countTodos(tr.startState.sliceDoc(fromA, toA));
      delta += countTodos(inserted.toString());
    });
    return count + delta; // a sketch: ignores TODOs split by the edit
  },
});

Undo: grouping keystrokes into steps

If each keystroke were its own undo step, undoing a typed word would take 8 presses. If everything were one step, one undo would erase a minute of work. Editors group by three signals. CodeMirror 6's history extension is a good model, and its defaults are worth quoting:

• Time. A change joins the previous group only if it comes within newGroupDelay, 500 ms by default. A pause starts a new step.
• Place. It must touch the range the previous group changed. Typing on line 3 and then on line 40 within 500 ms is still two steps.
• Kind. Typing and deleting (input.type, delete) can join the group before them. A paste (input.paste) never does, so it always starts a new step, and moving the cursor ends the group. IME composition updates always join, even after a pause, so a composed word is one step.
• Depth. At least 100 steps are kept (minDepth). Each step stores the inverse change set and the selection before it, not a copy of the document.

Collaboration adds one rule. When a remote change arrives, it is marked addToHistory: false, and the history maps its stored inverse changes through it. Undo then reverts only your own edits, at their new positions. The undo-redo guide covers command stacks in general; here it is enough that inverse changes are values that can be mapped like any position.

Cursors and selections: more than one blinking line

The naive plan is to trust the browser's selection: read window.getSelection() whenever you need the cursor. It breaks in three ways: most browsers show only one selection range, but programmers expect 5 cursors after Ctrl+D. The DOM selection points into nodes that the editor deletes on every redraw. And with only 40 lines in the DOM (next chapter), a selection that starts on line 10 and ends on line 9,000 has no DOM node to point at.

So the selection is part of the state, like the document. It is a list of ranges, each with an anchor (where the selection started) and a head (where the cursor is now, the end that moves with Shift+arrow). An empty range, where anchor equals head, is a plain cursor, and one range is the main one. After every transaction the ranges are sorted and overlapping ones are merged, so two cursors that meet become one.

The main range is copied into the real DOM selection so that the IME, the screen reader, and the phone's selection handles all see it. The other ranges are drawn by the editor as absolutely placed div elements in a layer behind the text. Every command runs once per range: CodeMirror's changeByRange takes a function that returns a change and a new range for each one, and maps later ranges through earlier changes.

The goal column

Put the cursor at column 30 of a long line and press Down. The next line has only 5 characters, so the cursor lands at its end. Press Down again onto another long line, and users expect column 30 again, not column 5.

The editor remembers a goal column on the range when vertical movement starts, uses it for every Up and Down, and drops it on any horizontal move or edit. CodeMirror 6 stores it as a horizontal pixel offset rather than a character count, which keeps it right for tabs, wide characters, and proportional fonts.

What is one character?

• Code units versus graphemes. The thumbs up emoji with a skin tone is 4 UTF-16 code units but one visible character, a grapheme cluster. So is a flag, and so is e followed by a combining accent. Arrow keys must step over the whole cluster or the cursor lands inside an emoji and the next keystroke corrupts it. Use Intl.Segmenter with granularity: "grapheme", or a built-in helper such as CodeMirror's findClusterBreak.
• Tabs. A tab is one character but jumps to the next multiple of the tab size. Column numbers in the status bar and the goal column must count visual columns, not characters (code below).
• Wide characters. Chinese and Japanese characters are roughly twice as wide as Latin letters in most monospace fonts, but not exactly, and emoji widths vary by font. An editor that computes x as column * charWidth puts the cursor in the wrong place on those lines. Measure from the DOM (Range.getClientRects()) for any line that is not plain ASCII.
• Bidirectional text. A string literal in Arabic or Hebrew runs right to left inside a left to right line. Pressing Right should move the cursor one step to the right on screen, which is a different character order from the stored one. The editor runs the Unicode Bidirectional Algorithm per line to find the runs and moves visually; a selection across a direction change can look like two separate highlights. The rtl-layouts lesson explains the algorithm.

function visualColumn(line: string, offset: number, tabSize = 4): number {
  let column = 0;
  for (let i = 0; i < offset; i++) {
    column = line[i] === "\t"
      ? column + tabSize - (column % tabSize) // jump to next tab stop
      : column + 1;
  }
  return column;
}

visualColumn("\tif (x)", 1);    // 4
visualColumn("ab\tc", 3);       // 4: the tab only filled 2 columns

Rendering only the visible lines

The naive view renders one div per line. A 100,000 line file then has well over half a million nodes counting highlight spans: seconds of layout and hundreds of MB. The virtualization lesson and the virtualized-list guide explain windowing in general. An editor adds three twists: line heights are unknown when lines wrap, the cursor and selection can sit in lines that are not rendered, and a single line can be 2 MB long.

The viewport and the height map

The viewport is the range of the document that gets DOM elements: the visible lines plus a margin, so a quick scroll doesn't show blank space before the next frame. CodeMirror 6 uses a margin of 1,000 pixels above and below. To know which lines fall in a pixel range without rendering them, the editor keeps a height map: a balanced tree over the lines where each node stores the total height of its lines. Finding the line at y = 1,200,000 px is a walk down the tree, O(log n).

Heights start as estimates. Without wrapping, every line is one line height. With wrapping, the estimate is the line length divided by the characters that fit in the width, rounded up, times the line height. When lines enter the viewport, the editor measures their real height and replaces the estimate.

If lines above the visible area turn out taller than estimated, the content below would jump. The editor prevents that with scroll anchoring: it notes the top visible line and its offset before the update, and adjusts scrollTop after measuring so that line stays put.

Measuring text: grid or real

To place the cursor and to turn a mouse click into a position, the editor converts between offsets and pixels. A monospace grid assumes every character is charWidth wide, so x is column * charWidth. It is fast and right for ASCII code, but wrong for Chinese, emoji, proportional fallback fonts, and bidi text.

Real measurement asks the browser: create a DOM Range over the character and call getClientRects(), or use document.caretPositionFromPoint (or the older, non-standard caretRangeFromPoint where it is missing) for clicks. A good editor uses the grid as a fast path on plain lines and measures the rest, caching results per line until the line changes.

Very long lines and very tall documents

• A minified 2 MB line would be one element with millions of characters and spans. CodeMirror 6, when wrapping is off and a line is longer than a few thousand characters, renders only the part near the visible columns and stands in for the rest with empty gaps of the estimated width. Monaco stops rendering a line after 10,000 characters by default (stopRenderingLineAfter).
• Browsers cap element height: a tall enough scroll area hits a limit in the tens of millions of pixels, lower in some browsers. One million lines at 20 px is 20 million pixels. CodeMirror 6 caps the real DOM height at 7 million pixels and scales positions inside it.
• Cursor in an unrendered line. A selection can end on line 9,000 while lines 1 to 60 are rendered. The real selection lives in the state, so commands such as Shift+Down read the state, never the DOM.

Syntax highlighting that keeps up with typing

The naive highlighter reruns its regular expressions over the whole document per keystroke and rebuilds every span. Cheap at 300 lines; hundreds of ms at 50,000, and typing stutters. Worse, regexes per line can't know that line 9,000 sits inside a comment that opened on line 8,990. Highlighting needs context from far above, but each keystroke can only afford a few milliseconds.

Parsing on a budget

Even an incremental parser cannot finish a 10 MB file in one frame. So parsing is split into time-boxed work. CodeMirror 6's language package is a good concrete model:

• When a transaction changes the document, the parser gets up to 20 ms of work right away, aimed at reaching the end of the viewport. The new tree is ready for the very paint that shows the keystroke.
• If it runs out of time, the view paints with the tree it has. Text past the parsed point is shown plain for a moment.
• The rest happens in the background: requestIdleCallback slices of 25 to 100 ms, with pauses between them, and a cap of 3 seconds of background work per 30 seconds so a huge file doesn't drain a laptop battery.
• It parses ahead of the viewport only by about 100,000 characters. The tail of a 10 MB file is parsed when you scroll there, or when a feature asks for it with a timeout (ensureSyntaxTree).

Why not a Web Worker? Tokens would come back a frame or more after the keystroke, so fresh text would flash uncolored. Time-boxed parsing on the main thread avoids that; workers suit slow, project-wide work such as type checking and linting (chapter 8). VS Code made the other trade: since late 2024 its TextMate tokenization runs in a worker by default (editor.experimental.asyncTokenization), accepting a short delay so a slow grammar never blocks input.

From tree to colored spans

import { syntaxTree } from "@codemirror/language";
import { Decoration, type EditorView } from "@codemirror/view";
import { RangeSetBuilder } from "@codemirror/state";

function highlightVisible(view: EditorView) {
  const out = new RangeSetBuilder<Decoration>();
  const tree = syntaxTree(view.state); // whatever is parsed so far
  for (const { from, to } of view.visibleRanges) {
    tree.iterate({
      from, to,
      enter: (node) => {
        const cls = classForNode(node.name); // "String" -> "tok-string"
        // Clip to the visible range so ranges reach the builder in order.
        const start = Math.max(node.from, from), end = Math.min(node.to, to);
        if (cls && start < end) out.add(start, end, Decoration.mark({ class: cls }));
      },
    });
  }
  return out.finish();
}

Two details matter. First, node types map to abstract highlight tags (string, keyword, comment), and a theme maps tags to classes. Grammars never mention colors, so one theme works for every language. Second, the result is only for the visible ranges: highlighting 50 lines costs the same in a 50 line file as in a 50,000 line one.

Extensions, architecture, and the embedding API

The naive editor grows an options object: lineNumbers: true, lint: true, vimMode: true, until there are 80 flags and each new feature is a pull request to the core. The online judge then wants read-only starter code, the review tool wants comment widgets between lines, and the playground wants a color swatch next to every CSS color. None of these fit a flag. The editor needs a way for outside code to add state, drawing, keys, and behavior, with clear rules for who wins when two extensions disagree.

Four kinds of decoration

Decorations are stored in a range set: a sorted, chunked structure of ranges that maps through a change set in one pass. When you type above 300 lint markers, they all shift without 300 updates. Gutters follow the same rule: line numbers, fold arrows, and lint icons are markers per line, computed only for the lines in the viewport.

import { Compartment } from "@codemirror/state";

const language = new Compartment();
const view = new EditorView({
  extensions: [basicSetup, language.of([])], // no grammar yet
  parent: host,
});

async function setLanguage(name: "python" | "javascript") {
  const ext = name === "python"
    ? (await import("@codemirror/lang-python")).python()
    : (await import("@codemirror/lang-javascript")).javascript();
  view.dispatch({ effects: language.reconfigure(ext) });
}

Autocomplete, hover, diagnostics, and where they run

Smart features need a language engine that understands the code: the TypeScript compiler, Pyright for Python, clangd for C++. These are big and slow, so they never run inside the keystroke path. There are three homes for them:

• In process, for small things. Completing words from the document, or keywords of a language, is fast enough on the main thread.
• A Web Worker. Monaco runs the TypeScript language service in a worker and talks to it by messages. The worker holds a copy of the document, updated with each change, so only the changes cross the boundary.
• A language server over a WebSocket. The Language Server Protocol (LSP) is JSON-RPC: the editor sends textDocument/didChange, asks textDocument/completion, and receives textDocument/publishDiagnostics. Any of the hundreds of existing servers works, running next to the user's code in a container. LSP positions are line and character, counted in UTF-16 units by default, which happens to match JavaScript strings.

The figure's failure path is the important part: replies can come back for an older document. Every request carries the document version, and the editor checks it when a reply arrives. If the user kept typing, it either maps the reply's positions through the changes since then (fine for diagnostics) or drops it and asks again (better for completions, which depend on the word being typed).

Requests that are no longer needed are canceled ($/cancelRequest in LSP) so a slow server doesn't build a queue. Lint runs after a pause: CodeMirror's lint extension waits 750 ms after the last change by default, the same idea as the debounce-throttle lesson.

The architecture, part by part

With the hard parts and the extension model decided, the pieces fall into clear boxes. Each boundary is drawn where the rate of change or the cost differs: input changes per keystroke, the view per frame, the parser on a time budget, the language engine on its own thread.

The component's interface

type CodeEditorProps = {
  defaultValue?: string;     // read once at mount
  value?: string;            // controlled: synced by a minimal diff
  onChange?: (update: { getValue: () => string; changes: ChangeSet }) => void;
  language?: "javascript" | "typescript" | "python" | "css" | "html";
  readOnly?: boolean;
  extensions?: Extension[];  // host additions, compared by identity
  theme?: "light" | "dark" | "high-contrast";
  ariaLabel: string;         // required: what the editor is for
  onReady?: (api: EditorApi) => void;
};

type EditorApi = {
  focus(): void;
  getValue(): string;        // builds the string only when asked
  setSelection(from: number, to?: number): void;
  revealLine(line: number): void;
};

Three choices in that interface are deliberate. onChange passes a getter, not the string: building a 10 MB string on every keystroke costs milliseconds and garbage, while most hosts only need it on save. ariaLabel is required, because an unlabeled editor is announced as just "edit text". Uncontrolled is the default, because the editor already owns its state; the host reads it when it needs it.

Wrapper pitfalls in React

• Re-creating the editor on every render. An effect that depends on an inline extensions array sees a new array each render, destroys the view, and builds a new one: undo history, cursor, scroll, and focus are lost, and each rebuild costs tens of ms. Create the view once, and push prop changes in with compartment reconfigure effects.
• The controlled value loop. onChange calls setCode, React re-renders, the wrapper sees a new value and calls setValue, which replaces the whole document. The cursor jumps to 0, undo history resets, and an IME composition in progress is destroyed. The fix: when the incoming value equals the text the editor already holds, do nothing. When it really differs (the host formatted the code), dispatch only the changed middle part, found by comparing common prefix and suffix, so the cursor maps through it.
• Double mounting in development. React's Strict Mode runs effects twice. Without view.destroy() in the cleanup, you get two editors stacked in one box.
• Server rendering. The editor needs the DOM. Render the code as a pre with the same font and line height on the server, then swap in the editor after a dynamic import. The page shows the code at once and nothing shifts when the editor arrives.

const External = Annotation.define<boolean>(); // marks changes that came from props

function CodeEditor({ value, onChange, ariaLabel }: CodeEditorProps) {
  const host = useRef<HTMLDivElement>(null);
  const view = useRef<EditorView | null>(null);
  const synced = useRef(value); // last value known to match the document
  const onChangeRef = useLatest(onChange); // avoids re-creating on new callbacks

  useEffect(() => {
    view.current = new EditorView({
      parent: host.current!,
      doc: value ?? "",
      extensions: [
        basicSetup,
        EditorView.contentAttributes.of({ "aria-label": ariaLabel }),
        EditorView.updateListener.of((u) => {
          if (!u.docChanged || u.transactions.some((t) => t.annotation(External))) return;
          synced.current = undefined; // the text changed inside the editor
          onChangeRef.current?.({ getValue: () => u.state.doc.toString(), changes: u.changes });
        }),
      ],
    });
    return () => view.current?.destroy();
  }, []); // eslint-disable-line react-hooks/exhaustive-deps

  useEffect(() => {
    const v = view.current;
    if (!v || value === undefined || value === synced.current) return;
    if (value !== v.state.doc.toString()) {
      v.dispatch({ changes: minimalDiff(v.state.doc, value), annotations: External.of(true) });
    }
    synced.current = value;
  }, [value]);

  return <div ref={host} />;
}

Large files, search, and bundle size

Large files: decide the limits up front

Everything so far keeps the cost of a keystroke independent of file size. But some features are inherently whole-file: folding ranges for every function, bracket pair colors, a minimap, word-based completion that indexes every identifier. On a 50 MB log they freeze the tab, and the answer is not cleverness but thresholds decided in the design. VS Code does exactly this: above 20 MB or 300,000 lines it switches to a large file mode and turns off tokenization and other heavy features, unless the user turns editor.largeFileOptimizations off.

Minified one-line files need their own rule, since line count says nothing about them: measure the longest line on load. Above a few thousand characters, render the line in windowed slices (chapter 6), cap tokenization per line (VS Code and Monaco skip lines over 20,000 characters by default, set by editor.maxTokenizationLineLength), and offer a "format document" button that pretty-prints it into a normal file.

Search and replace

• Never build the whole string. A search cursor iterates over the document tree's chunks, so a search in a 10 MB document allocates almost nothing. Plain text search can match across chunk borders by keeping a small tail buffer. Regular expressions run line by line, with a separate, slower cursor for patterns that span lines.
• Highlight what is visible, count the rest lazily. Matches in the viewport become mark decorations at once. The total count ("3 of 1,284") comes from a background pass in idle slices and can show "1,000+" until it finishes.
• Guard against runaway regexes. A pattern like (a+)+b on a 1 MB minified line can backtrack for seconds. Search in slices with a time check between lines, and offer to stop.
• Replace all is one transaction. Thousands of replacements become one change set, one undo step, and one redraw. Mapping the selection through it keeps the cursor where the user left it.
• Debounce the search box by about 100 to 200 ms on big files (see the debounce-throttle lesson).

Bundle size and loading

The editor must not slow the host page. We measured the published CodeMirror 6 packages that a basic setup with JavaScript pulls in, each minified and gzipped without tree shaking. @codemirror/view 6.43 alone is about 63 KB. The whole set (state, view, commands, language, autocomplete, search, lint, the Lezer runtime, and the JavaScript grammar) is about 185 KB, inside our 200 KB target.

Monaco is a different scale. In version 0.52 its main editor file is about 3.8 MB minified and 950 KB gzipped, and each language service runs in a separately loaded worker; the TypeScript worker alone adds about 1.3 MB gzipped. Your bundler and the languages you include move all of these numbers, so measure your own build.

• Don't put the editor on the critical path. Render a pre with the code first (a fast Largest Contentful Paint, no layout shift), then import() the editor after first paint or when the user focuses the box.
• One chunk per language. Load the Python grammar only when a Python file opens, through the compartment swap from chapter 8. The code-splitting lesson covers chunking strategy.
• Read-only views stay light. The review page's 30 small editors need highlighting and line numbers, not autocomplete, lint, or history. A read-only preset can skip those extensions.
• Preload on intent. Hovering the "Edit" button for 100 ms can start the download so the editor is ready on click.

Accessibility and theming

A code editor fails accessibility in quiet ways, and each has a concrete fix. A screen reader announces "blank" on every line because the text is drawn in a canvas. Tab inserts indentation, so a keyboard user who tabs into the editor can never tab out. Errors are shown only as red squiggles, which a color blind user cannot see and a screen reader never mentions.

Screen readers need real text

• The text must be in the accessibility tree. With a contenteditable content element marked role="textbox", aria-multiline="true", and an aria-label, screen readers read lines, words, and characters as the cursor moves, using their normal text commands.
• The hidden textarea needs help. A textarea holding one character gives a screen reader nothing to read. Monaco has an accessibility mode (accessibilitySupport, detected automatically on some platforms) that fills the textarea with the lines around the cursor, so arrow keys read real text; Alt+F1 opens its accessibility help.
• Windowing has a cost. Only rendered lines are in the DOM, so a screen reader's "read all" stops at the edge of the viewport. Keep the margin generous and make sure the cursor's line is always rendered.
• Announce what sighted users see at a glance. Put line and column in a status region, and add a command that reads the diagnostic at the cursor ("Error: missing semicolon, line 12") through a polite aria-live region. Make lint panels and autocomplete lists real lists with aria-activedescendant, the combobox pattern from the autocomplete guide.

The Tab key and the keyboard trap

WCAG success criterion 2.1.2, No Keyboard Trap, says that if keyboard focus can move into a component, it must be able to move out with the keyboard, and if that needs more than the standard keys, the user must be told how. Programmers want Tab to indent. Both are reasonable, so editors offer an escape hatch.

CodeMirror 6 doesn't bind Tab by default at all. If the host adds indentWithTab, pressing Escape makes the next Tab move focus out (for 2 seconds), and Ctrl+M (Shift+Alt+M on macOS, in the default keymap) toggles a mode where Tab always moves focus. Monaco's equivalent is Ctrl+M (Ctrl+Shift+M on macOS) to toggle "Tab moves focus". Our editor binds Tab to indent only when the host opts in, and then shows the escape hatch in a visible hint on first focus, as the focus-management and keyboard-navigation lessons recommend.

Contrast, forced colors, and motion

• Token colors are text, so each needs 4.5:1 contrast with the background (WCAG 1.4.3). Comments in pale gray fail this in many popular themes.
• Never use color alone: an error is a wavy underline plus a gutter icon plus a message on hover and in the lint panel.
• Windows high contrast mode sets forced-colors: active. It removes gradient backgrounds, so squiggles drawn with gradients vanish, and SVG squiggles keep a fixed color the user did not choose. Use text-decoration or borders with system colors such as CanvasText and Highlight, and ship a high contrast theme.
• With prefers-reduced-motion: reduce, turn off smooth scrolling for go to line and search jumps, and consider a steady cursor instead of a blinking one.

Theming with CSS variables

Grammars produce highlight tags, the highlighter maps tags to classes, and the theme gives classes colors. If those colors are CSS custom properties (--cm-keyword, --cm-bg, --cm-selection), switching from light to dark is one attribute change on the host's root element: no editor rebuild, no re-highlight, and the host's design system tokens can feed the editor directly. CodeMirror injects its base styles in a style element; under a strict Content Security Policy, pass the page's nonce through the EditorView.cspNonce facet, or the styles are blocked.

.cm-editor {
  background: var(--cm-bg);
  color: var(--cm-fg);
}
.tok-keyword { color: var(--cm-keyword); }
.tok-string { color: var(--cm-string); }
.tok-comment { color: var(--cm-comment); font-style: italic; }

[data-theme="dark"] {
  --cm-bg: #1e1e2e; --cm-fg: #e4e4ef;
  --cm-keyword: #c792ea; --cm-string: #a5d6a7; --cm-comment: #9aa0b4;
}

@media (forced-colors: active) {
  .cm-lintRange-error { background-image: none; text-decoration: wavy underline CanvasText; }
}

Running it in the interview

This question has more depth than any interview can cover, so the skill is choosing. Show you know the whole pipeline in two minutes, then go deep on the two or three parts the interviewer cares about. A good 60 minute plan:

If the interviewer steers early, follow them, but draw the pipeline in one minute first so they see where their part sits. Expect pushes on IME, position mapping, and the controlled value loop: those are the bugs editor teams actually fix.

Follow-up questions and strong answers

Common mistakes

• Answering with a library name and stopping. The interviewer asked how it works.
• Designing input with keydown only, which breaks IME, phone keyboards, and dictation.
• Storing the document as one string, or an array of lines, without discussing the cost at 100,000 lines.
• Re-highlighting the whole file per keystroke, or moving highlighting to a worker without noticing the extra frame of delay.
• Forgetting that decorations, cursors, and diagnostics must move when text is inserted before them.
• Making Tab indent with no way out of the editor.