Fix: highlight a TOC link entry when on the page or section it points to (RND-11155) - #4476
Fix: highlight a TOC link entry when on the page or section it points to (RND-11155)#4476zenoachtig wants to merge 2 commits into
Conversation
🦋 Changeset detectedLatest commit: 5b4f17b The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
A table-of-contents entry of type "link" that resolves to a page in the current space now computes its active state the same way page entries do, comparing the target page's paths against the current page path. Links pointing to a section of a page also highlight, but only while the reader is at that section, so sibling links to other sections of the same page don't all light up together. Cross-space and external targets are still excluded. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
a9bdbd8 to
5b4f17b
Compare
zenoachtig
changed the title
Style invalidation on a large API referenceElements restyled by opening one popup on the Snyk API reference. A share near or above 100% means the insertion restyles the whole document.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5b4f17bff4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
1 participant
Overview
In a published site's table of contents, an entry of type
linkwas never highlighted as active, even when the reader was on the exact page it points to. Page entries (document) compute their active state client-side frompathnamesvs.useCurrentPagePath(); link entries were rendered as a plainLinkwith no active logic and nopathnamesin their encoded payload.pathnamesandanchortoClientTOCPageLink, populated inencodeClientTableOfContentswhen a link resolves to a page in the current space. Uses the samegetSiteSpacePagePathshelper page entries use, so the two stay consistent.PageLinkItemcomputeisActiveand apply the samedata-active/aria-current="page"/ToCLinkItemActiveStylestreatment as page entries.kind: 'anchor'), not just whole-page links — these highlight only while the reader is at that section, matched on the current hash. A page commonly has several sibling links into different sections of it; without the hash condition all of them would light up at once.resolved.space?.id === context.space.id).Repro: https://gitbook.com/docs/~/changes/1288/create-content/formatting/inline#buttons — the "Buttons" entry under "Blocks" points at a section of Inline content, and now highlights alongside the Inline content page entry.
Testing
Verified against the repro URL on a local dev server. The encoded payload for the "Buttons" entry now carries its target:
At
#buttons, computed styles on the sidebar entries:data-active::beforebartruergb(254,85,27)truergb(254,85,27)falsefalseClicking "Icons" moves the highlight to Icons and leaves Inline content active.
Known limitation, inherited from the existing
useHash: it updates on link clicks and on mount, not on browser back/forward, so a back-button hash change doesn't move the highlight until the next navigation. This is shared with the hook's other consumers rather than introduced here.No automated test added: this is client-side rendering/navigation behavior driven by Next.js routing params, better covered by a Playwright test than a mocked unit test. Flagging it as a deliberate gap.
Commands run:
bun run lint,bunx oxfmt --check,bun run typecheck(2 pre-existing errors onmain, none added). The same computed-style checks were re-run against the deployed preview build and match.Demo
Preview build, with "Blocks" expanded in the sidebar: https://5d59f165-gitbook-open-v2-preview.gitbook.workers.dev/url/gitbook.com/docs/~/changes/1288/create-content/formatting/inline#buttons
Sidebar at
.../create-content/formatting/inline#buttons— "Buttons" highlighted alongside "Inline content":Same sidebar after clicking "Icons" — highlight moves, "Inline content" stays active:
Changelog
— Authored by Claude