tweak wording, correct typos and adjust grammar

Author: skirtles-code

src/guide/best-practices/performance.md

@@ -51,15 +51,15 @@ One of the most effective ways to improve page load performance is shipping smal
 
 - Be cautious of size when introducing new dependencies! In real world applications, bloated bundles are most often a result of introducing heavy dependencies without realizing it.
 
-  - If using a build step, prefer dependencies that offer ES module formats and are tree-shaking-friendly. For example, prefer `lodash-es` over `lodash`.
+  - If using a build step, prefer dependencies that offer ES module formats and are tree-shaking friendly. For example, prefer `lodash-es` over `lodash`.
 
-  - Check a dependency's size and evaluate whether it is worth the functionality it provides. Note if the dependency is tree-shaking-friendly, the actual size increase will depend on the APIs you actually import from it. Tools like [bundle.js.org](https://bundle.js.org/) can be used for quick checks, but measuring with your actual build setup will always be the most accurate.
+  - Check a dependency's size and evaluate whether it is worth the functionality it provides. Note if the dependency is tree-shaking friendly, the actual size increase will depend on the APIs you actually import from it. Tools like [bundle.js.org](https://bundle.js.org/) can be used for quick checks, but measuring with your actual build setup will always be the most accurate.
 
 - If you are using Vue primarily for progressive enhancement and prefer to avoid a build step, consider using [petite-vue](https://github.com/vuejs/petite-vue) (only **6kb**) instead.
 
 ### Code Splitting
 
-Code splitting stands for the build tool splitting the application bundle into multiple smaller chunks which can then be loaded on demand or in parallel. With proper code splitting, features required at page load can be downloaded immediately, with additional chunks being lazy loaded only when needed, thus improving performance.
+Code splitting is where a build tool splits the application bundle into multiple smaller chunks, which can then be loaded on demand or in parallel. With proper code splitting, features required at page load can be downloaded immediately, with additional chunks being lazy loaded only when needed, thus improving performance.
 
 Bundlers like Rollup (which Vite is based upon) or webpack can automatically create split chunks by detecting the ESM dynamic import syntax:
 
@@ -116,19 +116,19 @@ Now, for most components the `active` prop will remain the same when `activeId`
 
 ### `v-once`
 
-`v-once` is a built-in directive that can be used to render content that relies on runtime data but never needs to update. The entire sub tree it is used on will be skipped for all future updates. Consult its [API reference](/api/built-in-directives.html#v-once) for more details.
+`v-once` is a built-in directive that can be used to render content that relies on runtime data but never needs to update. The entire sub-tree it is used on will be skipped for all future updates. Consult its [API reference](/api/built-in-directives.html#v-once) for more details.
 
 ### `v-memo`
 
-`v-memo` is a built-in directive that can be used to conditionally skip the update of large sub trees or `v-for` lists. Consult its [API reference](/api/built-in-directives.html#v-memo) for more details.
+`v-memo` is a built-in directive that can be used to conditionally skip the update of large sub-trees or `v-for` lists. Consult its [API reference](/api/built-in-directives.html#v-memo) for more details.
 
 ## General Optimizations
 
 > The following tips affect both page load and update performance.
 
 ### Virtualize Large Lists
 
-One of the most common performance issues in all frontend applications is rendering large lists. No matter how performant a framework is, rendering a list with thousands of items **will** be slow due to the sheer amount of DOM nodes that the browser needs to handle.
+One of the most common performance issues in all frontend applications is rendering large lists. No matter how performant a framework is, rendering a list with thousands of items **will** be slow due to the sheer number of DOM nodes that the browser needs to handle.
 
 However, we don't necessarily have to render all these nodes upfront. In most cases, the user's screen size can display only a small subset of our large list. We can greatly improve the performance with **list virtualization**, the technique of only rendering the items that are currently in or close to the viewport in a large list.
 
@@ -139,7 +139,7 @@ Implementing list virtualization isn't easy, luckily there are existing communit
 
 ### Reduce Reactivity Overhead for Large Immutable Structures
 
-Vue's reactivity system is deep by default. While this makes state management intuitive, it does create a certain level of overhead when the data size is large, because every property access triggers proxy traps that performs dependency tracking. This typically becomes noticeable when dealing with large arrays of deeply nested objects, where a single render needs to access 100,000+ properties, so it should only affect very specific use cases.
+Vue's reactivity system is deep by default. While this makes state management intuitive, it does create a certain level of overhead when the data size is large, because every property access triggers proxy traps that perform dependency tracking. This typically becomes noticeable when dealing with large arrays of deeply nested objects, where a single render needs to access 100,000+ properties, so it should only affect very specific use cases.
 
 Vue does provide an escape hatch to opt-out of deep reactivity by using [`shallowRef()`](/api/reactivity-advanced.html#shallowref) and [`shallowReactive()`](/api/reactivity-advanced.html#shallowreactive). Shallow APIs create state that is reactive only at the root level, and exposes all nested objects untouched. This keeps nested property access fast, with the trade-off being that we must now treat all nested objects as immutable, and updates can only be triggered by replacing the root state:
 
@@ -153,7 +153,7 @@ shallowArray.value.push(newObject)
 // this does:
 shallowArray.value = [...shallowArr.value, newObject]
 
-// this won't trigger update...
+// this won't trigger updates...
 shallowArray.value[0].foo = 1
 // this does:
 shallowArray.value = [

src/guide/built-ins/keep-alive.md

@@ -71,7 +71,7 @@ By default, `<KeepAlive>` will cache any component instance inside. We can custo
 </KeepAlive>
 ```
 
-The match is checked against the component's [`name`](/api/options-misc.html#name) option, so components that need to be conditionally cached by `KeepAlive` must explicitly delcare a `name` option.
+The match is checked against the component's [`name`](/api/options-misc.html#name) option, so components that need to be conditionally cached by `KeepAlive` must explicitly declare a `name` option.
 
 ## Max Cached Instances
 
@@ -85,7 +85,7 @@ We can limit the maximum number of component instances that can be cached via th
 
 ## Lifecycle of Cached Instance
 
-When a component instance is removed from the DOM but is part of a component tree cached by `<KeepAlive>`, it goes into **deactivated** state instead of unmounted. When a component instance is inserted into the DOM as part of a cached tree, it is **activated**.
+When a component instance is removed from the DOM but is part of a component tree cached by `<KeepAlive>`, it goes into a **deactivated** state instead of being unmounted. When a component instance is inserted into the DOM as part of a cached tree, it is **activated**.
 
 <div class="composition-api">
 
@@ -110,7 +110,7 @@ onDeactivated(() => {
 </div>
 <div class="options-api">
 
-A kept-alive component can register lifecycle hooks for these two states using [`activated`](/api/options-lifecycle.html#activated) and [`deactovated`](/api/options-lifecycle.html#deactivated) hooks:
+A kept-alive component can register lifecycle hooks for these two states using [`activated`](/api/options-lifecycle.html#activated) and [`deactivated`](/api/options-lifecycle.html#deactivated) hooks:
 
 ```js
 export default {

src/guide/built-ins/suspense.md

@@ -30,7 +30,7 @@ The `<Suspense>` component gives us the ability to display top-level loading / e
 
 There are two types of async dependencies that `<Suspense>` can wait on:
 
-1. Components with an async `setup()` hook. This includes components with `<script setup>` that contains top-level `await` expressions.
+1. Components with an async `setup()` hook. This includes components using `<script setup>` with top-level `await` expressions.
 
 2. [Async Components](/guide/components/async.html).
 
@@ -85,17 +85,17 @@ The `<Suspense>` component has two slots: `#default` and `#fallback`. Both slots
 </Suspense>
 ```
 
-On initial render, `<Suspense>` will render its default slot content in memory. If any async dependencies are encountered during the process, it will enter **pending** state. During pending state, the fallback content will be displayed. When all encountered async dependencies have been resolved, `<Suspense>` enters **resolved** state and the resolved default slot content is displayed.
+On initial render, `<Suspense>` will render its default slot content in memory. If any async dependencies are encountered during the process, it will enter a **pending** state. During the pending state, the fallback content will be displayed. When all encountered async dependencies have been resolved, `<Suspense>` enters a **resolved** state and the resolved default slot content is displayed.
 
-If no async dependencies were encountered during the initial render, `<Suspense>` will directly go into resolved state.
+If no async dependencies were encountered during the initial render, `<Suspense>` will directly go into a resolved state.
 
-Once in resolved state, `<Suspense>` will only revert to pending state if the root node of the `#default` slot is replaced. New async dependencies nested deeper in the tree will **not** cause the `<Suspense>` to revert into pending state.
+Once in a resolved state, `<Suspense>` will only revert to a pending state if the root node of the `#default` slot is replaced. New async dependencies nested deeper in the tree will **not** cause the `<Suspense>` to revert to a pending state.
 
 When a revert happens, fallback content will not be immediately displayed. Instead, `<Suspense>` will display the previous `#default` content while waiting for the new content and its async dependencies to be resolved. This behavior can be configured with the `timeout` prop: `<Suspense>` will switch to fallback content if it takes longer than `timeout` to render the new default content. A `timeout` value of `0` will cause the fallback content to be displayed immediately when default content is replaced.
 
 ## Events
 
-In addition to the `pending` event, the `<suspense>` component also has `resolve` and `fallback` events. The `resolve` event is emitted when new content has finished resolving in the `default` slot. The `fallback` event is fired when the contents of the `fallback` slot are shown.
+The `<Suspense>` component emits 3 events: `pending`, `resolve` and `fallback`. The `pending` event occurs when entering a pending state. The `resolve` event is emitted when new content has finished resolving in the `default` slot. The `fallback` event is fired when the contents of the `fallback` slot are shown.
 
 The events could be used, for example, to show a loading indicator in front of the old DOM while new components are loading.
 

src/guide/built-ins/teleport.md

@@ -111,7 +111,7 @@ When using this component inside the initial HTML structure, there are a number
 
 The `to` target of `<Teleport>` expects a CSS selector string or an actual DOM node. Here, we are essentially telling Vue to "**teleport** this template fragment **to** the **`body`** tag".
 
-You can click the button below and inspect the `<body>` tag via browser devtools:
+You can click the button below and inspect the `<body>` tag via your browser's devtools:
 
 <script setup>
 let open = $ref(false)
@@ -170,7 +170,7 @@ Where the `isMobile` state can be dynamically updated by detecting media query c
 
 ## Multiple Teleports on the Same Target
 
-A common use case scenario would be a reusable `<Modal>` component of which there might be multiple instances active at the same time. For this kind of scenario, multiple `<Teleport>` components can mount their content to the same target element. The order will be a simple append - later mounts will be located after earlier ones within the target element.
+A common use case would be a reusable `<Modal>` component, with the potential for multiple instances to be active at the same time. For this kind of scenario, multiple `<Teleport>` components can mount their content to the same target element. The order will be a simple append - later mounts will be located after earlier ones within the target element.
 
 Given the following usage:
 

src/guide/built-ins/transition-group.md

@@ -8,7 +8,7 @@ import ListStagger from './transition-demos/ListStagger.vue'
 
 `<TransitionGroup>` is a built-in component designed for animating the insertion, removal, and order change of elements or components that are rendered in a list.
 
-## Difference from `<Transition>`
+## Differences from `<Transition>`
 
 `<TransitionGroup>` supports the same props, CSS transition classes, and JavaScript hook listeners as `<Transition>`, with the following differences:
 
@@ -52,7 +52,7 @@ Here is an example of applying enter / leave transitions to a `v-for` list using
 
 ## Move Transitions
 
-The above demo has some obvious flaws: when an item is inserted or removed, its sorrounding items instantly "jumps" into place instead of moving smoothly. We can fix this by adding a few additional CSS rules:
+The above demo has some obvious flaws: when an item is inserted or removed, its surrounding items instantly "jump" into place instead of moving smoothly. We can fix this by adding a few additional CSS rules:
 
 ```css{1,13-17}
 .list-move, /* apply transition to moving elements */
@@ -74,7 +74,7 @@ The above demo has some obvious flaws: when an item is inserted or removed, its
 }
 ```
 
-Now it looks much better - even animates smoothly when the whole list is shuffled:
+Now it looks much better - even animating smoothly when the whole list is shuffled:
 
 <ListMove />
 

src/guide/built-ins/transition.md

@@ -14,7 +14,7 @@ Vue offers two built-in components that can help work with transitions and anima
 
 - `<Transition>` for applying animations when an element or component is entering and leaving the DOM. This is covered on this page.
 
-- `<TransitionGroup>` for applying animations when an element or component is inserted into, removed from, or moved within a `v-for` list. This is covered in the next chapter.
+- `<TransitionGroup>` for applying animations when an element or component is inserted into, removed from, or moved within a `v-for` list. This is covered in [the next chapter](/guide/built-ins/transition-group.html).
 
 Aside from these two components, we can also apply animations in Vue using other techniques such as toggling CSS classes or state-driven animations via style bindings. These additional techniques are covered in the [Animation Techniques](/guide/extras/animation.html) chapter.
 
@@ -125,7 +125,7 @@ For a named transition, its transition classes will be prefixed with its name in
 
 `<Transition>` is most commonly used in combination with [native CSS transitions](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transitions/Using_CSS_transitions), as seen in the basic example above. The `transition` CSS property is a shorthand that allows us to specify multiple aspects of a transition, including properties that should be animated, duration of the transition, and [easing curves](https://developer.mozilla.org/en-US/docs/Web/CSS/easing-function).
 
-Here is a more advanced example transitioning more than one properties, with different duration and easing curves for enter and leave:
+Here is a more advanced example that transitions multiple properties, with different durations and easing curves for enter and leave:
 
 ```vue-html
 <Transition name="slide-fade">
@@ -319,9 +319,9 @@ You may notice that the animations shown above are mostly using properties like
 
 1. They do not affect the document layout during the animation, so they do not trigger expensive CSS layout calculation on every animation frame.
 
-2. Most modern browsers can leverage GPU hardware accelaration when animating `transform`.
+2. Most modern browsers can leverage GPU hardware acceleration when animating `transform`.
 
-In comparision, properties like `height` or `margin` will trigger CSS layout, so they are much more expensive to animate, and should be used with caution. We can check resources like [CSS-Triggers](https://csstriggers.com/) to see which properties will trigger layout if we animate them.
+In comparison, properties like `height` or `margin` will trigger CSS layout, so they are much more expensive to animate, and should be used with caution. We can check resources like [CSS-Triggers](https://csstriggers.com/) to see which properties will trigger layout if we animate them.
 
 ## JavaScript Hooks
 
@@ -362,7 +362,7 @@ function onAfterEnter(el) {}
 function onEnterCancelled(el) {}
 
 // called before the leave hook.
-// Most of the time, you shoud just use the leave hook
+// Most of the time, you should just use the leave hook
 function onBeforeLeave(el) {}
 
 // called when the leave transition starts.
@@ -463,13 +463,13 @@ Here's a demo using the [GreenSock library](https://greensock.com/) to perform t
 Transitions can be reused through Vue's component system. To create a reusable transition, we can create a component that wraps the `<Transition>` component and passes down the slot content:
 
 ```vue{5}
-<!-- MyTransitio.vue -->
+<!-- MyTransition.vue -->
 <script>
 // JavaScript hooks logic...
 </script>
 
 <template>
-  <!-- wrap the built in Transition component -->
+  <!-- wrap the built-in Transition component -->
   <Transition
     name="my-transition"
     @enter="onEnter"
@@ -523,7 +523,7 @@ In addition to toggling an element with `v-if` / `v-show`, we can also transitio
 
 ## Transition Modes
 
-In the previous example, the entering and leaving elements are animated at the same time, and we had to work make them `position: absolute` to avoid the layout issue when both elements are present in the DOM.
+In the previous example, the entering and leaving elements are animated at the same time, and we had to make them `position: absolute` to avoid the layout issue when both elements are present in the DOM.
 
 However, in some cases this isn't an option, or simply isn't the desired behavior. We may want the leaving element to be animated out first, and for the entering element to only be inserted **after** the leaving animation has finished. Orchestrating such animations manually would be very complicated - luckily, we can enable this behavior by passing `<Transition>` a `mode` prop:
 
@@ -574,7 +574,7 @@ Here's the previous demo with `mode="out-in"`:
 
 This can be useful when you've defined CSS transitions / animations using Vue's transition class conventions and want to switch between them.
 
-You can also apply different behavior in JavaScript transition hooks based on current state of your component. Finally, the ultimate way of creating dynamic transitions is through [reusable transition components](#reusable-transitions) that accept props to change the nature of the transition(s) to be used. It may sound cheesy, but the only limit really is your imagination.
+You can also apply different behavior in JavaScript transition hooks based on the current state of your component. Finally, the ultimate way of creating dynamic transitions is through [reusable transition components](#reusable-transitions) that accept props to change the nature of the transition(s) to be used. It may sound cheesy, but the only limit really is your imagination.
 
 ---