feat(App): add useId prop to customize Reka UI id generation#6569
feat(App): add useId prop to customize Reka UI id generation#6569Mat4m0 wants to merge 3 commits into
useId prop to customize Reka UI id generation#6569Conversation
📝 WalkthroughWalkthroughApp.vue replaces Vue's Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/runtime/components/App.vue`:
- Line 55: Upgrade the reka-ui dependency to the release that contains the
ConfigProvider.useId priority fix (the commit referenced in reka-ui#2683) so
that ConfigProvider :use-id="useRekaId" in App.vue is honored on Vue 3.5+;
update package.json to the fixed version, regenerate the lockfile (npm/yarn/pnpm
install) and verify that ConfigProvider (used in src/runtime/components/App.vue)
now respects the useRekaId prop rather than preferring Vue's global useId.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 67d9d3e6-bbd0-4770-bc7a-b709dc4b69aa
📒 Files selected for processing (1)
src/runtime/components/App.vue
commit: |
|
The fix for the ConfigProvider is released in: https://github.com/unovue/reka-ui/releases/tag/v2.9.10 |
|
@Mat4m0 It's merged 😊 |
useId prop to customize Reka UI id generation
|
Thanks for digging into this @Mat4m0! I tested the counter approach a bit more and I don't think we can make it the default: it only works when Reka primitives mount in the same order on server and client, which breaks as soon as async subtrees resolve out of order (two sibling components awaiting I've reworked your branch to expose the Let me know what you think of this direction! |
🔗 Linked issue
Resolves #5801
#5529 (maybe)❓ Type of change
📚 Description
UAppcurrently passes Vue'suseIdthrough to Reka'sConfigProvider.In Nuxt prerendered output, Vue's app ID sequence/prefix can differ between the server-rendered HTML and the client hydration pass. Reka primitives derive DOM IDs from their configured ID source, so components such as Accordion and Tabs can hydrate with different
id,aria-controls, andaria-labelledbyvalues than the prerendered HTML.This PR makes
UAppprovide a stable, instance-scoped Reka ID generator instead:The generator is scoped to the
UApprender instance, so SSR and client hydration replay the same sequence for Reka IDs instead of depending on Vue's app-level ID source.This is the Nuxt UI side of the fix: Nuxt UI provides the stable app-level ID source through the existing Reka
ConfigProvider.useIdAPI.The matching Reka UI fix (unovue/reka-ui#2683) is also required so Reka treats
ConfigProvider.useIdas the canonical source before falling back to Vue'suseId. Without that Reka-side precedence change, Nuxt UI can provide a stable generator but current Reka versions may still prefer Vue'suseIdinternally.This does not add a new public Nuxt UI API.
Tested locally with a Nuxt prerender reproduction using
UAppplus Reka Accordion/Tabs primitives:pnpm generate.output/publicBefore the Nuxt UI + Reka UI fixes, hydration reported Reka ID mismatches. With both fixes applied, there were no hydration warnings/errors.
📝 Checklist