Skip to content

Pourquoi utiliser NgRX dans son projet ?

Bien que vous puissiez créer votre propre système de gestion d'état en utilisant uniquement RxJS, il y a plusieurs raisons pour lesquelles vous pourriez envisager d'utiliser NgRx à la place :

  1. Architecture éprouvée: NgRx suit l'architecture de Redux, qui est largement reconnue et adoptée dans l'industrie pour la gestion d'état. Cette architecture est composée de store, actions et reducers.

  2. Maturité et communauté: NgRx possède une grande communauté d'utilisateurs et une vaste documentation. Avoir une communauté solide signifie qu'il est plus facile de trouver des ressources, des exemples et du support pour résoudre les problèmes.

  3. Effets et side effects: NgRx offre un mécanisme (Effects) pour gérer les effets secondaires de manière propre, ce qui peut être plus complexe avec un système fait maison.

  4. DevTools: Les outils de développement pour NgRx (tels que Redux DevTools) permettent de suivre l'évolution de l'état de l'application, de revenir en arrière et de rejouer des actions, ce qui est très utile pour le débogage.

  5. Sélecteurs optimisés: Avec NgRx, vous pouvez utiliser des sélecteurs pour extraire des données du store. Ces sélecteurs peuvent être memoïsés pour améliorer les performances, surtout dans de grandes applications.

  6. Garantie de prévisibilité: Avec le modèle unidirectionnel de flux de données de NgRx, vous pouvez être sûr que l'état change de manière prévisible.

  7. Scalabilité: Conçu pour des applications de grande envergure, NgRx est efficace pour gérer de grands états et de nombreux effets secondaires.

  8. Intégration avec Angular: NgRx est conçu spécifiquement pour Angular, ce qui signifie qu'il s'intègre bien avec le framework et tire parti de ses fonctionnalités, comme la détection de changement.

  9. Testabilité: NgRx est conçu pour être facilement testable. Les réducteurs sont des fonctions pures, et les effets peuvent être testés séparément.

  10. Mise à jour et maintenance: Utiliser une bibliothèque populaire et activement maintenue comme NgRx assure une meilleure compatibilité avec les futures versions d'Angular et les nouvelles fonctionnalités ou corrections de bugs.

Immutabilité

L'un des concepts fondamentaux de NGRX est l'immutabilité, ce qui signifie que l'état ne doit jamais être modifié directement. Au lieu de cela, lorsqu'une action est exécutée, le réducteur crée une nouvelle copie de l'état avec les changements nécessaires. Cela permet de s'assurer que l'état reste prévisible et qu'il peut être facilement testé et débogué.

Les problématiques de le l'approche mutable

Bien sûr! L'approche mutable, bien que parfois plus directe ou intuitive, peut entraîner de nombreux problèmes. Voici un exemple illustratif pour montrer une problématique courante avec la mutabilité.

Scénario : Suivi des modifications d'un tableau d'utilisateurs

Supposons que vous ayez une fonction qui prend un tableau d'utilisateurs et effectue une action sur ce tableau. Vous voulez également garder une trace du tableau original pour comparer avant et après les modifications.

javascript
let originalUsers = [
    { id: 1, name: "Alice" },
    { id: 2, name: "Bob" },
    { id: 3, name: "Charlie" }
];

let modifiedUsers = originalUsers;

function renameUser(userId, newName) {
    for (let user of modifiedUsers) {
        if (user.id === userId) {
            user.name = newName;
        }
    }
}

renameUser(2, "Robert");

console.log(originalUsers[1].name); // "Robert"
console.log(modifiedUsers[1].name); // "Robert"
let originalUsers = [
    { id: 1, name: "Alice" },
    { id: 2, name: "Bob" },
    { id: 3, name: "Charlie" }
];

let modifiedUsers = originalUsers;

function renameUser(userId, newName) {
    for (let user of modifiedUsers) {
        if (user.id === userId) {
            user.name = newName;
        }
    }
}

renameUser(2, "Robert");

console.log(originalUsers[1].name); // "Robert"
console.log(modifiedUsers[1].name); // "Robert"

Problématique

Même si nous n'avons appelé la fonction renameUser que sur modifiedUsers, le tableau originalUsers a également été modifié. C'est parce que originalUsers et modifiedUsers font référence au même objet en mémoire. Lorsque nous modifions l'un, l'autre est aussi affecté.

Dans des scénarios complexes, cela peut entraîner de graves problèmes :

  1. Difficulté de débogage : Les bugs causés par des mutations inattendues peuvent être difficiles à localiser et à résoudre.
  2. États incohérents: Si différents composants ou parties de votre application se basent sur l'ancien état (dans cet exemple, originalUsers), ils recevront des données inattendues, causant une incohérence.
  3. Répercussions sur d'autres fonctionnalités: Dans les applications complexes, une mutation inattendue peut avoir des conséquences en cascade, affectant d'autres fonctionnalités ou logiques.
  4. Tests difficiles: Les tests automatisés peuvent échouer de manière inattendue ou, pire encore, passer alors qu'ils ne devraient pas, en raison de mutations accidentelles.

Dans le cadre d'une bibliothèque comme NgRx, où la prévisibilité est essentielle, les mutations peuvent être particulièrement problématiques. En suivant une approche immuable, vous garantissez que l'état précédent est conservé intact, rendant le comportement de votre application beaucoup plus prévisible.