extend blog prevItem/nextItem metadata

[pondorasti]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Description

Extend the metadata that is passed to blog paginator buttons.

Has this been requested on Canny?

Not that I'm aware of.

Motivation

As part of my custom blog implementation, I would like to add more context to the paginator buttons for blogs. These includes, but is not limited to authors and date.

API design

Considering that the stock UI of the paginator buttons only requires title and permalink, I think it would make sense to allow developers to extend the metadata of each blog using a generator function. This way, a developer can choose the props they need and then swizzle the paginator component to update the UI.

plugins: [
    [
      '@docusaurus/plugin-content-blog',
      {
          metadataGenerator({
              defaultMetadataGenerator,
              content
          }) {}
      },
   ],
]
      

I'm not that familiar with the docusaurus codebase, but I assume another factor to keep in mind is to find a solution that generalizes nicely to the docs plugin too?

---

An alternative solution, that I've already implemented is to extend the metadata directly in the plugin internals, which would give developers the flexibility to do more structural changes when swizzling.

Have you tried building it?

I've made a minimal fork that updates loadContent() from docusaurus-plugin-content-blog to pass additional metadata to prevItem/nextItem props.

Again, this is just a quick POC and I'm open to solutions that handle the problem in a more generic way.

Self-service

• I'd be willing to contribute this feature to Docusaurus myself.

[slorber]

I understand this need but I don't think we should introduce a metadataGenerator for that. First metadata is kind of a broad term and there are multiple places where we could want to receive extra props, and we can't introduce a generator config function for each of them.

The way we'll solve this is by using React Server Components at build time, allowing you to pick from server components (that you can swizzle) any extra prop you need from the plugin content data structure.

Follow #9089 to track progress (long-term goal, not started).

Let's keep this issue open so that we keep the use case in mind, and expose queries so that it's easy to retrieve data about the next/previous blog post (or respectively doc)

[pondorasti]

Thanks for the detailed explanation @slorber 🙌. I will subscribe to the RSC issue, #9089, and happy to do some experimentation once the direction is more clear.