Ignore anchor with h1/lvl1
- Dominant language
- TypeScript
- Stars
- 4.4k
- Forks
- 439
- Avg merge
- 14h 32m
- Merged PRs (30d)
- 19
Description
## Description
https://docsearch.algolia.com/docs/tips/#add-anchors-to-headings and https://docsearch.algolia.com/docs/required-configuration/#use-the-right-classes-as-recordprops makes a lot of sense for h2,h3,h4, etc.
However, I believe that it's harmful to h1. e.g. https://docusaurus.io/ doesn't have an anchor. The value is so that people get a cleaner URL when they copy and paste it to share after a search, which happens quite often in my use cases.
I had to add this code so that the crawler won't pick up an anchor for the lvl1.
```diff
recordExtractor: ({ $, helpers, url }) => {
// Removing DOM elements we don't want to crawl
const toRemove = ".skip-algolia-crawler";
$(toRemove).remove();
+ $("#main-content, #__next").removeAttr("id");
```
## Steps to reproduce
I could reproduce on: https://mui.com/material-ui/react-alert/ with https://crawler.algolia.com/admin/crawlers/739c29c8-99ea-4945-bd27-17a1df391902/configuration/edit.
I get this URL: https://mui.com/material-ui/react-alert/#main-content.
## Expected behavior
`helpers.docsearch` doesn't try to find an anchor for h1.
I would get this URL: https://mui.com/material-ui/react-alert/.
## Environment
- DocSearch version: v3
Contributor guide
Research direction
Start with the helpers.docsearch anchor extraction behavior in DocSearch v3 and reproduce the reported case on https://mui.com/material-ui/react-alert/. Check how h1/lvl1 headings produce #main-content, then verify that the completed behavior leaves the page URL without an anchor while preserving anchors for lower-level headings.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- search
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100