From cdf8a47535ebe1a29314deeb31ee70e5a1c15048 Mon Sep 17 00:00:00 2001 From: Bruno Lesieur Date: Wed, 28 Jun 2017 14:12:39 +0200 Subject: [PATCH 1/2] Traduction de `state-management.md` Signed-off-by: Bruno Lesieur --- src/v2/guide/state-management.md | 36 ++++++++++++++++---------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/src/v2/guide/state-management.md b/src/v2/guide/state-management.md index 86256fce53..5a554316eb 100644 --- a/src/v2/guide/state-management.md +++ b/src/v2/guide/state-management.md @@ -1,20 +1,20 @@ --- -title: State Management (En) +title: Gestion des états type: guide order: 22 --- -## Official Flux-Like Implementation +## Implémentation officielle à la Flux -

**Cette page est en cours de traduction française. Revenez une autre fois pour lire une traduction achevée ou [participez à la traduction française ici](https://github.com/vuejs-fr/vuejs.org).**

Large applications can often grow in complexity, due to multiple pieces of state scattered across many components and the interactions between them. To solve this problem, Vue offers [vuex](https://github.com/vuejs/vuex): our own Elm-inspired state management library. It even integrates into [vue-devtools](https://github.com/vuejs/vue-devtools), providing zero-setup access to time travel.

+Les grosses applications peuvent souvent augmenter en complexité du fait des multiples parties d'états disséminés à travers divers composants et les interactions entre eux. Pour résoudre ce problème, Vue offre [Vuex](https://github.com/vuejs/vuex) : sa propre bibliothèque de gestion d'état inpiré par Elm. Il est même intégré à [vue-devtools](https://github.com/vuejs/vue-devtools), fournissant une possibilité de voir l'état dans le temps sans aucune configuration préalable. -### Information for React Developers +### Information pour les développeurs React -If you're coming from React, you may be wondering how vuex compares to [redux](https://github.com/reactjs/redux), the most popular Flux implementation in that ecosystem. Redux is actually view-layer agnostic, so it can easily be used with Vue via some [simple bindings](https://github.com/egoist/revue). Vuex is different in that it _knows_ it's in a Vue app. This allows it to better integrate with Vue, offering a more intuitive API and improved development experience. +Si vous venez de React, vous vous demanderez probablement quels sont les points de comparaisons entre Vuex et [Redux](https://github.com/reactjs/redux) (l'implémentation de Flux la plus populaire dans cet écosystème). Redux est actuellement une couche de vue agnostique, il peut donc être facilement utilisé avec Vue à l'aide de plusieurs [liaisons simples](https://github.com/egoist/revue). Vuex est différent dans le sens où il _sait_ ce qu'il y a dans une application Vue. Cela lui permet d'être mieux intégré à Vue, offrant une API plus intuitive et une meilleure expérience de développement. -## Simple State Management from Scratch +## Gestion d'état simple à partir de rien -It is often overlooked that the source of truth in Vue applications is the raw `data` object - a Vue instance simply proxies access to it. Therefore, if you have a piece of state that should be shared by multiple instances, you can simply share it by identity: +Nous n'avons pas assez insisté sur le fait que, dans des applications Vue, c'est l'objet `data` qui fait office de « source de vérité ». Une instance de Vue ne fait que proxifier l'accès à cet objet. Par conséquent, si vous avez une partie d'état qui doit être partagée par plusieurs instances, vous pouvez simplement la partager par référence : ``` js const sourceOfTruth = {} @@ -28,30 +28,30 @@ const vmB = new Vue({ }) ``` -Now whenever `sourceOfTruth` is mutated, both `vmA` and `vmB` will update their views automatically. Subcomponents within each of these instances would also have access via `this.$root.$data`. We have a single source of truth now, but debugging would be a nightmare. Any piece of data could be changed by any part of our app at any time, without leaving a trace. +Maintenant, quelque soit la manière dont `sourceOfTruth` sera mutée, les instances vmA` et `vmB` mettrons à jour leurs vues automatiquement. Les sous-composants à l'intérieur de chacune de ces instances y auront aussi accès via la propriété `this.$root.$data`. Maintenant, nous avons une unique source de vérité, mais le débogue pourrait être un vrai cauchemar. N'importe quel fragment de donnée pourrait être changé par n'importe quelle partie de notre application, à n'importe quel moment, et sans laisser de trace. -To help solve this problem, we can adopt a simple **store pattern**: +Pour nous aider à résoudre ce problème, nous allons adopter un simple **modèle de stockage (« store »)** : ``` js var store = { debug: true, state: { - message: 'Hello!' + message: 'Bonjour !' }, setMessageAction (newValue) { - if (this.debug) console.log('setMessageAction triggered with', newValue) + if (this.debug) console.log('setMessageAction déclenchée avec', newValue) this.state.message = newValue }, clearMessageAction () { - if (this.debug) console.log('clearMessageAction triggered') + if (this.debug) console.log('clearMessageAction déclenchée') this.state.message = '' } } ``` -Notice all actions that mutate the store's state are put inside the store itself. This type of centralized state management makes it easier to understand what type of mutations could happen and how are they triggered. Now when something goes wrong, we'll also have a log of what happened leading up to the bug. +Notez que toutes les actions qui changent l'état du store sont mises à l'intérieur du store lui-même. Ce type de gestion d'état centralisé permet de comprendre plus facilement quelles types de mutations sont faites et comment elles sont déclenchées. Maintenant, quand quelque chose se passera mal, nous auront des logs sur ce qui a conduit à ce bogue. -In addition, each instance/component can still own and manage its own private state: +De plus, chaque instance/composant peut gérer lui-même sont propre état privé : ``` js var vmA = new Vue({ @@ -69,10 +69,10 @@ var vmB = new Vue({ }) ``` -![State Management](/images/state.png) +![Gestion des états](/images/state.png) -

It's important to note that you should never replace the original state object in your actions - the components and the store need to share reference to the same object in order for mutations to be observed.

+

Il est important de noter que vous ne devriez jamais remplacer l'objet d'état original dans vos actions. Les composants et le store ont besoin de partager une référence sur le même objet pour que les mutations puissent être observées.

-As we continue developing the convention where components are never allowed to directly mutate state that belongs to a store, but should instead dispatch events that notify the store to perform actions, we eventually arrive at the [Flux](https://facebook.github.io/flux/) architecture. The benefit of this convention is we can record all state mutations happening to the store and implement advanced debugging helpers such as mutation logs, snapshots, and history re-rolls / time travel. +En élargissant notre convention au fait qu'il ne serait jamais permis à un composant de directement muter un état qui appartient au store, mais que l'on devrait à la place propager des évènements pour notifier le store qu'une action a été entreprise ; nous arriverions éventuellement à une architecture [Flux](https://facebook.github.io/flux/). Le bénéfice de cette convention est que nous pouvons enregistrer toutes les mutations de l'état qui apparaissent dans le store et implémenter des fonctions utilitaires avancées de débogage comme des logs de mutations, des instantanés, des rejouabilités d'historique ou de l'observation dans le temps. -This brings us full circle back to [vuex](https://github.com/vuejs/vuex), so if you've read this far it's probably time to try it out! +Nous avons fait le tour de la présentation de [Vuex](https://github.com/vuejs/vuex), aussi si vous êtes arrivé jusqu'ici, il est probablement temps de l'essayer ! From 7ef86cedf538bffb6928b25f33b462788507f3a9 Mon Sep 17 00:00:00 2001 From: Bruno Lesieur Date: Thu, 6 Jul 2017 10:39:19 +0200 Subject: [PATCH 2/2] Revu de Sylvain Signed-off-by: Bruno Lesieur --- src/v2/guide/state-management.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/v2/guide/state-management.md b/src/v2/guide/state-management.md index 5a554316eb..e4cb8ea2a7 100644 --- a/src/v2/guide/state-management.md +++ b/src/v2/guide/state-management.md @@ -1,20 +1,20 @@ --- -title: Gestion des états +title: Gestion de l'état type: guide order: 22 --- -## Implémentation officielle à la Flux +## Implémentation officielle semblable à Flux -Les grosses applications peuvent souvent augmenter en complexité du fait des multiples parties d'états disséminés à travers divers composants et les interactions entre eux. Pour résoudre ce problème, Vue offre [Vuex](https://github.com/vuejs/vuex) : sa propre bibliothèque de gestion d'état inpiré par Elm. Il est même intégré à [vue-devtools](https://github.com/vuejs/vue-devtools), fournissant une possibilité de voir l'état dans le temps sans aucune configuration préalable. +Les grosses applications peuvent souvent augmenter en complexité du fait des multiples parties d'état disséminées à travers divers composants et les interactions entre eux. Pour résoudre ce problème, Vue offre [vuex](https://github.com/vuejs/vuex) : notre propre bibliothèque de gestion d'état inpiré par Elm. Il est même intégré à [vue-devtools](https://github.com/vuejs/vue-devtools), permettant le voyage dans le temps sans aucune configuration préalable. ### Information pour les développeurs React -Si vous venez de React, vous vous demanderez probablement quels sont les points de comparaisons entre Vuex et [Redux](https://github.com/reactjs/redux) (l'implémentation de Flux la plus populaire dans cet écosystème). Redux est actuellement une couche de vue agnostique, il peut donc être facilement utilisé avec Vue à l'aide de plusieurs [liaisons simples](https://github.com/egoist/revue). Vuex est différent dans le sens où il _sait_ ce qu'il y a dans une application Vue. Cela lui permet d'être mieux intégré à Vue, offrant une API plus intuitive et une meilleure expérience de développement. +Si vous venez de React, vous pouvez vous demander comment Vuex se compare à [Redux](https://github.com/reactjs/redux) (l'implémentation de Flux la plus populaire dans cet écosystème). Redux est en fait agnostique de la couche vue, et peut donc être facilement utilisé avec Vue à l'aide de plusieurs [liaisons simples](https://github.com/egoist/revue). Vuex est différent dans le sens où il _sait_ qu'il est dans une application Vue. Cela lui permet de mieux s'intégrer avec Vue, offrant une API plus intuitive et une meilleure expérience de développement. ## Gestion d'état simple à partir de rien -Nous n'avons pas assez insisté sur le fait que, dans des applications Vue, c'est l'objet `data` qui fait office de « source de vérité ». Une instance de Vue ne fait que proxifier l'accès à cet objet. Par conséquent, si vous avez une partie d'état qui doit être partagée par plusieurs instances, vous pouvez simplement la partager par référence : +On n'insiste souvent pas assez sur le fait que, dans des applications Vue, c'est l'objet `data` qui fait office de « source de vérité ». Une instance de Vue ne fait que proxifier l'accès à cet objet. Par conséquent, si vous avez une partie d'état qui doit être partagée par plusieurs instances, vous pouvez simplement la partager par référence : ``` js const sourceOfTruth = {} @@ -28,9 +28,9 @@ const vmB = new Vue({ }) ``` -Maintenant, quelque soit la manière dont `sourceOfTruth` sera mutée, les instances vmA` et `vmB` mettrons à jour leurs vues automatiquement. Les sous-composants à l'intérieur de chacune de ces instances y auront aussi accès via la propriété `this.$root.$data`. Maintenant, nous avons une unique source de vérité, mais le débogue pourrait être un vrai cauchemar. N'importe quel fragment de donnée pourrait être changé par n'importe quelle partie de notre application, à n'importe quel moment, et sans laisser de trace. +Maintenant, quelle que soit la manière dont `sourceOfTruth` sera mutée, les instances `vmA` et `vmB` mettront à jour leurs vues automatiquement. Les sous-composants à l'intérieur de chacune de ces instances y auront aussi accès via la propriété `this.$root.$data`. Maintenant, nous avons une unique source de vérité, mais le débogage serait un cauchemar. N'importe quel fragment de donnée pourrait être changé par n'importe quelle partie de notre application, à n'importe quel moment, et sans laisser de trace. -Pour nous aider à résoudre ce problème, nous allons adopter un simple **modèle de stockage (« store »)** : +Pour nous aider à résoudre ce problème, nous pouvons adopter un simple **modèle de stockage (« store »)** : ``` js var store = { @@ -49,9 +49,9 @@ var store = { } ``` -Notez que toutes les actions qui changent l'état du store sont mises à l'intérieur du store lui-même. Ce type de gestion d'état centralisé permet de comprendre plus facilement quelles types de mutations sont faites et comment elles sont déclenchées. Maintenant, quand quelque chose se passera mal, nous auront des logs sur ce qui a conduit à ce bogue. +Notez que toutes les actions qui changent l'état du store sont mises à l'intérieur du store lui-même. Ce type de gestion d'état centralisé permet de comprendre plus facilement quel type de mutations peuvent survenir et comment elles sont déclenchées. Maintenant, quand quelque-chose tourne mal, nous auront également un log sur ce qui a conduit à ce bogue. -De plus, chaque instance/composant peut gérer lui-même sont propre état privé : +De plus, chaque instance/composant peut gérer lui-même son propre état privé : ``` js var vmA = new Vue({ @@ -69,10 +69,10 @@ var vmB = new Vue({ }) ``` -![Gestion des états](/images/state.png) +![Gestion de l'état](/images/state.png) -

Il est important de noter que vous ne devriez jamais remplacer l'objet d'état original dans vos actions. Les composants et le store ont besoin de partager une référence sur le même objet pour que les mutations puissent être observées.

+

Il est important de noter que vous ne devriez jamais remplacer l'objet d'état original dans vos actions. Les composants et le store ont besoin de partager une référence au même objet pour que les mutations puissent être observées.

-En élargissant notre convention au fait qu'il ne serait jamais permis à un composant de directement muter un état qui appartient au store, mais que l'on devrait à la place propager des évènements pour notifier le store qu'une action a été entreprise ; nous arriverions éventuellement à une architecture [Flux](https://facebook.github.io/flux/). Le bénéfice de cette convention est que nous pouvons enregistrer toutes les mutations de l'état qui apparaissent dans le store et implémenter des fonctions utilitaires avancées de débogage comme des logs de mutations, des instantanés, des rejouabilités d'historique ou de l'observation dans le temps. +Alors que nous continuons à développer la convention selon laquelle il n'est jamais permis à un composant de directement muter un état qui appartient au store, mais devrait à la place propager des évènements pour notifier le store qu'une action a été entreprise ; nous arriverons éventuellement à une architecture [Flux](https://facebook.github.io/flux/). Le bénéfice de cette convention est que nous pouvons enregistrer toutes les mutations d'état survenant sur le store et implémenter des fonctions utilitaires avancées de débogage telles que des logs de mutations, des clichés instantanés, et du voyage dans le temps sur l'historique des actions. -Nous avons fait le tour de la présentation de [Vuex](https://github.com/vuejs/vuex), aussi si vous êtes arrivé jusqu'ici, il est probablement temps de l'essayer ! +Nous avons fait le tour de la présentation de [vuex](https://github.com/vuejs/vuex), aussi si vous êtes arrivé jusqu'ici, il est probablement temps de l'essayer !