Rafraîchir vos connaissances en Front-End

Sadok Mhiri — Tue, 01 Feb 2022 15:28:07 +0000

Je crée cet article afin de partager avec vous des connaissances que je les voit nécessaires pour un développeur front-end. En tant que développeur front-end j’ai commencé depuis quelques années mon parcours d'apprentissage ainsi le développement des projets clients au fur et à mesure. Durant toute ces années j’ai suivi des cours en lignes, des tutoriels, les documentations des différentes technologies avec lesquelles j’avais travaillé et je me trouve toujours avec un manque d’informations. Je partage avec vous quelques sources d’apprentissage dans lesquelles j’ai de la confiance et je vous garantie que vous n’allez jamais perdre votre temps en les suivant. Frontendmasters, Freecodecamp, Pluralsight, Udemy.

JavaScript

En tant que développeur web il est indispensable de connaître les bases du JavaScript ainsi que comprendre comment le JS Engine fonctionne derrière les coulisses:

En JavaScript tout se passe dans un contexte d'exécution. Vous pouvez supposer que ce contexte d'exécution est un gros conteneur, invoqué lorsque le JS engine commence à exécuter du code JavaScript.

Dans ce conteneur, il y a principalement deux composants :

Composant mémoire : Variable environment
Composant du code : Execution thread

JavaScript est un langage synchrone à thread unique. C'est parce qu'il ne peut exécuter qu'une commande à la fois et dans un ordre spécifique.

Le moteur ( JS Engine) exécutera le code JavaScript en deux phases

Phase de création de mémoire
Phase d'exécution du code

Dans la phase de création de mémoire, JavaScript parcourra tout le code et allouera de la mémoire à toutes les variables et fonctions du code. Pour les variables, JavaScript stockera undefined dans la phase de création de la mémoire (uniquement avec les variables déclarées par le mot-clé VAR), et pour les fonctions, il conservera l'intégralité du code de la fonction. ( Ce mécanisme est reconnu par le terme Hoisting )

Lorsque JavaScript exécute des fonctions, il crée un contexte d'exécution à l'intérieur du contexte d'exécution global.
Une fois l'exécution des fonctions terminée, le moteur détruira son contexte d'exécution.

function sum(a, b) {
    return a+b;
}

sum(4,5);

Une fois tout le code exécuté, le contexte d'exécution global sera également détruit, et C'est ainsi que JavaScript exécutera le code en arrière-plan.

Call Stack:

On remarque de la section dernière que lorsqu'une fonction est invoquée en JavaScript, JavaScript crée son propre contexte d'exécution.

Le contexte d'exécution devient compliqué à mesure que nous imbriquons des fonctions à l'intérieur d'une fonction.

JavaScript gère la création et la suppression du contexte d'exécution du code à l'aide de Call Stack.

Hoisting:

Vous pouvez trouver dans d'autres articles que « Hoisting » signifiant des variables physiquement déplacées vers le haut, on peut consacrer cette idée comme introduction mais réellement ce n'est pas vraiment ce qui se passe en fait.

Lors de l’interprétation du code, le JS Engine passe par deux étapes:
Phase de création ( Creation phase )
Phase d’exécution ( Execution phase )

Le JS Engine passe d'abord par le code dans la phase de création et alloue de l'espace mémoire pour les variables déclarées avec le mot-clé var, il y a un autre joueur ici qui s'appelle l’Initializer, qui est chargé d'initialiser leur valeur à undefined.
Les fonctions sont également prises en compte et le JS Engine alloue leur espace mémoire et le remplit par leur code durant cette phase.

Dans la deuxième phase (phase d'exécution), le JS Engine parcourt le code et s'exécute.

Pour la plupart des fonctionnalités ES6 (let, const, paramètres par défaut, etc.), la phase de création fonctionne tout à fait différemment. Il parcourt toujours le code et alloue de l'espace pour les variables, mais l’Initializer définit les variables avec un mode spécial appelé TDZ (Temporal Dead Zone), ce qui signifie que les variables existent mais que vous ne pouvez pas y accéder tant que vous n'avez pas affecté une valeur.

Donc pour résumer:

Avec le mot-clé VAR : la variable est déclarée ( espace mémoire alloué ) et initialisée par « undefined »,
Avec les fonctionnalités ES6 (LET) : la variable est déclarée (espace mémoire alloué) et mise en mode TDZ (vous ne pouvez pas y accéder tant que vous n'avez pas affecté une valeur)
Vous pouvez accéder aux variables ( déclarées avec var ) et fonctions même avant leur déclaration ( les fonctions sont stockées dans la mémoire avec leur code dans la phase de création ).

Closure:

Signifie qu'une fonction interne a toujours accès aux variables et aux paramètres de sa fonction externe, même après le retour de la fonction externe.

exemple de Closure:

prenons cette fonction:

const multiply = (num) => {
    return (x) => num * x;
}

cette fonction permet de multipier un nombre num par un autre nombre x en prenant num en paramètre, et elle fait appel à une autre fonction en passant le paramètre x afin de retourner le résultat: num * x

En déclarons les deux constantes suivantes:

const double = multiply(2);
const triple = multiply(3);

double devient une référence à une fonction qui permet de prendre un nombre en paramètre et le multiplie par 2 car multiply est devenue une fonction qui retourne (num * x) dont num = 2 et x est le nombre qui sera passé en paramètre lors de l'invocation de la fonction.

triple devient une référence à une fonction qui permet de prendre un nombre en paramètre et le multiplie par 3 car triple est devenue une fonction qui retourne (num * x) ** dont **num = 3 et x est le nombre qui sera passé en paramètre lors de l'invocation de la fonction.

double(10); // 20
triple(10); // 30

DOM:

Je crois que le DOM pourrait être parmi les composants les plus essentiels du développement Web et que chaque développeur Front-end doit le comprendre convenablement.

Le DOM n'est qu'une représentation arborescente de la page, nous partons de la balise HTML jusqu'au corps en passant par chaque élément individuel.

Le navigateur nous donne l'API DOM à laquelle on pouvait accéder en utilisant quelque chose comme innerHTML ou getElementById, cette API nous permet de traverser l'accès DOM à n'importe quel nœud que nous voulons, de les supprimer, d'ajouter un nouveau nœud, etc.
Pour savoir plus sur le DOM, je vous propose de visiter les URLs suivants:
https://dev.to/karaluton/what-exactly-is-the-dom-jhg
https://htmldom.dev/

CSSOM:

Le DOM contient tout le contenu de la page. Le CSSOM contient tous les styles de la page, des informations sur la façon de styliser ce DOM. CSSOM est un peu similaire au DOM mais avec une petite différence, la construction DOM est incrémentielle alors que le CSSOM ne l'est pas car le navigateur bloque le rendu lors de cette phase,le rendu des pages est bloqué jusqu'à ce qu'il reçoive et traite tout le CSS car les règles peuvent être écrasées, de sorte que le contenu ne peut pas être rendu tant que le CSSOM n'est pas terminé.

CSS a son propre ensemble de règles pour identifier les jetons valides. N'oubliez pas que le C dans CSS signifie 'Cascade'. Les règles CSS tombent en cascade. Au fur et à mesure que l'analyseur convertit les jetons en nœuds, les descendants des nœuds héritent des styles. Les fonctionnalités de traitement incrémental ne s'appliquent pas à CSS comme elles le font avec HTML, car les règles suivantes peuvent remplacer les précédentes. Le modèle d'objet CSS est construit au fur et à mesure que le CSS est analysé, mais ne peut pas être utilisé pour créer l'arbre de rendu tant qu'il n'est pas complètement analysé, car les styles qui vont être écrasés par une analyse ultérieure ne doivent pas être affichés à l'écran.

Si ce sujet vous intéresse, jetez un coup d'œil sur le CRP ( Critical Rendering Path ).

CORS:

CORS ( Cross Origin Resource Sharing ) est un mécanisme de sécurité implémenté par les navigateurs.
Prenant cet URL: https://www.exemple.com/home/index.html

l’Origin de cet URL est: exemple.com

Une requête Cross Origin c’est quand un site web essaie de demander une ressource d’un URL avec un Origin différent.

Donc si ce site web exemple.com essaie d’envoyer une requête à autreexemple.com alors la requête est considérée comme une Cross Origin Request.

CORS intervient ici est offre la possibilité à autreexemple.com de spécifier les Origins qui seront autorisés à accéder à ses ressources. Tout cela est géré par l’utilisation des en-têtes HTTP:

Access-Control-Allow-Origin: https://www.exemple.com Pour que www.exemple.com soit le seul Origin qui peut y accéder.
Access-Control-Allow-Origin: * Pour que n’importe quel Origin peut y accéder.

REST API:

C’est une API ( Application Programming Interface ) qui utilise le style architectural REST ( Representational State Transfer ).

Ce style architectural permettant de fournir des normes entre les systèmes informatiques sur le web, facilitant ainsi la communication des systèmes entre eux. Les systèmes compatibles REST, souvent appelés systèmes RESTful. Parmi leurs caractéristiques, ils sont Stateless car ils séparent la relation client / serveur.

l'implémentation du client et l'implémentation du serveur peuvent se faire indépendamment sans que l'une se connaisse. Cela signifie que le code côté client peut être modifié à tout moment sans affecter le fonctionnement du serveur, et le code côté serveur peut être modifié sans affecter le fonctionnement du client.
Ceci signifie qu’une API REST peut être utilisée par plusieurs clients à la fois. On peut avoir par exemple une API REST qui sert à servir un client WEB ( Application WEB ), et d’autres clients Mobile ( Application Android, Application IOS, etc. ).

Pour qu’un client puisse se communiquer avec une API REST, sa requête doit principalement contenir les éléments suivants:

Méthode ( GET, POST, etc. )
Path ( Endpoint )
En-têtes HTTP ( HTTP headers )
Corps ( Body ) ( Optionnel )

Puisque les systèmes qui suivent le paradigme REST sont Stateless, ce qui signifie que le serveur n'a pas besoin de savoir dans quel état se trouve le client et vice versa. De cette façon, le serveur et le client peuvent comprendre n'importe quel message reçu, même sans voir les messages précédents.

Après avoir parlé du Javascript, DOM et CSSOM et quelques autre notions basique pour un développeur front-end, passons maintenant à la section suivante de notre article qui se focalise sur l’utilisation du JavaScript notamment l’utilisation des frameworks/librairies afin de créer des applications web dynamiques, interactives et modernes.

Dans cet article, j'ai choisi le framework Angular créé et supporté par Google et la librairie React.js créée et supportée par Facebook .

Angular

Angular est un framework de développement Javascript permettant de créer des applications SPA efficaces et sophistiquées.

Il s'agit de:

Un framework basé sur des composants pour créer des applications Web évolutives,
Une collection de bibliothèques bien intégrées qui couvrent une grande variété de fonctionnalités, notamment le routage, la gestion des formulaires, la communication client-serveur, etc.
Une suite d'outils de développement pour vous aider à développer, créer, tester et mettre à jour votre code

En fait, Une application Angular est une interaction entre les artefacts Angular suivants:

Modules
Services
Components
Directives
Pipes

Chaque artefact est représenté par une classe Typescript, Angular peut reconnaître une classe Typescript en tant que Angular artifact à l’aide des décorateurs.

Un décorateur permet principalement de déclarer des métadonnées pour une classe, une méthode, une propriété ou un paramètre. Lors de la configuration d’un component, on déclare des méta-donnés pour cette classe afin d’informer Angular qu’il s’agit d’un component.

Il existe 4 types de décorateurs en Angular:

Class Decorators
Property Decorators
Method Decorators
Parameter Decorators

Décorateurs de class:

Les décorateurs de classe sont les top-levels décorateurs qui sont utilisés pour définir le but des classes. Ils fournissent à Angular des informations indiquant qu'une classe particulière est un component, un module, un service, une pipe ou une directive.

Ex: @Component, @NgModule, @Injectable, @Pipe, @Directive.

Décorateur de propriété:

Les décorateurs de propriétés sont utilisés pour décorer les propriétés spécifiques au sein des classes.
Avec les décorateurs, vous pouvez par exemple placer le décorateur @Input() au-dessus de la propriété, pour lequel le compilateur d'Angular créera automatiquement une liaison d'entrée à partir du nom de la propriété et les liera ( Input Binding ).

Ex: @Input, @Output, @ViewChild, etc.

Décorateur de méthode:

Un décorateur de méthode décore des méthodes spécifiques au sein d’une classe avec des fonctionnalités. Ceci est déclaré juste avant une déclaration de méthode.
@HostListener en est un bon exemple. Cela indique à Angular que lorsqu'un événement sur l’hôte se produit, la méthode décorée est appelée avec l'événement.

Décorateur de paramètre:

Les décorateurs de paramètres sont utilisés pour décorer les paramètres dans le constructeur de classe. Par exemple - @Inject. Il indique à Angular avec quoi ce paramètre sera initialisé.

Encapsulation de la vue:

Shadow DOM:

Le Shadow DOM apporte l'encapsulation aux éléments HTML. En utilisant le shadow DOM, les balises, les styles et les comportements sont limités à l'élément et n'entrent pas en conflit avec les autres nœuds du DOM, ç-à-d que si une classe “.test” est définie dans le style du composant A, l'élément du composant B ayant la classe “test” ne sera pas infecté par le style définie dans le composant A.

Angular n’utilise pas à proprement parlé de Shadow DOM, mais il émule la séparation permise par le Shadow DOM en ajoutant des attributs spécifiques aux éléments
En effet, par défaut, Angular utilise l’émulation du Shadow DOM, et dans les métadonnées des composants (dans @Component), une propriété est ajoutée par défaut : encapsulation: ViewEncapsulation.Emulated. Du coup, Angular sera capable de limiter le scope des propriétés CSS à ce composant uniquement pour éviter tout débordement de style à d’autre partie de l’application. Et tout cela, sans utiliser le Shadow DOM

Mais comment cette émulation ?

Prenons l’exemple suivant:

@Component({
  selector: 'app-example',
  templateUrl: 'example.component.html',
  encapsulation: ViewEncapsulation.Emulated
})
class ExampleComponent {}

Angular va prévoir la génération du template avec cette contrainte. Une fois le HTML compilé, on voit que des attributs se sont rajoutés sur l’élément de notre composant ainsi que sur tous les éléments fils.

<app-example _ngcontent-0 _nghost-1>
  <div class="example" _ngcontent-1>
    ...

  </div>
</app-example>

Donc, Angular va prendre en considération ces attributs ( uniques pour chaque composants ) lors de génération du CSS final qui va donc pouvoir être complètement isolé à notre composant.

Si vous souhaitez enlever cette émulation, il suffit d’ajouter la propriété encapsulation: ViewEncapsulation.None dans les métadonnées du composant.

Dans le cas d’une ViewEncapsulation.None, aucune règle CSS ne sera scopée au composant. Dans ce cas, il est possible que le CSS d’autres composants écrase les règles définies dans celui-ci.

Si vous souhaitez utiliser le Shadow DOM, vous pouvez utiliser ViewEncapsulation.ShadowDom.

Data-Binding:

La liaison de données ou data binding, est la déclaration d’une relation entre un élément HTML et une source de données ( dans le fichier TypeScript ). Suite à cette déclaration, Angular effectuera les connexions nécessaires.
La liaison de données permet de ne pas avoir à coder soit-même le rendu initial, la connexion des event listeners, la suppression des valeurs modifiées de l'écran et la mise à jour des valeurs des données de l'application.
Le data binding est le cœur de la réactivité dans une application Angular.
Les data bindings possibles dans Angular sont les suivants :
- L’interpolation
- La liaison de propriété (property binding)
- La liaison d’événement (event binding)
- La liaison d’attribut (attribute binding)
- La liaison de classe (class binding)
- La liaison de style (style binding)
- La liaison de données dans les deux sens (two-way data binding)

Directives:

Dans Angular il existe trois types de directives : les composants, les directives d’attribut et les directives structurelles.

Les directives d’attribut modifient le comportement ou l’apparence d’un élément.
Les directives natives de ce type sont ngStyle et ngClass.

ngClass permet d’ajouter/enlever dynamiquement des classes aux éléments HTML du template.
ngStyle permet d’ajouter/enlever dynamiquement des styles aux éléments HTML du template.

Les directives structurelles modifient la structure du DOM, par exemple en ajoutant, supprimant ou manipulant des éléments.
Des exemples de directives natives de ce type sont ngFor, ngIf et ngSwitch.

Les directives structurelles sont facilement reconnaissables car elles commencent par un astérisque * qui est en fait un raccourci syntaxique pour <ng-template>.

Je vous recommande cet article génial afin de comprendre parfaitement le <ng-template> et les autres directives tels que <ng-content> et <ng-container>.

Services:

Afin d’utiliser les services dans une application Angular, il faut avoir une idée sur l’injection des dépendances ( Dependency injection ).

C’est quoi l’injection des dépendances ?

L'injection de dépendances est une technique par laquelle un objet fournit les dépendances d'un autre objet.
La documentation de Angular décrit l’injection des dépendances comme suit:

Les dépendances sont des services ou des objets dont une classe a besoin pour remplir sa fonction. L'injection de dépendances, ou DI, est un modèle de conception dans lequel une classe demande des dépendances à des sources externes plutôt que de les créer.

Et elle rajoute encore:

Le framework DI d'Angular fournit des dépendances à une classe lors de l'instanciation. Utilisez Angular DI pour augmenter la flexibilité et la modularité de vos applications.

Et on pourra aussi bénéficier de l’explication de l’injection des dépendances fourni par un très bon article sur FreeCodeCamp où ils disent:

L'injection de dépendance est souvent plus simplement appelée DI. Le paradigme existe dans tout Angular. Il maintient le code flexible, testable et modifiable. Les classes peuvent hériter d'une logique externe sans savoir comment la créer. Les consommateurs de ces classes n'ont pas besoin de savoir quoi que ce soit.

Les services sont un bienfaiteur clé de l'ID. Ils s'appuient sur le paradigme pour l'injection dans divers consommateurs. Ces consommateurs peuvent alors profiter de ce service fourni et/ou le transférer ailleurs. “

Donc pour résumer, l’injection des dépendances est le paradigme que Angular l’utilise afin qu'une classe puisse utiliser des fonctions et des variables d’une autre classe sans avoir l’instancier, et ces fonctions et variables sont partagées par toutes les autres classes qui en auront besoin.

Les services qui sont des classes Singleton vont souvent inclure des fonctions et des variables partageables entre plusieurs composants. Chaque composant peut injecter le service dans son constructeur afin de profiter des ses fonctions et de ses variables.
Mais attends ! c’est quoi le Singleton ?

Singleton est un design pattern qui implique une seule classe qui est chargée de créer une instance tout en s'assurant qu'une seule instance est créée. Cette classe fournit un moyen d'accéder à sa seule instance auquel on peut accéder directement sans avoir besoin d'instancier une autre fois l'objet de la classe. Une classe Singleton donc est une classe qui ne peut être instanciée qu’une seule fois et toutes les autres classes utilisent la même instance lors de leurs communications.

Dans Angular, un service est une classe Singleton qui ne peut être instancié qu’une seule fois où on peut définir des variables et des fonctions que les composants vont l’utiliser en utilisant l’injection des dépendances, ç-à-d qu’un composant peut injecter la classe du service dans son constructeur pour avoir un accès à ses fonctions et ses variables.
De cette manière la communication entre les composants se déroule.

React:

Passons maintenant à la section suivante où on va parler de React.js.

Comme on a parlé toute à l’heure à propos du DOM, on a mentionné que le navigateur nous donne l'API DOM à laquelle on pouvait accéder en utilisant quelque chose comme innerHTML ou getElementById, cette API nous permet de traverser l'accès DOM à n'importe quel nœud que nous voulons, de les supprimer, d'ajouter un nouveau nœud, etc. Ce mode de programmation s'appelait Impératif (paradigme impératif) : vous modifiez directement des parties individuelles de votre application en réponse aux événements de l'utilisateur.

La manipulation du DOM est l'une des tâches de performance les plus importantes, il faut beaucoup de temps pour que les changements DOM se produisent.

React vous dit: veuillez juste déclarez-moi simplement à quoi ressemble votre application.

Lorsque un élément JSX est rendu ( rendered ), chaque objet du Virtual DOM est mis à jour. Cela semble incroyablement inefficace, mais le coût est insignifiant car le DOM virtuel peut se mettre à jour si rapidement.

Une fois le Virtual DOM mis à jour, React compare le nouveau Virtual DOM avec une copie de l’ancien Virtual DOM ( qui a été pris juste avant la mise à jour ).
En comparant le nouveau Virtual DOM avec une version de pré-mise à jour, React détermine exactement quels objets ont été changés. Ce processus est appelé « Diffing ».

Une fois que React connaît quels objets du Virtual DOM ont été changés, React met alors à jour ces objets, et uniquement ces objets, sur le DOM réel.

Flux de données unidirectionnel:

Si l'état a changé dans le composant B, tous les changements ne peuvent que se répercuter, les données ne peuvent jamais remonter. C-a-d que tous les enfants du composants B ainsi que leurs enfants vont être re-rendu.

Hooks:

UseState:

L’état d’un composant React est susceptible d’être changé à un moment donné, lors d’une interaction de l’utilisateur, récupérer des données via une API, etc. Pour que ce changement soit prise en compte au niveau DOM, le hook useState fourni par React est l’élément clé qui nous permet de changer l’état du composant et de notifier le DOM afin de le prendre en considération et l’affiche car le DOM sera re-rendu à chaque changement d’état.

const [nom, setNom] = useState("Sadok");

On a défini un champ nommé “nom” dans l’état de notre composant initialisé avec “Sadok”.
Le second paramètre setNom est une fonction permettant de mettre à jour la valeur de ce champ et notifier le DOM qu’un changement au niveau de l’état du composant a eu lieu.

Note: Généralement, les Hooks de React sont utilisés avec une fonctionnalité de JavaScript ES6 connue avec le nom "Destructuring".
Pour en savoir plus, veuillez trouver une explication de la décomposition en JavaScript dans MDN.

UseEffect:

Le hook useEffect nous permet d'exécuter du code lors d’un changement d’état. Il s’agit d’une fonction qui prend deux paramètres, le premier est la fonction qui va être exécutée après le changement de l’état, le deuxième paramètre est un tableau où on définit les champs en question.

Prenons l’exemple suivant:

const [eligible, setEligible] = useState(false);
const [age, setAge] = useState("");

useEffect( () => {
    if ( age <= 35 ) {
        setEligible(true);
}
else {
    setEligible(false);
}
}, [age] );

On a définit deux champs dans notre état, age et eligible, supposons qu’on a une application qui fait un controle sur l’age, l’utilisateur saisit son age et s’il est inférieur ou égal à 35 ans alors il est éligible de faire quelque chose, sinon il est non éligible.

le hook useEffect nous permet de faire ce contrôle là en passant en premier paramètre la fonction permettant de tester si l'âge introduit est inférieur ou égal à 35 ou non et elle mettre à jour le champs eligible en appelant la fonction setEligible, et en second paramètre un tableau contenant le champs à contrôler ( age ). C-a-d qu'après chaque changement de la valeur du champ d’état age, la fonction passé en premier paramètre sera invoquée.

On peut définir plusieurs champs dans le tableau de dépendance ( le second paramètre de useEffect ).

On peut définir plusieurs useEffect dans un composant React.

Tous les useEffect seront exécutés une première fois lors de l’initialisation du composant.

useEffect est le bon endroit pour récupérer les données en passant un tableau vide en deuxième paramètre car de cette façon elle sera invoquée qu’une seule fois après l’initialisation du composant.

useEffect( () => {
    getActualites();
    getUsers();
    …
}, [] );

useEffect peut renvoyer une fonction, qui est appelée une fonction de nettoyage ( clean up function ) qui est invoquée lorsque ce composant va être détruit .

Redux et la gestion d'état ( state management ):

Chaque application interactive implique des événements interactifs.

Dans le contexte de React.js et les Single Page Applications (SPA), la gestion d'état ( state management ) est un moyen de partager les données entre les différents composants.
En d'autres termes, un état ( state ) est simplement un objet JavaScript représentant une partie d'un composant qui peut changer en fonction des actions de l'utilisateur.
Pour en savoir plus, vous pouvez jeter un coup d'œil sur la documentation de React.

Redux est une libraire basée sur l’architecture Flux qui a pour but de faciliter la gestion d’état dans une application React.

Redux repose principalement sur 4 acteurs principaux: Store, Reducer, Actions, Selectors.

Le Store est un conteneur d'état en mémoire. Il ne stocke l'état de notre application que pendant l'exécution de l'application. Il s’agit d’un objet JavaScript englobant.

En utilisant ce modèle, notre état est immuable, ce qui signifie qu'il n'est jamais modifié à la place, le Reducer crée un nouvel état à partir de l'état existant et l'Action définie qui fournit qu’est ce que va être changé d’un état à un autre à travers un Payload.

Pour chaque élément du Store, on peut lui associer un Selector qui permet à un composant de s'abonner à cet élément du Store pour être informé de ses changements.

Lorsqu'un nouvel état est remplacé dans le Store, le composant est informé de ce nouvel état et les valeurs liées dans la vue sont mises à jour.

Donc, le Store centralise l’état ( state ) de l’application et tous les composants peuvent soit lire les champs qu’ils en auront besoin à travers les Selectors, soit dispatcher des Actions afin de demander au Reducer de faire un changement dans le Store en passant le type de l’action et un Payload contenant les nouvelles données du champs en question.

Merci pour votre lecture, j’attends vos remarques et feedback dans les commentaires et à la prochaine :D

DEV Community: Sadok Mhiri