Skip to content

fix(react-ui): don't auto-open the last Accordion item on initial mount - #862

Open
Shinyaigeek wants to merge 2 commits into
thesysdev:mainfrom
Shinyaigeek:fix/accordion-initial-open
Open

fix(react-ui): don't auto-open the last Accordion item on initial mount#862
Shinyaigeek wants to merge 2 commits into
thesysdev:mainfrom
Shinyaigeek:fix/accordion-initial-open

Conversation

@Shinyaigeek

Copy link
Copy Markdown
Contributor

Summary

Fixes #861<Accordion> opens the last item on initial mount for a fully static (non-streaming) response, instead of the first.

The auto-open branch treats any growth in item count as "a new item arrived during streaming". On the baseline render prevItemCount is 0, so a static N-item response satisfies items.length > prevItemCount.current and opens items[items.length - 1]. This is the same defect shape as the <Tabs> issue #819: a streaming follow-along heuristic that doesn't exclude the initial mount.

Changes

  • Baseline pass opens the first item. prevItemCount now starts at null so the very first render is distinguishable from streaming growth. A static mount opens the first section — restoring the behavior from before the refactor(react-ui): simplify Accordion auto-open logic #485 refactor removed the first-item mount effect. Streaming follow-along is unchanged: an item arriving after the baseline still auto-opens the newest one (an accordion that mounts empty mid-stream records a 0 baseline, so its first item still auto-opens on arrival).
  • Track the auto-opened item by index, not by value. Previously, when a new item arrived before its value string had finished streaming, setOpenItem latched a prefix of the value (e.g. "ov" for "overview"); since the only re-sync trigger was count growth, the completed value never re-synced and every section ended up closed. Tracking the index re-syncs openItem once the value completes.

Reproduction / verification

Standalone repro against the published packages: https://github.com/Shinyaigeek/openui-accordion-repro

Before (published react-ui@0.13.1) After (this branch, local build)
before: Cherry open after: Apple open
  • Added an SSR regression test (Accordion.ssr.test.tsx) that renders the static three-section program through the real Renderer + openuiLibrary and asserts the first section is the open one. It fails on the previous implementation with [ 'false', 'false', 'true' ] (last open) and passes with this change.
  • pnpm test in packages/react-ui: 28 passed.
  • Verified in a browser via the repro with a local build of this branch: the first section (Apple) is open on mount.

🤖 Generated with Claude Code

The auto-open branch in Accordion treats any growth in item count as a
new item arriving during streaming. On the baseline render prevItemCount
is 0, so a fully static N-item response satisfies the check and opens
items[items.length - 1] — the last section — instead of the first (the
behavior before the thesysdev#485 refactor removed the first-item mount effect).

Record the baseline pass separately and open the FIRST item there;
streaming follow-along is unaffected, since an item arriving after the
baseline still auto-opens the newest one. Track the auto-opened item by
index rather than by value so a value string that is still streaming in
re-syncs once it completes, instead of latching a prefix that matches no
item and leaving every section closed.

Fixes thesysdev#861

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Shinyaigeek added a commit to Shinyaigeek/openui-accordion-repro that referenced this pull request Jul 25, 2026
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.

Accordion opens the last item on initial mount instead of the first

1 participant