Rafraîchir vos connaissances en Front-End
Tags: javascript, webdev, angular, react
Published: 2022-02-01 15:28:07



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](https://frontendmasters.com/), [Freecodecamp](http://freecodecamp.org), [Pluralsight](https://www.pluralsight.com), [Udemy](https://www.udemy.com).



#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 :
  1. Composant mémoire : Variable environment
  2. Composant du code : Execution thread





![Context d'exécution](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2lilvschvsv52wbs8vv8.jpg)


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
 1. Phase de création de mémoire
 2. 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);
```



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/539m0x9kjk4t2kps9ao5.jpg)


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.




![Call Stack](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ekqjk7ygnmpxq3q21wc5.jpg)



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



![Call Stack](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bb9e1lu7udedqx707vqh.jpg)



####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](https://developer.mozilla.org/fr/docs/Web/API/Document_Object_Model), je vous propose de visiter les URLs suivants: 
[https://dev.to/karaluton/what-exactly-is-the-dom-jhg](https://dev.to/karaluton/what-exactly-is-the-dom-jhg)
[https://htmldom.dev/](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.





![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vozei1mcfalse3i002ks.jpg)





Si ce sujet vous intéresse, jetez un coup d'œil sur le [CRP ( Critical Rendering Path )](https://developer.mozilla.org/en-US/docs/Web/Performance/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.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f9ip7376wjemnmse71pb.png)


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](https://angular.io/) créé et supporté par Google et la librairie [React.js](https://reactjs.org/) 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](https://www.freecodecamp.org/news/everything-you-need-to-know-about-ng-template-ng-content-ng-container-and-ngtemplateoutlet-4b7b51223691/)** 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](https://www.freecodecamp.org/news/angular-dependency-injection/) 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:**



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gnnl2ry3mp48f9a82ode.jpg)


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](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Operators/Spread_syntax).


####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](https://reactjs.org/docs/state-and-lifecycle.html). 

[Redux](https://redux.js.org/) 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