feat(theme-classic): allow collapsing part of code blocks

[Josh-Cena]

Motivation

Resolve #2215. I need this because most of the config tutorials on the website contain a lot of boilerplate to provide the context, but collapsing them makes the doc much more concise.

Have you read the Contributing Guidelines on pull requests?

Yes

Test Plan

Preview: https://deploy-preview-5783--docusaurus-2.netlify.app/docs/next/sidebar/#collapsible-categories

TODO

• Collapsing animation (using <Collapsible>)
• Better design (button color; icon; a boundary between collapsible parts and non-collapsible ones)
• Add a config option for default collapsed state?
• Write docs
• More usage on the website

[netlify]

✔️ [V2]
Built without sensitive environment variables

🔨 Explore the source changes: f8e226c

🔍 Inspect the deploy log: https://app.netlify.com/sites/docusaurus-2/deploys/61e6d2471d5f19000896cbaf

😎 Browse the preview: https://deploy-preview-5783--docusaurus-2.netlify.app

[github-actions]

⚡️ Lighthouse report for the changes in this PR:

Category	Score
🟠 Performance	87
🟢 Accessibility	98
🟢 Best practices	93
🟢 SEO	100
🟢 PWA	92

Lighthouse ran on https://deploy-preview-5783--docusaurus-2.netlify.app/

[slorber]

I find this feature interesting and we could definitively use something like this, but it's probably not so easy to get right, and not a high priority either

Some concerns:

• Does it really need to be in core? Maybe we can instead think of a more generic API so that users can build this kind of feature in userland, inventing their own markers? => smaller and more flexible API surface => less to maintain

• Inability to mix top-level highlight with sample markers

• Current UX is unable to contain multiple samples. GitHub diff/PR UX may be better?

• How does it work with progressive enhancement in mind and JS disabled? (may not matter much, as the meat of the content remains available)

[slorber]

wonder if sample is the best marker name? 🤔

[Josh-Cena]

This is directly from the Kotlin docs example in #2215: // sampleStart in that case. We can certainly bikeshed about this, and if we are to just build a generic API, maybe even no bikeshedding at all :D

[Josh-Cena]

Does it really need to be in core? Maybe we can instead think of a more generic API so that users can build this kind of feature in userland, inventing their own markers? => smaller and more flexible API surface => less to maintain

Sure, now we are back to the question of allowing more markers 👍 I'll look into making parseLines more generic & extensible.

[Josh-Cena]

Now that #7178 is merged, I will be closing this, because I feel like this is better implemented in userland, since different people will have ideas about different UX with such complicated feature. The linked issue will be closed as well.

cc @hamza1311 I know Yew will benefit from this, but feel free to swizzle CodeBlock and port the changes in this PR there.