Include "dynamic content" list into a page

[tgrall]

Hello,

TLTR;
I would like to include in a page/mdx a list of content based on their "keywords" (or custom attribute}
What is the best way to achieve this?

Content

1. My document site contains various types of content: simple doc, tutorials, simple application
2. I would like to be able to create a component that allows me to include the list of this content in a page.

For example, if I have a page that contains content about "Java Development", I would like to add a dynamic list to show "all the java tutorials", same for "python tutorials" and a generic page that shows "all tutorials"

what is the best way to achieve this?

[slorber]

Do you mean a tagging system?
For example here's the page of a blog tag: https://v2.docusaurus.io/blog/tags/recap

There's an issue to add this to docs as well:
#3434

[gsdatta]

Old conversation but was of interest. I assume @tgrall is looking for something similar to what gatsby provides https://www.gatsbyjs.com/docs/how-to/querying-data/, i.e. a way to query data about the docs that docusaurus is aware of. Even more powerful when using custom front-matter.

For example, "Give me all docs where front-matter.type == tutorial and front-matter.showInTutorialList == true" could be used to build a custom "Recommended reads" component.

[slorber]

@gsdatta we don't have a query engine or anything like that for now, but I'd like to be able to do something similar (without GraphQL)

[tobiasbueschel]

Adding to this thread, I'm looking for something similar to create dynamic readmes that show:

• List of pages that were added / modified in the last 7 days
• Any open to-dos (i.e. markdown checkbox items that are not marked as completed)

[muuki88]

We are thinking about migrating from Jekyll to docusaurus and are searching for a similar solution.

Our use case is the following. There are couple of different layouts, which identify certain pages. We use this to generate overview pages. Jekyll enables this by having global site.pages variables. The page variable contains the (front matter) meta data.

Here you can see one of those pages:

• https://github.com/prebid/prebid.github.io/blob/5d9377d92983ca176795f705847e7b5a67f9c4fc/download.md?plain=1#L58-L61
• https://github.com/prebid/prebid.github.io/blob/5d9377d92983ca176795f705847e7b5a67f9c4fc/download.md?plain=1#L70-L80

I'm unsure how this would work in docusaurus though. A very naive implementation would be to have access to a site variable, which is generated during build and used through out.

import site from '~/global/site'; // I don't care what the path looks like

# Cool page with MDX

{site.pages
  .filter(page => page.layout === 'foo')
  .forEach(page => (<div>{page.title}</div>)
}

Probably this is invalid MDX, because I have not used it a lot, but you get the gist. The same would be possible in a component of course.

Huge drawback is that we would end up with a possibly gigantic site.js file.

[slorber]

Having a gigantic site.js bundle is not a good idea for Docusaurus.

Unlike Jekyll it has to hydrate React on the frontend and adding too much to the JS will slow down hydration, leading to event listeners being attached with a delay, leading to a confusing ux where buttons wouldn't click.

We have an undocumented allContentLoaded plug-in lifecycle that you could use to pick/format the minimal data you need to inject it into a page. I may refactor the public api later but the feature is unlikely to disappear.

Unfortunately it doesn't allow injecting into an existing page, only create a new page.

React Server Components cous make all this easier and more flexible