Skip to content

Commit e4dd092

Browse files
ludo237yyx990803
authored andcommitted
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
1 parent e1940c0 commit e4dd092

18 files changed

+1194
-1
lines changed

docs/en/middlewares.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -48,7 +48,7 @@ const store = new Vuex.Store({
4848
})
4949
```
5050

51-
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.
51+
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.
5252

5353
### Built-in Logger Middleware
5454

docs/it/README.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
SUMMARY.md

docs/it/SUMMARY.md

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
# Tabella dei Contenuti
2+
3+
> Raccomandiamo di leggere il tutto secondo l'ordine stabilito.
4+
5+
- [Che cosa è Vuex?](intro.md)
6+
- [Per iniziare](getting-started.md)
7+
- Concetti fondamentali
8+
- [Stato e Getter](state.md)
9+
- [Mutation](mutations.md)
10+
- [Action](actions.md)
11+
- [Flusso dei Dati](data-flow.md)
12+
- [Struttura dell'Applicazione](structure.md)
13+
- [Middleware](middlewares.md)
14+
- [Modalità Strict](strict.md)
15+
- [Gestione dei Form](forms.md)
16+
- [Test del Codice](testing.md)
17+
- [Aggiornamento Automatico](hot-reload.md)
18+
- [Documentazione delle API](api.md)

docs/it/actions.md

Lines changed: 133 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,133 @@
1+
# Actions
2+
3+
> Le azioni, action, in Vuex sono i cosidetti "Actions creator" nel mondo di Flux. Ma questo termine è fuorviante.
4+
5+
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:
6+
7+
``` js
8+
// l'action più semplice
9+
function increment (store) {
10+
store.dispatch('INCREMENT')
11+
}
12+
13+
// una semplice azione con più argomenti
14+
// che sfrutta il distruttore dei ES2015
15+
function incrementBy ({ dispatch }, amount) {
16+
dispatch('INCREMENT', amount)
17+
}
18+
```
19+
20+
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!
21+
22+
``` js
23+
function incrementAsync ({ dispatch }) {
24+
setTimeout(() => {
25+
dispatch('INCREMENT')
26+
}, 1000)
27+
}
28+
```
29+
30+
Un esempio pratico può essere il sistema di checkout di un carrello che richiede **chiamate asincrone ad API** e **l'invio di mutation multiple**:
31+
32+
``` js
33+
function checkout ({ dispatch, state }, products) {
34+
// salviamo l'oggetto corrente
35+
const savedCartItems = [...state.cart.added]
36+
// inviamo una richiesta di checkout
37+
dispatch(types.CHECKOUT_REQUEST)
38+
// in questo caso le API accettano due callback per success e failure
39+
shop.buyProducts(
40+
products,
41+
// success
42+
() => dispatch(types.CHECKOUT_SUCCESS),
43+
// failure
44+
() => dispatch(types.CHECKOUT_FAILURE, savedCartItems)
45+
)
46+
}
47+
```
48+
49+
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**.
50+
51+
### Chiamare gli Action nei Componenti
52+
53+
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:
54+
55+
``` js
56+
// internamente ad un componente
57+
import { incrementBy } from './actions'
58+
59+
const vm = new Vue({
60+
vuex: {
61+
getters: { ... }, // i getter
62+
actions: {
63+
incrementBy // Utilizziamo la sintassi ES6 per gli oggetti
64+
}
65+
}
66+
})
67+
```
68+
69+
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:
70+
71+
``` js
72+
vm.incrementBy(1)
73+
```
74+
75+
è uguale a scrivere:
76+
77+
``` js
78+
incrementBy(vm.$store, 1)
79+
```
80+
81+
ma il beneficio di avere tale sintassi è che ora possiamo usare:
82+
83+
``` html
84+
<button v-on:click="incrementBy(1)">Incrementa di uno</button>
85+
```
86+
87+
Ovviamente potete utilizzare un altro nome dentro il componente, l'importante è referenziarlo all'istanza nello store:
88+
89+
``` js
90+
// il componente
91+
import { incrementBy } from './actions'
92+
93+
const vm = new Vue({
94+
vuex: {
95+
getters: { ... },
96+
actions: {
97+
plus: incrementBy // usiamo un altro nome
98+
}
99+
}
100+
})
101+
```
102+
103+
Ora l'action sarà legata a `vm.plus` invece che `vm.incrementBy`.
104+
105+
### Action Inline
106+
107+
Se un'azione è specifica per un determinato componente, allora possiamo usare una scorciatoia e definirla inline:
108+
109+
``` js
110+
const vm = new Vue({
111+
vuex: {
112+
getters: { ... },
113+
actions: {
114+
plus: ({ dispatch }) => dispatch('INCREMENT')
115+
}
116+
}
117+
})
118+
```
119+
120+
### Legare tutte le Action
121+
122+
Possiamo vincolare un componente ad avere tutte le action senza specificarne nessuna:
123+
124+
``` js
125+
import * as actions from './actions'
126+
127+
const vm = new Vue({
128+
vuex: {
129+
getters: { ... },
130+
actions // il componente ora accede a tutte le action
131+
}
132+
})
133+
```

docs/it/api.md

Lines changed: 94 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,94 @@
1+
# Referenza alle API
2+
3+
### Vuex.Store
4+
5+
``` js
6+
import Vuex from 'vuex'
7+
8+
const store = new Vuex.Store({ ...opzioni })
9+
```
10+
11+
### Opzioni per il Costruttore
12+
13+
- **state**
14+
15+
- tipo: `Oggetto`
16+
17+
Lo stato principale per lo store di Vuex.
18+
19+
[Dettagli](state.md)
20+
21+
- **mutations**
22+
23+
- tipo: `Oggetto`
24+
25+
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.
26+
27+
[Dettagli](mutations.md)
28+
29+
- **modules**
30+
31+
- tipo: `Oggetto`
32+
33+
Un Oggetto contenente tutti i sub moduli che si uniranno allo store, di solito è formato tipo:
34+
35+
``` js
36+
{
37+
key: {
38+
state,
39+
mutations
40+
},
41+
...
42+
}
43+
```
44+
45+
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).
46+
47+
- **middlewares**
48+
49+
- tipo: `Array<Oggetto>`
50+
51+
Un oggetto che contiene tutti i middleware del tipo:
52+
53+
``` js
54+
{
55+
snapshot: Boolean, // predefinito: false
56+
onInit: Funzione,
57+
onMutation: Funzione
58+
}
59+
```
60+
61+
Tutti i campi sono facoltativi. [Dettagli](middlewares.md)
62+
63+
- **strict**
64+
65+
- tipo: `Boolean`
66+
- predefinito: `false`
67+
68+
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.
69+
70+
[Dettagli](strict.md)
71+
72+
### Proprietà di istanza di Vuex.Store
73+
74+
- **state**
75+
76+
- tipo: `Oggetto`
77+
78+
Lo stato principale. In sola lettura.
79+
80+
### Metodi di istanza di Vuex.Store
81+
82+
- **dispatch(nomeMutazione: Stringa, ...argomenti)**
83+
84+
Directly dispatch a mutation. This is useful in certain situations are in general you should prefer using actions in application code.
85+
86+
- **watch(pathOrGetter: Stringa|Funzione, cb: Funzione, [opzioni: Oggetto])**
87+
88+
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.
89+
90+
To stop watching, call the returned handle Funzione.
91+
92+
- **hotUpdate(opzioni: Oggetto)**
93+
94+
Hot swap new actions and mutations. [Dettagli](hot-reload.md)

docs/it/book.json

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
../book.json

docs/it/data-flow.md

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
# Flusso dei Dati
2+
3+
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.
4+
5+
### Lo Store
6+
7+
``` js
8+
// store.js
9+
import Vue from 'vue'
10+
import Vuex from 'vuex'
11+
12+
Vue.use(Vuex)
13+
14+
// Stato iniziale della nostra applicazione
15+
const state = {
16+
count: 0
17+
}
18+
19+
// Definiamo tutte le mutazioni
20+
const mutations = {
21+
INCREMENT (state) {
22+
state.count++
23+
},
24+
DECREMENT (state) {
25+
state.count--
26+
}
27+
}
28+
29+
// creiamo lo store
30+
export default new Vuex.Store({
31+
state,
32+
mutations
33+
})
34+
```
35+
36+
### Action
37+
38+
``` js
39+
// actions.js
40+
export const increment = ({ dispatch }) => dispatch('INCREMENT')
41+
export const decrement = ({ dispatch }) => dispatch('DECREMENT')
42+
```
43+
44+
### Utilizziamo Vue
45+
46+
**Il Template**
47+
48+
``` html
49+
<div id="app">
50+
Hai Cliccato: {{ count }} volte
51+
<button v-on:click="increment">+</button>
52+
<button v-on:click="decrement">-</button>
53+
</div>
54+
```
55+
56+
**Lo Script**
57+
58+
``` js
59+
// Stiamo importanto ed iniettando lo store perchè questo è il componente di root
60+
// In un'applicazione grossa questo procedimento viene fatto una sola volta
61+
import store from './store'
62+
import { increment, decrement } from './actions'
63+
64+
const app = new Vue({
65+
el: '#app',
66+
store,
67+
vuex: {
68+
getters: {
69+
count: state => state.count
70+
},
71+
actions: {
72+
increment,
73+
decrement
74+
}
75+
}
76+
})
77+
```
78+
79+
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.
80+
81+
Noterete anche che il flusso dei dati è unidirezionale, come dovrebbe esserlo in Flux:
82+
83+
1. L'utente sfrutta un componente per eseguire delle action;
84+
2. Le action avvitano le mutazioni che cambiano lo stato;
85+
3. Una volta che lo stato cambia una proprietà dello store, tale cambiamento viene riflesso ai componenti tramite i getter.
86+
87+
<p align="center">
88+
<img width="700px" src="vuex.png">
89+
</p>

docs/it/forms.md

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
# Gestione dei Form
2+
3+
Quando si utilizza Vuex in modalità strict, può risultare difficile utilizzare `v-model` su uno stato che appartiene a Vuex:
4+
5+
``` html
6+
<input v-model="obj.message">
7+
```
8+
9+
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.
10+
11+
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`:
12+
13+
``` html
14+
<input :value="message" @input="updateMessage">
15+
```
16+
``` js
17+
// ...
18+
vuex: {
19+
getters: {
20+
message: state => state.obj.message
21+
},
22+
actions: {
23+
updateMessage: ({ dispatch }, e) => {
24+
dispatch('UPDATE_MESSAGE', e.target.value)
25+
}
26+
}
27+
}
28+
```
29+
30+
E ora scriviamo la mutation:
31+
32+
``` js
33+
// ...
34+
mutations: {
35+
UPDATE_MESSAGE (state, message) {
36+
state.obj.message = message
37+
}
38+
}
39+
```
40+
41+
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.

0 commit comments

Comments
 (0)