Apply suggestions from code review

Co-authored-by: skirtle <65301168+skirtles-code@users.noreply.github.com>
Co-authored-by: Jeff Yang <32727188+ydcjeff@users.noreply.github.com>

Author: 3 people

src/api/directives.md

@@ -246,8 +246,8 @@
 - **Modifiers:**
 
   - `.camel` - transform the kebab-case attribute name into camelCase.
-  - `.prop` - force a binding to be set as DOM property. <Badge text="3.2+"/>
-  - `.attr` - force a binding to be set as DOM attribute. <Badge text="3.2+"/>
+  - `.prop` - force a binding to be set as a DOM property. <Badge text="3.2+"/>
+  - `.attr` - force a binding to be set as a DOM attribute. <Badge text="3.2+"/>
 
 - **Usage:**
 
@@ -299,7 +299,7 @@
   <svg><a :xlink:special="foo"></a></svg>
   ```
 
-  When setting a binding on an element, Vue by default checks whether the element has the key defined as a property using an `in` operator check. If the property is defined, Vue will set the value as DOM property instead of an attribute. This should work in most cases, but you can override this behavior by explicitly using `.prop` or `.attr` modifiers. This is sometimes necessary especially when [working with custom elements](/guide/web-components.html#passing-dom-properties).
+  When setting a binding on an element, Vue by default checks whether the element has the key defined as a property using an `in` operator check. If the property is defined, Vue will set the value as a DOM property instead of an attribute. This should work in most cases, but you can override this behavior by explicitly using `.prop` or `.attr` modifiers. This is sometimes necessary, especially when [working with custom elements](/guide/web-components.html#passing-dom-properties).
 
   The `.prop` modifier also has a dedicated shorthand, `.`:
 
@@ -481,15 +481,15 @@
   </div>
   ```
 
-  When the component re-renders, if both `valueA` and `valueB` remains the same, all updates for this `<div>` and its children will be skipped. In fact, even the Virtual DOM vnode creation will also be skipped since the memoized copy of the sub-tree can be reused.
+  When the component re-renders, if both `valueA` and `valueB` remain the same, all updates for this `<div>` and its children will be skipped. In fact, even the Virtual DOM VNode creation will also be skipped since the memoized copy of the sub-tree can be reused.
 
   It is important to specify the memoization array correctly, otherwise we may skip updates that should indeed be applied.
 
   This directive is provided solely for micro optimizations in performance-critical scenarios and should be rarely needed. The most common case where this may prove helpful is when rendering large `v-for` lists (where `length > 1000`):
 
   ```html
   <div v-for="item in list" :key="item.id" v-memo="[item.id === selected]">
-    <p>ID: {{ id }} - selected: {{ item.id === selected }}</p>
+    <p>ID: {{ item.id }} - selected: {{ item.id === selected }}</p>
     <p>...more child nodes</p>
   </div>
   ```

src/api/global-api.md

@@ -270,7 +270,7 @@ document.body.appendChild(new MyVueElement({
 }))
 ```
 
-For more details on building Web Components with Vue, especially with Single File Components, see [Vue and Web Components](/guide/web-components#building-custom-elements-with-vue).
+For more details on building Web Components with Vue, especially with Single File Components, see [Vue and Web Components](/guide/web-components.html#building-custom-elements-with-vue).
 
 ## resolveComponent
 

src/api/sfc-script-setup.md

@@ -8,7 +8,7 @@ sidebarDepth: 1
 
 - More succinct code with less boilerplate
 - Ability to declare props and emitted events using pure TypeScript
-- Better runtime performance (template is compiled into render function in the same scope without an intermediate proxy)
+- Better runtime performance (the template is compiled into a render function in the same scope, without an intermediate proxy)
 - Better IDE type-inference performance (less work for the language server to extract types from code)
 
 ## Basic Syntax
@@ -21,9 +21,9 @@ console.log('hello script setup')
 </script>
 ```
 
-The code inside are compiled as the content of the component's `setup()` function. This means unlike normal `<script>`, which only executes once when the component is first imported, code inside `<script setup>` will **execute every time an instance of the component is created**.
+The code inside is compiled as the content of the component's `setup()` function. This means that unlike normal `<script>`, which only executes once when the component is first imported, code inside `<script setup>` will **execute every time an instance of the component is created**.
 
-### Top level bindings are exposed to template
+### Top-level bindings are exposed to template
 
 When using `<script setup>`, any top-level bindings (including variables, function declarations, and imports) declared inside `<script setup>` are directly usable in the template:
 
@@ -57,7 +57,7 @@ import { capitalize } from './helpers'
 
 ## Reactivity
 
-Reactive state needs to be explicitly created using [Reactivity APIs](/api/basic-reactivity.html). Similar to returned values from the `setup()` functions, refs are automatically unwrapped when referenced in templates:
+Reactive state needs to be explicitly created using [Reactivity APIs](/api/basic-reactivity.html). Similar to values returned from a `setup()` function, refs are automatically unwrapped when referenced in templates:
 
 ```vue
 <script setup>
@@ -85,7 +85,7 @@ import MyComponent from './MyComponent.vue'
 </template>
 ```
 
-Think of `MyComponent` as being referenced as a variable. If you have used JSX before, the mental model is similar here. The kebab-case equivalent `<my-component>` also works in the template - however PascalCase component tags are strongly recommended for consistency. It also helps differentiating from native custom elements.
+Think of `MyComponent` as being referenced as a variable. If you have used JSX, the mental model is similar here. The kebab-case equivalent `<my-component>` also works in the template - however PascalCase component tags are strongly recommended for consistency. It also helps differentiating from native custom elements.
 
 ### Dynamic Components
 
@@ -107,7 +107,7 @@ Note how the components can be used as variables in a ternary expression.
 
 ### Recursive Components
 
-SFCs can implicitly refer to itself via its filename. E.g. a file named `FooBar.vue` can refer to itself as `<FooBar/>` in its template.
+An SFC can implicitly refer to itself via its filename. E.g. a file named `FooBar.vue` can refer to itself as `<FooBar/>` in its template.
 
 Note this has lower priority than imported components. If you have a named import that conflicts with the component's inferred name, you can alias the import:
 
@@ -177,7 +177,7 @@ const attrs = useAttrs()
 
 ## Usage alongside normal `<script>`
 
-`<script setup>` can be used alongside normal `<script>`. A normal `<script>` maybe needed in cases where we need to:
+`<script setup>` can be used alongside normal `<script>`. A normal `<script>` may be needed in cases where we need to:
 
 - Declare options that cannot be expressed in `<script setup>`, for example `inheritAttrs` or custom options enabled via plugins.
 - Declaring named exports.
@@ -200,9 +200,9 @@ export default {
 </script>
 ```
 
-## Top level await
+## Top-level `await`
 
-Top level `await` can be used inside `<script setup>`. The resulting code will be compiled as `async setup()`:
+Top-level `await` can be used inside `<script setup>`. The resulting code will be compiled as `async setup()`:
 
 ```vue
 <script setup>
@@ -232,7 +232,7 @@ const emit = defineEmits<{
 
 - `defineProps` or `defineEmits` can only use either runtime declaration OR type declaration. Using both at the same time will result in a compile error.
 
-- When using type declaration, equivalent runtime declaration is automatically generated from static analysis to remove the need of double declaration and still ensure correct runtime behavior.
+- When using type declaration, the equivalent runtime declaration is automatically generated from static analysis to remove the need for double declaration and still ensure correct runtime behavior.
 
   - In dev mode, the compiler will try to infer corresponding runtime validation from the types. For example here `foo: String` is inferred from the `foo: string` type. If the type is a reference to an imported type, the inferred result will be `foo: null` (equal to `any` type) since the compiler does not have information of external files.
 
@@ -243,7 +243,7 @@ const emit = defineEmits<{
 - As of now, the type declaration argument must be one of the following to ensure correct static analysis:
 
   - A type literal
-  - A reference to a an interface or a type literal in the same file
+  - A reference to an interface or a type literal in the same file
 
   Currently complex types and type imports from other files are not supported. It is theoretically possible to support type imports in the future.
 
@@ -265,4 +265,4 @@ This will be compiled to equivalent runtime props `default` options. In addition
 
 ## Restriction: No Src Imports
 
-Due to the difference in module execution semantics, code inside `<script setup>` relies on the context of an SFC. When moved into external `.js` or `.ts` files, it may lead to confusions for both developers and tools. Therefore, **`<script setup>`** cannot be used with the `src` attribute.
+Due to the difference in module execution semantics, code inside `<script setup>` relies on the context of an SFC. When moved into external `.js` or `.ts` files, it may lead to confusion for both developers and tools. Therefore, **`<script setup>`** cannot be used with the `src` attribute.

src/api/sfc-spec.md

@@ -60,10 +60,10 @@ export default {
 
 ### Custom Blocks
 
-Additional custom blocks can be included in a `*.vue` file for any project specific needs, for example a `<docs>` block. Some real-world examples of custom blocks include:
+Additional custom blocks can be included in a `*.vue` file for any project-specific needs, for example a `<docs>` block. Some real-world examples of custom blocks include:
 
 - [Gridsome: `<page-query>`](https://gridsome.org/docs/querying-data/)
-- [vite-plguin-vue-gql: `<gql>`](https://github.com/wheatjs/vite-plugin-vue-gql)
+- [vite-plugin-vue-gql: `<gql>`](https://github.com/wheatjs/vite-plugin-vue-gql)
 - [vue-i18n: `<i18n>`](https://github.com/intlify/bundle-tools/tree/main/packages/vite-plugin-vue-i18n#i18n-custom-block)
 
 Handling of Custom Blocks will depend on tooling - if you want to build your own custom block integrations, see [SFC Tooling](/api/sfc-tooling.html#custom-blocks-integration) for more details.
@@ -117,7 +117,7 @@ If you prefer splitting up your `*.vue` components into multiple files, you can
 <script src="./script.js"></script>
 ```
 
-Beware that `src` imports follow the same path resolution rules to webpack module requests, which means:
+Beware that `src` imports follow the same path resolution rules as webpack module requests, which means:
 
 - Relative paths need to start with `./`
 - You can import resources from npm dependencies:
@@ -136,4 +136,4 @@ Beware that `src` imports follow the same path resolution rules to webpack modul
 
 ## Comments
 
-Inside each block you shall use the comment syntax of the language being used (HTML, CSS, JavaScript, Jade, etc). For top-level comments, use HTML comment syntax: `<!-- comment contents here -->`
+Inside each block you shall use the comment syntax of the language being used (HTML, CSS, JavaScript, Pug, etc.). For top-level comments, use HTML comment syntax: `<!-- comment contents here -->`

src/api/sfc-style.md

@@ -132,15 +132,15 @@ Refer to the [CSS Modules spec](https://github.com/css-modules/css-modules) for
 
 You can customize the property key of the injected classes object by giving the `module` attribute a value:
 
-```html
+```vue
 <template>
   <p :class="classes.red">red</p>
 </template>
 
 <style module="classes">
-  .red {
-    color: red;
-  }
+.red {
+  color: red;
+}
 </style>
 ```
 
@@ -190,4 +190,4 @@ p {
 </style>
 ```
 
-The actual value will be compiled into a hashed CSS custom property so the CSS is still static. The custom property will be applied to component's root element via inline styles and reactively updated if the source value changes.
+The actual value will be compiled into a hashed CSS custom property, so the CSS is still static. The custom property will be applied to the component's root element via inline styles and reactively updated if the source value changes.

src/api/sfc-tooling.md

@@ -17,16 +17,16 @@ It is also recommended to use these online playgrounds to provide reproductions
 
 ### Vite
 
-[Vite](https://vitejs.dev/) is a lightweight and fast build tool with first-class Vue SFC support. It is created by Evan You who is also the author of Vue itself! To get started with Vite + Vue, simply run:
+[Vite](https://vitejs.dev/) is a lightweight and fast build tool with first-class Vue SFC support. It is created by Evan You, who is also the author of Vue itself! To get started with Vite + Vue, simply run:
 
 ```sh
 npm init vite@latest
 ```
 
-Then select the Vue template and follow instructions.
+Then select the Vue template and follow the instructions.
 
 - To learn more about Vite, check out the [Vite docs](https://vitejs.dev/guide/).
-- To configure Vue specific behavior in a Vite project, for example passing options to the Vue compiler, check out docs for [@vitejs/plugin-vue](https://github.com/vitejs/vite/tree/main/packages/plugin-vue#readme).
+- To configure Vue-specific behavior in a Vite project, for example passing options to the Vue compiler, check out the docs for [@vitejs/plugin-vue](https://github.com/vitejs/vite/tree/main/packages/plugin-vue#readme).
 
 The [SFC Playground](https://sfc.vuejs.org/) also supports downloading the files as a Vite project.
 
@@ -71,7 +71,7 @@ Custom blocks are compiled into imports to the same Vue file with different requ
 
 - If using Vue CLI or plain webpack, a webpack loader should be configured to transform the matched blocks. [[Example](https://vue-loader.vuejs.org/guide/custom-blocks.html#custom-blocks)]
 
-## Lower Level Tools
+## Lower-Level Tools
 
 ### `@vue/compiler-sfc`
 

src/guide/introduction.md

@@ -314,7 +314,7 @@ In a large application, it is necessary to divide the whole app into components
 
 ### Relation to Custom Elements
 
-You may have noticed that Vue components look similar to **Custom Elements**, which are part of the [Web Components Spec](https://www.w3.org/wiki/WebComponents/). Indeed, parts of Vue's component design (for example the slot API) was influenced by the spec before it was natively implemented in browsers.
+You may have noticed that Vue components look similar to **Custom Elements**, which are part of the [Web Components Spec](https://www.w3.org/wiki/WebComponents/). Indeed, parts of Vue's component design (for example the slot API) were influenced by the spec before it was natively implemented in browsers.
 
 The main difference is that Vue's component model is designed as a part of a coherent framework that provides many additional features necessary for building non-trivial applications, for example reactive templating and state management - both of which the spec does not cover.
 

src/guide/single-file-component.md

@@ -73,13 +73,13 @@ SFC is a defining feature of Vue as a framework, and is the recommended approach
 - Static Site Generation (SSG)
 - Any non-trivial frontends where a build step can be justified for better development experience (DX).
 
-That said, we do realize there are scenarios where SFCs can feel like an overkill. This is why Vue can still be used via plain JavaScript without a build step. If you are just looking for enhancing largely static HTML with light interactions, you can also check out [petite-vue](https://github.com/vuejs/petite-vue), a 5kb subset of Vue optimized for progressive enhancement.
+That said, we do realize there are scenarios where SFCs can feel like overkill. This is why Vue can still be used via plain JavaScript without a build step. If you are just looking for enhancing largely static HTML with light interactions, you can also check out [petite-vue](https://github.com/vuejs/petite-vue), a 5kb subset of Vue optimized for progressive enhancement.
 
 ## What About Separation of Concerns?
 
 Some users coming from a traditional web development background may have the concern that SFCs are mixing different concerns in the same place - which HTML/CSS/JS were supposed to separate!
 
-To answer this question, it is important for us to agree that **separation of concerns is not equal to separation of file types.** The ultimate goal of engieerning principles is to improve maintainability of codebases. Separation of concerns, when applied dogmatically as separation of file types, does not help us reach that goal in the context of increasingly complex frontend applications.
+To answer this question, it is important for us to agree that **separation of concerns is not equal to separation of file types.** The ultimate goal of engineering principles is to improve maintainability of codebases. Separation of concerns, when applied dogmatically as separation of file types, does not help us reach that goal in the context of increasingly complex frontend applications.
 
 In modern UI development, we have found that instead of dividing the codebase into three huge layers that interweave with one another, it makes much more sense to divide them into loosely-coupled components and compose them. Inside a component, its template, logic, and styles are inherently coupled, and collocating them actually makes the component more cohesive and maintainable.