New plugin for classic theme hooks

[fanny]

💥 Proposal

Context

A few days ago, I started to build another theme to docusaurus, since we already have a good separation of concerns, I didn't have many problems to develop my components using the data provided by the @docusaurus/plugin-content-blog(Until now, I only created the blog components). This week I'm working in layout components, like: footer, navbar and etc. and because this, I needed to use some data provided by our classic theme custom hooks.

So, What I Did? I copied-paste the classic theme hooks to my bootstrap theme, we know that isn't sustainable and scalable copy-paste the classic theme hooks, but before I refactor anything, I want to know which things are considered advantages in this model, beyond the fact of the isolation for the classic module, and also get feedback about my ideas.

Design proposed

From our doc, we say:

"Themes are for providing UI components to present the content. Most content plugins need to be paired with a theme in order to be actually useful. The UI is a separate layer from the data schema, so it makes it easy to swap out the themes for other designs (i.e., Bootstrap)."

I loved this description, and yes, it's true, for contents, like, blog, docs, or things related to pages, we can use @docusaurus/plugin-content-docs, or @docusaurus/plugin-content-blog. My point here is: is it possible to reply the same for the layout things, like, scroll, tab group, logo and etc.. if you take a look in the hooks you'll see this:

---

| useHideableNavbar.js
  | useLocationHash.js
  | useLockBodyScroll.js
  | useLogo.js
  | useTOCHighlight.js
  | useTabGroupChoice.js
  | useTabGroupChoiceContext.js
  | useTheme.js
  | useThemeContext.js

Why not expose these data across all theme sources using our plugin system?

Something like @docusaurus/plugin-theme-layout-hooks or @docusaurus/plugin-content-theme

The content of the hooks, don't have the goal to be modified but shared with all themes, that
perhaps we will use.

DISCLAIMER: If this would be accepted, and can be more complex than expected, we probably would like to make the things in an incremental and focused way. But from what I saw, the only module that has a dependency with the hooks, is the classic theme.

Have you read the Contributing Guidelines on issues?

yep

[yangshun]

Why close this? I agree with this issue. Not all the hooks are generic enough to be shared though, e.g the theme ones which are only useful for a CSS framework supporting dark mode.

[fanny]

It's because i'm not certain if is really necessary, for example, studying more about bootstrap, they already have some built-in functions that i can use, instead of our hooks. And thinking in other user builtin themes, maybe they also want to build your own logic

[fanny]

Thinking in the architecture, I'm wondering whats the best place to put this plugin. Current, the plugin abstraction has the responsibility to provide the data for our components, right? But we do this based on some route(from what I saw), for example our docusaurus-plugin-content-docs, provide the data for all docs/* routes, this is what the actions are based on.

The theme plugin doesn't seem adequate for the purpose of this issues, because his semantics of to be created for provide components, although i think that since my goal is a plugin for themes, there's more sense define like a theme and export the getThemePath method, e.g.

But the semantics sounds weird in both cases, I don't know if is good add other module like hooks?
And we'll have
+- Plugins
+- Themes
+- Hooks
encapsulated by the preset. What are some of your ideas?

@lex111, since you contribute a lot in the classic components, I would love to know your opinion

[lex111]

Closing this as it is already implemented.