Créez une application web avec Vue.js

Lorsque l'on travaille avec des applications monopages (SPA), le concept de state management (gestion d'état) est un sujet couramment abordé.

Et même si ce sujet peut souvent mener à des discussions très complexes, le principal objectif recherché par tous est le suivant :

s'assurer que l'application utilise les bonnes données à tout moment.

Sur cette base, nous pouvons définir le state (ou état, en français) comme un instantané du data store à un moment donné. De multiples states sont utilisés à travers une application, ce qui explique la complexité inhérente à la gestion de ces éléments. Après tout, chaque composant utilisé contient sa propre propriété  data, ce qui signifie qu'il gère son propre state. Une fois que l'on ajoute la complexité du passage de données entre composants, cela devient effectivement très compliqué.

Pour illustrer cela, combien y a-t-il d'instances de state représentées dans l'exemple suivant ?

src/components/GroceryList.vue

<template>
    <div>
        <h1>{{ pageTitle }}</h1>
        <ul>
            <ListItem
                v-for="item in list"
                :key="item"
                :item="item"
            />
        </ul>
    </div>
</template>

<script>
import ListItem from './components/ListItem.vue'

export default {
    name: 'GroceryList',
    components: {
        ListItem
    },
    data() {
        return {
            list: ['pommes', 'bananes', 'cerises'],
            pageTitle: 'Ma liste de courses'
        }
    }
}
</script>j

À première vue, il semblerait qu'il y ait deux instances d'état : le composant parent  <GroceryList>  et le composant enfant   <ListItem>. Pourtant, il s'avère que nous sommes en réalité en présence de 4 instances de state au total :

1. GroceryList.

2. ListItem item="pommes".

3. ListItem item="bananes".

4. ListItem item="cerises".

Pour comprendre cela, imaginez que le composant  <ListItem>   ait été défini comme suit :

 <template>
    <div>
        <input type="checkbox" v-model="isPurchased" />
        <label>{{ item }}</label>
    </div>
</template>

<script>
export default {
    name: 'ListItem',
    props: {
        item: String
    },
    data() {
        return {
            isPurchased: false
        }
    }
}
</script>

Comme vous pouvez l'imaginer, chaque article de  <GroceryList>  doit pouvoir gérer le fait qu'il a été acheté ou non. Si les composants enfants partageaient un state unique, alors le fait de cocher un seul article mettrait automatiquement à jour les autres composants 😱.

Récupérez vos datas à la source unique de vérité

Dans les discussions autour de la gestion du state, et parmi les termes couramment cités, apparaît l'idée d'une « source unique de vérité » (qui est aussi parfois abrégée en « SSoT » pour Single Source of Truth). Le concept fondamental derrière une source unique de vérité est d'éviter la duplication inutile de données dans l'application.

Bien que cela puisse paraître anodin à première vue, le fait de stocker plusieurs copies des mêmes données dans une application est souvent la principale cause de bugs dans un système, car cela permet l'existence de différents jeux des « mêmes » données en même temps. Au lieu de n'avoir à mettre à jour qu'un seul jeu de données, l'application devra gérer plusieurs jeux de données, ce qui est problématique, car :

• du point de vue du code, cela s'avère bien plus difficile à gérer, car il existe une dépendance qu'il est facile d'oublier à mesure que le système se complexifie ;

• des bugs apparaissent en plus grand nombre à la suite de cette fragmentation.

C'est pour cette raison que le concept de source unique de vérité est essentiel au succès de tout système de gestion du state.

Entraînez-vous

Vous trouverez le code source des exercices dans le repo GitHub du cours, dans le dossier   cafe-with-a-view. Pour commencer, consultez la branche  P4C1-Begin.

Instructions

1. Évaluez le state actuel de l'application et déterminez où se trouvent les différentes propriétés des données.

2. Créez un plan ou un document visuel représentant la structure du state de l'application.

En résumé

Dans notre vision du système de gestionnaire de state idéal, ce dernier devrait être capable de :

• créer un espace de stockage de données unique qui servira de source unique de vérité pour toutes les données partagées ;

• permettre à n'importe quel composant de récupérer des données directement ;

• permettre à n'importe quel composant de modifier le data store unique directement.

Par chance, l'écosystème Vue.js dispose d'un système de state management capable de faire cela à notre place : Vuex. Hâte d'en savoir plus ?
Rendez-vous au prochain chapitre ! 🚀