Randy 9 anos atrás
pai
commit
88d321d311
2 arquivos alterados com 16 adições e 17 exclusões
  1. 12 13
      docs/zh-cn/concepts.md
  2. 4 4
      docs/zh-cn/intro.md

+ 12 - 13
docs/zh-cn/concepts.md

@@ -1,24 +1,24 @@
-# Core Concepts
+# 核心概念
 
-Similar to Vue itself, Vuex exposes a single `Vuex` constructor. You can use it to create **Vuex instances**. In most cases, you only need one Vuex instance for an app. You can think of a Vuex instance as an "enhanced store" that holds your app state.
+和 Vue 一样,Vuex 暴露一个 `Vuex` 构造,你可以实例化一个 `Vuex 实例`。一般情况下,一个应用中只需要一个 Vuex 实例。你可以把它当成一个『额外的 store』来管理应用状态。
 
-Each Vuex instance consists of three types of "ingredients":
+每个 Vuex 实例由三个部分组成:
 
-- **State**: A plain object representing the application state.
+- **State**: 一个反映应用状态的纯对象。
 
-- **Mutations**: Functions that mutates the state. Mutations **must be synchronous**.
+- **Mutations**: 一些用于改变状态的函数。Mutations **一定是同步的**。
 
-- **Actions**: Functions that dispatch mutations. An action can contain asynchronous operations and can dispatch multiple mutations.
+- **Actions**: 一些用于dispatch mutations 的函数。一个 action 可以包含异步操作,并且可以 dispatch 多个 mutations.
 
-Why do we differentiate between *mutations* and *actions*, rather then just simple functions that manipulate the state however we want? The reason is because we want to **separate mutation and asynchronicity**. A lot of application complexity roots from the combination of the two. When separated, they both become easier to reason about and write tests for.
+我们把 *mutations* 和 *actions* 分开而不是直接用函数去操作 state,原因是我们希望把 mutation 和异步操作分离。许多应用之所以复杂,正是犹豫这两者的耦合。我们解耦两者后,它们都会变得清晰和易于测试。
 
-> If you are familiar with Flux, note there's a term/concept difference here: Vuex mutations are the equivalent of Flux **actions**, while Vuex actions are equivalent to Flux **action creators**.
+> 如果你熟悉 Flux,在这里要注意两者的一些差异:Vuex mutations 相当于 Flux 的 **actions**, 而 Vuex 的 actions 相当于 Flux 的 **action creators**.
 
-### Creating a Vuex Instance
+### 创建一个 Vuex 实例
 
-> **NOTE:** We will be using ES2015 syntax for code examples for the rest of the docs. If you haven't picked it up, [you should](https://babeljs.io/docs/learn-es2015/)! The doc also assumes you are already familiar with the concepts discussed in [Building Large-Scale Apps with Vue.js](http://vuejs.org/guide/application.html).
+> **NOTE:** 我们将用 ES2015 语法写接下来的事例代码。如果你还没开始接触 ES2015,那么你应该[现在就开始用](https://babeljs.io/docs/learn-es2015/)! 我们还默认你已经熟悉 [Building Large-Scale Apps with Vue.js](http://vuejs.org/guide/application.html) 中所提到的概念。
 
-Creating a Vuex instance is pretty straightforward - just put the aforementioned ingredients together:
+创建一个 Vuex 实例非常简单——只需要把以上提到的三个部分放到一起:
 
 ``` js
 import Vuex from 'vuex'
@@ -30,5 +30,4 @@ const vuex = new Vuex({
 })
 ```
 
-Once created, you can access the state via `vuex.state`, and the actions via `vuex.actions`. You cannot directly access the mutation functions - they can only be triggered by actions or calling `vuex.dispatch()`. We will discuss each concept in more details next.
-
+实例化后,你就能通过 `vuex.state` 访问 state, 通过 `vuex.actions` 访问 actions。你不能直接访问 mutation functions——你只能通过 actions 或执行 `vuex.disptach()` 访问。接下来我们会更详细地讨论这几个概念。

+ 4 - 4
docs/zh-cn/intro.md

@@ -1,13 +1,13 @@
 ## 什么是 Vuex?
 
-Vuex 是 Vue.js 应用的应用状态管理结构。它受启发于 [Flux](https://facebook.github.io/flux/) 和 [Redux](https://github.com/rackt/redux),但 Vuex 的设计更加符合 Vue.js 的响应系统(reactivity system)
+Vuex 是 Vue.js 应用的 state 管理结构。它受启发于 [Flux](https://facebook.github.io/flux/) 和 [Redux](https://github.com/rackt/redux),但 Vuex 的设计更加符合 Vue.js 的 reactivity system
 
 ## 我为什么需要它?
 
 当你的应用还很简单的时候,你可能并不需要 Vuex,也不建议在过早地去用它。相反,如果你正在构建一个规模越来越大的 SPA 时,你会开始考虑如何管理好 Vue 组件之外的东西。这就是 Vuex 要做的事。
 
-我们在用 Vue.js 的时候,通常会把状态储存在组件的内部。也就是说,每一个组件都拥有自己单独的状态。然而有时候我们需要把一部分的状态共享给其它组件,通常我们都是使用第三方的事件系统去达到这个目的。这个模式的问题在于,事件流会在逐渐增长的组件树中变得复杂,并且在出现问题的时候很难去发现问题的所在。
+我们在用 Vue.js 的时候,通常会把 state 储存在组件的内部。也就是说,每一个组件都拥有自己单独的状态。然而有时候我们需要把一部分的 state 共享给其它组件,通常我们都是使用第三方的事件系统去达到这个目的。这个模式的问题在于,事件流会在逐渐增长的组件树中变得复杂,并且在出现问题的时候很难去发现问题的所在。
 
-为了更好的解决在大型应用中共享状态的问题,我们需要把组件状态(component local state)和应用级状态(application level state)区分开来。应用级的状态不属于任何特定的组件,但每一个组件仍然可以观察到状态变化从而自动更新 DOM。通过把状态管理放在同一个地方,我们就不需要在各个地方去处理各种事件,因为任何牵扯到多个组件的东西,都会放在这个地方。这样做也能使我们可以记录和检查 state 的改变,甚至可以做些像 time-travel 这样的调试。
+为了更好的解决在大型应用中共享 state 的问题,我们需要把组件 state(component local state)和应用级 state(application level state)区分开来。应用级的 state 不属于任何特定的组件,但每一个组件仍然可以观察到 state 变化从而自动更新 DOM。通过把 state 管理逻辑放在同一个地方,我们就不需要在各个地方去处理各种事件,因为任何牵扯到多个组件的东西,都会放在这个地方。这样做也能使记录和检查 state 的改变成为可能,甚至可以做些像 time-travel 这样的调试。
 
-即使 Vuex 在状态管理的分离方面有很多的约定,但不会影响你实际代码结构的灵活性。
+即使 Vuex 对状态管理的分离有一些约束,但不会影响你实际代码结构的灵活性。