refactor(value-editor): migrate to TypeScript and split by concern

[talissoncosta]

Thanks for submitting a PR! Please check the boxes below:

• I have read the Contributing Guide.
• I have added information to docs/ if required so people know about the feature.
• I have filled in the "Changes" section below.
• I have filled in the "How did you test this code" section below.

Changes

#8446 has merged, so this is rebased onto main and stands on its own.

No behaviour change intended. ValueEditor was a 254-line untyped class with no props contract, which is how placeholder and readOnly came to be passed at three call sites and silently ignored.

TypeScript. Renaming to .tsx produced 43 strict errors. All but two were missing prop/state interfaces and implicit any. The two that were not:

• renderValidation() was being called with an argument it does not accept
• <Tooltip position='top'> passes a prop TooltipProps does not declare

value is now FlagsmithValue rather than string, which is what the MV and segment call sites actually pass. That surfaced immediately once the interface existed.

Split by concern. Each piece is small, and the parsing is unit-testable on its own for the first time:

ValueEditor/
  ValueEditor.tsx                orchestrates, function component
  types.ts                       language union and display order
  validate.ts                    pure parse checks, no React
  components/LanguageSelector    the .txt/.json/.xml/.toml/.yaml row
  components/LanguageValidation  the tick or warning
  components/CopyValueButton     the copy control
  index.ts

Imports are unchanged at all eight call sites: the folder resolves where the file used to.

Dropped ionicons from this component. We already own warning and checkmark-circle, so it is a straight swap.

The format labels are real buttons now. They were <span onMouseDown>: not focusable, no role, no keyboard path. Same defect the copy control had in #8446, and leaving four of them beside a fixed fifth made no sense. They are BareButtons in a role="group" labelled "Value format", with aria-pressed carrying the selection.

mousedown was the reason they were spans: the editor is contenteditable, and pressing down on a button blurs it and loses the caret. preventDefault on mousedown stops the blur without stopping the click, so onClick does the work and the keyboard path comes for free. Verified in the browser: mousedown is default-prevented, focus stays in the editor, and the language still changes.

Stopped using polyfill-react-native here. Its Clipboard wraps the deprecated document.execCommand. Copying now goes through navigator.clipboard, which lib.dom already types.

To get there without importing the Utils object (whose Storybook stub explicitly asks new components not to), copyToClipboard is extracted into common/utils/copyToClipboard. Utils keeps the key and delegates, so its nineteen existing callers are untouched.

How did you test this code?

ValueEditor is clean under tsc --strict (the only remaining error in its story is Cannot find module 'storybook', which every story in the repo reports).

Drove the Storybook stories from #8446 in the browser and asserted on the rendered DOM in both themes: format label order, active language, validation icon present with the right tone class, copy still a <button> with its aria-label, and no ion-icon element anywhere.

That caught two regressions I had introduced and have fixed: the format labels came out alphabetically ordered, and the validation icon vanished.

ValueEditor owns its label now. Three treatments had grown up around one component: FieldLabel at two call sites, a raw <label> at two, a bespoke ValueRowLabel div at three, nothing in the SAML modal. None passed htmlFor, and ValueEditor accepted no id, so none of them actually named the editor.

It now takes label and labelTooltip and renders the FieldLabel itself, generating both ids so a caller cannot get the association wrong. The editor carries aria-labelledby, and the contenteditable gets role="textbox" with aria-multiline — without a role, a screen reader announces it as plain text and aria-labelledby has nothing to name.

That also settles the layout problem I raised earlier. Label and format buttons are now one flex row instead of two layers, so a long label can no longer run under the buttons. The multivariate control value is the widest case (label + weight chip + tooltip); measured at 380px, narrower than the drawer gets, it leaves a 56px gap rather than relying on there being room. Two stories cover it: BadgeLabel and BadgeLabelNarrow.

Tests

13 new unit tests, all passing (npm run test:unit).

• validate.ts — every language's valid and invalid paths. Writing them caught a wrong assumption of mine: a:\n- b\n - c is valid YAML, so the failure case now uses an unclosed quote and a bad indent.
• copyToClipboard.ts — writes the value, default and caller-supplied messages, and that a rejected write toasts and rethrows.

Both are plain .ts with no React, which is the only thing this project can unit test today: jest runs testEnvironment: 'node', testMatch picks up .ts but not .tsx, and there is no React Testing Library.

What is still not covered, honestly:

• The components. No RTL, so LanguageSelector, LanguageValidation, CopyValueButton and ValueEditor itself have no behavioural tests. The Storybook stories are visual coverage via Chromatic, not tests.
• The xml branch, left as it.todo. It needs DOMParser, which the node environment does not provide. Adding jest-environment-jsdom is a wider decision than this file.
• The real editor, in E2E. The existing E2E tests hit data-test selectors on the <textarea> that the E2E ? textarea : Highlight fork swaps in. They never exercise Highlight, the contenteditable that production actually renders. That is worth knowing before anyone reads the E2E suite as coverage of this component.

Reviewing this

Three things worth a look:

1. Icon drops className for most icons. It only spreads ...rest in 12 of ~100 cases, and warning hardcodes #FF9F43 rather than currentColor. I worked around it here with a wrapper span plus explicit fill='currentColor', rather than changing Icon and taking the blast radius. It is the same defect the design system audit flagged, and it deserves its own issue.

2. The validation icon is not actually red or green. _hljs.scss has .select-language .active .language-icon { color: var(--color-text-default) }, which out-specifies .text-danger / .text-success. Since validation only ever renders on the active label, that rule always wins. This is pre-existing, not something this PR introduced, and I left it alone so the diff stays a refactor. But an error icon rendering in body colour looks wrong and is a one-line fix once someone confirms the intent.

3. copyToClipboard extraction. Moving one function out of Utils and re-exporting it is a pattern, not a one-off, and it is the direction the Storybook stub asks for. Say if you would rather it stayed inside Utils and I reverted the extraction.

4. data-test is still there, deliberately. It is used in 11 places across 5 E2E files. It cannot move to a11y selectors yet: the editable surface is a contenteditable <code> with no role and no accessible name, and neither does the <textarea> that E2E swaps in. That is a real WCAG 4.1.2 gap, and it is also why the E2E ? textarea : Highlight fork exists at all, which means E2E never exercises the real editor. Giving the editor a role and a name would fix the a11y defect, let the tests use getByRole('textbox', { name: 'Value' }), and potentially delete that fork. Worth its own PR.

Still not done

• aria-pressed toggle buttons, not a radiogroup. A radiogroup is more precise for a mutually exclusive set, but wants roving tabindex and arrow-key navigation. Tab-to-each plus Enter/Space is accessible today; say if you would rather have the full radiogroup.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
flagsmith-frontend-preview	Ready	Preview	Sep 4, 2026 8:32pm UTC
flagsmith-frontend-staging	Ready	Preview	Sep 4, 2026 8:32pm UTC

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Ignored	Preview	Sep 4, 2026 8:32pm UTC

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}