Added Italian Translation (#117)

* Added Italian Translation

* Fixed link

* Translated State documentation

* Translated state

* Translated Mutations

* Improved translation

* Finished Action translation

* Finished Data Flow translation

* Translated structure

* Fixed wrong link

* Translated middlewares

* Improved translation

* Translated strict

* Translated forms

* Translated Hot Reload

* Translated API

* Started last translation

* Translate Testing. The translation is complete

docs/en/middlewares.md

@@ -48,7 +48,7 @@ const store = new Vuex.Store({
 })
 ```
 
-The middleware will be used by default. For production, use the build setup described [here](http://vuejs.org/guide/application.html#Deploying_for_Production) to convert the value of `process.env.NODE_ENV !== 'production'` to `false` for the final build.
+The middleware will be used by default. For production, use the build setup described [here](http://vuejs.org/guide/application.html#Deploying-for-Production) to convert the value of `process.env.NODE_ENV !== 'production'` to `false` for the final build.
 
 ### Built-in Logger Middleware
 

docs/it/README.md

@@ -0,0 +1 @@
+SUMMARY.md

docs/it/SUMMARY.md

@@ -0,0 +1,18 @@
+# Tabella dei Contenuti
+
+> Raccomandiamo di leggere il tutto secondo l'ordine stabilito.
+
+- [Che cosa è Vuex?](intro.md)
+- [Per iniziare](getting-started.md)
+- Concetti fondamentali
+  - [Stato e Getter](state.md)
+  - [Mutation](mutations.md)
+  - [Action](actions.md)
+- [Flusso dei Dati](data-flow.md)
+- [Struttura dell'Applicazione](structure.md)
+- [Middleware](middlewares.md)
+- [Modalità Strict](strict.md)
+- [Gestione dei Form](forms.md)
+- [Test del Codice](testing.md)
+- [Aggiornamento Automatico](hot-reload.md)
+- [Documentazione delle API](api.md)

docs/it/actions.md

@@ -0,0 +1,133 @@
+# Actions
+
+> Le azioni, action, in Vuex sono i cosidetti "Actions creator" nel mondo di Flux. Ma questo termine è fuorviante.
+
+Le action sono semplici funzioni che inviano le mutation. Per convenzione, le action in Vuex si aspettano sempre un istanza di store come primo argomento, seguito da altri argomenti opzionali:
+
+``` js
+// l'action più semplice
+function increment (store) {
+  store.dispatch('INCREMENT')
+}
+
+// una semplice azione con più argomenti
+// che sfrutta il distruttore dei ES2015
+function incrementBy ({ dispatch }, amount) {
+  dispatch('INCREMENT', amount)
+}
+```
+
+La domanda può sorgere spontanea, perchè non inviamo direttamente le mutation senza passare per le azioni? Ricordate che **le mutation sono sempre sincrone**? Bene, tramite le action noi possiamo scavalcare questo problema in quanto, internamente ad una action, possiamo gestire codice asincrono!
+
+``` js
+function incrementAsync ({ dispatch }) {
+  setTimeout(() => {
+    dispatch('INCREMENT')
+  }, 1000)
+}
+```
+
+Un esempio pratico può essere il sistema di checkout di un carrello che richiede **chiamate asincrone ad API** e **l'invio di mutation multiple**:
+
+``` js
+function checkout ({ dispatch, state }, products) {
+  // salviamo l'oggetto corrente
+  const savedCartItems = [...state.cart.added]
+  // inviamo una richiesta di checkout
+  dispatch(types.CHECKOUT_REQUEST)
+  // in questo caso le API accettano due callback per success e failure
+  shop.buyProducts(
+    products,
+    // success
+    () => dispatch(types.CHECKOUT_SUCCESS),
+    // failure
+    () => dispatch(types.CHECKOUT_FAILURE, savedCartItems)
+  )
+}
+```
+
+Si noti che invece di aspettarsi un valore di ritorno, la gestione delle API asincrone è fatta chiamando altre mutation. Possiamo quindi definire una regola di base dove **l'unico effetto prodotto dalla chiamata ad azioni è l'invio di mutation**.
+
+### Chiamare gli Action nei Componenti
+
+Forse avrete notato che le azioni, e le funzioni legate ad esse, non possono essere chiamate direttamente senza una referenza all'istanza dello store. Tecnicamente si potrebbe fare chiamando `action(this.$store)` internamente ad un metodo, è comunque consigliato esporre un set di API dal componente tramite `vuex.actions`, per esempio:
+
+``` js
+// internamente ad un componente
+import { incrementBy } from './actions'
+
+const vm = new Vue({
+  vuex: {
+    getters: { ... }, // i getter
+    actions: {
+      incrementBy // Utilizziamo la sintassi ES6 per gli oggetti
+    }
+  }
+})
+```
+
+Il codice appena visto lega l'azione `incrementBy` con l'istanza di uguale nome nello store ed espone tale istanza al componente tramite `vm.incrementBy`. Tutti gli argomenti passati ad `vm.incrementBy` saranno passai prima all'azione e poi allo store in questo modo:
+
+``` js
+vm.incrementBy(1)
+```
+
+è uguale a scrivere:
+
+``` js
+incrementBy(vm.$store, 1)
+```
+
+ma il beneficio di avere tale sintassi è che ora possiamo usare:
+
+``` html
+<button v-on:click="incrementBy(1)">Incrementa di uno</button>
+```
+
+Ovviamente potete utilizzare un altro nome dentro il componente, l'importante è referenziarlo all'istanza nello store:
+
+``` js
+// il componente
+import { incrementBy } from './actions'
+
+const vm = new Vue({
+  vuex: {
+    getters: { ... },
+    actions: {
+      plus: incrementBy // usiamo un altro nome
+    }
+  }
+})
+```
+
+Ora l'action sarà legata a `vm.plus` invece che `vm.incrementBy`.
+
+### Action Inline
+
+Se un'azione è specifica per un determinato componente, allora possiamo usare una scorciatoia e definirla inline:
+
+``` js
+const vm = new Vue({
+  vuex: {
+    getters: { ... },
+    actions: {
+      plus: ({ dispatch }) => dispatch('INCREMENT')
+    }
+  }
+})
+```
+
+### Legare tutte le Action
+
+Possiamo vincolare un componente ad avere tutte le action senza specificarne nessuna:
+
+``` js
+import * as actions from './actions'
+
+const vm = new Vue({
+  vuex: {
+    getters: { ... },
+    actions // il componente ora accede a tutte le action
+  }
+})
+```

docs/it/api.md

@@ -0,0 +1,94 @@
+# Referenza alle API
+
+### Vuex.Store
+
+``` js
+import Vuex from 'vuex'
+
+const store = new Vuex.Store({ ...opzioni })
+```
+
+### Opzioni per il Costruttore
+
+- **state**
+
+  - tipo: `Oggetto`
+
+    Lo stato principale per lo store di Vuex.
+
+    [Dettagli](state.md)
+
+- **mutations**
+
+  - tipo: `Oggetto`
+
+    Un Oggetto che ha come chiavi i nomi delle mutation e come valore il nome della funzione (handler) della mutation stessa. L'handler ricevere sempre `state` come primo argomento.
+
+    [Dettagli](mutations.md)
+
+- **modules**
+
+  - tipo: `Oggetto`
+
+    Un  Oggetto contenente tutti i sub moduli che si uniranno allo store, di solito è formato tipo:
+
+    ``` js
+    {
+      key: {
+        state,
+        mutations
+      },
+      ...
+    }
+    ```
+
+    Ogni modulo può contenere uno stato `state` e delle `mutations`, molto simile al'opzione di root. Lo stato di un modulo sarà legato a quello principale dello store e sarà accessibile tramite il nome del modulo. Una mutation in un modulo riceverà solo lo stato del modulo stesso invece di quello principale (root state).
+
+- **middlewares**
+
+  - tipo: `Array<Oggetto>`
+
+    Un oggetto che contiene tutti i middleware del tipo:
+
+    ``` js
+    {
+      snapshot: Boolean, // predefinito: false
+      onInit: Funzione,
+      onMutation: Funzione
+    }
+    ```
+
+    Tutti i campi sono facoltativi. [Dettagli](middlewares.md)
+
+- **strict**
+
+  - tipo: `Boolean`
+  - predefinito: `false`
+
+    Forza Vuex ad avere lo store in modalità strict. In questa modalità tutte le mutazioni al di fuori del sistema di mutation di Vuex solleveranno un Errore.
+
+    [Dettagli](strict.md)
+
+### Proprietà di istanza di Vuex.Store
+
+- **state**
+
+  - tipo: `Oggetto`
+
+    Lo stato principale. In sola lettura.
+
+### Metodi di istanza di Vuex.Store
+
+- **dispatch(nomeMutazione: Stringa, ...argomenti)**
+
+  Directly dispatch a mutation. This is useful in certain situations are in general you should prefer using actions in application code.
+
+- **watch(pathOrGetter: Stringa|Funzione, cb: Funzione, [opzioni: Oggetto])**
+
+  Watch a path or a getter Funzione's value, and call the callback when the value changes. Accepts an optional opzioni Oggetto that takes the same opzioni as Vue's `vm.$watch` method.
+
+  To stop watching, call the returned handle Funzione.
+
+- **hotUpdate(opzioni: Oggetto)**
+
+  Hot swap new actions and mutations. [Dettagli](hot-reload.md)

docs/it/book.json

@@ -0,0 +1 @@
+../book.json

docs/it/data-flow.md

@@ -0,0 +1,89 @@
+# Flusso dei Dati
+
+Costruiamo un semplice contatore tramite Vuex per avere una visione migliore su come i dati siano scambiati tra i vari componenti. Si noti che questo esempio è un estremizzazione per spiegare alcuni concetti chiavi, Vuex non è utile per questo tipo di applicazioni molto semplici.
+
+### Lo Store
+
+``` js
+// store.js
+import Vue from 'vue'
+import Vuex from 'vuex'
+
+Vue.use(Vuex)
+
+// Stato iniziale della nostra applicazione
+const state = {
+  count: 0
+}
+
+// Definiamo tutte le mutazioni
+const mutations = {
+  INCREMENT (state) {
+    state.count++
+  },
+  DECREMENT (state) {
+    state.count--
+  }
+}
+
+// creiamo lo store
+export default new Vuex.Store({
+  state,
+  mutations
+})
+```
+
+### Action
+
+``` js
+// actions.js
+export const increment = ({ dispatch }) => dispatch('INCREMENT')
+export const decrement = ({ dispatch }) => dispatch('DECREMENT')
+```
+
+### Utilizziamo Vue
+
+**Il Template**
+
+``` html
+<div id="app">
+  Hai Cliccato: {{ count }} volte
+  <button v-on:click="increment">+</button>
+  <button v-on:click="decrement">-</button>
+</div>
+```
+
+**Lo Script**
+
+``` js
+// Stiamo importanto ed iniettando lo store perchè questo è il componente di root
+// In un'applicazione grossa questo procedimento viene fatto una sola volta
+import store from './store'
+import { increment, decrement } from './actions'
+
+const app = new Vue({
+  el: '#app',
+  store,
+  vuex: {
+    getters: {
+      count: state => state.count
+    },
+    actions: {
+      increment,
+      decrement
+    }
+  }
+})
+```
+
+Ecco fatto, questa applicazione è molto semplice e mostra come le action, mutazioni e lo store funzionino in modo tale da manipolare, anche se in questo caso molto banalmente, lo stato in base agli eventi che arrivano dal template, o utente.
+
+Noterete anche che il flusso dei dati è unidirezionale, come dovrebbe esserlo in Flux:
+
+1. L'utente sfrutta un componente per eseguire delle action;
+2. Le action avvitano le mutazioni che cambiano lo stato;
+3. Una volta che lo stato cambia una proprietà dello store, tale cambiamento viene riflesso ai componenti tramite i getter.
+
+<p align="center">
+  <img width="700px" src="vuex.png">
+</p>

docs/it/forms.md

@@ -0,0 +1,41 @@
+# Gestione dei Form
+
+Quando si utilizza Vuex in modalità strict, può risultare difficile utilizzare `v-model` su uno stato che appartiene a Vuex:
+
+``` html
+<input v-model="obj.message">
+```
+
+Presupponendo che `obj` sia una proprietà derivata che restituisce un oggetto dallo store, avremmo una situazione dove `v-model` cerca di mutare direttamente `obj.message` quando l'utente modifica l'input. In modalità strict questo solleverebbe un errore a causa di una mutazione non avvenuta internamente ad una mutation di Vuex.
+
+Un modo per risolvere questo conflitto in Vuex è quello di legare l `<input>` ad una chiamata che si riferisce ad un'azione. L'input si lega tramite `input` oppure l'evento `change`:
+
+``` html
+<input :value="message" @input="updateMessage">
+```
+``` js
+// ...
+vuex: {
+  getters: {
+    message: state => state.obj.message
+  },
+  actions: {
+    updateMessage: ({ dispatch }, e) => {
+      dispatch('UPDATE_MESSAGE', e.target.value)
+    }
+  }
+}
+```
+
+E ora scriviamo la mutation:
+
+``` js
+// ...
+mutations: {
+  UPDATE_MESSAGE (state, message) {
+    state.obj.message = message
+  }
+}
+```
+
+Questo approccio rendere l'utilizzo di `v-model` leggermente più complesso ma è un trade-off necessario per rendere il vincolo tra l'input e lo stato tracciabile. Detto questo è giusto ricordare che Vuex non obbliga l'inserimento di tutti gli stati dentro ad uno store, se avete bisogno di tracciare degli stati che sono specifici di un solo componente è possibile farlo benissimo fuori dallo store di Vuex.

docs/it/getting-started.md

@@ -0,0 +1,54 @@
+# Per Iniziare
+
+Al centro di qualsiasi applicazione che utilizza Vuex si trova lo **store**. Uno `store` è sostanzialmente un contenitore che contiene, per l'appunto, tutti gli **stati dell'applicazione**. Ci sono due cose che differenziano Vuex da un oggetto globale tipico di JavaScript:
+
+1. Lo store di Vuex è reattivo. Quando un componente preleva uno stato da store, quest'ultimo verrà aggiornato nel caso quello specifico stato venga cambiato.
+
+2. Non potete cambiare uno stato nello store in modo diretto. L'unico modo per effettuare un cambiamento è quello di inviare in modo esplicito una **mutations**. Questa filosofia rende più facile tracciare qualsiasi cambiamento di stato.
+
+### Lo Store più Semplice
+
+> **NOTA:** Nel cosrso della guida utilizzeremo la sintassi JavaScript che si riferisce a `ES2015` se ancora non siete al corrente degli aggiornamenti [aggiornatevi al riguardo](https://babeljs.io/docs/learn-es2015/)!
+Questa documentazione, insoltre, assume che voi siate al corrente con i concetti discussi nel capitolo: [Costruire un'Applicazione scalabile](http://it.vuejs.org/guide/application.html).
+
+Creare uno Store in Vuex è un processo abbastanza semplice, si inizia con lo stato iniziale e qualche mutations:
+
+``` js
+import Vuex from 'vuex'
+
+const state = {
+  count: 0
+}
+
+const mutations = {
+  INCREMENT (state) {
+    state.count++
+  }
+}
+
+const store = new Vuex.Store({
+  state,
+  mutations
+})
+```
+
+Ora potrete accedere all oggetto stato tramite `store.state` ed eventualmente attivare mutazioni, per esempio sul nome:
+
+``` js
+store.dispatch('INCREMENT')
+
+console.log(store.state.count) // -> 1
+```
+
+Se preferite l'approccio ad oggetti potete fare:
+
+``` js
+// stesso risultato
+store.dispatch({
+  type: 'INCREMENT'
+})
+```
+
+Di nuovo, il motivo per il quale stiamo effettuando il dispatch invece di cambiare lo stato tramite `store.state.count` è perchè vogliamo esplicitamente tenere traccia del cambiamento in se. Questa semplice convenzione rende le nostre intenzioni più esplicite, aiutando anche a capire perchè cambiamo lo stato in determinati punti del nostro codice. In aggiunta, questo ci permette di implementare strumenti per tenere traccia delle mutazioni, salvarne una copia o fare anche debuggin trasversale.
+
+Ovviamente questo è un esempio molto semplice di come funziona Vuex e la centralizzazione degli stati. Più avanti discuteremo di alcuni concetti in dettagli come: [Stati](state.md), [Mutazioni](mutations.md) ed [Azioni](actions.md).

docs/it/hot-reload.md

@@ -0,0 +1,45 @@
+# Aggiornamento Automatico (Hot Reload)
+
+Vuex supporta l'aggiornamento automatico (Hot Reload o Aggiornamento a Caldo) per quanto riguarda i moduli, le mutation e gli action il tutto tramite WebPack [e le sue API](https://webpack.github.io/docs/hot-module-replacement.html).
+Ovviamente esiste anche l'alternativa tramite Browserify tramite il plugin [browserify-hmr](https://github.com/AgentME/browserify-hmr/).
+
+Per le mutation ed i moduli dovrete usare il metodo `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) {
+  // accetta le action o le mutation come moduli
+  module.hot.accept(['./mutations', './modules/a'], () => {
+    // richiede di aggiornare i moduli
+    // aggiungiamo .default tramite babel 6
+    const newMutations = require('./mutations').default
+    const newModuleA = require('./modules/a').default
+    // sostituiamo le nuove mutation ed i moduli nello store
+    store.hotUpdate({
+      mutations: newMutations,
+      modules: {
+        a: newModuleA
+      }
+    })
+  })
+}
+```
+
+Per quanto riguarda i getters non dovrete fare niente di specifico. I moduli di Webpack per l'hot reload vengono inseriti nella catena delle dipendenze che vanno ad analizzare i componenti di Vue per i getters, dato che i componenti vengono caricati via `vue-loader` essi sono automaticamente sotto "hot reload", questa catena è ricorsiva per ogni albero di componenti.

docs/it/intro.md

@@ -0,0 +1,13 @@
+## Che cos'è Vuex?
+
+Vuex è un'archietettura per sviluppare applicazioni in Vue.js avendo un controllo dello stato centralizzato. Ispirato da [Flux](https://facebook.github.io/flux/) e [Redux](https://github.com/rackt/redux), ma con una implementazione di fondo più semplice ed intuitiva per lavorare all'unisono con Vue.js ed il suo sistema reattivo.
+
+## Perchè dovrei aver bisogno di tutto ciò?
+
+Se la vostra applicazione è abbastanza semplice, probabilmente non avete bisogno di un'architettura come Vuex. Non applicate concetti in modo prematuro se non servono. Nel caso stiate costruendo una SPA di medie/grosse dimensioni allora si, l'esigenza di Vuex si fa più viva per gestire i vostri componenti ed il loro stato.
+
+Quando si utilizza Vue.js, tendiamo a conservare lo stato internamente ai nostri componenti. Con questo processo ogni componente avrà un "pezzo di stato", dell'intera applicazione, al suo interno. Quando i componenti iniziano a comunicare tra di loro, essi dovranno anche condividere lo stato attuale che conservano al loro interno, il che può portare ad un incongruenza quando più componenti condividono la stessa informazione sullo stato dell'applicazione. Una pratica molto comune per ovviare a questo problema è implementare un sistema di eventi personalizzati che inviano gli stati ad ogni componente che lo richiede. Questa metodologia però porta a costruire eventi sempre più complessi all aumentare dei componenti e degli stati che si frammentano sempre di più.
+
+Per gestire meglio gli stati in un'applicazione che è in continua crescita bisogna iniziare a differenziare **gli stati locali dei componenti** da **gli stati globali dell'applicazione**. Gli stati dell'applicazione non appartengono a nessun componente, ma tutti i componenti possono averne bisogno (per esempio per monitorare gli aggiornamenti del DOM). Centralizzando gli stati in un unico luogo non abbiamo più bisogno di passare eventi in giro per tutti i componenti. In aggiunta questa centralizzazione ci permette di monitorare meglio qualsiasi mutazione l'applicazione subisce.
+
+Vuex inoltre fornisce degli strumenti per suddividere al meglio la logica degli stati in varie parti ma senza intaccare la flessibilità di avere tutto centralizzato.

docs/it/middlewares.md

@@ -0,0 +1,83 @@
+# Middleware
+
+Lo store di Vuex accetta un'opzione detta `middlewares` che espone delle funzionalità per ogni mutation (si noti che non ha nulla a che vedere con i Middleware di Redux). Un Middleware in Vuex è un oggetto con al suo interno delle funzioni tipo:
+
+``` js
+const myMiddleware = {
+  onInit (state, store) {
+    // registra lo stato iniziale
+  },
+  onMutation (mutation, state, store) {
+    // chiamata ad ogni mutation
+    // l'argomento mutation viene fornito con { type, payload }
+  }
+}
+```
+
+un Middleware si può usare così:
+
+``` js
+const store = new Vuex.Store({
+  // ...
+  middlewares: [myMiddleware]
+})
+```
+
+Per definizione, il middleware riceve l'oggetto `state` ma può anche ricevere lo `store` in modo da chiamare delle mutation al suo interno. Dato che i Middleware sono usati principalmente per debugging **non possono mutare nessuno stato**.
+
+A volte un middleware potrebbe voler ricevere un'istantanea dello stato corrente in modo da poterla confrontare con l'eventuale stato post-mutation. Per fare ciò basta impostare l'ozione `snapshot: true`:
+
+``` js
+const myMiddlewareWithSnapshot = {
+  snapshot: true,
+  onMutation (mutation, nextState, prevState, store) {
+    // i due state, next e prev, sono snapshot dello state stesso
+    // prima e dopo la mutazione
+  }
+}
+```
+
+**I middleware che sfruttano gli snapshot andrebbero usati solo durante lo sviluppo**. Webpack, o Browserify, possono assicurarvi una pulizia di queste opzioni durante la build:
+
+``` js
+const store = new Vuex.Store({
+  // ...
+  middlewares: process.env.NODE_ENV !== 'production'
+    ? [myMiddlewareWithSnapshot]
+    : []
+})
+```
+
+In questo esempio viene usato il middleware se si è in ambiente di sviluppo. Per la build di produzione fate riferimento a [questo link](http://it.vuejs.org/guide/application.html#Distruibuzione-in-Produzione) che vi spiega come convertire `process.env.NODE_ENV !== 'production'` a `false` per la build finale.
+
+### Middleware Inclusi
+
+Vuex ha dei middleware per il debugging già inclusi:
+
+``` js
+import createLogger from 'vuex/logger'
+
+const store = new Vuex.Store({
+  middlewares: [createLogger()]
+})
+```
+
+Il middleware `createLogger` ha alcune opzioni interessanti:
+
+``` js
+const logger = createLogger({
+  collapsed: false, // auto espansione dei log delle mutation
+  transformer (state) {
+    // trasforma lo stato prima di loggare
+    // utile per esempio se si vuole speficiare quale subTree loggare
+    return state.subTree
+  },
+  mutationTransformer (mutation) {
+    // le mutation sono loggate nel formato { type, payload }
+    // ma possiamo specificare come formattarle a nostro piacimento
+    return mutation.type
+  }
+})
+```
+
+Si noti che il createLogger utilizza gli snapshot per gli stati, non usatelo in produzione.

docs/it/mutations.md

@@ -0,0 +1,135 @@
+# Mutations
+
+In Vuex le mutations, o mutazioni, sono degli eventi essenziali: ogni mutazione ha un **nome** ed un **handler**. L'handler è la funzione che riceverà lo stato come primo argomento:
+
+``` js
+import Vuex from 'vuex'
+
+const store = new Vuex.Store({
+  state: {
+    count: 1
+  },
+  mutations: {
+    INCREMENT (state) {
+      // stato in fase di mutazione
+      state.count++
+    }
+  }
+})
+``` 
+
+Utilizzare il nome della mutations tutto in maiuscolo è solo una convenzione che aiuta a distinguere le mutations da funzioni normali.
+
+Non è possibile richiamare un handler direttamente. Bisogna registrarlo tramite il sistema di dispatch dello store: "Quando `INCREMENT` è in dispatch allora chiama questo handler", ecco un esempio pratico:
+
+``` js
+store.dispatch('INCREMENT')
+```
+
+### Disptach con Argomenti
+
+E' possibile passare gli argomenti alla mutation:
+
+``` js
+// ...
+mutations: {
+  INCREMENT (state, n) {
+    state.count += n
+  }
+}
+```
+
+``` js
+store.dispatch('INCREMENT', 10)
+```
+
+In questo caso, `10` verrà passato al handler come secondo argomento. Nello specifico delle mutation questi argomenti vengono definiti **payload**.
+
+### Disptach tramite Oggetti
+
+> Richiede una versione >=0.6.2
+
+Si può eseguire il dispatch delle mutation tramite oggetti:
+
+``` js
+store.dispatch({
+  type: 'INCREMENT',
+  payload: 10
+})
+```
+
+Qundo si effettua questo tipo di dispatch, tramite oggetti, è buona norma includere tutti gli argomenti richiesti dalla mutation. Tutto l'oggetto verrà passato come secondo argomento all handler della mutation:
+
+``` js
+mutations: {
+  INCREMENT (state, mutation) {
+    state.count += mutation.payload
+  }
+}
+```
+
+### Le Mutation Seguono le Regole di Vue sulla Reattività
+
+Dato che lo stato di Store in Vuex segue la filosofia "reattiva" di Vue, quando mutiamo uno stato, tutti i componenti che osservano tale stato riceveranno l'aggiornamento in modo automatico.
+Questo significa che anche le mutation hanno bisogno di qualche precauzione:
+
+1. E' preferibile inizializzare ogni stato all interno dello store.
+
+2. Quando si aggiunge una proprietà ad un oggetto è consigliato:
+
+  - Utilizzare `Vue.set(obj, 'newProp', 123)`, o -
+
+  - Rimpiazzare l'oggetto corrente con uno nuovo che include la nuova proprietà. Per esempio utilizzando la `stage-2` della [sintassi di diffusione](https://github.com/sebmarkbage/ecmascript-rest-spread) possiamo scrivere una cosa del tipo:
+
+  ``` js
+  state.obj = { ...state.obj, newProp: 123 }
+  ```
+
+### Utilizzare delle Regole per i Nomi delle Mutation
+
+E' pratica comune utilizzare costanti per i nomi delle mutation, tale pratica favorisce il debug tramite strumenti come linter ed è poi possibile distinguere bene ogni mutation
+
+``` 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: { ... },
+  actions: { ... },
+  mutations: {
+    // possiamo sfruttare la sintassi ES2015 
+    // per utilizzare una costante come nome di una funzione!
+    [SOME_MUTATION] (state) {
+      // stato mutato
+    }
+  }
+})
+```
+
+L'utilizzo delle costanti è altamente consigliato soprattutto quando si divide in più moduli un'applicazione di larga scala. Tutta via non c'è nessuna regola che vi obbliga ad utilizzare tale sintassi se non vi piace.
+
+### Le Mutation devono essere Sincrone
+
+Una regola importante da tenere a mente è che **gli handler delle mutation devono essere sincroni** Perchè? Considerate il seguente esempio:
+
+``` js
+mutations: {
+  SOME_MUTATION (state) {
+    api.callAsyncMethod(() => {
+      state.count++
+    })
+  }
+}
+```
+
+Ora immaginate di dover debuggare l'applicazione e guardate il log delle mutation. Per ogni log sarebbe utile avere un immagine dello stato **prima** e **dopo** la mutazione, purtroppo la chiamata asincrona non ci permette di farlo dato che non viene eseguita quando la mutazione viene chiamata. Non sappiamo quando la chiamata asincrona viene effettivamente chiamata.
+
+### Sulle Azioni
+
+Le mutazioni di stato combinate con eventi asincroni possono portare difficoltà nel capire che cosa succede in un determinato momento. Per sempio se chiamate due metodi, entrambi implementano internamente delle chiamate asincrone, come potete stabilire l'ordine di chiamata? Ecco perchè dev'essere chiaro il motivo per il quale qualsiasi tipo di operazione asincrona dev'essere fatto tramite le [Azioni](actions.md)

docs/it/state.md

@@ -0,0 +1,159 @@
+# Stato e Getter
+
+### Albero a Stato Singolo
+
+Vuex utilizza un **albero a stato singolo** - questo singolo oggetto contiene tutti gli stati dell'applicazione e serve come "unica risorsa della verità". Vuex permette un solo store per applicazione. Un albero a stato singolo permette di localizzare specificatamente un singolo stato, modificarlo, salvarne una copia corrente ed effettuare debug e test.
+
+Questo principio non va in conflitto con il concetto di modularità, più avanti capiremo come distribuire lo stato in più moduli.
+
+### Sfruttare lo Stato nei Componenti di Vue
+
+Come visualizziamo lo stato internamente ad un componente Vue? Il modo più semplice è quello di sfruttare le [proprietà derivate](http://it.vuejs.org/guide/computed.html):
+
+``` js
+// internamente ad un Componente di Vue
+computed: {
+  count: function () {
+    return store.state.count
+  }
+}
+```
+
+Ogni volta che `store.state.count` cambia, verrà riflesso nella proprietà derivata e attiverà gli aggiornamenti del DOM necessari.
+
+Questo metodo, seppur semplice, può portare ad avere uno o più componenti che dipendono da un singleton globale, lo store, il quale può complicare la situazione in fase di test o se si vuole riutilizzare un componente in un'altra applicazione.
+Per evitare questo tipo di problemi, si può "iniettare" lo store internamente al componente, ecco come fare:
+
+1. Installato Vuex, collegate il componente principale (root) con lo store:
+
+  ``` js
+  import Vue from 'vue'
+  import Vuex from 'vuex'
+  import store from './store'
+  import MyComponent from './MyComponent'
+
+  // Questo passo è fondamentale in quando dice a vue
+  // Come comportarti con le opzioni relative a Vuex.
+  Vue.use(Vuex)
+
+  var app = new Vue({
+    el: '#app',
+    // Iniettiamo lo store direttamente nel componente
+    // Così facendo sarà disponibile a tutti i componenti figli
+    store,
+    components: {
+      MyComponent
+    }
+  })
+  ```
+
+  Iniettando lo store direttamente al componente principale, tutti i figli ne beneficeranno e lo store sarà disponibile tramite la proprietà `this.$store`. Comunque non è necessario utilizzare la referenza diretta:
+
+2. Internamente al componente figlio, possiamo sfruttare una funzione **getter** e farci restituire l'opzione `vuex.getters`:
+
+  ``` js
+  // MyComponent.js
+  export default {
+    template: '...',
+    data () { ... },
+    // Qui e dove lavoriamo con Vuex
+    vuex: {
+      getters: {
+        // Questo getter legherà `store.state.count` al componente tramite `this.count`
+        count: function (state) {
+          return state.count
+        }
+      }
+    }
+  }
+  ```
+
+  Si noti la sintassi speciale `vuex`. Al suo interno si specificano gli stati che il componente deve utilizzare dallo store. Per ogni proprietà dello store specificheremo un getter il quale riceve tutto l'albero degli stati dallo store
+  e seleziona solo lo stato che specifichiamo noi il valore verrà inserito in una properità del componente, proprio come una proprietà derivata.
+
+  In molti casi si può semplificare la sintassi del "getter" tramite ES2015:
+
+  ``` js
+  vuex: {
+    getters: {
+      count: state => state.count
+    }
+  }
+  ```
+
+### I Getter devono essere Puri
+
+Tutti i getter Vuex devono essere [delle funzioni pure](https://en.wikipedia.org/wiki/Pure_function) - esse devono prendere l'intero albero degli stati e restituire solo e soltanto un valore di tale stato. Questo rende il tutto più facile da modularizzare, testare e comporre. Significa anche che **non potrete usare `this` nei getter**.
+
+Se vi ritrovate nella situazione di dover usare `this`, per esempio per elaborare una properità derivata basata su uno stato locale del componente, allora dovrete definire un'altra proprietà derivata dedicata:
+
+``` js
+vuex: {
+  getters: {
+    currentId: state => state.currentId
+  }
+},
+computed: {
+  isCurrent () {
+    return this.id === this.currentId
+  }
+}
+```
+
+### I Getter posso restituire Stati Derivati
+
+Se consideriamo che i getter di Vuex dietro le quinte sono delle proprietà derivate, allora possiamo intuire che è possibile sfruttare alcune proprietà di quest'ultime per restituire uno stato più eleborato.
+Per esempio, si consideri che lo stato ha un array di `messaggi` contenente tutti i messaggi, ed un `currentThreadID` che rappresenta il thread corrente visualizzato dall utente.
+Ora, mettiamo caso di voler visualizzare tutti i messaggi che sono associati ad un Thread particolare:
+
+``` js
+vuex: {
+  getters: {
+    filteredMessages: state => {
+      return state.messages.filter(message => {
+        return message.threadID === state.currentThreadID
+      })
+    }
+  }
+}
+```
+
+Dato che le proprietà derivate di Vue.js sono messe in cache in modo automatico, non dovremo preoccuparci di chiamare questo metodo ad ogni mutazione dello stato!
+
+### Condividere dei Getter su più Componenti
+
+Come potete notare `filteredMessages` può essere utile in più componenti. In questo caso è buona idea esportare il metodo e condividerlo su più componenti:
+
+``` js
+// getters.js
+export function filteredMessages (state) {
+  return state.messages.filter(message => {
+    return message.threadID === state.currentThreadID
+  })
+}
+```
+
+``` js
+// In un componente..
+import { filteredMessages } from './getters'
+
+export default {
+  vuex: {
+    getters: {
+      filteredMessages
+    }
+  }
+}
+```
+
+Grazie al fatto che i Getter sono puri, tutti i getter possono essere condivisi tra i componenti e cachati in modo molto convenzionale: quando una dipendenza cambia viene rievalutata una sola volta per tutti i componenti!
+
+> Referenza a Flux: I getter di Vuex sono simili a [`mapStateToProps`](https://github.com/rackt/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options) in Redux. Comounque dato che ci si appoggia al sistema di proprietà derivate di Vue, c'è una netta differenza di prestazioni a favore di Vuex, troviamo più similitudini a [reselect](https://github.com/reactjs/reselect).
+
+### I Componenti Non Possono Mutare gli Stati
+
+E' importante ricordare che **i componenti non dovrebbero mai mutare uno stato in Vuex in modo diretto**. Ogni stato dev'essere mutato in modo esplicito e tracciabile, possibilmente sfruttando il sistema mutations di Vuex stesso.
+
+Per aiutare a rispettare questa regola, se in [Modalità Strict](strict.md), Vuex lancierà un errore se si prova a mutare uno stato in modo diretto.
+
+Con questa regola i vostri componenti in Vue avranno meno responsabilità: essi sono legati allo Store di Vuex in modalità sola lettura tramite i getter, l'unico modo per cambiare lo stato in qualsiasi modo è attivando le **mutations** (ne parleremo dopo). Il vantaggio è che i componenti potranno continuare ad operare sui loro stati locali se necessario ma senza doversi preoccupare di gestire la logica per gli stati globali dell'applicazione dato che, quest'ultimi, sono centralizzati internamente in Vuex.

docs/it/strict.md

@@ -0,0 +1,25 @@
+# Modalità Strict
+
+Per Abilitare la modalità strict basta passare `strict: true` quando si crea uno Store in Vuex:
+
+``` js
+const store = new Vuex.Store({
+  // ...
+  strict: true
+})
+```
+
+Quando si è in modalità strict, ogni volta che Vuex viene mutato al di fuori delle mutation un errore viene lanciato. Questa logica assicura che tutti gli stati siano tracciabili dal sistema di debug.
+
+### Sviluppo vs Produzione
+
+**Non abilutate la modalità strict quando pubblicate il progetto in produzione** La modalità strict esegue una scansione approfondita di ogni mutation per capire i cambiamenti effettuati sugli stati dello store - in produzione questo portrebbe a dei problemi di prestazioni.
+
+Come sui middleware anche qui possiamo automatizzare il processo di abilitazione/disabilitazione tramite gli strumenti di build:
+
+``` js
+const store = new Vuex.Store({
+  // ...
+  strict: process.env.NODE_ENV !== 'production'
+})
+```

docs/it/structure.md

@@ -0,0 +1,136 @@
+# Struttura dell'Applicazione
+
+Vuex non ti obbliga a seguire nessuna convenzione per quanto riguarda la struttura del codice però ci sono dei principi che possono essere utili e vale la pena tenere in considerazione:
+
+1. Lo stato dell'Applicazione è conservato in uno store, il quale è un singolo oggetto.
+
+2. L'unico modo di mutare lo stato è quello di inviare una mutation allo store.
+
+3. Le mutation sono sincrone, l'unico effetto che devono avere è quello di mutare uno stato.
+
+4. Possiamo esporre uno strato più complesso di API tramite le action. Le action possono incapsulare mutation e codice asincrono ma il fine ultimo di una action dev'essere sempre quello che attivare una mutation.
+
+5. I Componenti usano i getter per prelevare gli stati dallo store e chiamano le azioni per mutarli.
+
+La cosa interessante delle mutation, action e getter in Vuex è il fatto che **sono tutte funzioni javascript**. Se seguirete queste piccole regolette sarà più facile interscambiare la logica tra progetti che utilizzano VuexT. Di seguito sono mostrate delle strutture di base per i vostri progetti in Vuex.
+
+### Progetto Semplice
+
+Quando si parla di applicazioni semplici possiamo definire **store** e **actions** in due file separati:
+
+``` bash
+.
+├── index.html
+├── main.js
+├── components
+│   ├── App.vue
+│   └── ...
+└── vuex
+    ├── store.js     # file per lo store
+    └── actions.js   # file per le action
+```
+
+Per un esempio pratico potete rivedere [L'esempio del Contatore](https://github.com/vuejs/vuex/tree/master/examples/counter) oppureß [L'esempio TodoMVC](https://github.com/vuejs/vuex/tree/master/examples/todomvc).
+
+Alternativamente potete anche suddividere le mutation in un file a se stante.
+
+### Medium to Large Project
+
+Per tutte quelle applicazioni di medie o grosse dimensioni la struttura di Vuex può differire rispetto a quella vista precedentemente. Per esempio la suddivisione del codice in moduli atomici per ogni vario stato da monitorare (molto simile alla logica degli store in Flux o ai reducers in Redux), ognuno dei quali si occupa di uno specifico dominio nella vostra applicazione ecco un esempio di struttura:
+
+``` bash
+├── index.html
+├── main.js
+├── api
+│   └── ... # api request
+├── components
+│   ├── App.vue
+│   └── ...
+└── vuex
+    ├── actions.js        # Tutte le azioni
+    ├── store.js          # Qui assembliamo i moduli
+    ├── mutation-types.js # costanti globali
+    └── modules
+        ├── cart.js       # lo stato e le mutation per il carrello
+        └── products.js   # lo stato e le mutation per i prodotti
+```
+
+Un modulo, di solito, assomiglia a qualcosa del tipo:
+
+``` js
+// vuex/modules/products.js
+import {
+  RECEIVE_PRODUCTS,
+  ADD_TO_CART
+} from '../mutation-types'
+
+// stato iniziale
+const state = {
+  all: []
+}
+
+// mutations
+const mutations = {
+  [RECEIVE_PRODUCTS] (state, products) {
+    state.all = products
+  },
+
+  [ADD_TO_CART] (state, productId) {
+    state.all.find(p => p.id === productId).inventory--
+  }
+}
+
+export default {
+  state,
+  mutations
+}
+```
+
+Ed in vuex/store.js, possiamo assemblare tutti i moduli:
+
+``` js
+// vuex/store.js
+import Vue from 'vue'
+import Vuex from '../../../src'
+// importiamo i moduli
+import cart from './modules/cart'
+import products from './modules/products'
+
+Vue.use(Vuex)
+
+export default new Vuex.Store({
+  // combiniamoli
+  modules: {
+    cart,
+    products
+  }
+})
+```
+
+Lo stato iniziale di `cart` verrà legato alla root dell'albero degli stati in modo tale da ottenere `store.state.cart`. In aggiunta **tutte le mutation sono definite in un sub modulo e ricevono solo lo stato associato a tale sub modulo**. Questo significa che il modulo `cart` riceverà sempre `store.state.cart` come primo argomento.
+
+L'albero degli stati, e la sua root, non possono essere rimpiazzati all'interno dei moduli. Per esempio questo codice non funzionerà:
+
+``` js
+const mutations = {
+  SOME_MUTATION (state) {
+    state = { ... }
+  }
+}
+```
+
+Invece questo codice contiene la logica giusta per gestire gli alberi di ogni sub modulo:
+
+``` js
+const mutations = {
+  SOME_MUTATION (state) {
+    state.value = { ... }
+  }
+}
+```
+
+Dato che tutti i moduli esportano semplici funzioni ed oggetti javascript essi sono facili da testare e mantenere ma, soprattutto, possono essere aggiornati tramite "hot-reload". Ovviamente la guida descritta sopra è solo un indicazione di come dovrebbe essere strutturata un'applicazione tramite Vuex. Potete usare qualsiasi struttura voi riteniate adeguata.
+
+Si noti che non ci sono action nei moduli, questo perchè una singola azione può attivare differenti mutation in differenti moduli. E' sempre una buona idea separare le action dall'implementazione dei moduli.
+
+Per un esempio concreto potete rivedere [il Carrello della Spesa in Vuex](https://github.com/vuejs/vuex/tree/master/examples/shopping-cart).

docs/it/testing.md

@@ -0,0 +1,166 @@
+# Test del Codice
+
+La prima cosa da testare in un'applicazione che sfrutta Vuex sono le mutation e le action.
+
+### Testare le Mutation
+
+Per testare le mutation non abbiamo bisogno di nessun tipo di sistema specifico dato che esse si basano solo sugli argomenti che gli vengono passati. Se state utilizzando i moduli ES2015 potete mettere le vostre mutation nel file `store.js`, e potete esportarle come qualsiasi altro modulo:
+
+``` js
+const state = { ... }
+
+// esportiamo le mutation
+export const mutations = { ... }
+
+export default new Vuex.Store({
+  state,
+  mutations
+})
+```
+
+Testiamo una mutation sfruttando Mocha e Chai (potete usare qualsiasi framework voi troviate comodo):
+
+``` js
+// mutations.js
+export const INCREMENT = state => state.count++
+```
+
+``` js
+// mutations.spec.js
+import { expect } from 'chai'
+import { mutations } from './store'
+
+// creiamo la struttura
+const { INCREMENT } = mutations
+
+describe('mutations', () => {
+  it('INCREMENT', () => {
+    // facciamo un mock dello stato
+    const state = { count: 0 }
+    // applichiamo la mutation
+    INCREMENT(state)
+    // confrontiamo i risultati
+    expect(state.count).to.equal(1)
+  })
+})
+```
+
+### Testare le Action
+
+Le Action possono essere più complesse da testate dato che possono contenere chiamate ad API esterne a Vuex. Quando si testano le action, si dovrà fare uso, nella maggior parte dei casi, di un sistema di mocking - per esempio nel caso volessimo chiamare delle API ad un servizio di terze parti
+Per effettuare il mocking delle dipendenze, si può utilizzare il comodo sistema di [inject-loader](https://github.com/plasticine/inject-loader) assieme a WebPack.
+
+Esempio su una Action asincrona:
+
+``` js
+// actions.js
+import shop from '../api/shop'
+
+export const getAllProducts = ({ dispatch }) => {
+  dispatch('REQUEST_PRODUCTS')
+  shop.getProducts(products => {
+    dispatch('RECEIVE_PRODUCTS', products)
+  })
+}
+```
+
+``` js
+// actions.spec.js
+
+// utilizziamo la sintassi require per i loader inline
+// tramte inject-loader, ci restituisce un model
+// che ci permette di fare mocking
+import { expect } from 'chai'
+const actionsInjector = require('inject!./actions')
+
+// creiamo il modulo tramite mock
+const actions = actionsInjector({
+  '../api/shop': {
+    getProducts (cb) {
+      setTimeout(() => {
+        cb([ /* response dal mock */ ])
+      }, 100)
+    }
+  }
+})
+
+// testiamo le azioni con i risultati desiderati
+const testAction = (action, args, state, expectedMutations, done) => {
+  let count = 0
+  const dispatch = (name, ...payload) => {
+    const mutation = expectedMutations[count]
+    expect(mutation.name).to.equal(name)
+    if (payload) {
+      expect(mutation.payload).to.deep.equal(payload)
+    }
+    count++
+    if (count >= expectedMutations.length) {
+      done()
+    }
+  }
+  action({dispatch, state}, ...args)
+
+  if (count === 0) {
+    expect(expectedMutations.length).to.equal(0)
+    done()
+  }
+}
+
+describe('actions', () => {
+  it('getAllProducts', done => {
+    testAction(actions.getAllProducts, [], {}, [
+      { name: 'REQUEST_PRODUCTS' },
+      { name: 'RECEIVE_PRODUCTS', payload: [ /* mocked response */ ] }
+    ], done)
+  })
+})
+```
+
+### Eseguire i tests
+
+Se le tue mutation o action sono scritte in modo consono, i test non dovrebbero soffrire dipendeze esterne, come il browser e le sue API, anche durante l'uso di Mock. Detto questo potenzialmente è possibile pacchettizare i test tramite WebPack e farli girare sotto Node direttamente. Alternativamente è possibile utilizzare un sistema come `mocha-loader` o Karma assieme a `karma-webpack` per far girare i test in un browser reale.
+
+#### Girare sotto Node
+
+Ecco una config webpack per testare tramite Node:
+
+``` js
+module.exports = {
+  entry: './test.js',
+  output: {
+    path: __dirname,
+    filename: 'test-bundle.js'
+  },
+  module: {
+    loaders: [
+      {
+        test: /\.js$/,
+        loader: 'babel',
+        exclude: /node_modules/
+      }
+    ]
+  },
+  babel: {
+    presets: ['es2015']
+  }
+}
+```
+
+Successivamente:
+
+``` bash
+webpack
+mocha test-bundle.js
+```
+
+#### Testare nel Browser
+
+1. Installare `mocha-loader`
+2. Cambiare l `entry` dalla configurazione Webpack sopra citata in `'mocha!babel!./test.js'`.
+3. Inizializzare `webpack-dev-server` utilizzando la configurazione sopra citata
+4. Andare su `localhost:8080/webpack-dev-server/test-bundle`.
+5. Profit!
+
+#### Testare nel Browser tramite Karma e karma-webpack
+
+Per una guida più dettagliata su Karma consultare la [documentazione di vue-loader](http://vuejs.github.io/vue-loader/workflow/testing.html).