diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js index 764cb892b..f0b2a4d6f 100644 --- a/docs/.vuepress/config.js +++ b/docs/.vuepress/config.js @@ -313,7 +313,7 @@ module.exports = { { text: 'v3.x', items: [ - { text: 'v4.x', link: 'https://next.vuex.vuejs.org/' } + { text: 'v4.x', link: 'https://next.vuex.vuejs.org/ptbr/' } ] } ], diff --git a/docs/ptbr/README.md b/docs/ptbr/README.md index 945ff0424..dbc9d40c6 100644 --- a/docs/ptbr/README.md +++ b/docs/ptbr/README.md @@ -1,12 +1,16 @@ # O que é Vuex? +::: tip NOTE +Esta documentação é para o Vuex 3, que funciona com Vue 2. Se você está procurando a documentação para o Vuex 4, que funciona com Vue 3, [por favor, confira aqui](https://next.vuex.vuejs.org/ptbr/). +::: + -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 Vuex é um **padrão de gerenciamento de estado + biblioteca** para aplicações 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: +Vamos começar com uma aplicação simples de contador Vue: ``` js new Vue({ @@ -29,9 +33,9 @@ new Vue({ }) ``` -É um aplicativo independente com as seguintes partes: +É uma aplicação independente com as seguintes partes: -- O **estado** (_state_), que é a fonte da verdade que direciona nosso aplicativo; +- O **estado** (_state_), que é a fonte da verdade que direciona nossa aplicação; - 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_**. @@ -62,6 +66,6 @@ Se você quiser aprender Vuex de um modo interativo, você pode conferir esse cu 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 [store pattern](https://br.vuejs.org/v2/guide/state-management.html#Gerenciamento-de-Estado-do-Zero) 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: +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 a sua aplicação é simples, você provavelmente ficará bem sem o Vuex. Um simples [store pattern](https://br.vuejs.org/v2/guide/state-management.html#Gerenciamento-de-Estado-do-Zero) 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. diff --git a/docs/ptbr/api/README.md b/docs/ptbr/api/README.md index 3840a5104..9d5366d89 100644 --- a/docs/ptbr/api/README.md +++ b/docs/ptbr/api/README.md @@ -71,7 +71,7 @@ const store = new Vuex.Store({ ...options }) rootGetters // todos os getters ``` - Os _getters_ registrados estão expostos em _store.getters_. + Os _getters_ registrados estão expostos em `store.getters`. [Detalhes](../guide/getters.md) @@ -95,7 +95,7 @@ const store = new Vuex.Store({ ...options }) } ``` - 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. + 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) @@ -103,7 +103,7 @@ const store = new Vuex.Store({ ...options }) - type: `Array` - 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_). + Um _Array_ de funções de _plugin_ a serem aplicadas no _store_. O _plugin_ 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) @@ -120,7 +120,7 @@ const store = new Vuex.Store({ ...options }) - type: `boolean` - Ative ou desative as ferramentas de desenvolvedor para uma determinada instância vuex. Passar _false_ à instância diz ao _store_ Vuex para não se integrar ao _devtools_. Útil para quando se tem vários _stores_ em uma _single page_. + Ative ou desative as ferramentas de desenvolvedor para uma determinada instância vuex. Passar `false` à instância diz ao _store_ Vuex para não se integrar ao _devtools_. Útil para quando se tem vários _stores_ em uma _single_ _page_. ``` js { @@ -149,14 +149,14 @@ const store = new Vuex.Store({ ...options }) - `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) + 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): Promise` - `dispatch(action: Object, options?: Object): Promise` - 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) + 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 @@ -229,7 +229,7 @@ const store = new Vuex.Store({ ...options }) 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_). + _options_ can have `preserveState: true` que permite preservar o estado anterior. Útil com renderização do lado do servidor (_server-side-rendering_). ### unregisterModule @@ -287,4 +287,4 @@ const store = new Vuex.Store({ ...options }) - `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) + 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) diff --git a/docs/ptbr/guide/README.md b/docs/ptbr/guide/README.md index c4f3e4756..2d15f679d 100644 --- a/docs/ptbr/guide/README.md +++ b/docs/ptbr/guide/README.md @@ -31,7 +31,7 @@ const store = new Vuex.Store({ }) ``` -Agora, você pode acessar o objeto de estado como _store.state_ e acionar uma mudança de estado com o método _store.commit_: +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') @@ -39,10 +39,10 @@ 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_). +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 sua aplicação 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/). +Aqui está um exemplo da [aplicação 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). diff --git a/docs/ptbr/guide/actions.md b/docs/ptbr/guide/actions.md index 506d4d84c..ead8f153b 100644 --- a/docs/ptbr/guide/actions.md +++ b/docs/ptbr/guide/actions.md @@ -27,7 +27,7 @@ const store = new Vuex.Store({ }) ``` -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. +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): @@ -41,7 +41,7 @@ actions: { ### Ações de Despacho -As ações são acionadas com o método _store.dispatch_: +As ações são acionadas com o método `store.dispatch`: ``` js store.dispatch('increment') @@ -100,7 +100,7 @@ Observe que estamos realizando um fluxo de operações assíncronas, e gravando ### 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): +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' @@ -125,7 +125,7 @@ export default { 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_: +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: { @@ -177,4 +177,4 @@ actions: { } ``` -> É 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. +> É 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. diff --git a/docs/ptbr/guide/getters.md b/docs/ptbr/guide/getters.md index bc0922f4d..1d4c5fde2 100644 --- a/docs/ptbr/guide/getters.md +++ b/docs/ptbr/guide/getters.md @@ -36,13 +36,13 @@ const store = new Vuex.Store({ ### Acesso Estilo-Propriedade -Os _getters_ serão expostos no objeto _store.getters_ e você acessa valores como propriedades: +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: +Os _getters_ também receberão outros `getters` como o 2º argumento: ``` js getters: { diff --git a/docs/ptbr/guide/modules.md b/docs/ptbr/guide/modules.md index 269d64acc..3544450f1 100644 --- a/docs/ptbr/guide/modules.md +++ b/docs/ptbr/guide/modules.md @@ -2,7 +2,7 @@
Tente esta lição no Scrimba
-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. +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 nossa aplicação 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: @@ -55,7 +55,7 @@ const moduleA = { } ``` -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_: +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 = { @@ -87,7 +87,7 @@ const moduleA = { 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: +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({ @@ -136,7 +136,7 @@ Os _getters_ e as ações _namespaced_ receberão _getters_, _dispatch_ e _commi #### 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. +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_. @@ -176,7 +176,7 @@ modules: { #### 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: +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 { @@ -202,7 +202,7 @@ Se você quiser registrar ações globais em módulos com namespaces, você pode #### 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: +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: { @@ -280,7 +280,7 @@ export function createPlugin (options = {}) { ### Registro de Módulo Dinâmico -Você pode registrar um módulo **após** o _store_ ser criado com o método _store.registerModule_: +Você pode registrar um módulo **após** o _store_ ser criado com o método `store.registerModule`: ``` js // registra um módulo `myModule` @@ -294,15 +294,15 @@ store.registerModule(['nested', 'myModule'], { }) ``` -Os estados do módulo serão expostos como _store.state.myModule_ e _store.state.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. +O registro de módulo dinâmico possibilita que outros _plugins_ Vue aproveitem também o Vuex para gerenciamento de estado, anexando um módulo ao _store_ da aplicação. 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 da aplicação 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. #### Preservando o estado -É 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})` +É bem provável que você queira preservar o estado anterior ao registrar um novo módulo, como preservar o estado de uma aplicação Renderizada no Lado do Servidor (_Server_ _Side_ _Rendered_). Você pode fazer isso com a opção `preserveState`:`store.registerModule('a', module, {preserveState: true})` Quando você informa `preserveState: true`, o módulo é registrado, as ações, mutações e _getters_ são incluídos no _store_, mas o estado não. É assumido que estado da sua _store_ já contém um estado para aquele módulo e você não quer sobrescrevê-lo. @@ -310,7 +310,7 @@ Quando você informa `preserveState: true`, o módulo é registrado, as ações, À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_'`); +- 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. diff --git a/docs/ptbr/guide/mutations.md b/docs/ptbr/guide/mutations.md index 924ca4a38..a8d4dabd9 100644 --- a/docs/ptbr/guide/mutations.md +++ b/docs/ptbr/guide/mutations.md @@ -18,7 +18,7 @@ const store = new Vuex.Store({ }) ``` -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: +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') @@ -26,7 +26,7 @@ store.commit('increment') ### Commit com Payload -Você pode passar um argumento adicional para o _store.commit_, que é chamado de **_payload_** para a mutação: +Você pode passar um argumento adicional para o `store.commit`, que é chamado de **_payload_** para a mutação: ``` js // ... @@ -96,7 +96,7 @@ Como o estado de um _store_ Vuex é reativado pelo Vue, quando alteramos o estad ### 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: +É 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 toda a aplicação: ``` js // mutation-types.js @@ -136,11 +136,11 @@ mutations: { } ``` -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! +Agora imagine que estamos depurando a aplicação 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): +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' diff --git a/docs/ptbr/guide/plugins.md b/docs/ptbr/guide/plugins.md index b9c0f3925..d9204d0ee 100644 --- a/docs/ptbr/guide/plugins.md +++ b/docs/ptbr/guide/plugins.md @@ -83,7 +83,7 @@ const store = new Vuex.Store({ }) ``` -O _plugin_ vai ser usado por padrão. Para produção, você vai precisar do [DefinePlugin](https://webpack.js.org/plugins/define-plugin/) 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. +O _plugin_ vai ser usado por padrão. Para produção, você vai precisar do [DefinePlugin](https://webpack.js.org/plugins/define-plugin/) 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 diff --git a/docs/ptbr/guide/state.md b/docs/ptbr/guide/state.md index 70a7f4d6a..426c8876d 100644 --- a/docs/ptbr/guide/state.md +++ b/docs/ptbr/guide/state.md @@ -4,7 +4,7 @@
Tente esta lição no Scrimba
-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. +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 aplicação. Uma árvore única de estado facilita a localização de uma parte específica do estado, e permite capturar facilmente momentos do estado atual da aplicação 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. @@ -26,9 +26,9 @@ const Counter = { } ``` -Sempre que o _store.state.count_ muda, fará com que o dado computado seja reavaliado e ative as atualizações de _DOM_ associadas. +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. +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 requer dados fictícios (ou _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)`): @@ -87,7 +87,7 @@ export default { } ``` -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. +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([ diff --git a/docs/ptbr/guide/strict.md b/docs/ptbr/guide/strict.md index e07c3f653..0595177db 100644 --- a/docs/ptbr/guide/strict.md +++ b/docs/ptbr/guide/strict.md @@ -1,6 +1,6 @@ # Modo Estrito -Para habilitar o modo estrito, simplesmente passe _strict: true_ ao criar um _store_ Vuex: +Para habilitar o modo estrito, simplesmente passe `strict: true` ao criar um _store_ Vuex: ``` js const store = new Vuex.Store({ diff --git a/docs/ptbr/guide/structure.md b/docs/ptbr/guide/structure.md index b5cac0b86..4cbf4d4c1 100644 --- a/docs/ptbr/guide/structure.md +++ b/docs/ptbr/guide/structure.md @@ -2,7 +2,7 @@ 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_. +1. O estado do nível da aplicação é 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 @@ -10,7 +10,7 @@ O Vuex não restringe realmente como você estrutura seu código. Em vez disso, 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: +Para qualquer aplicação mais complexa, provavelmente precisaremos aproveitar os módulos. Aqui está um exemplo de estrutura de projeto: ``` bash ├── index.html