While an input method editor composes a character, why must a binding keep the in-progress text out of the model?

## What composition is Some text cannot be typed one character per key. An **input method editor** assembles a sequence of keystrokes into final characters: phonetic input resolved into ideographs, a dead key plus a vowel into an accented letter, a phone's predictive text replacing a whole word. While that assembly is in progress, the control must show the **unfinished text** — the user is choosing among candidates and needs to see what they are choosing. The platform brackets this window with composition start and end signals and reports the intermediate states as edits. The mechanics of those host events belong to the platform layer; what belongs to a binding is the decision of **what to do during the window**. ## Why the model must not see the window The intermediate text is a **user-interface artefact**, not a value. Everything that derives from the model treats it as a value anyway: - **Rules judging the value** run against text the user never committed, so a message flashes and clears while the user is mid-word. - **Counters and limits** measure intermediate units rather than final characters, so a remaining-characters count jumps around and a length cap can block a legal entry. - **Derived requests** fire once per intermediate state — a live filter or a lookup burning several calls for one word. - **Formatters** rewrite the buffer according to a value that does not exist yet. - A **submit** during the window would carry unfinished text. ## Why write-back is the dangerous half Reading intermediates is untidy; writing during composition is destructive. The control owns a composition buffer with its own caret and candidate state. When the framework asserts the bound value into the control mid-composition it **replaces that buffer**, and the observable results are: - the composition is cancelled and the candidate list disappears; - characters are duplicated, because the committed text is appended to text the control still held; - characters are dropped, because the write landed before the commit; - the caret jumps to the end, so the next keystroke continues in the wrong place. The rule follows directly: **do not write into a control while it is composing.** ## The handling shape 1. On the composition start signal, set a per-field *composing* flag. 2. While the flag is set, keep subscribing if you like, but **do not write the model** and above all **do not write the control**. The control renders its own buffer perfectly well without help. 3. On the composition end signal, read the control's value **once** and write it to the model as a single edit. 4. Clear the flag and allow downward writes again. 5. Clear the flag on **focus loss** too, so a field that loses focus mid-composition cannot get stuck with writes suspended. Step 5 is the one people leave out. Do not assume an end signal always arrives before a blur in every host and input method; the flag has to be recoverable. ## Adjacent cases with the same shape - **Predictive text and autocorrect** on touch keyboards replace a range of already-visible text rather than appending, and often arrive in the same bracketed window. A binding that assumed append-only edits mis-handles both. - **Dictation** streams partial transcriptions that are revised as more audio arrives — the same *not final yet* property. - **Commit-source bindings get this for free.** If the binding writes only on the committed-change event, its write already lands after composition finished, which is one honest reason to prefer a commit source for free-text fields in a multilingual product. | Binding source | Sees intermediate text? | Write-back risk during composition | |---|---|---| | per-edit, no composition handling | yes, every intermediate | high — can cancel or duplicate | | per-edit, suspended while composing | no | none, writes are held | | committed change | no | none, commit lands after the window | ## Reactivity models differ in how loudly this fails A runtime that re-asserts the bound value downward on every state write is the most exposed: publishing an intermediate immediately writes it back, so the damage is visible on the first composed word. A runtime with fine-grained tracking writes down only when the value actually differs from what it last wrote, so many compositions survive and the bug surfaces only when a formatter or a rule changes the value mid-window. A compile-time runtime generates the same subscription; nothing about compilation handles composition for you. Some frameworks' own bindings suspend during composition by default and hand-written listeners never do — which is exactly why replacing a binding with a listener is a behaviour change, not a refactor. ## How to answer this in an interview Say what composition is in one sentence, then split the answer: intermediates must reach the **control** and must not reach the **model**, and the write-back is the half that actually breaks input. Name the suspend-until-end handling and the focus-loss escape, and note that a commit-source binding sidesteps the whole thing.