facebook / facebook/docusaurus

RFC: allow routes to declare a React context

Open
#6,885 2 comments 1 reaction 0 assignees View on GitHub
domain: content plugin proposal
Dominant language
TypeScript
Stars
66.2k
Forks
10k
Avg merge
1d 3h
Merged PRs (30d)
52

Description

### Have you read the Contributing Guidelines on issues?

- [X] I have read the [Contributing Guidelines on issues](https://github.com/facebook/docusaurus/blob/main/CONTRIBUTING.md#reporting-new-issues).

### Motivation

It is convenient to be able to access page metadata as a hook, from anywhere in the tree, without any props drilling.

Some use-cases:
- @roydukkey implemented a `useFrontMatter()` hook in https://github.com/roydukkey/docusaurus-theme-frontmatter
- @Josh-Cena add a doc metadata banner to some docs, but it's a bit boilerplate: https://github.com/Josh-Cena/Josh-Cena.github.io/blob/04ba69169f6181bd623185bb8f9be1070a6fdb4c/src/components/DocMetadataBanner.tsx
- See also discussion: https://github.com/facebook/docusaurus/discussions/5468#discussioncomment-2238465

I think it could make sense to have a more generic Docusaurus core API to provide an official route context feature?

```js
addRoute({
path: "/docs/",
component: "DocVersion",
context: {sidebars}, // Something here
routes: [
addRoute({
path: "/docs/",
component: "DocItem",
context: {docMetadata}, // Something here
}}
],
}}
```

We could expose a generic `useRouteContext(): unknown`, and content plugins could expose consuming hooks to read it in a typesafe way.

If the route has multiple layers like above, we could merge the context (similar to MDXProvider components), eventually throw an error if some key is overridden.

This also means that we could remove the regular props from the existing layout components: now all the static data can always be read from the context hooks (apart from the dynamic props related to the UI state)

IMHO having "props-less" theme components also present some advantages. It would notably allow more flexibility to refactor theme components without any props breaking change.

Using context hooks also helps clarify the API surface to the context, and provides an additional layer for us to try to provide retro compatible changes in case the underlying data structures need to be updated.

---

I wonder what you think of this idea?

Of course, it would be a quite significant breaking change for users that have a lot of swizzled components, as props would have to be replaced by hooks calls in many places.

### Self-service

- [X] I'd be willing to do some initial work on this proposal myself.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.