mirror of
https://github.com/facebook/docusaurus.git
synced 2025-04-28 17:57:48 +02:00
334 lines
14 KiB
Text
334 lines
14 KiB
Text
---
|
|
description: Customize your site's appearance through creating your own theme components
|
|
---
|
|
|
|
# Swizzling
|
|
|
|
In this section, we will introduce how customization of layout is done in Docusaurus.
|
|
|
|
> Déjà vu...?
|
|
|
|
This section is similar to [Styling and Layout](./styling-layout.mdx), but this time, we will customize React components themselves, rather than what they look like. We will talk about a central concept in Docusaurus: **swizzling**, which allows **deeper site customizations**.
|
|
|
|
In practice, swizzling permits to **swap a theme component with your own implementation**, and it comes in 2 patterns:
|
|
|
|
- [**Ejecting**](#ejecting): creates a **copy** of the original theme component, which you can fully **customize**
|
|
- [**Wrapping**](#wrapping): creates a **wrapper** around the original theme component, which you can **enhance**
|
|
|
|
<details>
|
|
|
|
<summary>Why is it called swizzling?</summary>
|
|
|
|
**The name comes from Objective-C and Swift-UI**: [method swizzling](https://pspdfkit.com/blog/2019/swizzling-in-swift/) is the process of changing the implementation of an existing selector (method).
|
|
|
|
**For Docusaurus, component swizzling means providing an alternative component that takes precedence over the component provided by the theme.**
|
|
|
|
You can think of it as [Monkey Patching](https://en.wikipedia.org/wiki/Monkey_patch) for React components, enabling you to override the default implementation. Gatsby has a similar concept called [theme shadowing](https://www.gatsbyjs.com/docs/how-to/plugins-and-themes/shadowing/).
|
|
|
|
To gain a deeper understanding of this, you have to understand [how theme components are resolved](./advanced/client.mdx#theme-aliases).
|
|
|
|
</details>
|
|
|
|
## Swizzling Process
|
|
|
|
### Overview
|
|
|
|
Docusaurus provides a convenient **interactive CLI** to swizzle components. You generally only need to remember the following command:
|
|
|
|
```bash npm2yarn
|
|
npm run swizzle
|
|
```
|
|
|
|
It will generate a new component in your `src/theme` directory, which should look like this example:
|
|
|
|
```mdx-code-block
|
|
<Tabs>
|
|
<TabItem value="Ejecting">
|
|
```
|
|
|
|
```jsx title="src/theme/SomeComponent.js"
|
|
import React from 'react';
|
|
|
|
export default function SomeComponent(props) {
|
|
// You can fully customize this implementation
|
|
// including changing the JSX, CSS and React hooks
|
|
return (
|
|
<div className="some-class">
|
|
<h1>Some Component</h1>
|
|
<p>Some component implementation details</p>
|
|
</div>
|
|
);
|
|
}
|
|
```
|
|
|
|
```mdx-code-block
|
|
</TabItem>
|
|
<TabItem value="Wrapping">
|
|
```
|
|
|
|
```jsx title="src/theme/SomeComponent.js"
|
|
import React from 'react';
|
|
import SomeComponent from '@theme-original/SomeComponent';
|
|
|
|
export default function SomeComponentWrapper(props) {
|
|
// You can enhance the original component,
|
|
// including adding extra props or JSX elements around it
|
|
return (
|
|
<>
|
|
<SomeComponent {...props} />
|
|
</>
|
|
);
|
|
}
|
|
```
|
|
|
|
```mdx-code-block
|
|
</TabItem>
|
|
</Tabs>
|
|
```
|
|
|
|
To get an overview of all the themes and components available to swizzle, run:
|
|
|
|
```bash npm2yarn
|
|
npm run swizzle -- --list
|
|
```
|
|
|
|
Use `--help` to see all available CLI options, or refer to the reference [swizzle CLI documentation](./cli.mdx#docusaurus-swizzle).
|
|
|
|
:::tip Removing Unneeded Swizzled Components
|
|
|
|
If you decide that a previously swizzled component is no longer necessary, you can simply remove its file(s) from the `src/theme` directory. After removing the component, make sure to restart your development server to ensure the changes are properly reflected.
|
|
|
|
:::
|
|
|
|
:::note
|
|
|
|
After swizzling a component, **restart your dev server** in order for Docusaurus to know about the new component.
|
|
|
|
:::
|
|
|
|
:::warning Prefer staying on the safe side
|
|
|
|
Be sure to understand [which components are **safe to swizzle**](#what-is-safe-to-swizzle). Some components are **internal implementation details** of a theme.
|
|
|
|
:::
|
|
|
|
:::info
|
|
|
|
`docusaurus swizzle` is only an automated way to help you swizzle the component. You can also create the `src/theme/SomeComponent.js` file manually, and Docusaurus will [resolve it](./advanced/client.mdx#theme-aliases). There's no internal magic behind this command!
|
|
|
|
:::
|
|
|
|
### Ejecting {#ejecting}
|
|
|
|
Ejecting a theme component is the process of **creating a copy** of the original theme component, which you can **fully customize and override**.
|
|
|
|
To eject a theme component, use the swizzle CLI interactively, or with the `--eject` option:
|
|
|
|
```bash npm2yarn
|
|
npm run swizzle [theme name] [component name] -- --eject
|
|
```
|
|
|
|
An example:
|
|
|
|
```bash npm2yarn
|
|
npm run swizzle @docusaurus/theme-classic Footer -- --eject
|
|
```
|
|
|
|
This will copy the current `<Footer />` component's implementation to your site's `src/theme` directory. Docusaurus will now use this `<Footer>` component copy instead of the original one. You are now free to completely re-implement the `<Footer>` component.
|
|
|
|
```jsx title="src/theme/Footer/index.js"
|
|
import React from 'react';
|
|
|
|
export default function Footer(props) {
|
|
return (
|
|
<footer>
|
|
<h1>This is my custom site footer</h1>
|
|
<p>And it is very different from the original</p>
|
|
</footer>
|
|
);
|
|
}
|
|
```
|
|
|
|
:::warning
|
|
|
|
Ejecting an [**unsafe**](#what-is-safe-to-swizzle) component can sometimes lead to copying a large amount of internal code, which you now have to maintain yourself. It can make Docusaurus upgrades more difficult, as you will need to migrate your customizations if the props received or internal theme APIs used have changed.
|
|
|
|
**Prefer [wrapping](#wrapping) whenever possible**: the amount of code to maintain is smaller.
|
|
|
|
:::
|
|
|
|
:::tip Re-swizzling
|
|
|
|
To keep ejected components up-to-date after a Docusaurus upgrade, re-run the eject command and compare the changes with `git diff`. You are also recommended to write a brief comment at the top of the file explaining what changes you have made, so that you could more easily re-apply your changes after re-ejection.
|
|
|
|
:::
|
|
|
|
### Wrapping {#wrapping}
|
|
|
|
Wrapping a theme component is the process of **creating a wrapper** around the original theme component, which you can **enhance**.
|
|
|
|
To wrap a theme component, use the swizzle CLI interactively, or with the `--wrap` option:
|
|
|
|
```bash npm2yarn
|
|
npm run swizzle [theme name] [component name] -- --wrap
|
|
```
|
|
|
|
An example:
|
|
|
|
```bash npm2yarn
|
|
npm run swizzle @docusaurus/theme-classic Footer -- --wrap
|
|
```
|
|
|
|
This will create a wrapper in your site's `src/theme` directory. Docusaurus will now use the `<FooterWrapper>` component instead of the original one. You can now add customizations around the original component.
|
|
|
|
```jsx title="src/theme/Footer/index.js"
|
|
import React from 'react';
|
|
import Footer from '@theme-original/Footer';
|
|
|
|
export default function FooterWrapper(props) {
|
|
return (
|
|
<>
|
|
<section>
|
|
<h2>Extra section</h2>
|
|
<p>This is an extra section that appears above the original footer</p>
|
|
</section>
|
|
<Footer {...props} />
|
|
</>
|
|
);
|
|
}
|
|
```
|
|
|
|
<details>
|
|
<summary>What is this <code>@theme-original</code> thing?</summary>
|
|
|
|
Docusaurus uses [theme aliases](./advanced/client.mdx#theme-aliases) to resolve the theme components to use. The newly created wrapper takes the `@theme/SomeComponent` alias. `@theme-original/SomeComponent` permits to import original component that the wrapper shadows without creating an infinite import loop where the wrapper imports itself.
|
|
|
|
</details>
|
|
|
|
:::tip
|
|
|
|
Wrapping a theme is a great way to **add extra components around existing one** without [ejecting](#ejecting) it. For example, you can easily add a custom comment system under each blog post:
|
|
|
|
```jsx title="src/theme/BlogPostItem.js"
|
|
import React from 'react';
|
|
import BlogPostItem from '@theme-original/BlogPostItem';
|
|
import MyCustomCommentSystem from '@site/src/MyCustomCommentSystem';
|
|
|
|
export default function BlogPostItemWrapper(props) {
|
|
return (
|
|
<>
|
|
<BlogPostItem {...props} />
|
|
<MyCustomCommentSystem />
|
|
</>
|
|
);
|
|
}
|
|
```
|
|
|
|
:::
|
|
|
|
## What is safe to swizzle? {#what-is-safe-to-swizzle}
|
|
|
|
> With great power comes great responsibility
|
|
|
|
Some theme components are **internal implementation details** of a theme. Docusaurus allows you to swizzle them, but it **might be risky**.
|
|
|
|
<details>
|
|
|
|
<summary>Why is it risky?</summary>
|
|
|
|
Theme authors (including us) might have to update their theme over time: changing the component props, name, file system location, types... For example, consider a component that receives two props `name` and `age`, but after a refactor, it now receives a `person` prop with the above two properties. Your component, which still expects these two props, will render `undefined` instead.
|
|
|
|
Moreover, internal components may simply disappear. If a component is called `Sidebar` and it's later renamed to `DocSidebar`, your swizzled component will be completely ignored.
|
|
|
|
**Theme components marked as unsafe may change in a backward-incompatible way between theme minor versions.** When upgrading a theme (or Docusaurus), your customizations might **behave unexpectedly**, and can even **break your site**.
|
|
|
|
</details>
|
|
|
|
For each theme component, the swizzle CLI will indicate **3 different levels of safety** declared by theme authors:
|
|
|
|
- **Safe**: this component is safe to be swizzled, its public API is considered stable, and no breaking changes should happen within a theme **major version**
|
|
- **Unsafe**: this component is a theme implementation detail, not safe to be swizzled, and breaking changes might happen within a theme **minor version**
|
|
- **Forbidden**: the swizzle CLI will prevent you from swizzling this component, because it is not designed to be swizzled at all
|
|
|
|
:::note
|
|
|
|
Some components might be safe to wrap, but not safe to eject.
|
|
|
|
:::
|
|
|
|
:::info
|
|
|
|
Don't be too **afraid to swizzle unsafe components**: just keep in mind that **breaking changes** might happen, and you might need to upgrade your customizations manually on minor version upgrades.
|
|
|
|
:::
|
|
|
|
:::note Report your use-case
|
|
|
|
If you have a **strong use-case for swizzling an unsafe component**, please [**report it here**](https://github.com/facebook/docusaurus/discussions/5468) and we will work together to find a solution to make it safe.
|
|
|
|
:::
|
|
|
|
## Which component should I swizzle? {#which-component-should-i-swizzle}
|
|
|
|
It is not always clear which component you should swizzle exactly to achieve the desired result. `@docusaurus/theme-classic`, which provides most of the theme components, has about [100 components](https://github.com/facebook/docusaurus/tree/main/packages/docusaurus-theme-classic/src/theme)!
|
|
|
|
:::tip
|
|
|
|
To print an overview of all the `@docusaurus/theme-classic` components:
|
|
|
|
```bash npm2yarn
|
|
npm run swizzle @docusaurus/theme-classic -- --list
|
|
```
|
|
|
|
:::
|
|
|
|
You can follow these steps to locate the appropriate component to swizzle:
|
|
|
|
1. **Component description.** Some components provide a short description, which is a good way to find the right one.
|
|
2. **Component name.** Official theme components are semantically named, so you should be able to infer its function from the name. The swizzle CLI allows you to enter part of a component name to narrow down the available choices. For example, if you run `yarn swizzle @docusaurus/theme-classic`, and enter `Doc`, only the docs-related components will be listed.
|
|
3. **Start with a higher-level component.** Components form a tree with some components importing others. Every route will be associated with one top-level component that the route will render (most of them listed in [Routing in content plugins](./advanced/routing.mdx#routing-in-content-plugins)). For example, all blog post pages have `@theme/BlogPostPage` as the topmost component. You can start with swizzling this component, and then go down the component tree to locate the component that renders just what you are targeting. Don't forget to unswizzle the rest by deleting the files after you've found the correct one, so you don't maintain too many components.
|
|
4. **Read the [theme source code](https://github.com/facebook/docusaurus/tree/main/packages/docusaurus-theme-classic/src/theme)** and use search wisely.
|
|
|
|
:::tip Just ask!
|
|
|
|
If you still have no idea which component to swizzle to achieve the desired effect, you can reach out for help in one of our [support channels](/community/support).
|
|
|
|
We also want to understand better your fanciest customization use-cases, so please [**report them**](https://github.com/facebook/docusaurus/discussions/5468).
|
|
|
|
:::
|
|
|
|
## Do I need to swizzle? {#do-i-need-to-swizzle}
|
|
|
|
Swizzling ultimately means you have to maintain some additional React code that interact with Docusaurus internal APIs. If you can, think about the following alternatives when customizing your site:
|
|
|
|
1. **Use CSS.** CSS rules and selectors can often help you achieve a decent degree of customization. Refer to [styling and layout](./styling-layout.mdx) for more details.
|
|
2. **Use translations.** It may sound surprising, but translations are ultimately just a way to customize the text labels. For example, if your site's default language is `en`, you can still run `yarn write-translations -l en` and edit the `code.json` emitted. Refer to the [i18n tutorial](./i18n/i18n-tutorial.mdx) for more details.
|
|
|
|
:::tip
|
|
|
|
**The smaller, the better.** If swizzling is inevitable, prefer to swizzle only the relevant part and maintain as little code on your own as possible. Swizzling a small component often means less risk of **breaking changes** during upgrade.
|
|
|
|
[Wrapping](#wrapping) is also a far safer alternative to [ejecting](#ejecting).
|
|
|
|
:::
|
|
|
|
## Wrapping your site with `<Root>` {#wrapper-your-site-with-root}
|
|
|
|
The `<Root>` component is rendered at the **very top** of the React tree, above the theme `<Layout>`, and **never unmounts**. It is the perfect place to add stateful logic that should not be re-initialized across navigations (user authentication status, shopping cart state...).
|
|
|
|
Swizzle it **manually** by creating a file at `src/theme/Root.js`:
|
|
|
|
```js title="src/theme/Root.js"
|
|
import React from 'react';
|
|
|
|
// Default implementation, that you can customize
|
|
export default function Root({children}) {
|
|
return <>{children}</>;
|
|
}
|
|
```
|
|
|
|
:::tip
|
|
|
|
Use this component to render React Context providers.
|
|
|
|
:::
|