Skip to content

fix(app): text-card question renders visible, focused, sized textarea - #124

Merged
jeonghun-jj-lee merged 1 commit into
local/amicodefrom
amico/fix-121-text-card-input
Aug 7, 2026
Merged

fix(app): text-card question renders visible, focused, sized textarea#124
jeonghun-jj-lee merged 1 commit into
local/amicodefrom
amico/fix-121-text-card-input

Conversation

@jeonghun-jj-lee

Copy link
Copy Markdown
Contributor

Summary

Fixes three compounding failures that made kind: "text" question cards (the free-form input from PR #113 / amicode#245) render no visible text input.

Changes

1. CSS visibility (message-part.css)

Added a scoped [data-slot="question-text-form"] rule that gives the textarea a border, background tint, border-radius, and min-height when it is the primary input affordance. The choice-card's secondary custom-input stays transparent/borderless.

2. Container measurement race (session-question-dock.tsx)

After resizeInput (which sets height=0→scrollHeight), explicitly sync optionsHeight so the container never clips the textarea due to a ResizeObserver timing race.

3. Focus routing (session-question-dock.tsx)

Short-circuit focus() when text() is true — the textarea is the only focusable element and focusCustom handles it via the ref callback. Previously focus(0) targeted customRef (the choice-card's button), which doesn't render for text-kind questions.

Acceptance Criteria

  • Text-card textarea is visible (border + background + radius) in idle state
  • Textarea receives keyboard focus on mount
  • Textarea has non-zero height on mount (min-height: 36px)
  • Submitting non-empty text resolves the question (unchanged behavior)
  • Choice questions continue to render normally (scoped CSS, no functional change)
  • Both light and dark themes — text-form border/tint visible with adequate contrast

Verification

  • npm run lint — 0 new errors (1 pre-existing octal-literal error in an unrelated file)
  • tsgo -b — clean across all 30 packages (pre-push hook)
  • bun test in packages/app — 748 pass, 0 new failures

Closes #121

…#121)

Three compounding failures made kind:"text" question cards show no input:

1. CSS visibility: the textarea reused the choice-card's transparent/borderless
   custom-input style. Add a scoped [data-slot="question-text-form"] rule that
   gives it a border, background, radius, and min-height — the textarea is now
   visually distinct as the primary affordance.

2. Container measurement race: resizeInput sets height=0 then scrollHeight, but
   the ResizeObserver could fire during the transient. After resizeInput, sync
   optionsHeight explicitly so the container always accommodates the textarea.

3. Focus routing: focus() targeted customRef (the choice-card's "Type your own
   answer" button) which doesn't render for text-kind questions. Short-circuit
   the focus function when text() is true — focusCustom handles it via the ref
   callback.

Closes #121
@jeonghun-jj-lee
jeonghun-jj-lee marked this pull request as ready for review August 7, 2026 04:16
@jeonghun-jj-lee
jeonghun-jj-lee merged commit 15bc6c4 into local/amicode Aug 7, 2026
1 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

BUG: Free-form question card (kind: "text") renders no text input

1 participant