Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Another way to use vue components in markdown file #3906

Closed
4 tasks done
tangxiangmin opened this issue May 20, 2024 · 1 comment
Closed
4 tasks done

Another way to use vue components in markdown file #3906

tangxiangmin opened this issue May 20, 2024 · 1 comment

Comments

@tangxiangmin
Copy link

tangxiangmin commented May 20, 2024

Is your feature request related to a problem? Please describe.

Vitepress by default allows the use of Vue components within markdown files, as referenced in the documentation: Using Vue in Markdown.

This is particularly useful, especially in the documentation for frontend developers.

The only downside is that the imported components need to be managed separately in their own files:

<script setup>
import CustomComponent from '../../components/CustomComponent.vue'
</script>

For example, in the code above, you need to manually manage these external components. The general process might be to create a components directory and then implement the CustomComponent.vue component within it.

If this component is used in most markdown files, this approach is quite normal.

However, when setting up my own blog site using Vitepress, I found that certain components in the markdown files are often closely related to the context in which they are inserted within the document. They are used to demonstrate specific content of that document.

For components with this purpose, placing them in separate files and then importing and registering them through script setup doesn't seem to be a good practice: when reading the component content alone, the context from the markdown document might be lost.

For a blog with a rather disorganized categorization, it seems there needs to be a better way to manage these external components.

Describe the solution you'd like

I want to extend an inline vue block syntax that allows you to write components directly in markdown as SFC blocks, eliminating the need to manually manage external component files and import them.

When writing a standard Vue code block, you typically use the following syntax:

```vue
<template>
  <button>Original code</button>
</template>
```

The inline Vue component is enabled based on the vue code block by configuring the 'Component' field to true with a JSON string

```vue { "component": true } 
<script setup lang="ts">
import { add } from './util'
const onClick = ()=>{
    alert("click me")
}
</script>

<template>
  <button class="bg-red-100" @click="onClick">click me</button>
</template>

<style scoped>
button {
    color: red;
}
</style>
```

The above '{"component": true}' will extend the vue code block to build a vue SFC component running in markdown using the vite plugin, without any external files.

Inline components are identical to individually created SFC files and can access the current development environment, such as ts, unocss, other components, or tool modules.

Describe alternatives you've considered

No response

Additional context

I wrote a vite plugin to implement it, and now the code is running in my blog, sourcecode and document.

the options list

  • component: boolean, open inline component render
  • name: string, reuse this sfc block in current markdown file by the component name
  • lazy: boolean, lazy render the sfc block when manual <xxxComponentName />

What I want to discuss is

  • whether this feature is necessary or not.
  • If so, Whether the main branch can provide this feature

Validations

@tangxiangmin
Copy link
Author

I wrote a separate vite plugin: vite-plugin-vitepres-inline-sfc.

I hope will help people with this need.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant