From 1e34773391d7898b07e558748ad027a95aebf5db Mon Sep 17 00:00:00 2001 From: stakx Date: Sat, 3 Mar 2018 13:57:22 +0100 Subject: [PATCH] Fix a few typos --- src/_posts/012-release.md | 2 +- src/perf/index.md | 2 +- src/v2/cookbook/editable-svg-icons.md | 4 ++-- src/v2/cookbook/unit-testing-vue-components.md | 8 ++++---- src/v2/style-guide/index.md | 2 +- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/_posts/012-release.md b/src/_posts/012-release.md index e9143fd1c0..ea002a9688 100644 --- a/src/_posts/012-release.md +++ b/src/_posts/012-release.md @@ -25,7 +25,7 @@ There are also additional props-related improvements such as explicit one-time o ### Filter Arguments Improvements -In 0.11, filters always receive their arguments as plain strings. An argument can be enclosed in quotes to include whitespace, but the quotes are not automatically stripped when passed into the filter function. Some users were also confused about how to retrive a dynamic value on the vm instead of a plain string. +In 0.11, filters always receive their arguments as plain strings. An argument can be enclosed in quotes to include whitespace, but the quotes are not automatically stripped when passed into the filter function. Some users were also confused about how to retrieve a dynamic value on the vm instead of a plain string. In 0.12, the filter argument syntax now follows a simple rule: if an argument is enclosed in quotes, it will be passed in as a plain string; otherwise, it will be evaluated against the current vm as a dynamic value. diff --git a/src/perf/index.md b/src/perf/index.md index 0c53f0f2e0..7a2fdc3d37 100644 --- a/src/perf/index.md +++ b/src/perf/index.md @@ -8,7 +8,7 @@ title: Performance Comparisons Looking for the TodoMVC Benchmark? It's been removed because after discussion with some other framework authors we have agreed that: -1. The original intention of these benchmarks were for comparing Browser performance rather than that of frameworks. The "synchrorously trigger an action xxx times" test routine doesn't reflect meaningful real world user actions. +1. The original intention of these benchmarks were for comparing Browser performance rather than that of frameworks. The "synchronously trigger an action xxx times" test routine doesn't reflect meaningful real world user actions. 2. Due to internal implementation differences, frameworks that uses async rendering (e.g. Vue, Om, Mercury) gains the advantage by skipping part of the calculations that happened in the same event loop. The real world user experience doesn't demonstrate such dramatic difference. diff --git a/src/v2/cookbook/editable-svg-icons.md b/src/v2/cookbook/editable-svg-icons.md index f815716fe0..e1cbd42926 100644 --- a/src/v2/cookbook/editable-svg-icons.md +++ b/src/v2/cookbook/editable-svg-icons.md @@ -143,7 +143,7 @@ export default { } ``` -We're applying `refs` to the groups of paths we need to move, and as both sides of the scissors have to move in tandem, we'll create a funciton we can reuse where we'll pass in the `refs`. The use of GreenSock helps resolve animation support and transform-origin issues across browser. +We're applying `refs` to the groups of paths we need to move, and as both sides of the scissors have to move in tandem, we'll create a function we can reuse where we'll pass in the `refs`. The use of GreenSock helps resolve animation support and transform-origin issues across browser.

See the Pen Editable SVG Icon System: Animated icon by Vue (@Vue) on CodePen.

@@ -153,7 +153,7 @@ You can see more animated examples in the repo [here](https://github.com/sdras/v ## Additional Notes -Designers may change their minds. Product requirements change. Keeping the logic for the entire icon system in one base component means you can quickly update all of your icons and have it propogate through the whole system. Even with the use of an icon loader, some situations require you to recreate or edit every SVG to make global changes. This method can save you that time and pain. +Designers may change their minds. Product requirements change. Keeping the logic for the entire icon system in one base component means you can quickly update all of your icons and have it propagate through the whole system. Even with the use of an icon loader, some situations require you to recreate or edit every SVG to make global changes. This method can save you that time and pain. ## When To Avoid This Pattern diff --git a/src/v2/cookbook/unit-testing-vue-components.md b/src/v2/cookbook/unit-testing-vue-components.md index e8c5a95825..a8fa7aa60f 100644 --- a/src/v2/cookbook/unit-testing-vue-components.md +++ b/src/v2/cookbook/unit-testing-vue-components.md @@ -106,7 +106,7 @@ Let's take a look at the component code first:
{{ message }}
- Enter your username: + Enter your username:
should be present - if `error` is `false`, `
should not be present -And our first attempt at at test: +And our first attempt at test: ```js import { shallow } from 'vue-test-utils' @@ -176,7 +176,7 @@ The below example improves the test by: - only making one assertion per `it` block - having short, clear test descriptions - providing only the minimum data requires for the test -- refactoring duplucated logic (creating the `wrapper` and setting the `username` variable) into a factory function +- refactoring duplicated logic (creating the `wrapper` and setting the `username` variable) into a factory function *Updated test*: ```js @@ -222,7 +222,7 @@ At the top, we declare the factory function which merges the `values` object int ## Additional Context -Thee above test is fairly simple, but in practise Vue components often have other behaviors you want to test, such as: +The above test is fairly simple, but in practice Vue components often have other behaviors you want to test, such as: - making API calls - committing or dispatching mutations or actions with a `Vuex` store diff --git a/src/v2/style-guide/index.md b/src/v2/style-guide/index.md index 08f8cd0903..0eea3d3f73 100644 --- a/src/v2/style-guide/index.md +++ b/src/v2/style-guide/index.md @@ -693,7 +693,7 @@ components/ **Filenames of [single-file components](../guide/single-file-components.html) should either be always PascalCase or always kebab-case.** -PascalCase works best with autocompletion in code editors, as it's consistent with how we reference components in JS(X) and templates, wherever possible. However, mixed case filenames can sometimes create issues on case-insensitive filesystems, which is why kebab-case is also perfectly acceptable. +PascalCase works best with autocompletion in code editors, as it's consistent with how we reference components in JS(X) and templates, wherever possible. However, mixed case filenames can sometimes create issues on case-insensitive file systems, which is why kebab-case is also perfectly acceptable. {% raw %}
{% endraw %} #### Bad