Merged
Conversation
down in wiki when navigating
scroll down so far that it gets into the footer
Contributor
📝 WalkthroughWalkthroughThis pull request enhances wiki page navigation and code display by introducing scroll position persistence for the sidebar, a new scroll-to-heading utility for consistent anchor navigation, client-side tab switching for grouped code blocks via event delegation, accordion state persistence in navigation, and comprehensive CSS styling updates for tabbed code groups and scrollable tables. Changes
Sequence DiagramsequenceDiagram
actor User
participant WikiNav as WikiNavigation
participant WL as WikiLayout
participant ScrollUtil as wiki-scroll
participant DOM as Main Content<br/>(DOM)
participant Storage as sessionStorage
User->>WikiNav: Click TOC heading link
WikiNav->>Storage: Check if hash matches heading
alt Hash found
WikiNav->>WikiNav: Set activeId to hash
else Hash not found
WikiNav->>WikiNav: Find closest heading to scroll top
end
WikiNav->>DOM: history.replaceState(null, "", `#id`)
WikiNav->>ScrollUtil: scrollToWikiHeading(element)
ScrollUtil->>DOM: Get .main-wiki-content container
ScrollUtil->>DOM: Calculate target offset via getBoundingClientRect()
ScrollUtil->>DOM: container.scrollTo({ top, behavior: "smooth" })
User->>WL: Scroll sidebar
WL->>WL: Debounce scroll event
WL->>Storage: Save sidebar.scrollTop
User->>WL: Reload/navigate back
WL->>Storage: Read sidebar scroll position
WL->>DOM: Apply scrollTop in useLayoutEffect
DOM->>User: Sidebar restored to previous position
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
frontend/components/wiki/WikiNavigation.tsx (1)
255-257:⚠️ Potential issue | 🟡 MinorKeep the current branch expanded.
If
closedAccordionsalready contains a parent directory, this collapses it even whencurrentPathpoints to a descendant page. The active page and its TOC then stay hidden inside a closed section after direct/search navigation.🔧 Suggested fix
const itemPath = item.slug.join("/"); const uniqueKey = `${itemPath}-${depth}-${index}-${item.isFile ? "file" : "dir"}`; const isActive = currentPath === itemPath; + const isInCurrentBranch + = currentPath === itemPath || currentPath.startsWith(`${itemPath}/`); @@ <Accordion key={uniqueKey} type="single" collapsible - value={closedAccordions.has(itemPath) ? "" : itemPath} + value={isInCurrentBranch || !closedAccordions.has(itemPath) ? itemPath : ""} onValueChange={val => handleAccordionChange(itemPath, val)} className="px-0" >Also applies to: 317-318
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@frontend/components/wiki/WikiNavigation.tsx` around lines 255 - 257, The code collapses parent directories even when the active page is a descendant; update the collapse logic in WikiNavigation so that a directory with uniqueKey present in closedAccordions stays expanded if currentPath equals itemPath or is a descendant (e.g., currentPath.startsWith(itemPath + "/")). Locate where itemPath, uniqueKey and isActive are computed and change the check that reads closedAccordions.has(uniqueKey) to also test for ancestry (only for directories) — treat the accordion as "open" when isActive || currentPath.startsWith(itemPath + "/") so descendant pages keep their parent branch expanded (apply the same fix to the similar logic around the other occurrence at the later block).frontend/components/wiki/WikiLayout.tsx (1)
88-111:⚠️ Potential issue | 🟠 MajorDelegate heading-anchor clicks from
.main-wiki-contentusing event delegation.The effect snapshots the current
a.heading-anchornodes at mount with an empty dependency array. When{children}re-renders during client-side wiki navigation, new heading anchors on the next page won't have this handler attached, falling back to native anchor scrolling instead of the customscrollToWikiHeadingbehavior.This follows the same delegation pattern already used in the code-group (lines 116–198) and wiki-links (lines 200–237) handlers.
🔧 Suggested fix
useEffect(() => { const container = document.querySelector(".main-wiki-content"); if (!container) return; - const links = container.querySelectorAll("a.heading-anchor"); - const handleClick = (e: Event) => { - e.preventDefault(); - const href = (e.currentTarget as HTMLAnchorElement).getAttribute("href"); + const handleClick = (e: MouseEvent) => { + const link = (e.target as HTMLElement | null)?.closest("a.heading-anchor") as HTMLAnchorElement | null; + if (!link) + return; + + e.preventDefault(); + const href = link.getAttribute("href"); const targetId = href?.startsWith("#") ? href.slice(1) : null; if (targetId) { history.replaceState(null, "", `#${targetId}`); const target = document.getElementById(targetId); if (target) { scrollToWikiHeading(target); } } }; - links.forEach(link => link.addEventListener("click", handleClick)); + container.addEventListener("click", handleClick as EventListener); return () => { - links.forEach(link => link.removeEventListener("click", handleClick)); + container.removeEventListener("click", handleClick as EventListener); }; }, []);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@frontend/components/wiki/WikiLayout.tsx` around lines 88 - 111, The current useEffect in WikiLayout.tsx attaches click listeners to a static NodeList of a.heading-anchor elements at mount, so newly rendered anchors after client-side navigation won't get handlers; change this to use event delegation by adding a single click listener on the container (document.querySelector(".main-wiki-content")) that checks event.target (or closest("a.heading-anchor")) to find an anchor, prevents default, extracts the href/targetId, calls history.replaceState and then invokes scrollToWikiHeading for the resolved element; ensure you remove the delegated listener in the cleanup and keep the empty dependency array as before.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@frontend/styles/wiki.css`:
- Around line 229-230: Remove the deprecated declaration and fix spacing: delete
the `word-break: break-word;` line and instead ensure a supported rule is
present (e.g., use `overflow-wrap: anywhere;` or keep `overflow-wrap:
break-word;` if intentional) in the same rule block, and add the required blank
line before each of the rule blocks that were added (the blocks containing the
declarations at the locations that held `overflow-wrap`/`word-break` — update
the rule blocks where `overflow-wrap` is set and the other two new blocks
referenced) so the file conforms to the repo's blank-line style.
---
Outside diff comments:
In `@frontend/components/wiki/WikiLayout.tsx`:
- Around line 88-111: The current useEffect in WikiLayout.tsx attaches click
listeners to a static NodeList of a.heading-anchor elements at mount, so newly
rendered anchors after client-side navigation won't get handlers; change this to
use event delegation by adding a single click listener on the container
(document.querySelector(".main-wiki-content")) that checks event.target (or
closest("a.heading-anchor")) to find an anchor, prevents default, extracts the
href/targetId, calls history.replaceState and then invokes scrollToWikiHeading
for the resolved element; ensure you remove the delegated listener in the
cleanup and keep the empty dependency array as before.
In `@frontend/components/wiki/WikiNavigation.tsx`:
- Around line 255-257: The code collapses parent directories even when the
active page is a descendant; update the collapse logic in WikiNavigation so that
a directory with uniqueKey present in closedAccordions stays expanded if
currentPath equals itemPath or is a descendant (e.g.,
currentPath.startsWith(itemPath + "/")). Locate where itemPath, uniqueKey and
isActive are computed and change the check that reads
closedAccordions.has(uniqueKey) to also test for ancestry (only for directories)
— treat the accordion as "open" when isActive || currentPath.startsWith(itemPath
+ "/") so descendant pages keep their parent branch expanded (apply the same fix
to the similar logic around the other occurrence at the later block).
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 59af2898-51dd-46e1-b2a5-4f43b4a56cbf
⛔ Files ignored due to path filters (1)
frontend/pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (7)
frontend/components/wiki/WikiLayout.tsxfrontend/components/wiki/WikiNavigation.tsxfrontend/lib/markdown.tsfrontend/lib/wiki-scroll.tsfrontend/package.jsonfrontend/styles/globals.cssfrontend/styles/wiki.css
Comment on lines
+229
to
+230
| overflow-wrap: break-word; | ||
| word-break: break-word; |
Contributor
There was a problem hiding this comment.
Clear the stylelint failures in these new declarations.
This hunk currently fails stylelint: Line 230 uses deprecated word-break: break-word, and the added declarations at Lines 229, 276, and 293 are missing the blank line the repo enforces.
💡 Minimal fix
@@
.wiki-content {
`@apply` text-foreground;
+
overflow-wrap: break-word;
- word-break: break-word;
}
@@
.wiki-content code {
`@apply` px-2 py-1 rounded text-sm font-mono;
+
overflow-wrap: break-word;
}
@@
.wiki-content table {
`@apply` w-full border-collapse border mb-4;
+
display: block;
overflow-x: auto;
}Also applies to: 276-276, 293-294
🧰 Tools
🪛 Stylelint (17.6.0)
[error] 229-229: Expected empty line before declaration (declaration-empty-line-before)
(declaration-empty-line-before)
[error] 230-230: Unexpected deprecated keyword "break-word" for property "word-break" (declaration-property-value-keyword-no-deprecated)
(declaration-property-value-keyword-no-deprecated)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@frontend/styles/wiki.css` around lines 229 - 230, Remove the deprecated
declaration and fix spacing: delete the `word-break: break-word;` line and
instead ensure a supported rule is present (e.g., use `overflow-wrap: anywhere;`
or keep `overflow-wrap: break-word;` if intentional) in the same rule block, and
add the required blank line before each of the rule blocks that were added (the
blocks containing the declarations at the locations that held
`overflow-wrap`/`word-break` — update the rule blocks where `overflow-wrap` is
set and the other two new blocks referenced) so the file conforms to the repo's
blank-line style.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Bug Fixes