Portuguese Translation (#1302)

* First Commit

* Translated the inital files

* Translated the api docs

* Translate some files

* Translate some more files

* One more file

* made some fixes in translation

* made some fixes in translation

* make some fixes and translates

* Add more translations and fixes

* Add more translations and fixes

* Add the last file translated

docs/.vuepress/config.js

@@ -24,6 +24,11 @@ module.exports = {
       lang: 'kr',
       title: 'Vuex',
       description: 'Vue.js의 중앙 상태 관리'
+    },
+    '/ptbr/': {
+      lang: 'pt-BR',
+      title: 'Vuex',
+      description: 'Gerenciamento de Estado Centralizado para Vue.js'
     }
   },
   serviceWorker: true,
@@ -234,6 +239,47 @@ module.exports = {
           '/kr/guide/testing',
           '/kr/guide/hot-reload'
         ]
+      },
+      '/ptbr/': {
+        label: 'Português',
+        selectText: 'Idiomas',
+        editLinkText: 'Edite esta página no GitHub',
+        nav: [
+          {
+            text: 'Guia',
+            link: '/ptbr/guide/'
+          },
+          {
+            text: 'Referência da API',
+            link: '/ptbr/api/'
+          },
+          {
+            text: 'Notas da Versão',
+            link: 'https://github.com/vuejs/vuex/releases'
+          }
+        ],
+        sidebar: [
+          '/ptbr/installation',
+          '/ptbr/',
+          '/ptbr/guide/',
+          {
+            title: 'Conceitos Básicos',
+            collapsable: false,
+            children: [
+              '/ptbr/guide/state',
+              '/ptbr/guide/getters',
+              '/ptbr/guide/mutations',
+              '/ptbr/guide/actions',
+              '/ptbr/guide/modules'
+            ]
+          },
+          '/ptbr/guide/structure',
+          '/ptbr/guide/plugins',
+          '/ptbr/guide/strict',
+          '/ptbr/guide/forms',
+          '/ptbr/guide/testing',
+          '/ptbr/guide/hot-reload'
+        ]
       }
     }
   }

docs/ptbr/README.md

@@ -0,0 +1,63 @@
+# O que é Vuex?
+
+O Vuex é um **padrão de gerenciamento de estado + biblioteca** para aplicativos Vue.js. Ele serve como um _store_ centralizado 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 extensão oficial [Vue devtools](https://github.com/vuejs/vue-devtools) para fornecer recursos avançados sem configurações adicionais, como depuração viajando pelo histórico de estado (_time travel_) e exportação/importação de registros de estado em determinado momento.
+
+### O que é um "Padrão de Gerenciamento do Estado"?
+
+Vamos começar com um aplicativo simples de contador Vue:
+
+``` js
+new Vue({
+  // state
+  data () {
+    return {
+      count: 0
+    }
+  },
+  // view
+  template: `
+    <div>{{ count }}</div>
+  `,
+  // actions
+  methods: {
+    increment () {
+      this.count++
+    }
+  }
+})
+```
+
+É um aplicativo independente com as seguintes partes:
+
+- O **estado** (_state_), que é a fonte da verdade que direciona nosso aplicativo;
+- A **_view_**, que é apenas um mapeamento declarativo do **estado**;
+- As **ações** (_actions_), que são as possíveis maneiras pelas quais o estado pode mudar em reação às interações dos usuários da **_view_**.
+
+Esta é uma representação extremamente simples do conceito de "fluxo de dados unidirecional" (_one-way_):
+
+<p style="text-align: center; margin: 2em">
+  <img style="width:100%;max-width:450px;" src="/flow.png">
+</p>
+
+No entanto, a simplicidade é quebrada rapidamente quando temos **vários componentes que compartilham um estado comum**:
+
+- Múltiplas _views_ podem depender do mesmo pedaço de estado.
+- Ações de diferentes _views_ podem precisar mudar o mesmo pedaço de estado.
+
+Para o problema um, passar propriedades pode ser entediante para componentes profundamente aninhados e simplesmente não funcionam para componentes irmãos. Para o problema dois, frequentemente nos encontramos recorrendo a soluções como alcançar referências diretas da instância pai/filho ou tentar alterar e sincronizar várias cópias do estado por meio de eventos. Ambos os padrões são frágeis e levam rapidamente a um código não-sustentável.
+
+Então, por que não extraímos o estado compartilhado dos componentes, e o gerenciamos em um _singleton_ global? Com isso, nossa árvore de componentes se torna uma grande "_view_", e qualquer componente pode acessar o estado ou acionar ações, não importando onde elas estejam na árvore!
+
+Além disso, definindo e separando os conceitos envolvidos no gerenciamento do estado e aplicando certas regras, também damos ao nosso código mais estrutura e sustentabilidade.
+
+Esta é a ideia 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 o Vue.js tirar proveito de seu sistema de reatividade granular para atualizações eficientes.
+
+![vuex](/vuex.png)
+
+### Quando usar o Vuex?
+
+Embora o Vuex nos ajude a lidar com o gerenciamento de estado compartilhado, ele também vem com o custo de mais conceitos e códigos repetitivos. É uma escolha de prós e contras entre produtividade de curto e longo prazo
+
+Se você nunca construiu um SPA em grande escala e for direto para o Vuex, ele pode parecer detalhado e desanimador. Isso é perfeitamente normal - se o seu aplicativo é simples, você provavelmente ficará bem sem o Vuex. Um simples [global event bus](https://br.vuejs.org/v2/guide/components.html#Comunicacao-Nao-Pai-Filho) pode ser tudo que você precisa. Mas, se você está criando um SPA de médio a grande porte, é provável que tenha encontrado situações que fazem você pensar em como lidar melhor com o estado fora de seus componentes do Vue, e o Vuex será o próximo passo natural para você. Há uma boa citação de Dan Abramov, o autor do Redux:
+
+> As bibliotecas _Flux_ são como óculos: você saberá quando precisar delas.

docs/ptbr/api/README.md

@@ -0,0 +1,263 @@
+---
+sidebar: auto
+---
+
+# Referência da API
+
+## Vuex.Store
+
+``` js
+import Vuex from 'vuex'
+
+const store = new Vuex.Store({ ...options })
+```
+
+## Vuex.Store Opções do Construtor
+
+### estado
+
+- type: `Object | Function`
+
+  O objeto raiz de estado para o _store_ Vuex. [Detalhes](../guide/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](../guide/modules.md#reutilizacao-do-modulo)
+
+### mutações
+
+- type: `{ [type: string]: Function }`
+
+  Registra mutações no _store_. A função do manipulador sempre recebe `estado` como o 1º argumento (será o estado local do módulo se definido em um módulo) e receberá um 2º argumento _payload_ se houver um.
+
+  [Detalhes](../guide/mutations.md)
+
+### ações
+
+- type: `{ [type: string]: Function }`
+
+  Registra ações no _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
+  }
+  ```
+
+  E também recebe um 2º argumento _payload_ se houver um.
+
+  [Detalhes](../guide/actions.md)
+
+### getters
+
+- type: `{ [key: string]: Function }`
+
+  Registra _getters_ no _store_. A função _getter_ recebe os seguintes argumentos:
+
+  ```
+  state,     // será estado local do módulo se definido em um módulo.
+  getters    // o mesmo que store.getters
+  ```
+
+  Específico quando definido em um módulo
+
+  ```
+  state,       // será estado local do módulo se definido em um módulo.
+  getters,     // módulo de getters locais do módulo atual
+  rootState,   // estado global
+  rootGetters  // todos os getters
+  ```
+
+  Os _getters_ registrados estão expostos em _store.getters_.
+
+  [Detalhes](../guide/getters.md)
+
+### módulos
+
+- type: `Object`
+
+  Um objeto contendo sub módulos a serem incorporados no _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 do _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 1º 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](../guide/modules.md)
+
+### plugins
+
+- type: `Array<Function>`
+
+  Um _Array_ de funções de plug-in a serem aplicadas no _store_. O plug-in simplesmente recebe o _store_ como o único argumento e pode ouvir mutações (para persistência de dados de saída, registro ou depuração) ou mutações de despacho (para dados de entrada, por exemplo, websockets ou _observables_).
+
+  [Detalhes](../guide/plugins.md)
+
+### strict
+
+- type: `Boolean`
+- default: `false`
+
+  Força o _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](../guide/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
+
+-  `commit(type: string, payload?: any, options?: Object)`
+-  `commit(mutation: Object, options?: Object)`
+
+  Confirma (ou faz um _Commit_ de) uma mutação. _options_ pode ter _root: true_ que permite confirmar mutações da raiz em [módulos namespaced](../guide/modules.md#namespacing). [Detalhes](../guide/mutations.md)
+
+### dispatch
+
+-  `dispatch(type: string, payload?: any, options?: Object)`
+-  `dispatch(action: Object, options?: Object)`
+
+  Despacha uma ação. _options_ pode ter _root: true_ que permite despachar ações para raiz em [módulos namespaced](../guide/modules.md#namespacing). Retorna um _Promise_ que resolve todos os manipuladores de ação acionados. [Detalhes](../guide/actions.md)
+
+### replaceState
+
+-  `replaceState(state: Object)`
+
+  Substitua o estado da raiz do _store_. Use isso apenas para fins de _hydration_ / _time-travel_.
+
+### watch
+
+-  `watch(fn: Function, callback: Function, options?: Object): Function`
+
+  Visualiza de forma reativa um valor de retorno de `fn`, e chama o _callback_ para o retorno de chamada quando o valor for alterado. O `fn` recebe o estado do _store_ como o 1º argumento, e os _getters_ como o 2º argumento. Aceita um objeto de opções opcional que leva as mesmas opções que o método _vm.$watch_ do Vue.
+
+  Para parar um _watch_, chame a função _unwatch_ retornada.
+
+### subscribe
+
+-  `subscribe(handler: Function): Function`
+
+  Assina as mutações do _store_. O `manipulador` é 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)
+  })
+  ```
+
+  Para cancelar a assinatura, chame a função _unsubscribe_ retornada.
+
+  Mais comumente usado em plugins. [Detalhes](../guide/plugins.md)
+
+### subscribeAction
+
+-  `subscribeAction(handler: Function): Function`
+
+  > Novo na 2.5.0
+
+  Assina as ações do _store_. O `manipulador` é chamado para cada ação despachada e recebe o descritor de ação e o estado atual do _store_ como argumentos:
+
+  ``` js
+  store.subscribeAction((action, state) => {
+    console.log(action.type)
+    console.log(action.payload)
+  })
+  ```
+
+  Para cancelar a assinatura, chame a função _unsubscribe_ retornada.
+
+  Mais comumente usado em plugins. [Detalhes](../guide/plugins.md)
+
+### registerModule
+
+-  `registerModule(path: string | Array<string>, module: Module, options?: Object)`
+
+  Registra um módulo dinâmico. [Detalhes](../guide/modules.md#registro-de-modulo-dinamico)
+
+  _options_ can have _preserveState: true_ que permite preservar o estado anterior. Útil com renderização do lado do servidor (_server-side-rendering_).
+
+### unregisterModule
+
+-  `unregisterModule(path: string | Array<string>)`
+
+  Cancela o registro de um módulo dinâmico. [Detalhes](../guide/modules.md#registro-de-modulo-dinamico)
+
+### hotUpdate
+
+-  `hotUpdate(newOptions: Object)`
+
+  Faz _Hot_ _swap_ de novas ações e mutações. [Detalhes](../guide/hot-reload.md)
+
+## Métodos Auxiliares dos Componentes
+
+### mapState
+
+-  `mapState(namespace?: string, map: Array<string> | Object<string | function>): Object`
+
+  Criar dados computados do componente que retornam a subárvore do _store_ Vuex. [Detalhes](../guide/state.md#o-auxiliar-mapstate)
+
+  O 1º argumento pode ser opcionalmente uma _String_ com _namespace_. [Detalhes](../guide/modules.md#usando-metodos-auxiliares-com-namespace)
+
+  O segundo objeto que compõem os argumentos pode ser uma função. `function(state: any)`
+
+### mapGetters
+
+-  `mapGetters(namespace?: string, map: Array<string> | Object<string>): Object`
+
+  Criar dados computados do componente que retornam o valor calculado de um _getter_. [Detalhes](../guide/getters.md#o-auxiliar-mapgetters)
+
+  O 1º argumento pode ser opcionalmente uma _String_ com _namespace_. [Detalhes](../guide/modules.md#usando-metodos-auxiliares-com-namespace)
+
+### mapActions
+
+-  `mapActions(namespace?: string, map: Array<string> | Object<string | function>): Object`
+
+  Criar opções de métodos nos componentes que despacham uma ação. [Detalhes](../guide/actions.md#acoes-de-despacho-em-componentes)
+
+  O 1º argumento pode ser opcionalmente uma _String_ com _namespace_. [Detalhes](../guide/modules.md#usando-metodos-auxiliares-com-namespace)
+
+  O segundo objeto que compõem os argumentos pode ser uma função. `function(dispatch: function, ...args: any[])`
+
+### mapMutations
+
+-  `mapMutations(namespace?: string, map: Array<string> | Object<string | function>): Object`
+
+  Criar opções de métodos nos componentes que confirmam (ou fazem um _commit_ de) uma mutação. [Detalhes](../guide/mutations.md#confirmando-ou-fazendo-commits-de-mutacoes-em-componentes)
+
+  O 1º argumento pode ser opcionalmente uma _String_ com _namespace_. [Detalhes](../guide/modules.md#usando-metodos-auxiliares-com-namespace)
+
+  O segundo objeto que compõem os argumentos pode ser uma função. `function(commit: function, ...args: any[])`
+
+### createNamespacedHelpers
+
+-  `createNamespacedHelpers(namespace: string): Object`
+
+  Cria um componente _namespaced_ dos métodos auxiliares. O objeto retornado possui _mapState_, _mapGetters_, _mapActions_ e _mapMutations_, que estão conectados com o dado _namespace_. [Detalhes](../guide/modules.md#usando-metodos-auxiliares-com-namespace)

docs/ptbr/guide/README.md

@@ -0,0 +1,44 @@
+# Começando
+
+No centro de cada aplicação Vuex existe o **_store_**. Um "_store_" é basicamente um recipiente que contém o **estado** da sua aplicação. Há duas coisas que tornam um _store_ Vuex diferente de um objeto global simples:
+
+1. Os _stores_ Vuex são reativos. Quando os componentes do Vue obtêm o estado dele, eles atualizarão de forma reativa e eficiente se o estado do _store_ mudar.
+
+2. Você não pode alterar diretamente os estados do _store_. A única maneira de mudar o estado de um _store_ é explicitamente **confirmando (ou fazendo _commit_ de) 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.
+
+### O Store Mais Simples 
+
+> **NOTA:** Vamos usar a sintaxe ES2015 para exemplos de código para o resto da documentação. Se você ainda não aprendeu como usá-la, [veja aqui](https://babeljs.io/docs/learn-es2015/)!
+
+Após [instalar](../installation.md) o Vuex, vamos criar um _store_. É bem simples - basta fornecer um objeto de estado inicial, e algumas mutações:
+
+``` js
+// Certifique-se de chamar Vue.use(Vuex) primeiro se estiver usando o sistema de módulos
+
+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 confirmando (ou fazendo _commit_ de) 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 ter melhores argumetos sobre as mudanças de estado em seu aplicativo ao ler o código. Além disso, isso nos dá a oportunidade de implementar ferramentas que podem registrar cada mutação, capturar momentos do estado ou mesmo realizar depuração viajando pelo histórico de estado (_time travel_).
+
+Usar o estado do _store_ em um componente simplesmente envolve o retorno do estado dentro de um dado computado, porque o estado do _store_ é reativo. Acionar alterações simplesmente significa confirmar (ou fazer _commit_ de) mutações nos métodos dos 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/ptbr/guide/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 (ou fazem _commit_ de) mutações.
+- As ações podem conter operações assíncronas arbitrárias.
+
+Vamos registrar uma ação simples:
+
+``` 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 _context_ que expõe o mesmo conjunto de métodos/propriedades na instância do _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 _context.getters_. Veremos por que esse objeto _context_ não é a própria instância do _store_ quando apresentarmos [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 usar _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('increment')` diretamente? Você se lembra 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 _payload_ e despacho estilo-objeto:
+
+``` js
+// despacho com um payload
+store.dispatch('incrementAsync', {
+  amount: 10
+})
+
+// despacho com objeto
+store.dispatch({
+  type: 'incrementAsync',
+  amount: 10
+})
+```
+
+Um exemplo mais prático de ações reais seria uma ação para fazer _checkout_ 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]
+    // envia solicitação de checkout, e otimista
+    // limpa o carrinho
+    commit(types.CHECKOUT_REQUEST)
+    // a API da loja 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 (ou fazendo _commit_ deles).
+
+### 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 do componente para chamadas do _store.dispatch_ (esta ação requer injeção do _store_ na instância raiz):
+
+``` js
+import { mapActions } from 'vuex'
+
+export default {
+  // ...
+  methods: {
+    ...mapActions([
+      'increment', // mapeia `this.increment()` para `this.$store.dispatch('increment')`
+
+      // `mapActions` também suporta 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 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 você pode fazer:
+
+``` js
+store.dispatch('actionA').then(() => {
+  // ...
+})
+```
+
+E também em outra ação:
+
+``` js
+actions: {
+  // ...
+  actionB ({ dispatch, commit }) {
+    return dispatch('actionA').then(() => {
+      commit('someOtherMutation')
+    })
+  }
+}
+```
+
+Finalmente, se fizermos uso de [async / await](https://tc39.github.io/ecmascript-asyncawait/), podemos compor nossas ações como esta:
+
+``` js
+// assumindo que `getData()` e `getOtherData()` retornam Promises
+
+actions: {
+  async actionA ({ commit }) {
+    commit('gotData', await getData())
+  },
+  async actionB ({ dispatch, commit }) {
+    await dispatch('actionA') // espera 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á um _Promise_ que resolve quando todos os manipuladores desencadeados foram resolvidos.

docs/ptbr/guide/core-concepts.md

@@ -0,0 +1,13 @@
+# Conceitos Básicos
+
+Vamos aprender 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/ptbr/guide/forms.md

@@ -0,0 +1,62 @@
+# Manipulação de Formulários
+
+Ao usar o Vuex no modo estrito, pode ser um pouco complicado usar `v-model` em um pedaço do estado que pertence ao Vuex:
+
+``` html
+<input v-model="obj.message">
+```
+
+Assuming `obj` is a computed property that returns an Object from the store, the `v-model` here will attempt to directly mutate `obj.message` when the user types in the input. In strict mode, this will result in an error because the mutation is not performed inside an explicit Vuex mutation handler.
+
+Assumindo que `obj` é um dado computado que retorna um Objeto do _store_, o `v-model` aqui tentará alterar diretamente o `obj.message` quando o usuário digitar alguma coisa. No modo estrito, isso resultará em um erro porque a mutação não é executada dentro de um manipulador explícito de mutação Vuex.
+
+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 verboso do que o `v-model` + estado local, e também perdemos alguns dos recursos úteis do `v-model`. Uma abordagem alternativa está usando uma dado computado 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/ptbr/guide/getters.md

@@ -0,0 +1,116 @@
+# Getters
+
+Às vezes, talvez precisemos calcular o estado derivado com base no estado do _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_ no _store_. Você pode pensar neles como dados computados para os _stores_. Como os dados computados, o resultado de um _getter_ é armazenado em cache com base em suas dependências e só será reavaliado quando algumas de suas dependências forem alteradas.
+
+Os _getters_ receberão o estado como 1º 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)
+    }
+  }
+})
+```
+
+### Acesso Estilo-Propriedade
+
+Os _getters_ serão expostos no objeto _store.getters_ e você acessa valores como propriedades:
+
+``` js
+store.getters.doneTodos // -> [{ id: 1, text: '...', done: true }]
+```
+
+Os _getters_ também receberão outros _getters_ como o 2º 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
+  }
+}
+```
+
+Observe que os _getters_ acessados ​​como propriedades são armazenados em cache como parte do sistema de reatividade do Vue.
+
+### Acesso Estilo-Método
+
+Você também pode passar argumentos para os _getters_ retornando uma função. Isso é particularmente útil quando você deseja consultar um _Array_ no _store_:
+
+```js
+getters: {
+  // ...
+  getTodoById: (state) => (id) => {
+    return state.todos.find(todo => todo.id === id)
+  }
+}
+```
+
+``` js
+store.getters.getTodoById(2) // -> { id: 2, text: '...', done: false }
+```
+
+Observe que os _getters_ acessados ​​via métodos serão executados toda vez que você os chamar, e o resultado não será armazenado em cache.
+
+### O Auxiliar `mapGetters`
+
+O auxiliar `mapGetters` simplesmente mapeia os _getters_ do _store_ para os dados computados locais:
+
+``` js
+import { mapGetters } from 'vuex'
+
+export default {
+  // ...
+  computed: {
+    // mistura os getters nos dados computatos com o operador spread
+    ...mapGetters([
+      'doneTodosCount',
+      'anotherGetter',
+      // ...
+    ])
+  }
+}
+```
+
+Se você deseja mapear um _getter_ com um nome diferente, use um objeto:
+
+``` js
+...mapGetters({
+  // mapeia `this.doneCount` para `this.$store.getters.doneTodosCount`
+  doneCount: 'doneTodosCount'
+})
+```

docs/ptbr/guide/hot-reload.md

@@ -0,0 +1,44 @@
+# Hot Reloading (Recarregamento Rápido)
+
+O Vuex suporta _hot-reloading_ de mutações, módulos, ações e _getters_ durante o desenvolvimento, utilizando o _webpack_ [Hot Module Replacement API](https://webpack.js.org/guides/hot-module-replacement/). Você também pode usá-lo no 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'], () => {
+    // requer os módulos atualizados
+    // tem que adicionar .default aqui devido à saída do módulo babel 6
+    const newMutations = require('./mutations').default
+    const newModuleA = require('./modules/a').default
+    // troca nas 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 brincar com o hot-reload.

docs/ptbr/guide/modules.md

@@ -0,0 +1,323 @@
+# Módulos
+
+Devido ao uso de uma única árvore de estado, todo o estado de nossa aplicação está contido dentro de um grande objeto. No entanto, à medida que nosso aplicativo cresce em escala, o _store_ pode ficar realmente inchado.
+
+Para ajudar com isso, o Vuex nos permite dividir nosso _store_ em **módulos**. Cada módulo pode conter seu próprio estado, mutações, ações, _getters_ e até módulos aninhados - é todo o complexo caminho abaixo:
+
+``` 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 Local do Módulo
+
+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 módulo
+      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 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 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 dos módulos ainda são registrados sob o **_namespace_ global** - isso permite que vários módulos reajam ao mesmo tipo de ação/mutação.
+
+Se você quer que seus módulos sejam mais independentes ou reutilizáveis, você pode marcá-los como _namespaced_ com _namespaced: true_. Quando o módulo é registrado, todos os _getters_, ações e mutações serão automaticamente _namespaced_ 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 namespace
+      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 escrever prefixo no mesmo módulo. Alternar entre _namespaced_ ou não, não afeta o código dentro do módulo.
+
+#### Acessando Recursos Globais em Módulos 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 despachar ações confirmar (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: {
+      // dispatch e commit também estão localizados para este módulo
+      // eles aceitarão a opção `root` para o dispatch/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) { ... }
+    }
+  }
+}
+```
+
+#### Registrar Ação Global em Módulos com Namespaces
+
+Se você quiser registrar ações globais em módulos com namespaces, você pode marcá-lo com _root: true_ e colocar a definição de ação na função _handler_. Por exemplo:
+
+``` js
+{
+  actions: {
+    someOtherAction ({dispatch}) {
+      dispatch('someAction')
+    }
+  },
+  modules: {
+    foo: {
+      namespaced: true,
+
+      actions: {
+        someAction: {
+          root: true,
+          handler (namespacedContext, payload) { ... } // -> 'someAction'
+        }
+      }
+    }
+  }
+}
+```
+
+#### Usando Métodos 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_ do _namespace_ do módulo como o 1º argumento para os auxiliares, de modo que todas as ligações sejam feitas usando esse módulo como o contexto. O acima 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 auxiliares com _namespace_ usando _createNamespacedHelpers_. Ele retorna um objeto com novos métodos auxiliares dos componentes vinculados ao valor do _namespace_ fornecido:
+
+``` js
+import { createNamespacedHelpers } from 'vuex'
+
+const { mapState, mapActions } = createNamespacedHelpers('some/nested/module')
+
+export default {
+  computed: {
+    // procure em `some/nested/module`
+    ...mapState({
+      a: state => state.a,
+      b: state => state.b
+    })
+  },
+  methods: {
+    // procure em `some/nested/module`
+    ...mapActions([
+      'foo',
+      'bar'
+    ])
+  }
+}
+```
+
+#### Advertência para Desenvolvedores de Plug-ins
+
+Você pode se preocupar com espaços de nomes imprevisíveis para seus módulos quando você cria um [plugin](plugins.md) que fornece os módulos e permite que os usuários os incluam em um _store_ Vuex. Seus módulos também serão _namespaced_ se os usuários do plugin adicionarem seus módulos em um módulo _namespaced_. Para adaptar esta situação, você pode precisar receber um valor de _namespace_ através de uma opção sua no plugin:
+
+``` js
+// obtem valor do namespace via opção no plugin
+// e retorna a função plugin do Vuex
+export function createPlugin (options = {}) {
+  return function (store) {
+    // add namespace to plugin module's types
+    // adicionar namespace aos tipos de módulo do plug-in
+    const namespace = options.namespace || ''
+    store.dispatch(namespace + 'pluginAction')
+  }
+}
+```
+
+### Registro de Módulo Dinâmico
+
+Você pode registrar um módulo **após** o _store_ ser criado com o método _store.registerModule_:
+
+``` js
+// registra um módulo `myModule`
+store.registerModule('myModule', {
+  // ...
+})
+
+// registra um módulo aninhado `nested/myModule`
+store.registerModule(['nested', 'myModule'], {
+  // ...
+})
+```
+
+Os estados do módulo serão expostos como _store.state.myModule_ e _store.state.nested.myModule_.
+
+O registro de módulo dinâmico possibilita que outros plug-ins Vue aproveitem também o Vuex para gerenciamento de estado, anexando um módulo ao _store_ do aplicativo. Por exemplo, a biblioteca [`vuex-router-sync`](https://github.com/vuejs/vuex-router-sync) integra o vue-router com o vuex gerenciando o estado da rota do aplicativo em um módulo conectado dinamicamente.
+
+Você também pode remover um módulo dinamicamente registrado com o `store.unregisterModule(moduleName)`. Note que você não pode remover módulos estáticos (declarados na criação do _store_) com este método.
+
+É bem provável que você queira preservar o estado anterior ao registrar um novo módulo, como preservar o estado de um aplicativo Renderizado no Lado do Servidor (_Server_ _Side_ _Rendered_). Você pode fazer isso com a opção `preserveState`:`store.registerModule('a', module, {preserveState: true})`
+
+### Reutilização do Módulo
+
+Às vezes, podemos precisar criar várias instâncias de um módulo, por exemplo:
+
+- Criando multiplos _stores_ que usam o mesmo módulo (e.g. Para [evitar Singletons com informações de estado no SSR](https://ssr.vuejs.org/en/structure.html#avoid-stateful-singletons) quando a opção _runInNewContext_ é _false_ ou `'_once_'`);
+- Registrar o mesmo módulo várias vezes no mesmo _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 entre estados de _store_/módulo quando ele sofrer uma mutação.
+
+This is actually the exact same problem with `data` inside Vue components. So the solution is also the same - use a function for declaring module state (supported in 2.3.0+):
+
+Este é exatamente o mesmo problema com _data_ dentro dos componentes do Vue. Então 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/ptbr/guide/mutations.md

@@ -0,0 +1,172 @@
+# Mutações
+
+A única maneira de realmente mudar de estado em um _store_ Vuex é por confirmar (ou fazer _commit_ de) uma mutação. As mutações do Vuex são muito semelhantes aos eventos: cada mutação tem uma cadeia de caracteres **tipo** e um **manipulador**. A função do manipulador é onde realizamos modificações de estado reais e ele receberá o estado como o 1º 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 evento: "Quando uma mutação com o tipo _increment_ é acionada, chame este 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 o _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 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
+})
+```
+
+### Confirmação (ou Commit) Estilo-Objeto
+
+Uma maneira alternativa de confirmar (ou fazer um _commit_ de) uma mutação é usando diretamente um objeto que tenha uma propriedade `type`:
+
+``` js
+store.commit({
+  type: 'increment',
+  amount: 10
+})
+```
+
+Ao usar a Confirmação Estilo-Objeto, o objeto inteiro será passado como o _payload_ para os manipuladores de mutação, portanto, o manipulador permanecerá o mesmo:
+
+``` js
+mutations: {
+  increment (state, payload) {
+    state.count += payload.amount
+  }
+}
+```
+
+### Mutações Seguem as Regras de Reatividade do Vue
+
+Como o estado de um _store_ Vuex é reativado pelo Vue, quando alteramos o estado, os componentes do Vue observando o estado serão atualizados automaticamente. Isso também significa que as mutações do Vuex estão sujeitas às mesmas ressalvas de reatividade ao trabalhar com o Vue simples:
+
+1. Prefira inicializar o estado inicial do seu _store_ com todos os campos desejados antecipadamente.
+
+2. Ao adicionar novas propriedades a um Objeto, você deve:
+
+  - Usar `Vue.set(obj, 'newProp', 123)`, ou
+
+  - Substitua esse objeto por um novo. Por exemplo, usando o _stage-3_ [object spread syntax](https://github.com/sebmarkbage/ecmascript-rest-spread) nós podemos escrevê-lo assim:
+
+    ``` js
+    state.obj = { ...state.obj, newProp: 123 }
+    ```
+
+### Usando Constantes para Tipos de Mutação
+
+É um padrão comumente visto usar constantes para tipos de mutação em várias implementações do _Flux_. Isso permite que o código aproveite as ferramentas como os _linters_, e colocar todas as constantes em um único arquivo permite que seus colaboradores tenham uma visão geral das mutações 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 nome do dado computado do ES2015
+    // para usar uma constante como o nome da função
+    [SOME_MUTATION] (state) {
+      // muda o estado
+    }
+  }
+})
+```
+
+Se usar constantes é em grande parte uma preferência - pode ser útil em grandes projetos com muitos desenvolvedores, mas é totalmente opcional se você não gostar 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 observando os logs de mutação do devtool. Para cada mutação registrada, o devtool precisará capturar os momentos "antes" e "depois" do estado. No entanto, o _callback_ assíncrono dentro da mutação de exemplo acima torna isso impossível: o _callback_ ainda não é chamado quando a mutação é confirmada (ou o _commit_ da mutação é feito) e não há como o devtool saber quando o _callback_ será realmente chamado - qualquer mutação de estado executada no _callback_ é essencialmente impossível de rastrear!
+
+### Confirmando (ou fazendo Commits de) Mutações em Componentes
+
+Você pode confirmar (ou fazer _commit_ de) mutações em componentes com `this.$store.commit('xxx')`, ou use o auxiliar `mapMutations` que mapeia métodos de componentes para chamadas _store.commit_ (requer injeção _store_ raiz):
+
+``` 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')`
+    })
+  }
+}
+```
+
+### Vamos as Ações
+
+Assincronia combinada com mutação de estado pode tornar seu programa muito difícil de ser compreendido. Por exemplo, quando você chama dois métodos com _callbacks_ assíncronos que alteram 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, **mutações são transações síncronas**:
+
+``` js
+store.commit('increment')
+// qualquer mudança de estado que a mutação "increment" pode causar
+// deve ser feito neste momento.
+```
+
+Para lidar com operações assíncronas, vamos apresentar [Ações](actions.md).

docs/ptbr/guide/plugins.md

@@ -0,0 +1,126 @@
+# Plugins
+
+Os _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 um _store_ como seu único argumento:
+
+``` js
+const myPlugin = store => {
+  // chamado quando o store é inicializado
+  store.subscribe((mutation, state) => {
+    // chamada após cada mutação.
+    // A mutação vem no formato de `{ type, payload }`.
+  })
+}
+```
+
+E pode ser usada assim:
+
+``` js
+const store = new Vuex.Store({
+  // ...
+  plugins: [myPlugin]
+})
+```
+
+### Confirmando (ou fazendo _commit_ de) Mutações Dentro de Plugins
+
+_Plugins_ não tem permissão para alterar o estado diretamente - similar aos componentes, eles podem apenas acionar mudanças fazendo o _commit_ de mutações.
+
+Por fazer _commit_ de mutações, um _plugin_ pode ser usado para sincronizar uma fonte de dados ao _store_. Por exemplo, para sincronizar uma fonte de dados _websocket_ ao _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]
+})
+```
+
+### Capturando os Momentos do Estado
+
+Às vezes, um _plugin_ pode querer receber "momentos" do estado, e também comparar o estado pós-mutação com o estado de pré-mutação. Para conseguir isso, você precisará realizar 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 capturam momentos do estado devem ser usados apenas durante o desenvolvimento.** Quando usamos _webpack_ ou _Browserify_, podemos construir nossas próprias ferramentas _build_ 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 do `process.env.NODE_ENV !== 'production'` para _false_ no _build_ final.
+
+### Plugin de Log Integrado
+
+> 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 depuração:
+
+``` js
+import createLogger from 'vuex/dist/logger'
+
+const store = new Vuex.Store({
+  plugins: [createLogger()]
+})
+```
+
+A função _createLogger_ tem algumas opções:
+
+``` js
+const logger = createLogger({
+  collapsed: false, // expande automaticamente mutações registradas no log
+  filter (mutation, stateBefore, stateAfter) {
+    // retorna `true` se uma mutação deve ser registrada no log
+    // `mutation` é um `{ type, payload }`
+    return mutation.type !== "aBlacklistedMutation"
+  },
+  transformer (state) {
+    // transforma o estado antes de regitrá-lo no log.
+    // por exemplo, retorna apenas uma sub-árvore específica
+    return state.subTree
+  },
+  mutationTransformer (mutation) {
+    // mutações são registradas no log no formato de `{ type, payload }`
+    // mas podemos formatá-las como quisermos.
+    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_ capturam momentos do estado, então use-os apenas durante o desenvolvimento.

docs/ptbr/guide/state.md

@@ -0,0 +1,109 @@
+# Estado
+
+### Árvore Única de Estado
+
+O Vuex usa uma **árvore única de estado** - ou seja, esse único objeto contém todo o estado do seu nível de aplicação e serve como a "única fonte da verdade". Isso também significa que você terá apenas um _store_ para cada aplicativo. Uma árvore única de estado facilita a localização de uma parte específica do estado, e permite capturar facilmente momentos do estado atual do aplicativo para fins de depuração.
+
+A árvore única de 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 Estado Vuex nos Componentes Vue
+
+Então, como exibimos o estado dentro do _store_ em nossos componentes Vue? Uma vez que os _stores_ Vuex são reativos, a maneira mais simples de "recuperar" o estado é simplesmente retornar algum estado do _store_ 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 o dado computado seja reavaliado e ative as atualizações de _DOM_ associadas.
+
+No entanto, esse padrão faz com que o componente dependa do _store_ _singleton_ global. Ao usar um sistema de módulo, ele precisa importar o _store_ em todos os componentes que usam o estado do _store_ e também requer _mocking_ ao testar o componente.
+
+O Vuex fornece um mecanismo para "injetar" o _store_ 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',
+  // fornece o store usando a opção "store".
+  // isso irá injetar a instância do store em todos os componentes filhos.
+  store,
+  components: { Counter },
+  template: `
+    <div class="app">
+      <counter></counter>
+    </div>
+  `
+})
+```
+
+Ao fornecer a opção _store_ para a instância raiz, o _store_ será injetado em todos os componentes filho da raiz e estará disponível neles como `this.$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 do estado do _store_ ou _getters_, declarar todos esses dados computados pode ser repetitivo e verboso. Para lidar com isso, podemos usar o auxiliar `mapState` que gera funções _getter_ computadas para nós, economizando algumas linhas de código:
+
+``` js
+// em builds completos, os auxiliares são expostos como Vuex.mapState
+import { mapState } from 'vuex'
+
+export default {
+  // ...
+  computed: mapState({
+    // As arrow functions (ou 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 um _Array_ de _Strings_ para _mapState_ quando o nome de um dado computado mapeado é o mesmo que um nome de árvore secundária do estado.
+
+``` js
+computed: mapState([
+  // mapeia this.count para store.state.count
+  'count'
+])
+```
+
+### Objeto Spread Operator
+
+Observe que _mapState_ retorna um objeto. Como usá-lo em combinação com outros dados computados locais? 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 [Spread Operator](https://github.com/sebmarkbage/ecmascript-rest-spread) (que é uma proposta de ECMAScript em estágio 4), podemos simplificar muito a sintaxe:
+
+``` js
+computed: {
+  localComputed () { /* ... */ },
+  // mistura isso no objeto externo com o objeto spread operator
+  ...mapState({
+    // ...
+  })
+}
+```
+
+### Componentes Ainda Podem Ter Um Estado Local
+
+O uso do Vuex não significa que você deve colocar **tudo** no estado do Vuex. Embora colocar mais estado no Vuex torna suas mutações de estado mais explícitas e depuráveis, às vezes também pode tornar o código mais verboso e indireto. Se um pedaço de estado pertence estritamente a um único componente, pode ser bom deixá-lo apenas como um estado local. Você deve pesar os prós e contras e tomar decisões que atendam às necessidades de desenvolvimento da sua aplicação.

docs/ptbr/guide/strict.md

@@ -0,0 +1,25 @@
+# Modo Estrito
+
+Para habilitar o modo estrito, simplesmente passe _strict: true_ ao criar um _store_ Vuex:
+
+``` js
+const store = new Vuex.Store({
+  // ...
+  strict: true
+})
+```
+
+Em modo estrito, sempre que o estado do Vuex é mudado 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 fazer um _deploy_ 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/ptbr/guide/structure.md

@@ -0,0 +1,32 @@
+# 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 do aplicativo é centralizado no _store_.
+
+2. A única maneira de mudar o estado é confirmando (ou 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 do seu _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 aproveitar os módulos. Aqui está um exemplo de estrutura de projeto:
+
+``` bash
+├── index.html
+├── main.js
+├── api
+│   └── ... # abstrações para fazer requisições a API
+├── components
+│   ├── App.vue
+│   └── ...
+└── store
+    ├── index.js          # onde montamos módulos e exportamos a store
+    ├── actions.js        # ações raiz
+    ├── mutations.js      # mutações raiz
+    └── modules
+        ├── cart.js       # módulo cart
+        └── products.js   # módulo products
+```
+
+Como referência, confira o [Exemplo do Carrinho de Compras](https://github.com/vuejs/vuex/tree/dev/examples/shopping-cart).

docs/ptbr/guide/testing.md

@@ -0,0 +1,240 @@
+# Testando
+
+As partes principais que queremos testar no 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 = { ... }
+
+// exporta `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/_framework_ 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'
+
+// desestrutura `mutações` atribuidas
+const { increment } = mutations
+
+describe('mutations', () => {
+  it('INCREMENT', () => {
+    // mock o estado
+    const state = { count: 0 }
+    // aplica a mutação
+    increment(state)
+    // afirma o resultado
+    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 [inject-loader](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
+
+// use a sintaxe 'require' para inline loaders.
+// com inject-loader, isso retorna um factory de módulos
+// que nos permite injetar dependências mocked (ou simuladas).
+import { expect } from 'chai'
+const actionsInjector = require('inject-loader!./actions')
+
+// cria o módulo com nossos mocks
+const actions = actionsInjector({
+  '../api/shop': {
+    getProducts (cb) {
+      setTimeout(() => {
+        cb([ /* resposta simulada */ ])
+      }, 100)
+    }
+  }
+})
+
+// auxiliar para teste de ação com mutações esperadas
+const testAction = (action, payload, state, expectedMutations, done) => {
+  let count = 0
+
+  // mock commit (ou confirmação simulada)
+  const commit = (type, payload) => {
+    const mutation = expectedMutations[count]
+
+    try {
+      expect(type).to.equal(mutation.type)
+      if (payload) {
+        expect(payload).to.deep.equal(mutation.payload)
+      }
+    } catch (error) {
+      done(error)
+    }
+
+    count++
+    if (count >= expectedMutations.length) {
+      done()
+    }
+  }
+
+  // chame a ação com store mocked (ou simulado) e argumentos
+  action({ commit, state }, payload)
+
+  // verifica 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: { /* resposta simulada */ } }
+    ], done)
+  })
+})
+```
+
+Se você tem espiões disponíveis em seu ambiente de teste (por exemplo via [Sinon.JS](http://sinonjs.org/)), você pode usá-los em vez do auxiliar `testAction`:
+
+``` js
+describe('actions', () => {
+  it('getAllProducts', () => {
+    const commit = sinon.spy()
+    const state = {}
+    
+    actions.getAllProducts({ commit, state })
+    
+    expect(commit.args).to.deep.equal([
+      ['REQUEST_PRODUCTS'],
+      ['RECEIVE_PRODUCTS', { /* resposta simulada */ }]
+    ])
+  })
+})
+```
+
+### Testando Getters
+
+Se seus _getters_ tiverem uma computação complicada, vale a pena testá-los. Os _Getters_ também são muito simples de testar pelo 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', () => {
+    // simulando estado
+    const state = {
+      products: [
+        { id: 1, title: 'Apple', category: 'fruit' },
+        { id: 2, title: 'Orange', category: 'fruit' },
+        { id: 3, title: 'Carrot', category: 'vegetable' }
+      ]
+    }
+    // simulando getter
+    const filterCategory = 'fruit'
+
+    // obtem 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' }
+    ])
+  })
+})
+```
+
+### Executando 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 simulação 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.
+
+#### Executando 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
+```
+
+#### Executando no Browser
+
+1. Instale o _mocha-loader_.
+2. Mude a `entrada` da configuração do _webpack_ acima para `'mocha-loader!babel-loader!./test.js'`.
+3. Inicie o _webpack-dev-server_ usando a configuração.
+4. Vá para _localhost:8080/webpack-dev-server/test-bundle_.
+
+#### Executando 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).

docs/ptbr/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 os links de 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 o `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 um sistema de módulos, você deve instalar o Vuex obrigatóriamente via `Vue.use()`:
+
+``` js
+import Vue from 'vue'
+import Vuex from 'vuex'
+
+Vue.use(Vuex)
+```
+
+Você não precisa fazer isso se for incluir o `vuex` via tags script.
+
+### Promise
+
+Vuex requer [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises). Se os seus navegadores não implementarem o _Promise_ (e.g. IE), você pode usar uma biblioteca _polyfill_, 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 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
+```