feat(theme): ability to use <DocCardList> without items prop, on any doc page

[slorber]

Motivation

It's annoying to have to write:

import DocCardList from '@theme/DocCardList';
import {useCurrentSidebarCategory} from '@docusaurus/theme-common';

<DocCardList items={useCurrentSidebarCategory().items}/>

when it could just be:

import DocCardList from '@theme/DocCardList';

<DocCardList />

Also it should be possible to use it on regular docs too, not just category index pages:

items prop is kept for retro compatibility but undocumented. Maybe we'll want to remove it later unless someone comes up with a use-case for it

Test Plan

unit tests + dogfood in our doc

retrocompatible: old docs version still use the items prop + hook

Test links

Deploy preview:

• https://deploy-preview-8008--docusaurus-2.netlify.app/docs/category/guides/
• https://deploy-preview-8008--docusaurus-2.netlify.app/docs/sidebar/
• https://deploy-preview-8008--docusaurus-2.netlify.app/docs/sidebar/items/#embedding-generated-index-in-doc-page

[netlify]

✅ [V2]

Name	Link
🔨 Latest commit	7aed44e
🔍 Latest deploy log	https://app.netlify.com/sites/docusaurus-2/deploys/63079ea29c2de9000713bdf9
😎 Deploy Preview	https://deploy-preview-8008--docusaurus-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[github-actions]

⚡️ Lighthouse report for the deploy preview of this PR

URL	Performance	Accessibility	Best Practices	SEO	PWA	Report
/	🟢 90	🟢 98	🟢 100	🟢 100	🟠 80	Report
/docs/installation	🟠 75	🟢 100	🟢 100	🟢 100	🟢 90	Report

[github-actions]

Size Change: +100 B (0%)

Total Size: 814 kB

Filename	Size	Change
website/build/assets/js/main.********.js	610 kB	+100 B (0%)

ℹ️ View Unchanged

Filename	Size
website/.docusaurus/globalData.json	52.5 kB
website/build/assets/css/styles.********.css	111 kB
website/build/index.html	40.9 kB

_{compressed-size-action}

[Josh-Cena]

This is very nice. I would definitely keep supporting items—from a design perspective, I always prefer using props to context where possible since that makes the dependency explicit. Keeping it means the component may be used as a pure design system component instead of being coupled to any context.

[slorber]

This is very nice. I would definitely keep supporting items—from a design perspective, I always prefer using props to context where possible since that makes the dependency explicit. Keeping it means the component may be used as a pure design system component instead of being coupled to any context.

yes I'm fine to keep it! although not sure in which case you'd want to use it, curious to know ;)

[Josh-Cena]

Maybe for example, filtering some items or pushing more items?