You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The only way to actually change state in a Vuex store is by committing a mutation. Vuex mutations are very similar to events: each mutation has a string**type**and a **handler**. The handler function is where we perform actual state modifications, and it will receive the state as the first argument:
3
+
La seule façon de vraiment modifier l'état dans un store Vuex est d'acter une mutation. Les mutations Vuex sont très similaires aux évènements : chaque mutation a un**type**sous forme de chaîne de caractères et un **gestionnaire**. La fonction de gestion est en charge de procéder aux véritables modifications de l'état, et elle reçoit l'état en premier argument:
4
4
5
5
```js
6
6
conststore=newVuex.Store({
@@ -9,22 +9,22 @@ const store = new Vuex.Store({
9
9
},
10
10
mutations: {
11
11
increment (state) {
12
-
//mutate state
12
+
//muter l'état
13
13
state.count++
14
14
}
15
15
}
16
16
})
17
17
```
18
18
19
-
You cannot directly call a mutation handler. The options here is more like event registration: "When a mutation with type `increment`is triggered, call this handler." To invoke a mutation handler, you need to call **store.commit** with its type:
19
+
Vous ne pouvez pas appeler directement un gestionnaire de mutation. Le parti-pris ici est proche de l'abonnement à un évènement : « Lorsqu'une mutation du type `increment`est déclenchée, appelle ce gestionnaire. » Pour invoquer un gestionnaire de mutation, il faut appeler `store.commit` avec son type:
20
20
21
21
```js
22
22
store.commit('increment')
23
23
```
24
24
25
-
### Commit with Payload
25
+
### Acter avec un argument additionnel
26
26
27
-
You can pass an additional argument to `store.commit`, which is called the **payload** for the mutation:
27
+
Vous pouvez donner un argument additionnel (« payload ») à la fonction `store.commit` lors de la mutation:
28
28
29
29
```js
30
30
// ...
@@ -38,7 +38,7 @@ mutations: {
38
38
store.commit('increment', 10)
39
39
```
40
40
41
-
In most cases, the payload should be an object so that it can contain multiple fields, and the recorded mutation will also be more descriptive:
41
+
Dans la plupart des cas, l'argument additionnel devrait être un objet, ainsi il peut contenir plusieurs champs, et les mutations enregistrées seront également plus descriptives :
42
42
43
43
```js
44
44
// ...
@@ -54,9 +54,9 @@ store.commit('increment', {
54
54
})
55
55
```
56
56
57
-
### Object-Style Commit
57
+
### Acter avec un objet
58
58
59
-
An alternative way to commit a mutation is by directly using an object that has a`type`property:
59
+
Une méthode alternative pour acter une mutation est d'utiliser directement un objet qui a une propriété`type` :
60
60
61
61
```js
62
62
store.commit({
@@ -65,7 +65,7 @@ store.commit({
65
65
})
66
66
```
67
67
68
-
When using object-style commit, the entire object will be passed as the payload to mutation handlers, so the handler remains the same:
68
+
Lors de l'utilisation d'un objet pour acter, c'est l'objet lui-même qui ferra office d'argument pour aux gestionnaires de mutation, le gestionnaire reste donc inchangé :
69
69
70
70
```js
71
71
mutations: {
@@ -75,25 +75,25 @@ mutations: {
75
75
}
76
76
```
77
77
78
-
### Mutations Follow Vue's Reactivity Rules
78
+
### Les mutations suivent les règles de réactivité de Vue
79
79
80
-
Since a Vuex store's state is made reactive by Vue, when we mutate the state, Vue components observing the state will update automatically. This also means Vuex mutations are subject to the same reactivity caveats when working with plain Vue:
80
+
Puisqu'un état de store de Vuex est rendu réactif par Vue, lorsque nous mutons l'état, les composants Vue observant cet état seront automatiquement mis à jour. Cela signifie également que les mutations Vuex sont sujettes aux mêmes limitations qu'avec l'utilisation de Vue seul :
81
81
82
-
1.Prefer initializing your store's initial state with all desired fields upfront.
82
+
1.Initialisez de préférence le store initial de votre état avec tous les champs désirés auparavant.
83
83
84
-
2.When adding new properties to an Object, you should either:
84
+
2.Lorsque vous ajoutez de nouvelles propriétés à un objet, vous devriez soit :
85
85
86
-
-Use`Vue.set(obj, 'newProp', 123)`, or -
86
+
-Utiliser`Vue.set(obj, 'newProp', 123)`, ou
87
87
88
-
-Replace that Object with a fresh one. For example, using the stage-3 [object spread syntax](https://github.com/sebmarkbage/ecmascript-rest-spread) we can write it like this:
88
+
-Remplacer cet objet par un nouvel objet. Par exemple, en utilisant [opérateur de décomposition](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Op%C3%A9rateurs/Op%C3%A9rateur_de_d%C3%A9composition) (stage-2), il est possible d'écrire :
89
89
90
90
```js
91
91
state.obj= { ...state.obj, newProp:123 }
92
92
```
93
93
94
-
### Using Constants for Mutation Types
94
+
### Utilisation de constante pour les noms de mutation
95
95
96
-
It is a commonly seen pattern to use constants for mutation types in various Flux implementations. This allows the code to take advantage of tooling like linters, and putting all constants in a single file allows your collaborators to get an at-a-glance view of what mutations are possible in the entire application:
96
+
C'est une façon de faire régulière que d'utiliser des constantes pour les types de mutations dans diverses implémentations de Flux. Cela permet au code de bénéficier d'outils comme les linters (des outils d'aide à l'analyse syntaxique), et écrire toutes ces constantes dans un seul fichier permet à vos collaborateurs d'avoir un aperçu de quelles mutations sont possibles dans toute l'application:
97
97
98
98
``` js
99
99
// mutation-types.js
@@ -108,20 +108,20 @@ import { SOME_MUTATION } from './mutation-types'
108
108
const store = new Vuex.Store({
109
109
state: { ... },
110
110
mutations: {
111
-
// we can use the ES2015 computed property name feature
112
-
// to use a constant as the function name
111
+
// nous pouvons utiliser la fonctionnalité de nom de propriété calculée
112
+
// pour utiliser une constante en tant que nom de fonction
113
113
[SOME_MUTATION] (state) {
114
-
// mutate state
114
+
// muter l'état
115
115
}
116
116
}
117
117
})
118
118
```
119
119
120
-
Whether to use constants is largely a preference - it can be helpful in large projects with many developers, but it's totally optional if you don't like them.
120
+
Utiliser les constantes ou non relève de la préférence personnelle. Cela peut être bénéfique sur un gros projet avec beaucoup de développeurs, mais c'est totalement optionnel si vous n'aimez pas cette pratique.
121
121
122
-
### Mutations Must Be Synchronous
122
+
### Les mutations doivent être synchrones
123
123
124
-
One important rule to remember is that**mutation handler functions must be synchronous**. Why? Consider the following example:
124
+
Une règle importante à retenir est que**les fonctions de gestion des mutations doivent être synchrones**. Pourquoi ? Considérons l'exemple suivant :
125
125
126
126
```js
127
127
mutations: {
@@ -133,11 +133,11 @@ mutations: {
133
133
}
134
134
```
135
135
136
-
Now imagine we are debugging the app and looking at the devtool's mutation logs. For every mutation logged, the devtool will need to capture a "before" and "after" snapshots of the state. However, the asynchronous callback inside the example mutation above makes that impossible: the callback is not called yet when the mutation is committed, and there's no way for the devtool to know when the callback will actually be called - any state mutation performed in the callback is essentially un-trackable!
136
+
Maintenant imaginons que nous deboguons l'application et que nous regardons dans les logs de mutation des outils de développement (« devtools »). Pour chaque mutation enregistrée, le devtool aura besoin de capturer un instantané de l'état « avant » et un instantané « après ». Cependant, la fonction de rappel asynchrone de l'exemple ci-dessus rend l'opération impossible : la fonction de rappel n'est pas encore appelée lorsque la mutation est actée, et il n'y a aucun moyen pour le devtool de savoir quand la fonction de rappel sera véritablement appelée. Toute mutation d'état effectuée dans la fonction de rappel est essentiellement intraçable !
137
137
138
-
### Committing Mutations in Components
138
+
### Acter des mutations dans les composants
139
139
140
-
You can commit mutations in components with`this.$store.commit('xxx')`, or use the `mapMutations`helper which maps component methods to `store.commit`calls (requires root `store`injection):
140
+
Vous pouvez acter des mutations dans les composants avec `this.$store.commit('xxx')`, ou en utilisant la fonction utilitaire `mapMutations`qui attache les méthodes du composant aux appels de `store.commit`(nécessite l'injection de `store`à la racine) :
141
141
142
142
```js
143
143
import { mapMutations } from'vuex'
@@ -146,26 +146,26 @@ export default {
146
146
// ...
147
147
methods: {
148
148
...mapMutations([
149
-
'increment', // map this.increment() to this.$store.commit('increment')
150
-
151
-
// mapMutations also supports payloads:
152
-
'incrementBy' // this.incrementBy(amount) maps to this.$store.commit('incrementBy', amount)
149
+
'increment'//attacher `this.increment()` à `this.$store.commit('increment')`
150
+
151
+
//`mapMutations` supporte également les paramètres additionnels :
152
+
'incrementBy'//attacher `this.incrementBy(amount)` à `this.$store.commit('incrementBy', amount)`
153
153
]),
154
154
...mapMutations({
155
-
add: 'increment' // map this.add() to this.$store.commit('increment')
155
+
add:'increment'//attacher `this.add()` à `this.$store.commit('increment')`
156
156
})
157
157
}
158
158
}
159
159
```
160
160
161
-
### On to Actions
161
+
### En avant vers les actions
162
162
163
-
Asynchronicity combined with state mutation can make your program very hard to reason about. For example, when you call two methods both withasync callbacks that mutate the state, how do you know when they are called and which callback was called first? This is exactly why we want to separate the two concepts. In Vuex, **mutations are synchronous transactions**:
163
+
L'asynchronisme combiné à la mutation de l'état peut rendre votre programme très difficile à comprendre. Par exemple, lorsque vous appelez deux méthodes avec toutes les deux des foncitons de rappel asynchrones qui changent l'état, comment savez-vous quelle fonction de rappel est appelée en première ? C'est exactement la raison pour laquelle nous voulons séparer les deux concepts. Avec Vuex, **les mutations sont des transactions synchrones**:
164
164
165
165
```js
166
166
store.commit('increment')
167
-
// any state change that the "increment" mutation may cause
168
-
// should be done at this moment.
167
+
//n'importe quel changement d'état de « increment » par mutation
168
+
//devrait être faite de manière synchrone.
169
169
```
170
170
171
-
To handle asynchronous operations, let's introduce [Actions](actions.md).
171
+
Pour gérer les opérations asynchrones, tournons-nous vers les[Actions](actions.md).
0 commit comments