Skip to content

Commit 73c8d0f

Browse files
committed
Starting review for mutations.md
Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>
1 parent fb8f0c4 commit 73c8d0f

File tree

1 file changed

+25
-28
lines changed

1 file changed

+25
-28
lines changed

docs/en/mutations.md

Lines changed: 25 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Mutations
22

3-
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 le state dans un store Vuex est de commiter une mutation. Les mutations Vuex sont très similaires aux events : chaque mutation a un **type** sous forme de chaîne de caractères et un **handler**. La fonction handler est là où nous procédons aux véritables modifications du state, et elle reçoit le state en premier argument :
44

55
``` js
66
const store = new Vuex.Store({
@@ -16,15 +16,15 @@ const store = new Vuex.Store({
1616
})
1717
```
1818

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 handler de mutation. La façon de faire est plutôt comme un abonnement à un event : "Lorsqu'une mutation du type `increment` est déclenchée, appelle ce handler." Pour invoquer un handler de mutation, il faut appeler **store.commit** avec son type :
2020

2121
``` js
2222
store.commit('increment')
2323
```
2424

25-
### Commit with Payload
25+
### commiter avec un Payload
2626

27-
You can pass an additional argument to `store.commit`, which is called the **payload** for the mutation:
27+
Vous pouvez donner un autre argument à **store.commit** pour la mutation, qui s'appelle **payload** :
2828

2929
``` js
3030
// ...
@@ -38,7 +38,7 @@ mutations: {
3838
store.commit('increment', 10)
3939
```
4040

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, le payload devrait être un objet, ainsi il peut contenir plusieurs champs, et les mutations enregistrées seront également plus descriptives :
4242

4343
``` js
4444
// ...
@@ -56,7 +56,7 @@ store.commit('increment', {
5656

5757
### Object-Style Commit
5858

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 commiter une mutation est d'utiliser directement un objet qui a une propriété `type` :
6060

6161
``` js
6262
store.commit({
@@ -65,7 +65,7 @@ store.commit({
6565
})
6666
```
6767

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'utlisation de l'object-style commit, l'objet entier sera fourni comme payload aux handlers de mutation, donc le handler reste inchangé :
6969

7070
``` js
7171
mutations: {
@@ -75,25 +75,25 @@ mutations: {
7575
}
7676
```
7777

78-
### Mutations Follow Vue's Reactivity Rules
78+
### Les mutations suivent les règles de réactivité de Vue
7979

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 state de store de Vuex est rendu réactif par Vue, lorsque nous mutons le state, les composants Vue observant ce state seront automatiquement mis à jour. Cela signifie également que les mutations Vuex sont sujettes aux mêmes inconvénients que lorsqu'on travaille avec Vue :
8181

82-
1. Prefer initializing your store's initial state with all desired fields upfront.
82+
1. Initialisez de préférence le state initial de votre state avec tous les champs désirés auparavant.
8383

84-
2. When adding new properties to an Object, you should either:
84+
2. Lorsque vous ajoutez de nouvelles propriétés à un Object, vous devriez soit :
8585

86-
- Use `Vue.set(obj, 'newProp', 123)`, or -
86+
- Utiliser `Vue.set(obj, 'newProp', 123)`, ou -
8787

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 Object par un nouvel Object. Par exemple, en utilisant [object spread syntax](https://github.com/sebmarkbage/ecmascript-rest-spread) (stage-2), il est possible d'écrire :
8989

9090
``` js
9191
state.obj = { ...state.obj, newProp: 123 }
9292
```
9393

94-
### Using Constants for Mutation Types
94+
### Utilisation de constante pour les noms de mutation
9595

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, 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 :
9797
9898
``` js
9999
// mutation-types.js
@@ -117,11 +117,11 @@ const store = new Vuex.Store({
117117
})
118118
```
119119
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 &mdash; 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.
121121
122-
### Mutations Must Be Synchronous
122+
### Les mutations doivent être synchrones
123123
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 handler de mutations doivent être synchrones**. Pourquoi ? Considérons l'exemple suivant :
125125

126126
``` js
127127
mutations: {
@@ -133,11 +133,11 @@ mutations: {
133133
}
134134
```
135135

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 debuggons l'application et que nous regardons dans les logs de mutation des devtools. Pour chaque mutation enregistrée, le devtool aura besoin de capturer un instantané du state "avant" et un instantané "après". Cependant, le callback asynchrone du l'exemple ci-dessus rend l'opération impossible : le callback n'est pas encore appelé lorsque la mutation est committée, et il n'y a aucun moyen pour le devtool de savoir quand le callback sera véritablement appelé &mdash; toute mutation du state effectuée dans le callack est essentiellement intraçable !
137137
138-
### Committing Mutations in Components
138+
### commiter des mutations dans les composants
139139
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 commiter des mutations dans les composants avec `this.$store.commit('xxx')`, ou en utilisant le helper `mapMutations` qui attache les méthodes du composant aux appels de `store.commit` (nécessite l'injection de `store` à la racine) :
141141

142142
``` js
143143
import { mapMutations } from 'vuex'
@@ -146,10 +146,7 @@ export default {
146146
// ...
147147
methods: {
148148
...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' // map this.increment() to this.$store.commit('increment')
153150
]),
154151
...mapMutations({
155152
add: 'increment' // map this.add() to this.$store.commit('increment')
@@ -158,14 +155,14 @@ export default {
158155
}
159156
```
160157

161-
### On to Actions
158+
### En avant vers les actions
162159

163-
Asynchronicity combined with state mutation can make your program very hard to reason about. For example, when you call two methods both with async 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**:
160+
L'asynchronisme combiné à la mutation du state peut rendre votre programme très difficile à comprendre. Par exemple, lorsque vous appelez deux méthodes avec toutes les deux des callbacks asynchrones qui changent le state, comment savez-vous quand elles sont appelées et quel callback est appelé en premier ? C'est exactement la raison pour laquelle nous voulons séparer les deux concepts. Avec Vuex, **les mutations sont des transactions synchrones** :
164161

165162
``` js
166163
store.commit('increment')
167164
// any state change that the "increment" mutation may cause
168165
// should be done at this moment.
169166
```
170167

171-
To handle asynchronous operations, let's introduce [Actions](actions.md).
168+
Pour gérer les opérations asynchrones, présentons les [Actions](actions.md).

0 commit comments

Comments
 (0)