components / inlineedit

InlineEdit

Display-first field that expands into focused editing for quick metadata changes without leaving the current layout.

Overview

What it is

This section explains the intent of the component before the implementation details.

  • InlineEdit is for quick edits where the surrounding layout should stay visible and stable.
  • It lets the user move from reading to editing without navigating to a separate form.

Aliases

editable text, inline rename

Decision guide

How to choose it

Use these notes to decide quickly whether this is the right DK component for the job.

Decision guide

  • Choose InlineEdit when the interaction should feel deliberate, documented, and reusable across product surfaces.
  • If the scenario is more specialized than the current InlineEdit contract, prefer a simpler component or build a dedicated workflow on top of the lower-level DK primitives.

Do

  • Keep the InlineEdit label, value, or status language direct enough to scan quickly.
  • Use the documented size and state recipes instead of inventing one-off variants in product code.

Do not

  • Do not hide the main purpose of InlineEdit behind decorative copy or overloaded surface treatments.
  • Do not stretch InlineEdit into a workflow it was not designed to handle just because the visuals are close.

Usage

When to use

Prefer these situations when choosing this component.

  • Use InlineEdit for short renames, labels, and inline metadata edits.
  • Use multiline mode for concise notes when the edit still belongs in place.

Usage

When not to use

These patterns are better served by a different component or a simpler surface.

  • Do not use InlineEdit for long-form editing or rich text.
  • Do not use it when the edit needs full-form validation and multiple related fields.

Anti-patterns

  • Using InlineEdit as a generic layout container instead of a purpose-built interaction or content surface.
  • Forking the documented recipe in product code instead of extending the shared DK contract.

Migration notes

  • Migrate legacy inlineedit usage by mapping existing variants and states onto the documented DK props before porting any custom styling.
  • Treat the docs examples as the reference contract for accessibility and event behavior during adoption.

Anatomy

Structural parts

The anatomy explains which pieces matter to the recipe and accessibility model.

read state

display

Non-editing surface that shows the committed value.

active editor

field

Input or textarea that appears while editing.

commit controls

actions

Save/cancel controls for multiline editing.

API

Public interface

The docs contract distinguishes props, DOM events, and slots so integration behavior is explicit.

Props

NameTypeDefaultDescription
valuestring—Controlled committed value.
labelstring—Visible label for the inline editor.
descriptionstring—Supporting helper copy.
placeholderstring—Placeholder shown when the value is empty.
disabledbooleanfalseDisables entry into editing mode.
multilinebooleanfalseSwitches the editor into textarea mode.
onChange(detail: { value: string }) => void—Callback fired while the draft changes.
onCommit(detail: { value: string }) => void—Callback fired when the edit is committed.
onCancel(detail: { value: string }) => void—Callback fired when editing is cancelled.
themeThemeContract—Overrides the compiled DK theme used to resolve tokens and recipes for this component.

Events

NamePayloadDescription
change{ value: string }Fires while the draft changes.
commit{ value: string }Fires when the edit is committed.
cancel{ value: string }Fires when the edit is cancelled.

Slots

NameDescription
defaultInlineEdit is prop-driven in v1 and does not expose slot-based adornments.

Recipes

Variants, sizes, and states

These notes summarize the intended recipe surface rather than exposing raw implementation detail first.

Variants

  • single-line: Commit on blur or Enter for quick scalar edits.
  • multiline: Explicit save/cancel controls for slightly longer edits.

Sizes

  • default: InlineEdit uses one compact density tuned for in-place editing.

States

  • display: Committed display state
  • editing: User is actively editing the value

Accessibility

Accessibility contract

This is the behavior the component promises to assistive tech and keyboard users today.

Semantics

  • Uses standard field labeling through visible labels, descriptions, and error text.
  • Exposes disabled and required semantics through the underlying form control.

Keyboard

  • Supports native focus and text entry behavior.
  • Enter starts editing from the display state, Escape cancels, and multiline mode exposes explicit save/cancel controls.

Screen readers

  • Connects visible label, helper text, and error text to the native control.

Checklist

  • Verify the visible label or title still produces a clear accessible name.
  • Verify focus remains obvious in every supported state and size.
  • Verify disabled, selected, and error states do not rely on color alone.

Implementation

Tokens and slot vars

This section shows the representative compiled slot variables that the runtime consumes for the selected design system.

root

--dk-inline-gap
0.45rem

label

--dk-inline-label-color
#16181c
--dk-inline-label-size
clamp(1.333rem, 1.2222rem + 0.494vw, 1.667rem)
--dk-inline-label-weight
600

display

--dk-inline-display-bg
#f2f5fb
--dk-inline-display-fg
#16181c
--dk-inline-display-border
#95989d
--dk-inline-display-radius
clamp(0.75rem, 0.6875rem + 0.278vw, 0.938rem)
--dk-inline-display-block-size
44px
--dk-inline-display-inline-padding
clamp(1.333rem, 1.2222rem + 0.494vw, 1.667rem)
--dk-inline-display-font-size
clamp(1.333rem, 1.2222rem + 0.494vw, 1.667rem)

field

--dk-inline-field-bg
#f2f5fb
--dk-inline-field-fg
#16181c
--dk-inline-field-border
#2072e4
--dk-inline-field-radius
clamp(0.75rem, 0.6875rem + 0.278vw, 0.938rem)
--dk-inline-field-block-size
44px
--dk-inline-field-inline-padding
clamp(1.333rem, 1.2222rem + 0.494vw, 1.667rem)
--dk-inline-field-font-size
clamp(1.333rem, 1.2222rem + 0.494vw, 1.667rem)

description

--dk-inline-description-color
#16181c
--dk-inline-description-size
clamp(0.75rem, 0.6875rem + 0.278vw, 0.938rem)

actions

--dk-inline-actions-gap
clamp(0.75rem, 0.6875rem + 0.278vw, 0.938rem)

Implementation notes

  • InlineEdit is intentionally display-first. If the edit belongs in a broader form, move it into a full field layout instead.

Implementation checklist

  • Use the public component API first and only drop to lower-level primitives when the component contract genuinely does not fit.
  • Keep theme overrides token-driven so proofs and recipes stay meaningful.
  • Verify the shipped examples and proof fixtures still represent the real product scenario you are implementing.

Examples

Copy-paste examples

Each example is intentionally practical, grouped by starter, common pattern, and edge-case coverage.

Examples
3
Depth
expanded

Starter

1 example

starter

Starter: in-place rename

Click the label to enter editing mode without leaving the page.

Copy snippet

<InlineEdit label="Project name" value="Launch roadmap" onCommit={(detail) => saveName(detail.value)} />

Common patterns

1 example

common

Common: short note editing

Multiline mode adds explicit save/cancel controls for draft management.

Copy snippet

<InlineEdit multiline={true} label="Release note" value="Add rollout caveats here." />

Edge cases

1 example

edge

Edge: locked metadata

Disable the editor when the current user can review but not change the value.

Copy snippet

<InlineEdit label="Project name" value="Launch roadmap" disabled={true} />

Verification

Curated proof fixtures

Proofs stay visible in the docs so the system shows what it can guarantee, not just what it can render.

default-md

pass

size=md

  • Contrast: 98.5 Lc
  • Target: 44px