Show table of contents on pages with toc: true - #232
Conversation
Render the TableOfContents sidebar for content pages (achievements, history, current) and documentation pages when their frontmatter has toc: true, matching the blog article behavior.
There was a problem hiding this comment.
Pull request overview
This PR restores Table of Contents rendering for non-blog Markdown pages by introducing a shared layout component that mirrors the existing blog TOC UX, and wiring it into several top-level pages plus all documentation detail pages.
Changes:
- Added
ContentWithToccomponent andshouldShowTochelper to conditionally render a responsive TOC layout based on frontmattertoc: true. - Updated
/achievements,/history,/currentpages to use the shared TOC-capable renderer. - Updated documentation detail pages (
/documentation/[doc]) to use the shared TOC-capable renderer and widened the layout container to accommodate the sidebar.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| components/content-with-toc.tsx | New shared wrapper that renders TableOfContents + MarkdownRenderer when toc: true. |
| app/achievements/page.tsx | Switched to ContentWithToc and widened container to support a TOC sidebar. |
| app/history/page.tsx | Switched to ContentWithToc and widened container to support a TOC sidebar. |
| app/current/page.tsx | Switched to ContentWithToc and widened container to support a TOC sidebar. |
| app/documentation/[doc]/page.tsx | Switched doc detail rendering to ContentWithToc and widened container to support a TOC sidebar. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| <div className="lg:hidden w-full"> | ||
| <TableOfContents content={content} /> | ||
| </div> | ||
| <div className="w-full lg:flex-1 lg:min-w-0"> | ||
| <MarkdownRenderer content={content} showMeta={showMeta} noCard={noCard} /> |
|
Thanks for the PR. It seems that you have activated TOC support only for the 3 sub-pages of "About Us" and the pages in the |
|
Makes sense, thank you! I'll update the PR. |
…down pages - Extend TableOfContents to extract raw HTML headings (<hN id=...>) with explicit ids, falling back to github-slugger for id-less HTML headings. Reconstructs inline-split headings inside lists/paragraphs (doc 02 pattern). - Wire ContentWithToc into all remaining markdown-driven pages (21 files). GSoC project pages already rendered TableOfContents, no change needed. Now all 8 pages with toc: true (achievements, history, current, 5 docs) show complete TOCs matching rendered heading ids; existing anchor links recover.
|
Another question: Why do you need to modify so many files? Is there no way to set a global default for the whole site? And if I add a new page, will it automatically support a ToC? Or do I need to modify an additional file |
|
Each route in app/ independently reads its markdown and chooses its renderer, there's no shared base layout for markdown pages. The 22 changes wire ContentWithToc into every existing page that renders markdown bodies. And the new pages: They won't auto-get ToC. You'll need to import ContentWithToc in the new page file (3 lines: import, destructure data, swap renderer). No global default exists today. If you'd like to avoid that boilerplate for future pages, I can add a tiny withToc wrapper helper? |
|
For the blog pages ( OK, the withToc wrapper is perhaps a good idea. @gativarshney @rudra-iitm WDYT is there an easier and cleaner way to let all markdown or HTML pages support a ToC, by just having |
|
Blog posts auto-get ToC because they all share one catch-all route (app/[...slug]/page.tsx). Every other markdown page is a separate route component that explicitly chooses its renderer — no global default exists. The withToc wrapper would shrink new-page boilerplate to one line. Longer-term, a shared MarkdownPage base component (encapsulates matter + ContentWithToc) is the cleanest way to make toc: true just work everywhere without a big refactor. Happy to hear from @gativarshney and @rudra-iitm on the direction. |
|
@tillkamppeter I think the current PR is fine as scoped and fixes #226 for the pages that needed it without changing the pages that already work. For the site-wide question, with the current route structure, "toc: true" alone cannot automatically enable the TOC for every Markdown/HTML page. Blog posts work this way because they all go through the same "[...slug]" route, whereas the other page types have separate route components that choose how their content is rendered. I think "withToc" is a useful middle ground for a follow-up: it would reduce the repeated wiring to a small opt-in step, although it wouldn't make "toc: true" work automatically by itself. A shared "MarkdownPage" abstraction could get closer to the fully automatic behavior for the simpler Markdown pages, but I wouldn't make that part of this fix. Some pages have their own layouts and rendering requirements, so making everything use one abstraction would be a much larger refactor. So my preference would be to keep this PR focused, consider "withToc" as a small follow-up, and revisit a shared Markdown abstraction separately if we want to address the broader duplication. |
|
Thanks, @gativarshney I have merged this PR now. Thanks a lot for your comment. "withToc" and/or "MarkdownPage" can be handled in later PRs. |
Fixes #226.
Pages and documentation articles with
toc: truein their frontmatter no longerdisplay a table of contents, it only worked for blog articles.
ContentWithToccomponent (sticky right sidebar on desktop,"On This Page" box above content on mobile), matching the blog layout.
/achievements,/history,/current, and all documentationpages.
yarn buildpasses.