메인 컨텐츠로 이동
Version: 2.0.0-beta.17

플러그인

플러그인은 도큐사우루스 2 사이트 내에서 기능을 담당하는 구성 요소입니다. 각 플러그인은 개별적인 기능을 가지고 있습니다. Plugins may work and be distributed as part of a bundle via presets.

플러그인 만들기

플러그인은 contextoptions 2개의 파라미터를 가지는 함수입니다. It returns a plugin instance object (or a promise). 플러그인은 함수 또는 모듈로 만들 수 있습니다. For more information, refer to the plugin method references section.

Function definition

도큐사우루스 설정 파일을 아래와 같이 지정하면 플러그인을 함수처럼 사용할 수 있습니다.

docusaurus.config.js
module.exports = {
// ...
plugins: [
async function myPlugin(context, options) {
// ...
return {
name: 'my-plugin',
async loadContent() {
// ...
},
async contentLoaded({content, actions}) {
// ...
},
/* 다른 lifecycle API */
};
},
],
};

모듈 정의

You can use a plugin as a module path referencing a separate file or npm package:

docusaurus.config.js
module.exports = {
// ...
plugins: [
// without options:
'./my-plugin',
// or with options:
['./my-plugin', options],
],
};

Then in the folder my-plugin, you can create an index.js such as this:

my-plugin.js
module.exports = async function myPlugin(context, options) {
// ...
return {
name: 'my-plugin',
async loadContent() {
/* ... */
},
async contentLoaded({content, actions}) {
/* ... */
},
/* 다른 lifecycle API */
};
};

You can view all plugins installed in your site using the debug plugin's metadata panel.

Plugins come as several types:

  • package: an external package you installed
  • project: a plugin you created in your project, given to Docusaurus as a local file path
  • local: a plugin created using the function definition
  • synthetic: a "fake plugin" Docusaurus created internally, so we take advantage of our modular architecture and don't let the core do much special work. You won't see this in the metadata because it's an implementation detail.

You can access them on the client side with useDocusaurusContext().siteMetadata.pluginVersions.

플러그인 설계

Docusaurus' implementation of the plugins system provides us with a convenient way to hook into the website's lifecycle to modify what goes on during development/build, which involves (but is not limited to) extending the webpack config, modifying the data loaded, and creating new components to be used in a page.

테마 설계

When plugins have loaded their content, the data is made available to the client side through actions like createData + addRoute or setGlobalData. This data has to be serialized to plain strings, because plugins and themes run in different environments. Once the data arrives on the client side, the rest becomes familiar to React developers: data is passed along components, components are bundled with Webpack, and rendered to the window through ReactDOM.render...

Themes provide the set of UI components to render 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, which makes swapping designs easy.

For example, a Docusaurus blog may consist of a blog plugin and a blog theme.

note

This is a contrived example: in practice, @docusaurus/theme-classic provides the theme for docs, blog, and layouts.

docusaurus.config.js
module.exports = {
themes: ['theme-blog'],
plugins: ['plugin-content-blog'],
};

And if you want to use Bootstrap styling, you can swap out the theme with theme-blog-bootstrap (another fictitious non-existing theme):

docusaurus.config.js
module.exports = {
themes: ['theme-blog-bootstrap'],
plugins: ['plugin-content-blog'],
};

Now, although the theme receives the same data from the plugin, how the theme chooses to render the data as UI can be drastically different.

While themes share the exact same lifecycle methods with plugins, themes' implementations can look very different from those of plugins based on themes' designed objectives.

테마는 여러분이 도큐사우루스 사이트를 빌드하고 사이트, 플러그인, 테마 자신이 사용할 수 있는 컴포넌트를 공급하도록 설계됩니다. A theme still acts like a plugin and exposes some lifecycle methods, but most likely they would not use loadContent, since they only receive data from plugins, but don't generate data themselves; themes are typically also accompanied by an src/theme directory full of components, which are made known to the core through the getThemePath lifecycle.

다시 정리하면

  • 테마는 플러그인과 같은 lifecycle 메소드를 공유합니다.
  • 테마는 모든 플러그인이 설정된 이후 동작합니다.
  • Themes add component aliases by providing getThemePath.