(Add pt-br language) Fixes pullrequest of DavidWilliamBalbino (#1238)

* Fixes pullrequest of DavidWilliamBalbino

* Added Portuguese Link in LANGS.md

* I made a revision of translation

* Added plugin translate

* I made more one revision of translation

* More one revision

* Revision

* Revision of Links

* Encoded File Revision

* Geral Revision

* Adjustment in General Revision

docs/LANGS.md

@@ -1,5 +1,6 @@
 * [English](en/)
 * [简体中文](zh-cn/)
+* [Português](pt-br/)
 * [Français](fr/)
 * [Русский](ru/)
 * [日本語](ja/)

docs/pt-br/README.md

@@ -0,0 +1 @@
+{% include "./SUMMARY.md" %}

docs/pt-br/SUMMARY.md

@@ -0,0 +1,21 @@
+# Vuex
+
+> Nota: para os usuários TypeScript, vuex@3.0+ requer vue@2.5+ e vice-versa.
+
+- [Notas de versão](https://github.com/vuejs/vuex/releases)
+- [Instalação](installation.md)
+- [O que é Vuex?](intro.md)
+- [Começando](getting-started.md)
+- [Conceitos do núcleo](core-concepts.md)
+  - [Estado](state.md)
+  - [Getters](getters.md)
+  - [Mutações](mutations.md)
+  - [Ações](actions.md)
+  - [Módulos](modules.md)
+- [Estrutura da Aplicação](structure.md)
+- [Plugins](plugins.md)
+- [Modo estrito](strict.md)
+- [Manipulação de formulários](forms.md)
+- [Teste](testing.md)
+- [Hot Reload](hot-reload.md)
+- [Referência da API](api.md)

docs/pt-br/actions.md

@@ -0,0 +1,178 @@
+# Ações
+
+As ações são semelhantes às mutações, as diferenças são as seguintes:
+ - Em vez de mudar o estado, as ações confirmam mutações.
+ - As ações podem conter operações assíncronas arbitrárias.
+Vamos registrar uma simples ação:
+
+``` js
+const store = new Vuex.Store({
+  state: {
+    count: 0
+  },
+  mutations: {
+    increment (state) {
+      state.count++
+    }
+  },
+  actions: {
+    increment (context) {
+      context.commit('increment')
+    }
+  }
+})
+```
+
+Os manipuladores de ação recebem um objeto de contexto que expõe o mesmo conjunto de métodos / propriedades na instância da _store_ , para que você possa chamar `context.commit` para confirmar uma mutação ou acessar o estado e os getters através do `context.state` e do `contexto. getters`.
+Veremos por que esse objeto de contexto não é a própria instância da _store_  quando apresentamos [Módulos](modules.md) mais tarde.
+
+Na prática, muitas vezes usamos ES2015 [desestruturação de argumentos](https://github.com/lukehoban/es6features#destructuring) para simplificar um pouco o código(especialmente quando precisamos chamar `commit` várias vezes):
+
+``` js
+actions: {
+  increment ({ commit }) {
+    commit('increment')
+  }
+}
+```
+
+### Ações de Despacho
+
+As ações são acionadas com o método `store.dispatch`:
+
+``` js
+store.dispatch('increment')
+```
+
+Isso pode parecer óbvio à primeira vista: se quisermos incrementar a contagem, por que não chamamos `store.commit ('incremento') diretamente? Lembre-se de que ** as mutações devem ser síncronas **? As ações não. Podemos executar ** operações assíncronas ** dentro de uma ação:
+
+``` js
+actions: {
+  incrementAsync ({ commit }) {
+    setTimeout(() => {
+      commit('increment')
+    }, 1000)
+  }
+}
+```
+
+As ações suportam o mesmo formato de carga útil e despacho de estilo de objeto:
+
+``` js
+// dispatch com payload
+store.dispatch('incrementAsync', {
+  amount: 10
+})
+
+// dispatch com objeto
+store.dispatch({
+  type: 'incrementAsync',
+  amount: 10
+})
+```
+
+Um exemplo mais prático de ações reais seria uma ação para fazer check-out de um carrinho de compras, que envolve ** chamar uma API assíncrona ** e ** confirmar múltiplas mutações **:
+
+``` js
+actions: {
+  checkout ({ commit, state }, products) {
+    // salva os itens que estão no carrinho
+    const savedCartItems = [...state.cart.added]
+    // enviar solicitação de checkout
+    // limpa o carrinho
+    commit(types.CHECKOUT_REQUEST)
+    // a API da store aceita um callback bem-sucedido e um callback com falha
+    shop.buyProducts(
+      products,
+      // callback em caso de sucesso
+      () => commit(types.CHECKOUT_SUCCESS),
+      // callback em caso de falha
+      () => commit(types.CHECKOUT_FAILURE, savedCartItems)
+    )
+  }
+}
+```
+
+Observe que estamos realizando um fluxo de operações assíncronas e gravando os efeitos colaterais (mutações de estado) da ação confirmando-os.
+
+### Ações de Despacho em Componentes
+
+Você pode despachar ações em componentes com `this. $store.dispatch ('xxx')`, ou usar o auxiliar `mapActions` que mapeia métodos de componente para chamadas do ` store.dispatch` (esta ação requer a injeção root `store`):
+
+``` js
+import { mapActions } from 'vuex'
+
+export default {
+  // ...
+  methods: {
+    ...mapActions([
+      'increment', // mapeia `this.increment()` para `this.$store.dispatch('increment')`
+
+      // `mapActions` also supports payloads:
+      'incrementBy' // mapeia `this.incrementBy(amount)` para `this.$store.dispatch('incrementBy', amount)`
+    ]),
+    ...mapActions({
+      add: 'increment' // mapeia `this.add()` para `this.$store.dispatch('increment')`
+    })
+  }
+}
+```
+
+### Composição de ações
+
+As ações geralmente são assíncronas, então, como sabemos quando uma ação é realizada? E, o mais importante, como podemos compor ações múltiplas em conjunto para lidar com fluxos assíncronos mais complexos?
+
+A primeira coisa a saber é que o `store.dispatch` pode manipular o Promise retornado pelo manipulador de ação acionado e também retorna Promise:
+
+``` js
+actions: {
+  actionA ({ commit }) {
+    return new Promise((resolve, reject) => {
+      setTimeout(() => {
+        commit('someMutation')
+        resolve()
+      }, 1000)
+    })
+  }
+}
+```
+
+Agora, é possivel:
+
+``` js
+store.dispatch('actionA').then(() => {
+  // ...
+})
+```
+
+E em outra ação também:
+
+``` js
+actions: {
+  // ...
+  actionB ({ dispatch, commit }) {
+    return dispatch('actionA').then(() => {
+      commit('someOtherMutation')
+    })
+  }
+}
+```
+
+Por fim, se usarmos [async / await](https://tc39.github.io/ecmascript-asyncawait/), podemos compor nossas ações como esta:
+
+``` js
+// Assumindo que `getData ()` e `getOtherData ()` retornam Promessas
+
+actions: {
+  async actionA ({ commit }) {
+    commit('gotData', await getData())
+  },
+  async actionB ({ dispatch, commit }) {
+    await dispatch('actionA') // esperar que `actionA` termine
+    commit('gotOtherData', await getOtherData())
+  }
+}
+```
+
+> É possível para um `store.dispatch` desencadear vários manipuladores de ação em diferentes módulos. Neste caso, o valor retornado será uma Promise que resolve quando todos os manipuladores desencadeados foram resolvidos.
+

docs/pt-br/api.md

@@ -0,0 +1,218 @@
+# Referência de Api
+
+### Vuex.Store
+
+``` js
+import Vuex from 'vuex'
+
+const store = new Vuex.Store({ ...options })
+```
+
+### Vuex.Store Opções do construtor
+
+- **state**
+
+  - type: `Object | Function`
+
+O objeto do estado da raiz para a _store_  Vuex. [Detalhes](state.md)
+    Se você passar uma função que retorna um objeto, o objeto retornado é usado como o estado da raiz. Isso é útil quando você deseja reutilizar o objeto de estado, especialmente para reutilização de módulos. [Detalhes](modules.md#módulo-reutilização)
+
+- **mutações**
+
+  - type: `{ [type: string]: Function }`
+
+    Registra mutações na _store_ . A função do manipulador sempre recebe `estado` como o primeiro argumento (será o estado local do módulo se definido em um módulo) e receberá um segundo argumento `payload` se houver um.
+
+    [Detalhes](mutations.md)
+
+- **ações**
+
+  - type: `{ [type: string]: Function }`
+
+    Registra ações na _store_ . A função do manipulador recebe um objeto `context` que expõe as seguintes propriedades:
+    ``` js
+    {
+      state,      // o mesmo que `store.state`, ou estado local se estiver em módulos
+      rootState,  // o mesmo que `store.state`, apenas em módulos
+      commit,     // o mesmo que `store.commit`
+      dispatch,   // o mesmo que `store.dispatch`
+      getters,    // o mesmo que `store.getters`, ou com getters locais se estiver em módulos
+      rootGetters // o mesmo que `store.getters`, apenas em módulos
+    }
+    ```
+
+    [Detalhes](actions.md)
+
+- **getters**
+
+  - type: `{ [key: string]: Function }`
+
+    Registra getters na _store_ . A função getter recebe os seguintes argumentos:
+    ```
+    state,     // será o estado local do módulo, se definido em um módulo.
+    getters    // o mesmo que store.getters
+    ```
+
+    Especifique quando definido em um módulo
+
+    ```
+    state,       // será o estado local do módulo, se definido em um módulo.
+
+    getters,     // Módulo getters locais do módulo atual
+    rootState,   // estado global
+    rootGetters  // todos os getters
+    ```
+
+    Os getters registrados estão expostos em `store.getters`.
+
+    [Detalhes](getters.md)
+
+- **módulos**
+
+  - type: `Object`
+
+    Um objeto contendo sub módulos a serem incorporados na _store_ , de forma que:
+    ``` js
+    {
+      key: {
+        state,
+        namespaced?,
+        mutations?,
+        actions?,
+        getters?,
+        modules?
+      },
+      ...
+    }
+    ```
+
+    Cada módulo pode conter "estado" e "mutações" semelhantes às opções raiz. O estado de um módulo será anexado ao estado da raiz da _store_  usando a chave do módulo. As mutações e getters de um módulo receberão apenas o estado local do módulo como o primeiro argumento em vez do estado da raiz e as ações do módulo 'context.state` também apontarão para o estado local.
+
+    [Detalhes](modules.md)
+
+- **plugins**
+
+  - type: `Array<Function>`
+
+	Um array de funções de plugin a serem aplicadas na _store_ . O plugin simplesmente recebe a _store_  como o único argumento e pode ouvir mutações (para persistência de dados de saída, log ou depuração) ou mutações de despacho (para dados de entrada, por exemplo, websockets ou observáveis).
+
+    [Detalhes](plugins.md)
+
+- **strict**
+
+  - type: `Boolean`
+  - default: `false`
+
+    Força a _store_  Vuex em modo estrito. No modo estrito, qualquer mutação ao estado do Vuex fora dos manipuladores de mutação acusará um erro.
+
+    [Detalhes](strict.md)
+
+### Vuex.Store Propriedades da instância
+
+- **state**
+
+  - type: `Object`
+
+    O estado raiz. Apenas leitura.
+
+- **getters**
+
+  - type: `Object`
+
+    Expõe os getters registrados. Apenas leitura.
+
+### Vuex.Store Métodos da instância
+
+- **`commit(type: string, payload?: any, options?: Object) | commit(mutation: Object, options?: Object)`**
+
+  Confirma uma mutação. `options` pode ter` root: true` que permite confirmar mutações da raiz em [namespaced modules](modules.md#namespacing). [Detalhes](mutations.md)
+
+- **`dispatch(type: string, payload?: any, options?: Object) | dispatch(action: Object, options?: Object)`**
+
+  Despacha uma ação. `options` pode ter `root: true` que permite enviar ações para raiz em [namespaced modules](modules.md#namespacing). Retorna Promise que resolve todos os manipuladores de ação acionados. [Detalhes](actions.md)
+
+- **`replaceState(state: Object)`**
+
+  Substitua o estado da raiz da _store_ . Use isso apenas para fins de hidratação / viagem no tempo.
+
+- **`watch(getter: Function, cb: Function, options?: Object)`**
+
+  Visualiza de forma reativa um valor de retorno da função getter e chame o callback para o retorno de chamada quando o valor mudar. O getter recebe o estado da _store_  como o primeiro argumento e os getters como o segundo argumento. Aceita um objeto de opções opcional que leva as mesmas opções que o método `vm. $ Watch` do Vue.
+
+  Para parar de visualizar, chame para a função do manipulador retornada.
+
+- **`subscribe(handler: Function)`**
+
+  Assina as mutações da _store_ . O `handler` é chamado após cada mutação e recebe o descritor de mutação e o estado pós-mutação como argumentos:
+
+  ``` js
+  store.subscribe((mutation, state) => {
+    console.log(mutation.type)
+    console.log(mutation.payload)
+  })
+  ```
+
+  Usado com mais frequência em plugins. [Detalhes](plugins.md)
+
+- **`subscribeAction(handler: Function)`**
+
+  > Novo em 2.5.0
+
+  Assina as ações da _store_ . O `handler` é chamado para cada ação despachada e recebe o descritor de ação e o estado atual da _store_  como argumentos:
+
+  ``` js
+  store.subscribeAction((action, state) => {
+    console.log(action.type)
+    console.log(action.payload)
+  })
+  ```
+
+  Usado com mais frequência em plugins. [Detalhes](plugins.md)
+
+- **`registerModule(path: string | Array<string>, module: Module, options?: Object)`**
+
+  Registra um módulo dinâmico. [Detalhes](modules.md#dynamic-module-registration)
+
+  `options` pode ter `preserveState: true` que permite preservar o estado anterior. Util para renderização server-side.
+
+- **`unregisterModule(path: string | Array<string>)`**
+
+  Cancela o registro de um módulo dinâmico. [Detalhes](modules.md#dynamic-module-registration)
+
+- **`hotUpdate(newOptions: Object)`**
+
+  Faz Hot swap de novas ações e mutações. [Detalhes](hot-reload.md)
+
+### Component Binding Helpers
+
+- **`mapState(namespace?: string, map: Array<string> | Object): Object`**
+
+  Cria componentes computadas de opções que retornam a subárvore da _store_  Vuex. [Detalhes](state.md#the-mapstate-helper)
+
+  O primeiro argumnto pode ser opcionalmente uma string com namespace. [Detalhes](modules.md#binding-helpers-with-namespace)
+
+- **`mapGetters(namespace?: string, map: Array<string> | Object): Object`**
+
+  Cria componentes computadas de opções que retornam valor avaliado deo getter. [Detalhes](getters.md#the-mapgetters-helper)
+
+  O primeiro argumento pode ser opcionalmente uma string com namespace. [Detalhes](modules.md#binding-helpers-with-namespace)
+
+- **`mapActions(namespace?: string, map: Array<string> | Object): Object`**
+
+  Cria um componente com métodos e opções que despacham uma ação.
+
+[Detalhes](actions.md#dispatching-actions-in-components)
+
+  O primeiro argumento pode ser opcionalmente uma string com namespace. [Detalhes](modules.md#binding-helpers-with-namespace)
+
+- **`mapMutations(namespace?: string, map: Array<string> | Object): Object`**
+
+  Cria um componente com métodos e opções que confirmam uma mutação. [Detalhes](mutations.md#committing-mutations-in-components)
+
+  O primeiro argumento pode ser opcionalmente uma string com namespace. [Detalhes](modules.md#binding-helpers-with-namespace)
+
+- **`createNamespacedHelpers(namespace: string): Object`**
+
+  Cria um component namespaced ajudante de ligação . O objeto retornado possui  `mapState`, `mapGetters`, `mapActions` e `mapMutations`, que estão conectados com o namespace dado. [Detalhes](modules.md#binding-helpers-with-namespace)
+
+

docs/pt-br/book.json

@@ -0,0 +1,19 @@
+{
+  "gitbook": "2.x.x",
+  "plugins": ["edit-link", "prism", "-highlight", "github"],
+  "pluginsConfig": {
+    "edit-link": {
+      "base": "https://github.com/vuejs/vuex/tree/dev/docs",
+      "label": "Edite esta página"
+    },
+    "github": {
+      "url": "https://github.com/vuejs/vuex/"
+    }
+  },
+  "links": {
+    "sharing": {
+      "facebook": false,
+      "twitter": false
+    }
+  }
+}

docs/pt-br/core-concepts.md

@@ -0,0 +1,12 @@
+# Conceitos básicos
+
+Estaremos aprendendo os conceitos básicos do Vuex nestes capítulos. São eles:
+  - [Estado](state.md)
+  - [Getters](getters.md)
+  - [Mutações](mutations.md)
+  - [Ações](actions.md)
+  - [Módulos](modules.md)
+
+Uma compreensão profunda de todos esses conceitos é essencial para o uso de vuex.
+Vamos começar.
+

docs/pt-br/forms.md

@@ -0,0 +1,57 @@
+# Manipulação de formulários
+
+Ao usar o Vuex no modo estrito, pode ser um pouco complicado usar `v-model` em um pedaço de estado que pertence ao Vuex:
+``` html
+<input v-model="obj.message">
+```
+
+Assumindo que `obj` é um dado computado que retorna um objeto da _store_ , o` v-model` aqui tentará mutar diretamente `obj.message` quando o usuário digitar a entrada. No modo estrito, isso resultará em um erro porque a mutação não é realizada dentro de um manipulador de mutação Vuex explícito.
+O "modo Vuex" para lidar com isso é vinculando o valor do(s) `<input>`'s e chamar uma ação no evento `input` ou` change`:
+``` html
+<input :value="message" @input="updateMessage">
+```
+``` js
+// ...
+computed: {
+  ...mapState({
+    message: state => state.obj.message
+  })
+},
+methods: {
+  updateMessage (e) {
+    this.$store.commit('updateMessage', e.target.value)
+  }
+}
+```
+
+E aqui está o manipulador de mutação:
+
+``` js
+// ...
+mutations: {
+  updateMessage (state, message) {
+    state.obj.message = message
+  }
+}
+```
+
+### Dados computados bidirecionais (Two-way)
+
+É certo que o acima é um pouco mais detalhado do que o `v-model` + estado local, e também perdemos alguns dos recursos úteis do `v-model`. Uma abordagem alternativa está usando uma propriedade computada bidirecional com um setter:
+ ``` html
+<input v-model="message">
+```
+``` js
+// ...
+computed: {
+  message: {
+    get () {
+      return this.$store.state.obj.message
+    },
+    set (value) {
+      this.$store.commit('updateMessage', value)
+    }
+  }
+}
+```
+

docs/pt-br/getters.md

@@ -0,0 +1,108 @@
+# Getters
+
+Às vezes, talvez precisemos calcular o estado derivado com base no estado da _store_  , por exemplo, filtrar através de uma lista de itens e contá-los:
+
+``` js
+computed: {
+  doneTodosCount () {
+    return this.$store.state.todos.filter(todo => todo.done).length
+  }
+}
+```
+
+Se mais do que um componente precisa fazer uso disso, temos que duplicar a função, ou extraí-lo em um auxiliar compartilhado e importá-lo em vários lugares - ambos são menos do que o ideal.
+O Vuex nos permite definir "getters" na _store_ . Você pode pensar neles como dados computados para _stores_ . Como os dados computados, o resultado de um getter é armazenado em cache com base em suas dependências e só irá avaliar novamente quando algumas de suas dependências mudarem.
+
+Getters receberam o estado como seu primeiro argumento:
+
+``` js
+const store = new Vuex.Store({
+  state: {
+    todos: [
+      { id: 1, text: '...', done: true },
+      { id: 2, text: '...', done: false }
+    ]
+  },
+  getters: {
+    doneTodos: state => {
+      return state.todos.filter(todo => todo.done)
+    }
+  }
+})
+```
+
+Os getters serão descritos no objeto `store.getters`:
+
+``` js
+store.getters.doneTodos // -> [{ id: 1, text: '...', done: true }]
+```
+
+Getters também receberá outros getters como o segundo argumento:
+
+``` js
+getters: {
+  // ...
+  doneTodosCount: (state, getters) => {
+    return getters.doneTodos.length
+  }
+}
+```
+
+``` js
+store.getters.doneTodosCount // -> 1
+```
+
+Agora podemos usar facilmente isso dentro de qualquer componente:
+
+``` js
+computed: {
+  doneTodosCount () {
+    return this.$store.getters.doneTodosCount
+  }
+}
+```
+
+Você também pode passar argumentos para getters retornando uma função. Isso é particularmente útil quando você deseja consultar um _array_  na _store_ :
+
+```js
+getters: {
+  // ...
+  getTodoById: (state) => (id) => {
+    return state.todos.find(todo => todo.id === id)
+  }
+}
+```
+
+``` js
+store.getters.getTodoById(2) // -> { id: 2, text: '...', done: false }
+```
+
+### O auxiliar `mapGetters`
+
+O auxiliar `mapGetters` simplesmente mapeia os getters da _store_  para os dados computados locais:
+
+``` js
+import { mapGetters } from 'vuex'
+
+export default {
+  // ...
+  computed: {
+    // misturar os getters em dados computados com o spread operator
+    ...mapGetters([
+      'doneTodosCount',
+      'anotherGetter',
+      // ...
+    ])
+  }
+}
+```
+
+Se você deseja mapear um getter para um nome diferente, use um objeto:
+
+``` js
+...mapGetters({
+  // mapeia `this.doneCount` para `store.getters.doneTodosCount`
+  doneCount: 'doneTodosCount'
+})
+```
+

docs/pt-br/getting-started.md

@@ -0,0 +1,43 @@
+# Começando
+
+No centro de cada aplicação Vuex existe a ** loja **. Uma "loja" é basicamente um recipiente que contém a sua aplicação ** state **. Há duas coisas que tornam uma loja Vuex diferente de um objeto global simples:
+
+1. As lojas Vuex são reativas. Quando os componentes do Vue obtêm o estado dele, eles atualizarão de forma reativa e eficiente se o estado da loja mudar.
+
+2. Você não pode mutar diretamente o estado da loja. A única maneira de mudar o estado de uma loja é explicitamente ** comitar mutações **. Isso garante que cada mudança de estado deixe um registro rastreável e permite ferramentas que nos ajudem a entender melhor nossas aplicações.
+
+### A loja mais simples
+
+> **NOTA:** Vamos usar a sintaxe ES2015 para exemplos de código para o resto dos documentos. Se você não o pegou, [você deveria](https://babeljs.io/docs/learn-es2015/)!
+
+Após [instalar](installation.md) Vuex, vamos criar uma loja. É bastante direto - apenas forneça um objeto de estado inicial e algumas mutações:
+
+``` js
+// Certifique-se de chamar Vue.use(Vuex) primeiro se estiver usando um sistema de módulo
+const store = new Vuex.Store({
+  state: {
+    count: 0
+  },
+  mutations: {
+    increment (state) {
+      state.count++
+    }
+  }
+})
+```
+
+Agora, você pode acessar o objeto de estado como `store.state` e acionar uma mudança de estado com o método` store.commit`:
+
+``` js
+store.commit('increment')
+
+console.log(store.state.count) // -> 1
+```
+
+Novamente, a razão pela qual estamos comitando uma mutação em vez de mudar `store.state.count 'diretamente, é porque queremos rastreá-la explicitamente. Esta convenção simples torna sua intenção mais explícita, de modo que você possa argumentar sobre as mudanças de estado em seu aplicativo melhor ao ler o código. Além disso, isso nos dá a oportunidade de implementar ferramentas que podem registrar cada mutação, tirar instantâneos de estado ou mesmo realizar depuração de viagem no tempo.
+Usar o estado da loja em um componente simplesmente envolve o retorno do estado dentro de uma propriedade computada, porque o estado da loja é reativo. Acionar as mudanças simplesmente significa comprometer mutações nos métodos componentes.
+
+Aqui está um exemplo do [aplicativo de contador do Vuex mais básico](https://jsfiddle.net/n9jmu5v7/1269/).
+
+Em seguida, discutiremos cada conceito chave em mais detalhes, começando com [Estado](state.md).
+

docs/pt-br/hot-reload.md

@@ -0,0 +1,44 @@
+# Hot Reloading (recarregamento rapido)
+
+O Vuex suporta hot reloading de mutações, módulos, ações e getters durante o desenvolvimento, usando o pacote do webpack [Hot Module Replacement API](https://webpack.js.org/guides/hot-module-replacement/). Você também pode usá-lo em Browserify com o plugin [browserify-hmr](https://github.com/AgentME/browserify-hmr/).
+
+Para mutações e módulos, você precisa usar o método da API `store.hotUpdate()`:
+
+``` js
+// store.js
+import Vue from 'vue'
+import Vuex from 'vuex'
+import mutations from './mutations'
+import moduleA from './modules/a'
+
+Vue.use(Vuex)
+
+const state = { ... }
+
+const store = new Vuex.Store({
+  state,
+  mutations,
+  modules: {
+    a: moduleA
+  }
+})
+
+if (module.hot) {
+  // Aceita ações e mutações como 'hot modules'
+  module.hot.accept(['./mutations', './modules/a'], () => {
+    // Necessita dos módulos atualizados
+    // Necessário adicionar .default devido ao módulo babel 6
+    const newMutations = require('./mutations').default
+    const newModuleA = require('./modules/a').default
+    // trocar as novas ações e mutações
+     store.hotUpdate({
+      mutations: newMutations,
+      modules: {
+        a: newModuleA
+      }
+    })
+  })
+}
+```
+
+Confira o [counter-hot example](https://github.com/vuejs/vuex/tree/dev/examples/counter-hot) para usar o hot-reload.

docs/pt-br/installation.md

@@ -0,0 +1,76 @@
+# Instalação
+
+### Download Direto / CDN
+
+[https://unpkg.com/vuex](https://unpkg.com/vuex)
+
+<!--email_off-->
+[Unpkg.com](https://unpkg.com) fornece links CDN baseados em NPM. O link acima sempre apontará para a última versão do NPM. Você também pode usar uma versão / tag específica por meio de URLs como `https://unpkg.com/vuex@2.0.0`.
+<!--/email_off-->
+
+Inclua `vuex` após o Vue e ele se instalará automaticamente:
+
+``` html
+<script src="/path/to/vue.js"></script>
+<script src="/path/to/vuex.js"></script>
+```
+
+### NPM
+
+``` bash
+npm install vuex --save
+```
+
+### Yarn
+
+``` bash
+yarn add vuex
+```
+
+Quando usado com sistema de módulos, você deve instalar explicitamente o Vuex via `Vue.use()`:
+
+``` js
+import Vue from 'vue'
+import Vuex from 'vuex'
+
+Vue.use(Vuex)
+```
+
+Você não precisa fazer isso ao usar tags globais de script.
+
+### Promise
+
+Vuex requer [Promise](https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Guide/Usando_promises). Se os seus navegadores não implementarem o Promise (e.g. IE), você pode usar uma polyfill library, como a [es6-promise](https://github.com/stefanpenner/es6-promise).
+
+Você pode incluí-la via CDN:
+
+``` html
+<script src="https://cdn.jsdelivr.net/npm/es6-promise@4/dist/es6-promise.auto.js"></script>
+```
+
+Então `window.Promise` estará disponível automaticamente.
+
+Se você preferir usar um gerenciador de pacotes como NPM ou Yarn, instale-o com os seguintes comandos:
+
+``` bash
+npm install es6-promise --save # NPM
+yarn add es6-promise # Yarn
+```
+
+Além disso, adicione a linha abaixo em qualquer lugar no seu código antes de usar o Vuex:
+
+``` js
+import 'es6-promise/auto'
+```
+
+### Dev Build
+
+Você terá que clonar diretamente do GitHub e fazer o build do `vuex` se
+quiser usar a compilação mais recente do dev.
+
+``` bash
+git clone https://github.com/vuejs/vuex.git node_modules/vuex
+cd node_modules/vuex
+npm install
+npm run build
+```

docs/pt-br/intro.md

@@ -0,0 +1,66 @@
+# O que é Vuex?
+
+O Vuex é um ** padrão de gerenciamento de estado + biblioteca ** para aplicativos Vue.js. Ele serve como uma loja centralizada para todos os componentes em uma aplicação, com regras garantindo que o estado só possa ser mutado de forma previsível.
+Ele também se integra com a versão [devtools extension](https://github.com/vuejs/vue-devtools) do Vue para fornecer recursos avançados, como depuração de tempo-viagem de zero-config e exportação / importação de instantâneo de estado.
+
+### O que é um "Padrão de Gerenciamento do Estado"?
+
+Vamos começar com um simples aplicativo de contador Vue:
+
+``` js
+new Vue({
+  // state
+  data () {
+    return {
+      count: 0
+    }
+  },
+  // view
+  template: `
+    <div>{{ count }}</div>
+  `,
+  // actions
+  methods: {
+    increment () {
+      this.count++
+    }
+  }
+})
+```
+
+É um aplicativo autônomo com as seguintes partes:
+
+- O ** state **, que é a fonte da verdade que impulsiona nosso aplicativo;
+- A ** view **, que é apenas um mapeamento declarativo do ** estado **;
+- As ** actions **, que são as possíveis maneiras pelas quais o estado pode mudar em reação às entradas de usuários da ** view **.
+
+Esta é uma representação extremamente simples do conceito de "fluxo de dados unidirecional":
+<p style="text-align: center; margin: 2em">
+  <img style="width:100%;max-width:450px;" src="./images/flow.png">
+</p>
+
+No entanto, a simplicidade rapidamente se quebra quando temos ** múltiplos componentes que compartilham o estado comum **:
+
+- Várias visualizações podem depender da mesma parte do estado.
+
+- As ações de diferentes views podem precisar mutar a mesma parte de estado
+Para o problema um, passar propriedades pode ser tediosos para componentes profundamente aninhados e simplesmente não funcionam para componentes irmãos. Para o problema dois, muitas vezes nos encontramos recorrendo a soluções como a busca de referências diretas de instâncias pai / filho ou tentando mutar e sincronizar múltiplas cópias do estado através de eventos. Ambos esses padrões são frágeis e rapidamente levam a um código não sustentável.
+
+Então, por que não extraímos o estado compartilhado dos componentes e gerenciamos isso em um singleton global? Com isso, nossa árvore de componentes se torna uma grande "view", e qualquer componente pode acessar o estado ou ações de trigger, não importa onde eles estão na árvore!
+
+Além disso, definindo e separando os conceitos envolvidos na gestão do estado e aplicando certas regras, também damos ao nosso código mais estrutura e capacidade de manutenção.
+
+Esta é a idéia básica por trás do Vuex, inspirada por
+ [Flux](https://facebook.github.io/flux/docs/overview.html), [Redux](http://redux.js.org/) e [The Elm Architecture](https://guide.elm-lang.org/architecture/). Ao contrário dos outros padrões, o Vuex também é uma implementação de biblioteca adaptada especificamente para Vue.js para aproveitar seu sistema de reatividade granular para atualizações eficientes.
+
+![vuex](./images/vuex.png)
+
+### Quando devo usar-lo?
+
+Embora o Vuex nos ajude a lidar com gerenciamento de estado compartilhado, ele também vem com o custo de mais conceitos e relatórios. É um trade-off entre produtividade a curto prazo e longo prazo.
+
+Se você nunca construiu um SPA de grande escala e pulando direito para o Vuex, pode parecer detalhista e assustador. Isso é perfeitamente normal - se o seu aplicativo for simples, você provavelmente estará bem sem o Vuex. Um simples [global event bus](https://br.vuejs.org/v2/guide/components.html#Comunicacao-Nao-Pai-Filho) pode ser tudo o que você precisa. Mas se você estiver construindo um SPA de médio a grande escala, é provável que você tenha encontrado situações que o façam pensar sobre como lidar melhor com o estado fora dos componentes do Vue e o Vuex será o próximo passo natural para você. Há uma boa citação de Dan Abramov, o autor da Redux:
+
+> As bibliotecas Flux são como óculos: você saberá quando você precisar deles.
+
+

docs/pt-br/modules.md

@@ -0,0 +1,286 @@
+# Módulos
+
+Devido ao uso de uma árvore de um único estado, todo o estado do nosso aplicativo está contido dentro de um objeto grande. No entanto, à medida que nossa aplicação cresce em escala, a _store_  pode ficar realmente inchada.
+Para ajudar com isso, o Vuex nos permite dividir nossa _store_  em ** módulos **. Cada módulo pode conter seu próprio estado, mutações, ações, getters e até mesmo módulos aninhados – tudo é "quebrado" daqui pra frente:
+``` js
+const moduleA = {
+  state: { ... },
+  mutations: { ... },
+  actions: { ... },
+  getters: { ... }
+}
+
+const moduleB = {
+  state: { ... },
+  mutations: { ... },
+  actions: { ... }
+}
+
+const store = new Vuex.Store({
+  modules: {
+    a: moduleA,
+    b: moduleB
+  }
+})
+
+store.state.a // -> `moduleA`'s state
+store.state.b // -> `moduleB`'s state
+```
+
+### Estado do local do modulo
+
+Dentro das mutações e getters de um módulo, o 1º argumento recebido será ** o estado local do módulo **.
+
+ ``` js
+const moduleA = {
+  state: { count: 0 },
+  mutations: {
+    increment (state) {
+      // `state` é o estado local do modulo
+      state.count++
+    }
+  },
+
+  getters: {
+    doubleCount (state) {
+      return state.count * 2
+    }
+  }
+}
+```
+
+Da mesma forma, dentro das ações do módulo, `context.state` irá expor o estado local e o estado da raiz será exposto como` context.rootState`:
+
+``` js
+const moduleA = {
+  // ...
+  actions: {
+    incrementIfOddOnRootSum ({ state, commit, rootState }) {
+      if ((state.count + rootState.count) % 2 === 1) {
+        commit('increment')
+      }
+    }
+  }
+}
+```
+
+Além disso, dentro do módulo getters, o estado da raiz será exibido como seu 3º argumento:
+
+``` js
+const moduleA = {
+  // ...
+  getters: {
+    sumWithRootCount (state, getters, rootState) {
+      return state.count + rootState.count
+    }
+  }
+}
+```
+
+### Namespacing
+
+Por padrão, ações, mutações e getters dentro de módulos ainda estão registradas no ** namespace global ** - isso permite que vários módulos reajam com o mesmo tipo de mutação / ação.
+Se você deseja que seus módulos sejam mais autônomos ou reutilizáveis, você pode marcá-lo como namespaced com `namespaced: true`. Quando o módulo é registrado, todos os seus getters, ações e mutações serão automaticamente escritos com nomes com base no caminho no qual o módulo está registrado. Por exemplo:
+
+``` js
+const store = new Vuex.Store({
+  modules: {
+    account: {
+      namespaced: true,
+
+      // module assets
+      state: { ... }, // O estado do módulo já está aninhado e não é afetado pela opção de namespaced
+       getters: {
+        isAdmin () { ... } // -> getters['account/isAdmin']
+      },
+      actions: {
+        login () { ... } // -> dispatch('account/login')
+      },
+      mutations: {
+        login () { ... } // -> commit('account/login')
+      },
+
+      // módulos aninhados
+      modules: {
+        // herda o namespace do modulo pai
+        myPage: {
+          state: { ... },
+          getters: {
+            profile () { ... } // -> getters['account/profile']
+          }
+        },
+
+        // aninhar ainda mais o namespace
+        posts: {
+          namespaced: true,
+
+          state: { ... },
+          getters: {
+            popular () { ... } // -> getters['account/posts/popular']
+          }
+        }
+      }
+    }
+  }
+})
+```
+
+Os getters e as ações Namespaced receberão `getters`,` dispatch` e `commit` localizados. Em outras palavras, você pode usar os recursos do módulo sem prefixo de escrita no mesmo módulo. Alternar entre namespaced ou não não afeta o código dentro do módulo.
+
+#### Acessando ativos globais em módulos de Namespaced
+
+Se você quiser usar estado global e getters, `rootState` e` rootGetters` são passados como o 3º e 4º argumentos para funções getter, e também expostos como propriedades no objeto `context` passado para funções de ação.
+
+Para enviar ações ou fazer um commit de mutações no namespace global, passe `{root: true}` como o 3º argumento para `dispatch 'e' commit '.
+ ``` js
+modules: {
+  foo: {
+    namespaced: true,
+
+    getters: {
+      // `getters` está localizado nos getters deste módulo
+      // você pode usar rootGetters como 4º argumento de getters
+      someGetter (state, getters, rootState, rootGetters) {
+        getters.someOtherGetter // -> 'foo/someOtherGetter'
+        rootGetters.someOtherGetter // -> 'someOtherGetter'
+      },
+      someOtherGetter: state => { ... }
+    },
+
+    actions: {
+      // despachar e confirmar também estão localizados para este módulo
+      // eles aceitarão a opção `root` para o envio / commit da raiz
+
+      someAction ({ dispatch, commit, getters, rootGetters }) {
+        getters.someGetter // -> 'foo/someGetter'
+        rootGetters.someGetter // -> 'someGetter'
+
+        dispatch('someOtherAction') // -> 'foo/someOtherAction'
+        dispatch('someOtherAction', null, { root: true }) // -> 'someOtherAction'
+
+        commit('someMutation') // -> 'foo/someMutation'
+        commit('someMutation', null, { root: true }) // -> 'someMutation'
+      },
+      someOtherAction (ctx, payload) { ... }
+    }
+  }
+}
+```
+
+#### Ligando Auxiliares com namespace
+
+Ao vincular um módulo com namespace aos componentes com os auxiliares `mapState`,` mapGetters`, `mapActions` e` mapMutations`, ele pode ficar um pouco verboso:
+``` js
+computed: {
+  ...mapState({
+    a: state => state.some.nested.module.a,
+    b: state => state.some.nested.module.b
+  })
+},
+methods: {
+  ...mapActions([
+    'some/nested/module/foo',
+    'some/nested/module/bar'
+  ])
+}
+```
+
+Nesses casos, você pode passar a string de namespace do módulo como o 1º argumento para os auxiliares para que todas as ligações sejam feitas usando esse módulo como contexto. O anterior pode ser simplificado para:
+
+
+``` js
+computed: {
+  ...mapState('some/nested/module', {
+    a: state => state.a,
+    b: state => state.b
+  })
+},
+methods: {
+  ...mapActions('some/nested/module', [
+    'foo',
+    'bar'
+  ])
+}
+```
+
+Além disso, você pode criar helpers com nomes usando o `createNamespacedHelpers`. Ele retorna um objeto com novos auxiliares de ligação de componentes que estão vinculados com o valor de namespace fornecido:
+
+``` js
+import { createNamespacedHelpers } from 'vuex'
+
+const { mapState, mapActions } = createNamespacedHelpers('some/nested/module')
+
+export default {
+  computed: {
+    // look up in `some/nested/module`
+    ...mapState({
+      a: state => state.a,
+      b: state => state.b
+    })
+  },
+  methods: {
+    // look up in `some/nested/module`
+    ...mapActions([
+      'foo',
+      'bar'
+    ])
+  }
+}
+```
+
+#### Advertência para desenvolvedores de plugin
+Você pode se preocupar com o namespacing imprevisível para seus módulos quando você cria um [plugin](plugins.md) que fornece os módulos e permite que os usuários os adicionem a uma _store_  Vuex. Seus módulos serão também escritos por namespacing se os usuários do plugin adicionarem seus módulos em um módulo namespace. Para adaptar esta situação, talvez seja necessário receber um valor de namespace através da opção do plugin:
+
+``` js
+// pega o valor do namespace via opção de plugin
+// e retorna a função de plugin Vuex
+export function createPlugin (options = {}) {
+  return function (store) {
+    // add namespace to plugin module's types
+    const namespace = options.namespace || ''
+    store.dispatch(namespace + 'pluginAction')
+  }
+}
+```
+
+### Registro de módulo dinâmico
+Você pode registrar um módulo ** após ** a _store_  foi criada com o método `store.registerModule`:
+
+``` js
+// register a module `myModule`
+store.registerModule('myModule', {
+  // ...
+})
+
+// register a nested module `nested/myModule`
+store.registerModule(['nested', 'myModule'], {
+  // ...
+})
+```
+
+O estado do módulo será exposto como `store.state.myModule` e` store.state.nested.myModule`.
+O registro de módulo dinâmico torna possível que outros plugins do Vue também alavancem o Vuex para gerenciamento de estado anexando um módulo à _store_  do aplicativo. Por exemplo, a biblioteca [`vuex-router-sync`](https://github.com/vuejs/vuex-router-sync) integra vue-router com vuex, gerenciando o estado da rota do aplicativo em um módulo anexado dinamicamente.
+
+Você também pode remover um módulo registrado dinamicamente com `store.unregisterModule (moduleName)`. Observe que você não pode remover módulos estáticos (declarados na criação da _store_ ) com este método.
+Pode ser provável que você queira preservar o estado anterior ao registrar um novo módulo, como preservar o estado de um aplicativo Server Side Rendered. Você pode conseguir isso com a opção `preserveState`:` store.registerModule ('a', module, {preserveState: true}) `
+
+### Reutilização do Módulo
+Às vezes, talvez precisemos criar várias instâncias de um módulo, por exemplo:
+
+- Criando várias _stores_  que usam o mesmo módulo (por exemplo, para [evitar Singletons com informações de estado no SSR](https://ssr.vuejs.org/en/structure.html#avoid-statelet-singletons) quando a opção `runInNewContext` é `false` ou `'once'`);
+- Registre o mesmo módulo várias vezes na mesma _store_ .
+
+Se usarmos um objeto simples para declarar o estado do módulo, esse objeto de estado será compartilhado por referência e causará poluição do estado do armazenamento / módulo quando estiver mutado.
+Este é exatamente o mesmo problema com `data` dentro dos componentes do Vue. Portanto, a solução também é a mesma - use uma função para declarar o estado do módulo (suportado em 2.3.0+):
+
+``` js
+const MyReusableModule = {
+  state () {
+    return {
+      foo: 'bar'
+    }
+  },
+  // mutações, ações, getters...
+}
+```
+

docs/pt-br/mutations.md

@@ -0,0 +1,171 @@
+# Mutações
+
+A única maneira de mudar o estado em uma _store_  Vuex é fazendo _commit_  de uma mutação. As mutações Vuex são muito semelhantes aos eventos: cada mutação possui uma string ** tipo ** e um ** manipulador **. A função do manipulador é onde nós executamos modificações de estado reais e receberá o estado como o primeiro argumento:
+
+``` js
+const store = new Vuex.Store({
+  state: {
+    count: 1
+  },
+  mutations: {
+    increment (state) {
+      // muda o estado
+      state.count++
+    }
+  }
+})
+```
+
+Você não pode chamar diretamente um manipulador de mutação. Pense nisso mais como registro de eventos: "Quando uma mutação com tipo `incremento` é ativada, chame esse manipulador." Para invocar um manipulador de mutação, você precisa chamar `store.commit` com seu tipo:
+
+``` js
+store.commit('increment')
+```
+
+### Commit com payload
+
+Você pode passar um argumento adicional para `store.commit`, que é chamado de ** payload ** para a mutação:
+
+``` js
+// ...
+mutations: {
+  increment (state, n) {
+    state.count += n
+  }
+}
+```
+``` js
+store.commit('increment', 10)
+```
+
+Na maioria dos casos, o payload deve ser um objeto para que ele possa conter vários campos e a mutação gravada também será mais descritiva:
+
+``` js
+// ...
+mutations: {
+  increment (state, payload) {
+    state.count += payload.amount
+  }
+}
+```
+
+``` js
+store.commit('increment', {
+  amount: 10
+})
+```
+
+### Commit com Object-Style
+
+Uma maneira alternativa de confirmar uma mutação é usando diretamente um objeto que possui uma propriedade `type`:
+``` js
+store.commit({
+  type: 'increment',
+  amount: 10
+})
+```
+
+Ao fazer um _commit_  com object-style, todo o objeto será passado como payload para os manipuladores de mutação, de modo que o manipulador permaneça o mesmo:
+
+``` js
+mutations: {
+  increment (state, payload) {
+    state.count += payload.amount
+  }
+}
+```
+
+### Mutações seguem as regras de reatividade do Vue
+
+Uma vez que o estado de uma _store_  Vuex é reativo para o Vue, quando mutar o estado, os componentes Vue que observam o estado serão atualizados automaticamente. Isso também significa que as mutações Vuex estão sujeitas às mesmas ressalvas de reatividade quando se trabalha com apenas Vue:
+
+1. Prefira inicializar o estado inicial da sua _store_  com todos os campos desejados antecipadamente.
+
+2. Ao adicionar novas propriedades a um objeto, você deve:
+
+  - Use `Vue.set(obj, 'newProp', 123)`, ou
+
+
+  - Substitua esse Objeto por um novo. Por exemplo, usando o estágio 3 [object spread syntax](https://github.com/sebmarkbage/ecmascript-rest-restpread), podemos gravá-lo assim:
+
+
+    ``` js
+    state.obj = { ...state.obj, newProp: 123 }
+    ```
+
+### Usando Constantes para Tipos de Mutação
+
+É um padrão normalmente visto para usar constantes para tipos de mutação em várias implementações de Flux. Isso permite que o código aproveite ferramentas como linters e colocar todas as constantes em um único arquivo permite que seus colaboradores tenham uma visão rápida de quais mutações são possíveis em todo o aplicativo:
+
+``` js
+// mutation-types.js
+export const SOME_MUTATION = 'SOME_MUTATION'
+```
+
+``` js
+// store.js
+import Vuex from 'vuex'
+import { SOME_MUTATION } from './mutation-types'
+
+const store = new Vuex.Store({
+  state: { ... },
+  mutations: {
+    // podemos usar o recurso de dado computado do ES2015
+    // usar uma constante como o nome da função
+    [SOME_MUTATION] (state) {
+      // mutate state
+    }
+  }
+})
+```
+
+Querer usar constantes é ,em grande parte, uma preferência - pode ser útil em grandes projetos com muitos desenvolvedores, mas é totalmente opcional se você não gosta deles.
+
+### Mutações devem ser síncronas
+
+Uma regra importante a lembrar é que ** as funções do manipulador de mutação devem ser síncronas **. Por quê? Considere o seguinte exemplo:
+``` js
+mutations: {
+  someMutation (state) {
+    api.callAsyncMethod(() => {
+      state.count++
+    })
+  }
+}
+```
+
+Agora imagine que estamos depurando o aplicativo e observamos os registros de mutação do devtool. Para cada mutação registrada, o devtool precisará capturar "antes" e "depois" _snapshots_  do estado. No entanto, o retorno de chamada assíncrono dentro da mutação de exemplo acima torna isso impossível: o _callback_  ainda não foi chamado quando a mutação foi comitada, e não existe nenhuma maneira para o devtool saber quando o _callback_  será chamado - qualquer mutação de estado realizada no retorno desse _callback_  é essencialmente não rastreável!
+
+### Fazendo commit de Mutações em Componente
+Você pode fazer um commit de mutações em componentes com `this.$store.commit('xxx')`, ou use o auxiliar `mapMutations` que mapeia métodos de componente para chamadas` store.commit` (requer a injeção root `store`):
+``` js
+import { mapMutations } from 'vuex'
+
+export default {
+  // ...
+  methods: {
+    ...mapMutations([
+      'increment', // mapeia `this.increment()` para `this.$store.commit('increment')`
+
+      // `mapMutations` também suporta payloads:
+      'incrementBy' // mapeia `this.incrementBy(amount)` para `this.$store.commit('incrementBy', amount)`
+    ]),
+    ...mapMutations({
+      add: 'increment' // mapeia `this.add()` para `this.$store.commit('increment')`
+    })
+  }
+}
+```
+
+### Ações
+
+Assincronicidade combinada com a mutação do estado pode tornar o seu programa muito difícil de acontecer. Por exemplo, quando você chama dois métodos com retrocessos assíncronos que mutam o estado, como você sabe quando eles são chamados e qual callback foi chamado primeiro? É exatamente por isso que queremos separar os dois conceitos. No Vuex, as mutações ** são transações síncronas **:
+
+``` js
+store.commit('increment')
+// qualquer alteração de estado que a mutação "incrementar" possa causar
+// deve ser feita neste momento
+```
+
+Para lidar com operações assíncronas, vamos apresentar as [Ações](actions.md).
+

docs/pt-br/plugins.md

@@ -0,0 +1,130 @@
+# Plugins
+
+As _stores_ do Vuex aceitam a opção `plugins` que expõe hooks para cada mutação. Um plugin Vuex é simplesmente uma função que recebe uma store como seu único argumento:
+
+
+``` js
+const myPlugin = store => {
+  // chamado quando a store é inicializada
+  store.subscribe((mutation, state) => {
+    // chamada após cada mutação
+    // a mutação vem no formato `{ type, payload }`.
+  })
+}
+```
+
+E pode ser usada assim:
+
+``` js
+const store = new Vuex.Store({
+  // ...
+  plugins: [myPlugin]
+})
+```
+
+### Fazendo Commit de Mutações dentro de Plugins
+
+Plugins não tem permissão para mudar diretamente o estado - similar aos componentes, eles podem apenas disparar mudanças fazendo commit de mutações.
+
+Ao fazer um commit de uma mutação, um plugin pode ser usado para sincronizar uma fonte de dados à _store_ . Por exemplo, para sincronizar uma fonte de dados websocket à _store_  (isso é só um exemplo inventado, na realidade a função `createPlugin` pode receber parâmetros adicionais para tarefas mais complexas):
+
+
+``` js
+export default function createWebSocketPlugin (socket) {
+  return store => {
+    socket.on('data', data => {
+      store.commit('receiveData', data)
+    })
+    store.subscribe(mutation => {
+      if (mutation.type === 'UPDATE_DATA') {
+        socket.emit('update', mutation.payload)
+      }
+    })
+  }
+}
+```
+
+``` js
+const plugin = createWebSocketPlugin(socket)
+
+const store = new Vuex.Store({
+  state,
+  mutations,
+  plugins: [plugin]
+})
+```
+
+### Gravando Snapshots do Estado
+
+Às vezes, um plugin pode querer receber "snapshots" do estado, e comparar o estado pós-mutação com o pré-mutação. Para conseguir isso, você precisa fzer uma cópia profunda do objeto de estado:
+
+
+``` js
+const myPluginWithSnapshot = store => {
+  let prevState = _.cloneDeep(store.state)
+  store.subscribe((mutation, state) => {
+    let nextState = _.cloneDeep(state)
+
+    // compara `prevState` e `nextState`...
+
+    // salva o estado para a próxima mutação
+    prevState = nextState
+  })
+}
+```
+
+**Plugins que tiram snapshots do estado devem ser usados apenas durante o desenvolvimento.** Quando usamos webpack ou Browserify, podemos construir nossas próprias ferramentas que lidam com isso para nós:
+
+``` js
+const store = new Vuex.Store({
+  // ...
+  plugins: process.env.NODE_ENV !== 'production'
+    ? [myPluginWithSnapshot]
+    : []
+})
+```
+
+O plugin vai ser usado por padrão. Para produção, você vai precisar do [DefinePlugin](https://webpack.github.io/docs/list-of-plugins.html#defineplugin) para webpack ou [envify](https://github.com/hughsk/envify) para Browserify para converter o valor de  `process.env.NODE_ENV !== 'production'` para `false` na build final.
+
+### Plugin de Log Embutido
+
+> Se você está usando [vue-devtools](https://github.com/vuejs/vue-devtools) provavelmente não precisará disso.
+
+Vuex vem com um plugin de log para casos comuns de debug:
+
+
+``` js
+import createLogger from 'vuex/dist/logger'
+
+const store = new Vuex.Store({
+  plugins: [createLogger()]
+})
+```
+
+A função `createLogger` recebe alguns argumentos:
+
+``` js
+const logger = createLogger({
+  collapsed: false, // expande automaticamente funções logadas
+  filter (mutation, stateBefore, stateAfter) {
+    // retorna `true` se a mutação deve ser logada
+    // `mutation` é uma `{ type, payload }`
+    return mutation.type !== "aBlacklistedMutation"
+  },
+  transformer (state) {
+    // transforma o estado antes de logá-lo
+    // por exemplo, retorna apenas uma sub-árvore específica
+    return state.subTree
+  },
+  mutationTransformer (mutation) {
+    // mutações são logadas no formato `{ type, payload }`
+    // mas podemos formatá-las como quiser.
+    return mutation.type
+  },
+  logger: console, // implementação da API `console`, default `console`
+})
+```
+
+O arquivo de log também pode ser incluído diretamente via tag `<script>` e vai expor a função `createVuexLogger` globalmente.
+
+Perceba que esses plugins tiram snapshots do estado, então use-os apenas durante o desenvolvimento.

docs/pt-br/state.md

@@ -0,0 +1,105 @@
+# Estado
+
+### Árvore simples de estado
+
+O Vuex usa uma ** árvore de estado único ** - isto é, este único objeto contém todo o seu nível de aplicativo e serve como "fonte única de verdade". Isso também significa que você terá apenas uma loja para cada aplicativo. Uma única árvore de estados torna direto localizar um pedaço de estado específico e nos permite facilmente tirar instantâneos do estado do aplicativo atual para fins de depuração.
+
+A árvore de um único estado não entra em conflito com a modularidade - em capítulos posteriores, discutiremos como dividir seu estado e mutações em sub-módulos.
+### Obtendo o Vuex State em Vue Components
+
+Então, como exibimos o estado dentro da loja em nossos componentes do Vue? Uma vez que as lojas Vuex são reativas, a maneira mais simples de "recuperar" o estado é simplesmente retornar algum estado da loja dentro de um [dado computado](https://br.vuejs.org/v2/guide/computed.html):
+
+``` js
+// vamos criar um componente de contador
+const Counter = {
+  template: `<div>{{ count }}</div>`,
+  computed: {
+    count () {
+      return store.state.count
+    }
+  }
+}
+```
+
+Sempre que o `store.state.count` muda, fará com que a propriedade computada seja reavaliada e ative as atualizações de DOM associadas.
+No entanto, esse padrão faz com que o componente dependa no singleton da loja global. Ao usar um sistema de módulo, ele precisa importar a loja em todos os componentes que usam o estado da loja e também requer mocking ao testar o componente.
+
+O Vuex fornece um mecanismo para "injetar" a loja em todos os componentes filho do componente raiz com a opção `store` (habilitada por` Vue.use (Vuex) `):
+``` js
+const app = new Vue({
+  el: '#app',
+  // forneça a loja usando a opção "store".
+  // isso irá injetar a instância da loja em todos os componentes filho.  store,
+  components: { Counter },
+  template: `
+    <div class="app">
+      <counter></counter>
+    </div>
+  `
+})
+```
+
+Ao fornecer a opção `store` para a instância raiz, a loja será injetada em todos os componentes filho da raiz e estará disponível neles como esta. $ Store`. Vamos atualizar a nossa implementação `Counter`:
+
+``` js
+const Counter = {
+  template: `<div>{{ count }}</div>`,
+  computed: {
+    count () {
+      return this.$store.state.count
+    }
+  }
+}
+```
+
+### O auxiliar `mapState`
+
+Quando um componente precisa fazer uso de várias propriedades de estado da loja ou getters, declarar que todas essas propriedades computadas podem ser repetitivas e verbosas. Para lidar com isso, podemos usar o ajudante `mapState` que gera funções getter computadas para nós, economizando algumas linhas de código:
+
+``` js
+// em pleno desenvolvimento, os ajudantes são expostos como Vuex.mapState
+ import { mapState } from 'vuex'
+
+export default {
+  // ...
+  computed: mapState({
+    // As funções de seta podem tornar o código muito sucinto!    count: state => state.count,
+
+    // passar o valor da string 'count' é o mesmo que `state => state.count`
+    countAlias: 'count',
+
+    // para acessar o estado local com `this`, uma função normal deve ser usada
+     countPlusLocalState (state) {
+      return state.count + this.localCount
+    }
+  })
+}
+```
+
+Também podemos passar uma matriz de seqüência de caracteres para `mapState` quando o nome de uma propriedade calculada mapeada é o mesmo que um nome de árvore secundária de estado.
+
+``` js
+computed: mapState([
+  // map this.count to store.state.count
+  'count'
+])
+```
+
+### Operador de propagação de objetos (_ES2015_ _Spread_ _Operator_ )
+
+Observe que `mapState` retorna um objeto. Como usá-lo em combinação com outras propriedades locais computadas? Normalmente, teríamos que usar um utilitário para fundir vários objetos em um para que possamos passar o objeto final para `computado`. No entanto, com o [operador de propagação de objetos](https://github.com/sebmarkbage/ecmascript-rest-spread) (que é uma proposta de ECMAScript em estágio 3), podemos simplificar muito a sintaxe:
+
+``` js
+computed: {
+  localComputed () { /* ... */ },
+  // Misture isso no objeto externo com o operador de propagação do objeto
+
+  ...mapState({
+    // ...
+  })
+}
+```
+
+### Componentes ainda podem ter um estado local
+
+O uso do Vuex não significa que você deve colocar ** all ** no estado no Vuex. Embora colocar mais estado no Vuex torna suas mutações estatais mais explícitas e devolvíveis, às vezes também pode tornar o código mais detalhado e indireto. Se um pedaço de estado pertence estritamente a um único componente, pode ser apenas bom deixá-lo como um estado local. Você deve pesar os trade-offs e tomar decisões que atendam às necessidades de desenvolvimento do seu aplicativo.

docs/pt-br/strict.md

@@ -0,0 +1,26 @@
+# Modo estrito
+
+Para habilitar o modo estrito, simplesmente passe `strict: true` ao criar uma _store_  Vuex:
+
+``` js
+const store = new Vuex.Store({
+  // ...
+  strict: true
+})
+```
+
+Em modo estrito, sempre que o estado do Vuex é mutado fora dos manipuladores de mutação, um erro será lançado. Isso garante que todas as mutações do estado possam ser explicitamente rastreadas por ferramentas de depuração.
+
+### Desenvolvimento vs. Produção
+
+** Não habilite o modo estrito ao implantar para a produção! ** O modo estrito executa um observador profundo síncrono na árvore de estados para detectar mutações inapropriadas e pode ser bastante caro quando você faz grande quantidade de mutações no estado. Certifique-se de desligá-lo na produção para evitar o custo de desempenho.
+
+Semelhante aos plugins, podemos deixar as ferramentas de compilação lidar com isso:
+
+``` js
+const store = new Vuex.Store({
+  // ...
+  strict: process.env.NODE_ENV !== 'production'
+})
+```
+

docs/pt-br/structure.md

@@ -0,0 +1,31 @@
+# Estrutura da aplicação
+
+O Vuex não restringe realmente como você estrutura seu código. Em vez disso, ele impõe um conjunto de princípios de alto nível:
+
+1. O estado do nível de aplicativo é centralizado na _store_ .
+
+2. A única maneira de mudar o estado é fazendo commit das ** mutações **, que são transações síncronas.
+
+3. A lógica assíncrona deve ser encapsulada e pode ser composta com ** ações **.
+Enquanto você seguir estas regras, depende de você como estruturar seu projeto. Se o arquivo da sua _store_  for muito grande, basta começar a dividir as ações, mutações e getters em arquivos separados.
+
+Para qualquer aplicativo não trivial, provavelmente precisaremos alavancar módulos. Aqui está uma estrutura de projeto de exemplo:
+
+``` bash
+├── index.html
+├── main.js
+├── api
+│   └── ... # abstrações para fazer pedidos de API
+├── components
+│   ├── App.vue
+│   └── ...
+└── store
+    ├── index.js          # onde montamos módulos e exportamos a store    ├── actions.js            # ações da raiz
+    ├── mutations.js      # mutações da raiz
+    └── modules
+        ├── cart.js       # modulo cart
+        └── products.js   # modulo products
+```
+
+Como referência, confira o [Exemplo do carrinho de compras](https://github.com/vuejs/vuex/tree/dev/examples/shopping-cart).
+

docs/pt-br/testing.md

@@ -0,0 +1,219 @@
+# Testando
+
+As partes principais que queremos testar em Vuex são mutações e ações.
+### Testando Mutações
+As mutações são muito simples de testar, porque são apenas funções que dependem completamente de seus argumentos. Um truque é que se você estiver usando módulos ES2015 e colocar suas mutações dentro do arquivo `store.js`, além da exportação padrão, você também deve exportar as mutações como uma exportação nomeada:
+
+``` js
+const state = { ... }
+
+// exportar `mutações` como uma exportação nomeada
+export const mutations = { ... }
+
+export default new Vuex.Store({
+  state,
+  mutations
+})
+```
+
+Exemplo de teste de uma mutação usando Mocha + Chai (você pode usar qualquer biblioteca de estrutura / asserção que você gosta):
+
+``` js
+// mutations.js
+export const mutations = {
+  increment: state => state.count++
+}
+```
+
+``` js
+// mutations.spec.js
+import { expect } from 'chai'
+import { mutations } from './store'
+
+// destructure assign `mutations`
+const { increment } = mutations
+
+describe('mutations', () => {
+  it('INCREMENT', () => {
+    // mock state
+    const state = { count: 0 }
+    // apply mutation
+    increment(state)
+    // assert result
+    expect(state.count).to.equal(1)
+  })
+})
+```
+
+### Testando ações
+
+As ações podem ser um pouco mais complicadas porque podem chamar as APIs externas. Ao testar ações, geralmente precisamos fazer algum nível de _mocking_  - por exemplo, podemos resumir as chamadas da API em um serviço e simular esse serviço dentro de nossos testes. A fim de simular facilmente as dependências, podemos usar o webpack e [injetor-carregador](https://github.com/plasticine/inject-loader) para agrupar nossos arquivos de teste.
+
+Exemplo de teste de uma ação assíncrona:
+
+``` js
+// actions.js
+import shop from '../api/shop'
+
+export const getAllProducts = ({ commit }) => {
+  commit('REQUEST_PRODUCTS')
+  shop.getProducts(products => {
+    commit('RECEIVE_PRODUCTS', products)
+  })
+}
+```
+
+``` js
+// actions.spec.js
+
+// uso a sintaxe 'require' para inline loaders.
+// com inject-loader, isso retorna uma factory de módulos
+// que nos permite injetar dependências simuladas. import { expect } from 'chai'
+const actionsInjector = require('inject-loader!./actions')
+
+// crie o módulo com nossos mocks
+const actions = actionsInjector({
+  '../api/shop': {
+    getProducts (cb) {
+      setTimeout(() => {
+        cb([ /* mocked response */ ])
+      }, 100)
+    }
+  }
+})
+
+// ajudante para teste de ação com mutações esperadas
+const testAction = (action, payload, state, expectedMutations, done) => {
+  let count = 0
+
+  // mock commit
+  const commit = (type, payload) => {
+    const mutation = expectedMutations[count]
+
+    try {
+      expect(mutation.type).to.equal(type)
+      if (payload) {
+        expect(mutation.payload).to.deep.equal(payload)
+      }
+    } catch (error) {
+      done(error)
+    }
+
+    count++
+    if (count >= expectedMutations.length) {
+      done()
+    }
+  }
+
+  // chame a ação com uma loja e argumentos simulados
+   action({ commit, state }, payload)
+
+  // verificar se nenhuma mutação deveria ter sido enviada
+  if (expectedMutations.length === 0) {
+    expect(count).to.equal(0)
+    done()
+  }
+}
+
+describe('actions', () => {
+  it('getAllProducts', done => {
+    testAction(actions.getAllProducts, null, {}, [
+      { type: 'REQUEST_PRODUCTS' },
+      { type: 'RECEIVE_PRODUCTS', payload: { /* mocked response */ } }
+    ], done)
+  })
+})
+```
+
+### Testando Getters
+
+Se seus getters tiverem uma computação complicada, vale a pena testá-los. Os Getters também são muito diretos para testar o mesmo motivo que as mutações.
+
+Exemplo testando um getter:
+``` js
+// getters.js
+export const getters = {
+  filteredProducts (state, { filterCategory }) {
+    return state.products.filter(product => {
+      return product.category === filterCategory
+    })
+  }
+}
+```
+
+``` js
+// getters.spec.js
+import { expect } from 'chai'
+import { getters } from './getters'
+
+describe('getters', () => {
+  it('filteredProducts', () => {
+    // mock state
+    const state = {
+      products: [
+        { id: 1, title: 'Apple', category: 'fruit' },
+        { id: 2, title: 'Orange', category: 'fruit' },
+        { id: 3, title: 'Carrot', category: 'vegetable' }
+      ]
+    }
+    // mock getter
+    const filterCategory = 'fruit'
+
+    // obter o resultado do getter
+    const result = getters.filteredProducts(state, { filterCategory })
+
+    // afirma o resultado
+    expect(result).to.deep.equal([
+      { id: 1, title: 'Apple', category: 'fruit' },
+      { id: 2, title: 'Orange', category: 'fruit' }
+    ])
+  })
+})
+```
+
+### Execução de testes
+
+Se suas mutações e ações estiverem escritas corretamente, os testes não devem ter dependência direta das APIs do navegador após uma mudança apropriada. Assim, você pode simplesmente agrupar os testes com o webpack e executá-lo diretamente no Node. Alternativamente, você pode usar `mocha-loader` ou Karma +` karma-webpack` para executar os testes em navegadores reais.
+
+#### Rodando no Node
+
+Crie a seguinte configuração de webpack (juntamente com [`.babelrc`](https://babeljs.io/docs/usage/babelrc/)):
+
+``` js
+// webpack.config.js
+module.exports = {
+  entry: './test.js',
+  output: {
+    path: __dirname,
+    filename: 'test-bundle.js'
+  },
+  module: {
+    loaders: [
+      {
+        test: /\.js$/,
+        loader: 'babel-loader',
+        exclude: /node_modules/
+      }
+    ]
+  }
+}
+```
+
+Então:
+
+``` bash
+webpack
+mocha test-bundle.js
+```
+
+#### Rodando no Browser
+
+1. Instale `mocha-loader`.
+2. Mude a `entrada` da configuração do webpack acima para `'mocha-loader! Babel-loader! ./ test.js'`.
+3. Inicie `webpack-dev-server` usando a configuração.
+4. Vá para `localhost: 8080 / webpack-dev-server / test-bundle`.
+
+#### Rodando no Browser com Karma + karma-webpack
+
+Consulte a instalação na [documentação do vue-loader](https://vue-loader.vuejs.org/pt_BR/workflow/testing.html).
+