docs: remove special characters

pull/1624/head
Divyansh Singh 2 years ago
parent f4d5417930
commit 12ca9dd3c7

@ -1,6 +1,6 @@
# Frontmatter Configs
Frontmatter enables page based configuration. On every markdown, youre free to add Any settings to override any global app or theme configs. Also, there are configs which you can only define in Frontmatter.
Frontmatter enables page based configuration. On every markdown, you're free to add Any settings to override any global app or theme configs. Also, there are configs which you can only define in Frontmatter.
```yaml
---

@ -11,7 +11,7 @@ editLink: true
Between the triple-dashed lines, you can set [predefined variables](../config/frontmatter-configs), or even create custom ones of your own. These variables can be used via the special <code>$frontmatter</code> variable.
Heres an example of how you could use it in your Markdown file:
Here's an example of how you could use it in your Markdown file:
```md
---

@ -279,7 +279,7 @@ export default {
</ul>
```
A [list of valid languages](https://github.com/shikijs/shiki/blob/main/docs/languages.md) is available on Shikis repository.
A [list of valid languages](https://github.com/shikijs/shiki/blob/main/docs/languages.md) is available on Shiki's repository.
You may also customize syntax highlight theme in app config. Please see [`markdown` options](../config/app-configs#markdown) for more details.
@ -360,7 +360,7 @@ Alternatively, it's possible to highlight directly in the line by using the `//
export default {
data () {
return {
msg: 'Highlighted!' // [!code hl]
msg: 'Highlighted!' // [!code hl]
}
}
}
@ -392,7 +392,7 @@ Additionally, you can define a number of lines to focus using `// [!code focus:<
export default {
data () {
return {
msg: 'Focused!' // [!code focus]
msg: 'Focused!' // [!code focus]
}
}
}
@ -422,8 +422,8 @@ Adding the `// [!code --]` or `// [!code ++]` comments on a line will create a d
export default {
data () {
return {
msg: 'Removed' // [!code --]
msg: 'Added' // [!code ++]
msg: 'Removed' // [!code --]
msg: 'Added' // [!code ++]
}
}
}
@ -454,8 +454,8 @@ Adding the `// [!code warning]` or `// [!code error]` comments on a line will co
export default {
data () {
return {
msg: 'Error', // [!code error]
msg: 'Warning' // [!code warning]
msg: 'Error', // [!code error]
msg: 'Warning' // [!code warning]
}
}
}

@ -129,7 +129,7 @@ Later in your markdown files, the component can be interleaved between the conte
```
::: warning IMPORTANT
Make sure a custom components name either contains a hyphen or is in PascalCase. Otherwise, it will be treated as an inline element and wrapped inside a `<p>` tag, which will lead to hydration mismatch because `<p>` does not allow block elements to be placed inside it.
Make sure a custom component's name either contains a hyphen or is in PascalCase. Otherwise, it will be treated as an inline element and wrapped inside a `<p>` tag, which will lead to hydration mismatch because `<p>` does not allow block elements to be placed inside it.
:::
### Using Components In Headers <ComponentInHeader />

@ -10,7 +10,7 @@ VitePress is currently in `alpha` status. It is already suitable for out-of-the-
We love VuePress v1, but being built on top of Webpack, the time it takes to spin up the dev server for a simple doc site with a few pages is just becoming unbearable. Even HMR updates can take up to seconds to reflect in the browser!
Fundamentally, this is because VuePress v1 is a Webpack app under the hood. Even with just two pages, it's a full on Webpack project (including all the theme source files) being compiled. It gets even worse when the project has many pages every page must first be fully compiled before the server can even display anything!
Fundamentally, this is because VuePress v1 is a Webpack app under the hood. Even with just two pages, it's a full on Webpack project (including all the theme source files) being compiled. It gets even worse when the project has many pages - every page must first be fully compiled before the server can even display anything!
Incidentally, Vite solves these problems really well: nearly instant server start, an on-demand compilation that only compiles the page being served, and lightning-fast HMR. Plus, there are a few additional design issues I have noted in VuePress v1 over time but never had the time to fix due to the amount of refactoring it would require.
@ -22,9 +22,9 @@ There're couple of things that are improved from VuePress v1....
### It uses Vue 3
Leverages Vue 3's improved template static analysis to stringify static content as much as possible. Static content is sent as string literals instead of JavaScript render function code the JS payload is therefore much cheaper to parse, and hydration also becomes faster.
Leverages Vue 3's improved template static analysis to stringify static content as much as possible. Static content is sent as string literals instead of JavaScript render function code - the JS payload is therefore much cheaper to parse, and hydration also becomes faster.
Note the optimization is applied while still allowing the user to freely mix Vue components inside markdown content the compiler does the static/dynamic separation for you automatically and you never need to think about it.
Note the optimization is applied while still allowing the user to freely mix Vue components inside markdown content - the compiler does the static/dynamic separation for you automatically and you never need to think about it.
### It uses Vite under the hood

Loading…
Cancel
Save