Skip to content

Components: Generate Textarea #4245

Open

Description

@JasonVMo

Summary

Deliver Textarea as an original reviewed React Native component contract, implementation, public export, and evidence-backed desktop behavior. Parent: #4273.

Current state - 2026-10-02 (UTC)

Observed: Audited against main at 75c55923873124201d2ffbf3b3e67960047bd481. There is no implemented/exported textarea component or colocated contract on main. This generation issue remains open.

Assessment: Native no-resize/growth contract decision.

Dependencies and next action

Input/TextInput and focus foundations exist. CSS drag-resize parity is not supplied by the current native contract; #4252 is completed.

Start with the component's source-backed native contract review. A missing local contract is work to author, not a reason to wait for the completed #4252. Only the named unresolved component/host/product decisions above remain prerequisites; do not carry forward blanket overlay-wave or missing-Fabric blockers.

Component scope

  • Review a multiline native editor with an explicit no-drag-resize adaptation; distinguish fixed height, content growth, and any future native resize handle.
  • Define controlled/uncontrolled value, rows/height constraints, scrolling, disabled/read-only behavior, and multiline accessibility.
  • Reuse editor styling/focus foundations and qualify auto-growth, line alignment, constrained width, and caret behavior without claiming browser textarea semantics.

Non-goals

Do not migrate legacy consumers, add mobile support, copy private/web source prose into the public package, or rewrite unrelated component APIs. Desktop V1 Win32/Windows/macOS behavior is compatibility evidence, not an iOS canonical baseline. Keep shared hosting, icons, and focus ownership in their named tasks.

Delivery and acceptance

  • Author an original colocated SPEC.md and spec/ companions with schema-version-2 sources[], requirement IDs, source authority, and explicit native divergences; pass pre-code contract review before implementation.
  • Implement the typed state/style/render/assembly stages, finite variant axes, optional slots, native root refs, user-prop/style forwarding, and explicit package exports covered by src/index.test.ts. Preserve React 19 ref props, shared focus policy, theme-only style caching, disabled-over-pressed-over-hovered precedence, and repository source boundaries.
  • Add runtime and compile-time coverage for public API, every finite axis, optional content, accessibility, disabled state, constrained layout, and each controlled/uncontrolled or externally selected state path.
  • Add representative and stress stories with top-level executable wdio cases. Use the delivered Storybook/native assertion infrastructure (Infrastructure: Add native accessibility assertions and Storybook test support #4255, Infrastructure: Add Storybook end-to-end test pipelines #4256); record actual Windows/macOS results and Win32 compatibility evidence, with capability skips stated rather than counted as passes.
  • Run owning-workspace format, lint, build, and tests, plus Windows/macOS Storybook bundles; run the root build for changed public types/exports/manifests and add a changeset for package changes. Record a readiness level with its evidence under Components: Component tests for the agentic component library #4216 and Components: Component readiness model and initial assessment #4251.
  • Merge the reviewed implementation before closing this generation issue. Source contracts, branch code, successful bundling, or a closed unmerged PR alone do not establish delivered readiness.

Contract review is normal phase-one work, not a missing-ingestion blocker. #4252 is complete; the old specs/<name>/blockers.md records are historical evidence, not live authoring inputs.

Current native qualification limits: #4342 tracks all-skipped WDIO selections being reported as passed; inspect executed cases rather than aggregate success. #4343, #4346, and #4347 retain full accessibility, native state projection, and focus-regression qualification. #4344 tracks native catalog crash exclusions, and #4349 tracks qualifying/promoting required CI. These are evidence/readiness gates, not a claim that delivered test infrastructure or every component behavior is missing.

Evidence

Evidence reflects this repository snapshot; the checked-in candidate drift report is dated 2026-08-31 and is not a fresh upstream audit.

Activity

  1. changed the title [-]Generate Textarea[/-] [+]Components: Generate Textarea[/+] on Aug 21, 2026
  2. krasnoff commented on Sep 4, 2026

    @krasnoff

    Jason Morse (@JasonVMo)
    I would like to work on this feature

  3. krasnoff commented on Sep 6, 2026

    @krasnoff

    I have two more questions regarding this component:

    1. according to the guidelines in https://github.com/microsoft/fluentui-react-native?tab=contributing-ov-file we have to place new components in experimental folder while in the component specific instruction we have to place it in the components folder. So, where to place the component?
    2. I dont have access to some of the files metioned in Canonical spec and source table.
  4. JasonVMo commented on Sep 8, 2026

    @JasonVMo
    ContributorAuthor

    I have two more questions regarding this component:

    1. according to the guidelines in https://github.com/microsoft/fluentui-react-native?tab=contributing-ov-file we have to place new components in experimental folder while in the component specific instruction we have to place it in the components folder. So, where to place the component?
    2. I dont have access to some of the files metioned in Canonical spec and source table.

    This issue is part of a larger effort to be able to generate the components from specs, while adapting to both newer and older design systems. The components are all being built in the packages/agentic/components package which should be ESM and tree-shakable (via the @rnx-kit/metro-serializer-esbuild package) though at some point we can consider submodules if necessary. While the controls should be runnable in android/ios we are focusing on desktop at the moment.

    Things are rapidly evolving at this point and it will be hard to build controls if you aren't internal. Bug fixes are welcome, but for the time being the new components are an internal effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions