-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
feat(search): add runtime support for DocSearch v4 #11327
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
Conversation
✅ [V2]
To edit notification comments on pull requests, go to your Netlify project configuration. |
⚡️ Lighthouse report for the deploy preview of this PR
|
|
No dependency changes detected. Learn more about Socket for GitHub. 👍 No dependency changes detected in pull request |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR
I'm ok to help dogfood DocSearch v4 on Docusaurus v3.x, because it looks mostly retrocompatible in terms of API, and probably not too disruptive in terms of UX
But:
-
DocSearch v4 is still in beta, and I'm seeing it being still actively worked on. We can't prevent our users from upgrading to the latest Docusaurus v3.x release due to changes you make that affect us. It would be preferable to either wait for your GA release, or to keep retrocompatibility with DocSearch v3 and let users upgrade on their own term (we can eventually let newly initialized Docusaurus sites use DocSearch v4 by default)
-
Do you guarantee that there will be no more breaking change in DocSearch v4 that could annoy Docusaurus users if they upgrade their dependencies in the future?
-
There are a few things like labels and disruptive design changes that are currently not retro-compatible, making it difficult to merge this for Docusaurus v3 because this would force Docusaurus v3 users to upgrade DocSearch if they upgrade to our latest v3. I want to derisk and let users choose.
To me, the most disruptive design/UX change you include in DocSearch v4 is the larger search bar button. If we merge this PR as is, this is going to affect many sites upgrading to the latest Docusaurus v3.x release, in particular the layout of the navbar.
For example, the React Native website would have its title elipsed for some screen sizes, and that doesn't look good.
Many Docusaurus sites have crowded navbars where labels and items have been optimized to avoid that. We don't want all these sites to have to write custom CSS if they upgrade to our latest minor release.
Including us, cf what reports our visual regression testing tool doesn't look good for the default viewport size:
Considering the placeholder remains "Search" (and I'm not sure we want to change it, even for Docusauus v4), I see no reason to have such a large search bar button, and would prefer to revert to the DocSearch v3 size.
In general, we advertise our minor version releases to be seamless upgrades. Some users upgrade without even looking at our release notes, that should not contain any migration instructions.
The design changes coming with DocSearch v4 are significant enough to disrupt existing sites, that may inadvertently ship DocSearch v4 to production without knowing, and then being disappointed that their CSS customizations and theming doesn't look that good. We want to avoid that, that's why I'd prefer to keep DocSearch v3 retrocompatibility. Or we'll have to wait for Docusaurus v4.
packages/docusaurus-theme-search-algolia/src/theme/SearchBar/index.tsx
Outdated
Show resolved
Hide resolved
packages/docusaurus-theme-search-algolia/src/theme/SearchBar/index.tsx
Outdated
Show resolved
Hide resolved
packages/docusaurus-theme-search-algolia/src/theme/SearchBar/index.tsx
Outdated
Show resolved
Hide resolved
packages/docusaurus-theme-search-algolia/src/theme/SearchBar/index.tsx
Outdated
Show resolved
Hide resolved
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
|
Thanks for the detailed feedback 🙏 TLDR: this PR no longer forces anyone onto DocSearch v4, keeps the v3 look-and-feel, and gates every v4-only feature behind a version check. Docusaurus v3 users can safely upgrade. What changed since your review
On future breaking changesI can’t promise we will never tweak the v4 beta–we are still working on some accessibility fixes, but:
Happy to tweak anything else you’d like, but I think this addresses the retrofit + UX concerns you raised. |
packages/docusaurus-theme-search-algolia/src/theme/SearchBar/index.tsx
Outdated
Show resolved
Hide resolved
packages/docusaurus-theme-search-algolia/src/theme/SearchBar/index.tsx
Outdated
Show resolved
Hide resolved
packages/docusaurus-theme-search-algolia/src/theme/SearchBar/index.tsx
Outdated
Show resolved
Hide resolved
packages/docusaurus-theme-search-algolia/src/theme/SearchBar/index.tsx
Outdated
Show resolved
Hide resolved
packages/docusaurus-theme-search-algolia/src/theme/SearchBar/index.tsx
Outdated
Show resolved
Hide resolved
packages/docusaurus-theme-search-algolia/src/theme/SearchTranslations/index.ts
Show resolved
Hide resolved
|
Thanks again for the review. All relevant fixes are in this commit: |
099d1b4 to
b7c60c5
Compare
|
Thanks, it seems to work. Just want to report a few issues:
This won't block the current PR, though, and I'll merge the PR asap. |
|
Hmmm, no, doesn't work yet 😅:
|
Sorry about that! We wanted to keep it backwards compatible and just mark it as deprecated for a case such as this 😅 |
|
Thanks! There's also something else that our CI caught (unfortunately, it can't post a comment on external PRs but can be seen on this job) Upgrading Algolia to support AskAI makes our main bundle 325 kb heavier (minimized and tree-shaken), that's a lot just for this feature:
We are importing the modal with dynamic imports: Can you check your dependency graph to ensure this doesn't happen? It's a bit annoying for us if users upgrade to DocSearch v4 and their site becomes +39% heavier. Since this is the main bundle, this will also delay React hydration and lower the Lighthouse scores. I'm fine if the heavy things are lazy loaded on button hover/click, but paying the cost upfront is a bit too much 😅, and it will be the case even if users don't enable AskAI. |
|
Thanks for the flag @slorber Optimization is on our roadmap. We'll work towards that too. We just released v4.0.1 which should fix all the issues you mentioned in the previous comment. |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR is ready to merge 🥳
However there's a twist
Due to a 300+kb main bundle size increase, we are going to support DocSearch v4 at runtime, but won't use DocSearch v4 by default until that issue is solved.
The cost is too high, and it affects sites that do not even use the new Ask AI feature.
For that reason, and until it is fixed, those willing to use DocSearch v4 on their site will need to use a package manager resolution config:
{
"overrides": {
"@docsearch/react": "^4.0.0"
}
}{
"resolutions": {
"@docsearch/react": "^4.0.0"
}
}Other package managers may provide similar package resolution features (for example: pnpm overrides overrides) and Yarn v2+ CLI)
Docusaurus v3 will be compatible with both DocSearch v3/v4.
We are also going to run DocSearch v4 on our production website docusaurus.io, to dogfood the new DocSearch / Ask AI feature, and ensure the compatibility does not break.
Should you use DocSearch v4?
If you want to use DocSearch v4 / Ask AI now, you can with an opt-in bundler config, but keep in mind this will increase your main bundle size and potentially slow down the initial load time and React hydration time on all pages of your site.
If you don't plan to use Ask AI, we recommend continuing to use DocSearch v3, and not paying the bundle size increase cost.
In the future, we should be able to optimize that so that the 300+kb are code-split to a separate lazy-loaded bundle. Read the upcoming v3.9 blog post to know what the final tradeoff will be when this feature appears in a stable version of Docusaurus.
Edit: the optimization will be ready for Docusaurus v3.9, see follow-up PR here: #11421
|
The bundle size issue should be fixed in #11421 |

IMPORTANT
@slorber: This PR adds runtime support for DocSearch v4, but does not upgrade to DocSearch v4.
If you want to use DocSearch v4, make sure to read this comment: #11327 (review)
And check this follow-up PR: #11421
Motivation
10 years of DocSearch!
It’s been a decade since DocSearch was launched, empowering millions of developers to find documentation faster and more intuitively.
5 years since DocSearch v3:
After half a decade of feedback and innovation, we’re excited to unveil the next major leap.
This PR updates DocSearch to its latest version (v4) and introduces the Ask AI feature, reflecting our vision for the next generation of documentation search. Our goal is to provide a more powerful, accessible, and intelligent search experience for your users.
Ask AI is completely optional and never enabled by default. DocSearch v4 can be used independently of Ask AI, giving you full control over your integration.
What is included in this PR
askAipropTest Plan
Try the new search experience by clicking the search button or using the keyboard shortcut (
Cmd + KorCtrl + K).Features
DocSearch v4
Ask AI
References