feat(ui): implement deep linking in CodeTabs via URL hash

[moshams272]

Description

Implement deep linking in CodeTabs component by using the active tab state via the URL hash.

In Details

• Add optional groupId prop to generate unique anchor IDs across multiple CodeTabs instances on the same page in format: tab-{groupId}-{language}-{index}, falling back to React's useId() when groupId is not provided.
• Read the URL hash on mount via a lazy initializer in useState() to set the correct initial tab without a double render.
• Update the URL silently on tab click using history.replaceState to avoid polluting the browser history

Validation

After building, I checked the tabs by clicking on them, and then the URL hash changed.

Related Issues

Fixes #9140

Check List

• I have read the Contributing Guidelines and made commit messages that follow the guideline.
• I have run pnpm format to ensure the code follows the style guide.
• I have run pnpm test to check if all tests are passing.
• I have run pnpm build to check if the website builds without errors.
• I've covered new added functionality with unit tests if necessary.

[vercel]

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

Project	Deployment	Actions	Updated
nodejs-org	Ready	Preview	Sep 13, 2026 5:26pm UTC

[ovflowd]

We want to avoid having the CodeTabs being a client-component in all cases. We could use a wrapper that uses use client specifically for when these groupIds or whatnot are passed, ands we can do the logic of what gets used on shiki I guess?

That said per the repo guidelines it is an absolute no-go using winodw APIs from within components, not to mention adding so many event listeners (1 per CodeTab) is going to be an absolute nightmare for the browser.

[AugustinMauroy]

I dunno how to reproduce what I have done but it's may happened

[avivkeller]

LGTM minus Claudio's concerns

[moshams272]

We want to avoid having the CodeTabs being a client-component in all cases. We could use a wrapper that uses use client specifically for when these groupIds or whatnot are passed, ands we can do the logic of what gets used on shiki I guess?

That said per the repo guidelines it is an absolute no-go using winodw APIs from within components, not to mention adding so many event listeners (1 per CodeTab) is going to be an absolute nightmare for the browser.

Got it, I saw the use client used in BaseCodeBox first. After your comment, I find the pattern you mean used in AvatarGroup.

I think Augustin's bug happened because of the React Hydration Error in the useState.

[ovflowd]

Got it, I saw the use client used in BaseCodeBox first. After your comment, I find the pattern you mean used in AvatarGroup.

We might need to revisit why BaseCodeBox uses "use client" but still we should thrive for reducing client components as much as possible :)

[moshams272]

We might need to revisit why BaseCodeBox uses "use client" but still we should thrive for reducing client components as much as possible :)

I reached for a fair solution. We use useMediaQuery.ts as a custom hook and access the window through it. So, could I do the same?! Or we should revisit it too ;)

It's an initial thinking for now.

[ovflowd]

I reached for a fair solution. We use useMediaQuery.ts as a custom hook and access the window through it. So, could I do the same?! Or we should revisit it too ;)

In terms of should window APIs be behind safe Hooks, yes. But in terms of, should we have god knows how many Event Listeners because they're tied to one CodeBox? No.

You might want to think of a React Context Provider, with one hook that keeps an eye on Hash changes. Or you might defer it to a HoC, so that on the apps, such as Next.js and doc-kit we defer the implementation of this, for example, Next.js has a Router/Navigation API, you could inject results on the CodeBox...

I guess it's more of a thinking of "who should be responsible for listening to this" you could argue it should be the Component itself, because he's the one interested on this, that said, it's only interested on the scenarios where it should even care abou that. IMO, the Component should subscribe to the changes aka ask to the parent component or context provider "has the hash changed?" ... yet that the responsibility of actually setting up the Event Listener shouldn't be part of the Component's responsibility.... As "Window" or even a Hook that "listens to Window" is something unbeknown to the Component. The Component's "world" should always be anything that is inside said Component. That's a very common mistake some React Components do on, for example, Modals. Where they let the Modal itself be the one observing if anyone clicked outside the Modal, whereas that should never be the Modal's responsibility.

So think a bit of how to approach this, both in a way that is properly designed and that can be reused (ie: if this is a prop/callback to the Component, you defer the implementation details (be it window APIs, be it Next.js APIs...) to the consumer) and how to make it reliable and performant.

I hope my explanation helps!