Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

active matching to multiple sub paths #8018

Open
6 of 7 tasks
juliusmarminge opened this issue Aug 28, 2022 · 4 comments · May be fixed by #8079
Open
6 of 7 tasks

active matching to multiple sub paths #8018

juliusmarminge opened this issue Aug 28, 2022 · 4 comments · May be fixed by #8079
Labels
bug An error in the Docusaurus core causing instability or issues with its execution

Comments

@juliusmarminge
Copy link

Have you read the Contributing Guidelines on issues?

Prerequisites

  • I'm using the latest version of Docusaurus.
  • I have tried the npm run clear or yarn clear command.
  • I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
  • I have tried creating a repro with https://new.docusaurus.io.
  • I have read the console error message carefully (if applicable).

Description

When using versioned docs with explicit paths (v10 docs are at trpc.io/v10/introduction, v9 at trpc.io/v9/introduction etc), every single sub route of /v10 is active matched from the navbar.

We have some items in the navbar that are doc items (introduction, quickstart and usage with next.js) that are all being marked as active when browsing the documentation.

Reproducible demo

https://github.com/trpc/trpc/tree/next/www

Steps to reproduce

  1. Go to
  2. Click on either any of the nav-items
  3. See all of the above being marked active ❌
    CleanShot 2022-08-29 at 00 47 11

Expected behavior

If clicking quickstart, only that should be marked active etc.

Actual behavior

all subroutes under /v10/* or /v9/* is marked active.

Your environment

  • Public source code: https://github.com/trpc/trpc/tree/next/www
  • Public site URL: https://trpc.io
  • Docusaurus version used: 2.0.1
  • Environment name and version (e.g. Chrome 89, Node.js 16.4): Latest Safari, Chrome & Firefox
  • Operating system and version (e.g. Ubuntu 20.04.2 LTS): MacOS 12.5.1

Self-service

  • I'd be willing to fix this bug myself.
@juliusmarminge juliusmarminge added bug An error in the Docusaurus core causing instability or issues with its execution status: needs triage This issue has not been triaged by maintainers labels Aug 28, 2022
@slorber slorber removed the status: needs triage This issue has not been triaged by maintainers label Sep 1, 2022
@slorber
Copy link
Collaborator

slorber commented Sep 1, 2022

Agree there's something weird here.

I think it could be a regression of #7430, or it has always been there (this navbar item may not be used that much, and maybe more often for docs in different sidebars)

CleanShot 2022-09-01 at 11 53 14@2x

If the sidebar of the browsed doc is active, we should add a custom className instead of marking the doc navbar item as active (this is what enables a tab-like navigation, cf the docSidebar item type. But in your case it doesn't make sense to have it here)

@slorber
Copy link
Collaborator

slorber commented Sep 1, 2022

Note: maybe you would want "docs" to remain highlighted when browsing any doc? (ie have a "tab-like" highlighting pattern? 🤷‍♂️ Not having any navbar item highlighted could also be confusing for users, as they don't know in which part of the site they are currently?

@juliusmarminge
Copy link
Author

I think we just want to be able to put a regex pattern on doc-type items too. Currently, if we put a activeBaseRegex on a navbar item with type doc, it doesn't do anything since that isn't being run for those type of items from my understanding.

@juliusmarminge
Copy link
Author

Note: maybe you would want "docs" to remain highlighted when browsing any doc? (ie have a "tab-like" highlighting pattern? 🤷‍♂️ Not having any navbar item highlighted could also be confusing for users, as they don't know in which part of the site they are currently?

That's a solid point. I think for our case (if we could setup our own regex matching) we could have the Docs navitem being highlighted no matter where you are but for the more exact paths (such as Quickstart or Usage with Next.js) we would only want active when you are on that exact page, (i.e. /v(v.*?)/quickstart etc)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An error in the Docusaurus core causing instability or issues with its execution
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants