
Si vous voulez faire carrière dans le développement, vous vous trouverez à un moment donné à un carrefour. Deux chemins très différents s'en éloignent. Les deux chemins sont difficiles, et pourtant même les difficultés sont radicalement différentes. 

L'un des chemins, le front-end, semble plat, brillant et lumineux, à l'air libre et ensoleille. Et pourtant, il est sinueux, il tourne, et surtout il y a des foules hargneuses de chaque côté, prêtes à bondir sur ceux qui trébuchent sur la route. 

L'autre chemin, celui du back-end, semble escarpe, froid et isole, avec des précipices prêts à engloutir ceux qui y tombent. Et pourtant, le chemin lui-même est droit et solide.

Aucun des deux chemins n'est facile. Lequel choisirez-vous ? 

La réponse pourrait bien dépendre de qui vous êtes. Voyons pourquoi. 

Il faut commencer par préciser que le développement back-end et front-end ont deux objectifs très différents. 

En termes simples, l'objectif du développement back-end est de produire un système logique. Un système ou les entrées peuvent être nettoyées et les sorties sont connues ; un système ou les règles sont primordiales. Le back-end consiste à manipuler les données, à trouver la bonne façon de les formater, de les stocker, de les récupérer, de les envoyer. Et surtout d'y appliquer une logique mathématique froide. 

Le back-end consiste à faire en sorte que les ordinateurs parlent aux ordinateurs de la manière la plus efficace possible. On y traite de vérité objective. Et donc on n’y fait jamais faire confiance à l'utilisateur, à ce qu’il déclare ou ce qu’il fait.

Le développement font-end, quant à lui, consiste à traiter avec des humains. Et contrairement aux ordinateurs, les humains sont désordonnés et imprévisibles, et merveilleusement varies. 

Un ordinateur fera exactement ce que vous lui dites de faire, ni plus ni moins. 

Les humains peuvent faire plus ou moins ce que vous attendez d’eux, ou… exactement le _contraire_ de ce que vous attendez d'eux, juste… parce que. 

Ou encore ils peuvent deviner ce qu'il faut faire sans que vous leur demandiez quoi que ce soit. 

Le développement font-end consiste donc à chercher à faire plaisir à l'utilisateur, à lui offrir l'expérience la plus esthétique, la plus amusante et la plus divertissante. 

Il comporte des éléments de créativité et d'art. 

En ce sens, l'objectif _fondamental_ du développement front-end ne peut pas être facilement mesure ou défini, parce qu’il est intrinsèquement subjectif.

On pourrait presque dire qu'il y a là une opposition cerveau gauche/cerveau droit entre le développement back-end et front-end. 

Mais la différence ne s'arrête pas là. 

Elle concerne également les concepts, les compétences et les technologies qui doivent être maîtrises en cours de route. Voyons ça ensemble. 

Précisons tout de même que ces deux chemins ont un tronçon commun, un socle sur lequel bâtir l'édifice. 

Cette fondation commune inclut Git, bien sûr. 

Et même en étant développeurs back-end il est nécessaire de comprendre les bases de HTML et CSS. 

Par ailleurs le JavaScript ou le TypeScript seront utiles dans les deux cas (puisqu’avec NodeJS le Javascript est devenu un langage serveur).

Il y a également besoin dans les deux cas de comprendre le fonctionnement des API, puisqu’elles sont la "colle" (ou : l'interface, qui est le I de API) entre le front-end et le back-end. 

Maintenant qu’on a vu ce que back et front ont en commun, voyons leurs différences. 

Tout d’abord le back. Le développeur back-end s'occupe de stocker et de manipuler les données de la manière la plus propre, la plus efficace et la plus sûre possible. 

Avec un minimum de répétitions, sans fioritures. 

Les questions auxquelles il faut répondre sont donc les suivantes : 

1/ Comment les données sont-elles structurées ? (et la réponse dépend de si nous utilisons  une base de données relationnelle, qui peut être interrogée avec SQL, ou dans un magasin clé/valeur, ou encore un autre type de base de données NoSQL). 

2/ Comment l'utilisateur est-il authentifié ? 

3/ Comment, sur la base de l'utilisateur, de ses actions et des données dont nous disposons, appliquons-nous des règles de logique, et réécrivons-nous les données ?

Et pour répondre à ces questions, nous devons avoir une solide compréhension du fonctionnement des bases de données. 

Nous devons comprendre comment fonctionne un serveur sans état (ou stateless) et connaître les règles ACID des bases de données, et leur raison d'être. 

Nous devons comprendre comment mettre les données en cache et invalider le cache. Nous devons avoir une solide compréhension du fonctionnement du cryptage : comment l'utiliser et ses limites. 

Et bien sûr, maîtriser au moins un des langages côte serveur (PHP, NodeJS, Python, Java...). 

Pour résumer : en back-end on uniformise, on sécurise, on s’assure que tout rentre bien dans les cases.

En front-end à l’inverse, la principale préoccupation est de gérer le fait que les gens accèdent au Web avec une très grande variété d'appareils.

Des téléphones androïdes lents de 360 pixels de large en mode portrait jusqu’aux ordinateurs de bureau fulgurants avec 5K pixels de large (en mode paysage). 

Et en plus ces appareils ont des connexions réseau très différentes. Certains ont la fibre, mais d’autres ont une connexion EDGE. 

Les questions auxquelles il faut répondre sont donc les suivantes : 
1/ Comment pouvons-nous dégrader gracieusement l’expérience ? Comment pouvons-nous offrir une expérience agréable et fonctionnelle sur des appareils radicalement différents ?

1/ Comment faire pour que les images soient nettes sur un écran 5K et s'affichent immédiatement sur une connexion lente ? 

3/ Comment pouvons-nous donner l'impression que quelque chose se passe, que l'entrée de l'utilisateur a bien été prise en compte, même si nous attendons toujours la réponse du serveur ?

Et pour répondre à ces questions, nous devons comprendre le fonctionnement des navigateurs, comprendre comment optimiser les données envoyées, et comment faire en sorte que la page soit la plus rapide possible. 

Nous devons comprendre ce qu’est la conception responsive mobile-first, le chargement décalé, ou lazy-loading, ainsi que les formats d'image. 

Et il nous faut aussi comprendre les subtilités de CSS, ainsi que ses différents modes (block, flexbox, grid,..), le HTML sémantique, le SEO technique, et bien sûr JavaScript.  

J’en entends au fond qui disent « moi je veux être développeur fullstack » c’est-à-dire à la fois font-end et back-end. 

Et c’est un noble idéal (et puis ca paie mieux aussi :D ) Qu’en est-t-il donc du fullstack ?

Et bien il faut préciser que vous ne pouvez jamais commencer par le développement fullstack. Vous ne pouvez pas maitriser simultanément le back-end et le front-end. 
Si vous voulez maitriser deux sujets, il faut commencer par en maitriser un. 
 
Ceci étant dit, c’est vrai que pour maîtriser un des deux (front ou back) vous aurez de toute façon besoin de comprendre une partie de ce qui se passe de l'autre côté du grand fossé entre navigateurs et serveurs. 

Qui plus est, les lignes entre le front-end et le back-end deviennent progressivement de plus en plus floues. 

D'abord par le fait des frameworks côte client tels que React ou Vue ou Angular qui déplacent autant que possible la logique métier vers le côté client. 

Et deuxièmement par le fait des frameworks full-stack tels que NextJS ou NuxtJS ou vous finissez par écrire du code qui sera exécuté à la fois côte serveur et côte client. 

Mais les différences *fondamentales* entre les mentalités et les compétences requises pour le développement côte front-end ou back-end signifient que la grande majorité d’entre nous auront une zone de confort. 

Un côté de la division serveur/navigateur sur lequel on préfère travailler. 

Et cela pourrait être simplement dû à la composition de notre personnalité.



Les développeurs full-stack n'existent pas, et je suis l'un d'entre eux

La différence entre le développement frontend et le développement backend, expliquée


J'ai commencé à coder quand j'avais 10 ans. Mon grand-père m'a donné un ZX81 avec 1 kilo-octet de RAM. Il se branchait sur la télévision, et la vitesse d'horloge de l'unité centrale était calibré sur la fréquence de rafraîchissement de la télévision.

Et depuis lors, dans chaque emploi que j'ai eu, j'ai codé. Même quand le codage ne faisait pas partie de la description du poste, même maintenant que je suis dans le management. Parfois, c'était par nécessité, parce que le bateau coulait rapidement et que tout le monde devait être sur le pont. (Oui, j'ai vu ma part de naufrages de startups). Mais la plupart du temps, c'est par choix. Parce que pour moi, coder est un plaisir. Voici pourquoi.

## Raison 0 : Le code est un jeu d'exploration, un voyage
Coder, c'est avant tout apprendre : apprendre de nouveaux langages, de nouvelles technologies, de nouvelles techniques, de nouvelles façons de faire. Il s'agit de se familiariser avec les callbacks, la programmation orientée objet, le comportement asynchrone, les promesses, la programmation fonctionnelle (surtout depuis l'arrivée des hooks), les bases de données, les navigateurs, les plates-formes mobiles, les moteurs de jeux... Évidemment, il ne s'agit pas _que_ de cela. Mais il s'agit en quelque sorte d'un _voyage_. Un voyage dans l'esprit de personnes brillantes (et parfois moins brillantes) qui ont créé des choses nouvelles, étranges et passionnantes. 

Et le plaisir se trouve dans le voyage, dans le processus de découverte des idées et de la créativité qui ont permis de produire toutes ces nouvelles technologies.

## Raison 1 : Le code est un jeu de construction
Coder, c'est _créer_ quelque chose à partir de rien, d'électrons et d'un peu d'imagination. 

Il y a une joie à produire quelque chose de nouveau et de beau que des inconnus vont découvrir et, espérons-le, comprendre et apprécier. Bien sûr, la première itération échoue généralement lamentablement à l'aune de ce critère-là, mais c'est aussi une joie de pouvoir ensuite affiner et polir quelque chose d'imparfait, pour en tirer quelque chose de beau.

## Raison 2 : Le code est un jeu de stratégie
Il arrive que, malgré tous vos efforts, l'ordinateur refuse de se plier à votre volonté, surtout lorsque vous vous aventurez sur un terrain inconnu peuplé de nouvelles technologies et de nouveaux concepts. 

Ou lorsque vous essayez de faire en sorte que les navigateurs se comportent de manière raisonable ou uniforme. Dans cette situation, il est utile d'apprendre à penser latéralement, à aborder le problème sous différents angles, voire même... à le contourner. Il existe de nombreuses façons d'atteindre son but, de centrer un div ou d'interroger une base de données.

## Raison 3 : Le code est un jeu d'énigmes
J'adore lire des romans policiers. J'aime essayer de comprendre qui est le coupable, et percer le mystère des motivations et des interactions psychologiques qui sous-tendent tout cela. Et le code a une certaine mesure de cela. 

En particulier lorsqu'il s'agit de comprendre la raison pour laquelle les choses ne fonctionnent pas ou, pour paraphraser Chesterton, la raison encore plus sombre pour laquelle les choses fonctionnent alors qu'elles ne le devraient pas.

## Le code est mon travail de 9 à 5 et mon activité secondaire.
Toutes ces raisons se combinent pour expliquer pourquoi tant de développeurs choisissent de passer leur temps libre à coder : parce que, comme Jane McGonigal l'a déclaré dans son livre Reality is Broken : "Les jeux nous rendent heureux parce qu'ils représentent un travail difficile que nous choisissons pour nous-mêmes, et il s'avère que presque rien ne nous rend plus heureux qu'un bon et dur labeur". 

Le codage est un bon travail difficile avec des résultats visibles et le sentiment d'avoir surmonté les périls du voyage lorsque vous atteignez enfin votre destination.

Et la nature du logiciel fait que ce voyage nous appelle à chaque instant.

Quatre raisons pour lesquelles j'adore coder

 En tant que manager avec quelques années d'expérience en développement, j'ai souvent des développeurs juniors ou des stagiaires qui viennent me voir pour essayer de comprendre pourquoi leur code ne se comporte pas comme ils s'y attendent. Lorsqu'ils codent en React, cela provient le plus souvent d'un manque de compréhension du comportement de useState. Voici donc cinq erreurs que j'ai vues au cours de l'apprentissage de React et particulièrement de useState.
 
## Pas assez d'état
C'est la première erreur commise par un développeur (très) junior qui n'avait pas encore compris à quel moment la  fonction de rendu d'un composant React est appelée. Il avait modifié une variable dans un callback `onClick` et s'est ensuite demandé pourquoi cette modification n'était pas prise en compte à l'écran. En règle générale, tout ce qui est externe à l'application doit être stocké quelque part dans l'état (ou dans un mécanisme équivalent), que ce soit le fait qu'un utilisateur ait cliqué ou le retour d'un appel d'API. "Tu devrais stocker cela dans l'état", je lui ai-je dit, "sinon, l'information se perdra entre les trames de rendu". 

## L'état contient trop d'informations
L'erreur suivante (par le même gars) était l'étape d'après, la suite de la précédente, et représentait un mouvement de balancier dans l'autre sens. Il était tellement déterminé à s'assurer que tout était stocké en toute sécurité qu'il a également inclus des valeurs calculées qui étaient simplement le résultat d'autres variables d'état. Bien sûr, s'il s'agissait simplement d'une question de code mal fagotté, il ne serait peut-être pas venu chercher de l'aide. Mais l'affichage ne se mettait à jour qu'une fois sur deux lorsqu'il cliquait. En regardant le code, j'ai vu qu'il faisait quelque chose comme ceci : 
```js
if (condition) setScore(score + 1) ;
if (score > 0) setButtonActive(true) ;
```
Dans le code ci-dessus, le score n'a pas changé entre les deux lignes (parce que nous sommes dans la même trame de rendu - ou "frame"). Et la deuxième ligne stocke quelque chose qui peut être déduit de l'autre variable d'état. Et c'est pour ça que l'affichage ne se mettait pas mis à jour. "Je lui ai dit : "Tu n'as pas besoin de tout stocker, la logique que tu peux déduire des autres variables d'état n'a pas besoin d'être stockée".


## L'état est mis à jour trop souvent
A un autre endroit du code, le même gars avait écrit quelque chose qui ressemblait à ceci: 

```js
if (condition) setScore(score + 1) ;
// ..... quelques lignes plus loin 
if (condition2) setScore(score + 1) ;
```
Ici de la même façon, le score n'a pas été changé entre les deux lignes, et ne s'incrémente au final qu'une seule fois, au mieux. 

Pour corriger ceci, on peut passer une fonction à la fonction d'état  
```js
if (condition) setScore((prev) => prev + 1) ;
// ..... quelques lignes plus loin 
if (condition2) setScore((prev) => prev + 1) ;
```

Ainsi la mise à jour de l'état s'applique sur la valeur en cours de l'état, et non sur la valeur initialement définie en début de l'appel de la fonction de rendu.
 
Il n'en était pas encore là dans son apprentissage, mais un jour il apprendra que si l'état est un peu complexe, avec des variables interdépendantes qui doivent être mises à jour de manière coordonnée ou non triviale, il pourrait être préférable de faire appel à useReducer. Mais il n'en est pas là. Pas encore.

 
## Redéfinir trop de choses dans le rendu
Quelques jours plus tard, il était de retour. Il avait un formulaire où il était convaincu de tout faire correctement, et pourtant l'état était réinitialisé chaque fois qu'il entrait des données dans le formulaire HTML. Maintenant, à ce stade, je tiens à préciser qu'il s'agit d'une personne à la fois très brillante et très sympathique. Cependant, il venait de commencer à apprendre React, donc il faisait à peu près toutes les erreurs à faire, et je commençais à douter de la sagesse de lui faire développer en utilisant React. Mais c'était un stage, et il était venu pour apprendre. Et l'expérience n'est souvent que la somme des erreurs passées, donc selon cette norme... tout se passait très bien. 
Il avait pris à cœur mes conseils sur le fait de recalculer des choses qui n'avaient pas besoin d'être stockées. Mais il avait été un peu trop enthousiaste à propos de tout cela. La conversation s'est déroulée comme suit :

 - Attendez, où commence ce composant ? 
 - Juste en haut du fichier, ici. 
 - Et où est-ce qu'il se termine ? Je ne peux pas trouver la fin.  
 - C'est ici, en bas du fichier. 
 - Et c'est quoi tout ça au milieu ? 
 - Ce sont les fonctions et les constantes que j'ai définies, et le composant pour le formulaire HTML. Parce que j'ai besoin que l'état de ce composant soit partagé avec le composant principal.
 
J'espère qu'il n'a pas vu le regard de désespoir qui a du paraître sur mon visage. 
"Toutes les constantes et toutes les fonctions qui fournissent simplement une logique sans manipuler l'état peuvent être déplacées hors du composant, dans un fichier séparé. Vous pouvez juste importer vos points d'entrée et les utiliser." Je lui ai dit. "Et le composant Form redéfini dans le composant principal... eh bien vous le redéfinissez complètement à chaque trame de rendu, donc vous montrez en fait un nouveau composant à chaque mise à jour."

Nous avons finalement refactoré entièrement ce bout de code.

## S'appuyer uniquement sur les props initiaux pour définir l'état

Je dois avouer que je me suis personnellement rendu coupable de cette erreur. J'avais créé un composant qui affichait essentiellement une barre de progression circulaire basée sur les props que je lui transmettais. Il stockait donc son état comme ceci : 

```js
const [progress, setProgress] = useState(props.init) ;
```
Bien sûr, le problème ici est que tout changement dans les props n'affectera pas l'état, une fois que la première initialisation est faite. 
Ici, il y a deux solutions possibles, qui dépendent de ce qui est fait exactement dans le composant. Si le composant n'a pas de logique interne qui met à jour l'état, vous n'avez pas besoin de stocker l'état. Mais dans mon cas spécifique, j'avais besoin de l'état, donc j'ai utilisé useEffect :
```js
const [progress, setProgress] = useState(props.init) ;
useEffect(()=> { 
  setProgress(props.init) ;
}, [props.init]) ; 
```

## Mise à jour de l'état avec un objet muté
Il s'agit d'une erreur classique qui découle d'un manque de compréhension du fonctionnement des objets en JavaScript, et plus précisément du fait que la mutation des objets ne déclenche pas la détection des changements de React. En effet, l'affectation d'un objet se fait par référence, c'est-à-dire que lorsque vous affectez un objet à une variable, vous ne faites que stocker le pointeur de l'objet dans votre variable, de sorte que deux variables peuvent pointer vers le même objet.
```js
let a = {nom : "Bob"} ;
let b = a ;
b.name = "Alice" ;
// ici a==b et a.name == "Alice" ;
```
En termes de React, cela signifie que faire quelque chose comme ceci ne mettra pas à jour l'affichage, car la valeur de la variable state ne change pas, elle pointe toujours vers le même objet :
```
const [state, setState]=useState({score:0}) ;
const onClick =() => {
  state.score += 1 ;
  setState(state) ;
}
```
La solution, bien sûr, est de créer une copie de l'état, par exemple avec l'opérateur d'étalement ou en déclarant un nouvel objet (ou, pour être parfaitement honnête, en utilisant simplement un scalaire dans l'exemple ci-dessus) : 
```js
const [state, setState]=useState({score:0}) ;
const onClick =() => {
   setState({..state, score : state.score+1}) ;
}
```
## Pas juger

Même si le chemin était tortueux, mon collègue s'est plu à apprendre à manipuler React. Et je suis certain que j'ai du faire au moins autant d'erreurs dans mon processus d'apprentissage. Je suis souvent horrifié quand je vois du vieux code à moi. 

Et pour être parfaitement honnête, j'ai moi-même beaucoup profité des interactions. Le fait d'expliquer comment les choses marchent est une bonne façon de continuer à apprendre, et une expérience gratifiante.

Bref, j'aime bien expliquer le code !

6 erreurs de débutant en React (et comment les éviter)


Voici donc comment résoudre un sudoku en python, et quand on sait résoudre une grille, on sait aussi la générer. C'est relativement simple, en quatre fonctions, vous pouvez trouver un lien vers le code en bas de l'article. 

La première qui crée la grille, la deuxième qui cherche les possibilités d'une case, la troisième qui résout, qui fait la première résolution la résolution simple d'une grille, et la quatrième qui fait la résolution complète de la grille. 

Quel est le problème que je cherche à résoudre ? C'est la raison pour laquelle je fais ça en réalité : parce que j'ai commencé à créer un livre de Sudoku (sur KDP) en utilisant des grilles générées par un service en ligne, et la génération de PDF via React. Ma fille est venue en me disant : « Papa, papa ! En fait, là, dans cette grille-là, il y a deux possibilités ! » Et donc j'ai voulu vérifier que je n'avais pas fait d'erreur, et que mon truc marchait. Et c’est la raison pourquoi j’ai codé ce programme qui fait ce test. 

## La création de grille avec createGrid
Comment structure-t-on la grille ? On commence par lire les données existantes puis on crée un tableau, en réalité un tableau de tableau. Dans chacun de ses petits tableaux, les neuf, et bien ils ont neuf chiffres et ces neuf chiffres ils peuvent valoir entre 0 et 9, 0 signifiant une case vide, les chiffres 1 à 9 signifiant les cases déjà renseignées. 

La récupération des possibilités d’une case avec getPossibilities
Dans ce tableau de chiffres de 0, 9 on va faire une première fonction qui s'appelle getPossibilities. Cette fonction va renvoyer le tableau de l’ensemble des possibilités, dans l’état actuel de la grille, pour une des cases. Si la case est non nulle, la seule possibilité est le chiffre qui est déjà renseigné, donc on renvoie un tableau ne contenant que ce chiffre-là. Si la case est actuellement à 0, on regarde l’ensemble des chiffres (supérieurs à 0) qui sont sur la même ligne, la même colonne, ou la même case de 3x3, et on les liste dans un tableau. 
On itère ensuite de 1 à 9 pour trouver l’ensemble des chiffres qui ne sont pas contenus dans le tableau des chiffres existants, et qui sont donc des candidats possibles pour cette case-là. Cette fonction va donc renvoyer un tableau qui peut avoir aucune élément (si il y a une erreur dans la grille), une seul élément (qui est donc le bon élément pour la case), ou plusieurs éléments. 

## Une première résolution simple avec simpleSolve
La fonction simpleSolve va faire une résolution basique comme son nom l'indique. Cette résolution basique commence par faire une copie profonde du tableau (un « deep copy ») pour ne pas altérer le tableau reçu en paramètre. Ensuite la fonction itère sur l’ensemble des cases. Pour chacune des cases de la grille valant zéro, elle appelle getPossibilities pour récupérer les possibilités sur cette case-là. Il y a alors trois cas possibles. Premier cas, il n'y a qu'une seule possibilité dans une case : dans ce cas, la fonction va renseigner cette possibilité-là dans la case (et c'est pour ça qu'on a fait une copie profonde au début). Deuxième cas, il y n’a aucune possibilité : dans ce cas la fonction renvoie une erreur. Troisième cas, il y a plusieurs possibilités : dans ce cas la fonction incrémente un compteur qui sert à mesurer le nombre de zéros restants dans la grille. Une fois que la fonction a bouclé sur l’ensemble des cases, de deux choses l’une. Soit, nous avons trouvé des nouvelles valeurs mais il reste des zéros dans la grille, dans quel cas on recommence une nouvelle boucle en réinitialisant le compteur de zéros. Soit, il n’y a pas (ou plus) eu de remplacement ou il reste plus aucun zéro sur la grille, et dans ce cas la fonction est arrivée au bout de ce qu’elle peut faire. (S'il n'y a plus de 0, la grille a été résolue.) La fonction renvoie donc ce qu’elle a réussi à faire de la grille, ainsi que le nombre de 0 restants. 

## La résolution complète avec solveGrid
La fonction solveGrid va commencer par lancer un simpleSolve sur la grille, ce qui va en plus avoir davantage de faire une copie profonde de la grille. Si le simpleSolve ne résout pas la grille, si elle revoie une grille où il reste des 0, on a donc des cases avec plusieurs possibilités. Que fait-on alors ? On essaye ces différentes possibilités. On prend une case avec plusieurs possibilités (par exemple une des cases qui présente le moins de possibilités différentes). Puis on crée plusieurs copies de la grille, une pour chaque possibilité. Dans ces grilles on applique chacune des possibilités. Comme si c'était de nouvelles réalités qu'on créait. Comme en mécanique quantique, comme le chat de Schrödinger, on créé une variante de la réalité où on a dit : "cette case a cette possibilité à présent". 

Que fait-on alors avec ces grilles ? On fait une récursion : on rappelle la même fonction, solveGrid, avec les nouvelles grilles. Et ces nouvelles exécutions de la fonction vont appliquer pour chaque grille tout ce qu'on a déjà vu au-dessus, à commencer par la résolution simple. Et si la fonction trouve encore des cases où il y a plusieurs possibilités, elle va elle-même relancer des résolutions de variantes. Le processus va se dérouler et va faire des branches, et des branches de branches, comme un arbre qui explore la viabilité des différentes possibilités. 

Dans ces branches plusieurs choses peuvent se passer. Le cas le plus simple, c’est de se retrouver avec une case avec aucune possibilité. Dans ce cas, la branche n’est pas viable : on la met de côté et on l’oublie, elle va juste renvoyer un tableau vide. A l’inverse, on peut aussi arriver à une solution valable, une grille résolue où il ne reste plus aucun 0. Dans ce cas, la fonction renvoie un tableau contenant la solution trouvée, la grille remplie. 

A présent, replaçons-nous dans le contexte de l’exécution de la fonction qui a crée plusieurs branches. Chaque branche, chaque exécution renvoie un tableau contenant les solutions trouvées, la fonction concatène ces tableaux, et les renvoie à son parent, du moment que ce tableau des grilles valides comporte 0 ou 1 élément, et c’est ainsi que les solutions remontent l’arbre des possibilités. Par contre, si le tableau comporte deux solutions ou plus, la fonction créé une erreur, parce que la présence de deux grilles valables signifie que la grille parente est erronée. 

In fine nous avons donc trois cas de figure, dans le cas de la première exécution de ma fonction solveGrid. Il peut y avoir une seule solution, dans ce cas la grille est valable. Il peut y avoir aucune solution, dans ce cas ma grille est erronée. Et il peut y avoir plusieurs solutions, et dans ce cas ma grille ne comporte pas assez d’information pour être résolue. 

## Pour aller plus loin
Ce système de backtracking par récursion nous permet non seulement de vérifier qu'une grille est valable, mais aussi de mesurer la difficulté de la grille en mesurant combien de fois on a besoin d'appeler la version complexe de la résolution, puisqu’il s’agit de cas (et de cases) non évidents. 
En prime, le même code nous permet aussi de pouvoir générer des grilles valables, en plaçant quelques chiffres initialement (à la main ou au hasard) et en allant dans la fonction solveGrid et en prenant une branche qui ne retourne qu’une seule solution (en allant plus ou moins profond dans les branches pour calibrer la difficulté).  


Comment résoudre et générer une grille de sudoku avec du backtracking et de la récusion



Pourquoi (et comment) utiliser les Promises ? Que sont les Promise (ou promesses, en Français), pourquoi les utiliser, comment s’en servir ?  

## Le problème du javascript

Fondamentalement, le JavaScript est mono tache. 

Qu’est-ce qu’on entend par là ? Cela signifie que s’il fait quelque chose qui lui prend du temps – un gros calcul par exemple – il ne peut plus rien faire d’autre. 

De temps en temps ça m’arrive de faire un « while » où j’oublie d’incrémenter la chose sur laquelle j’ai ma condition, et donc de créer une boucle infinie. Dans ce cas... tout se fige. Le navigateur ne répond plus, je dois forcer la fenêtre à se fermer. 

Alors évidemment c’est un cas extrême, mais comme vous le savez surement, les films au cinéma tournent à 24 images par seconde, et les jeux vidéo à au moins 30 FPS. Mais 24 images/s, ça signifie une image toutes les 40 millisecondes environ. 

Pour dire les choses autrement, les calculs ou des traitements en JavaScript doivent tous durer moins de 40 millisecondes, sinon les utilisateurs vont avoir l’impression que l’application « rame ».

Mais si on veut faire un appel à une API, en gros à un serveur web, l’aller-retour du message va forcément mettre plus de temps que ça. Le JavaScript ne peut pas se permettre d’attendre. 

## Les fonctions callback 

Du coup ce qu’on fait – à l’époque, et fondamentalement, encore aujourd’hui – c’est d’utiliser des traitements asynchrones, en disant au navigateur : « lance tel processus (par exemple, appelle telle API), et quand c’est fini, rappelle-moi ». Ou plus exactement, exécute cette fonction que je te donne en paramètre. Cette fonction s’appelle une callback : qui signifie justement le fait de rappeler. 
 
Ce fonctionnement permet des logiques un peu construites, par exemple : quand l’utilisateur clique sur le bouton, connecte-toi en appelant le login, récupère les données d’authentification et interprète les, puis rappelle tel web service avec les données de connexion pour mettre à jour les informations du joueur. Rien de bien compliqué dans l’absolu, mais ce genre de fonctionnement produit des callbacks dans des callbacks dans des callback, ce qui rend le code difficilement lisible. Ce que certains ont appelé : « l’enfer des callbacks ». 

Un autre problème se profile également avec ce genre de fonctionnement : le traitement des erreurs. Il faut faire un traitement spécifique à chaque niveau de profondeur, et si une de ces erreurs n’est pas traitée, il est assez difficile de la débugger avec des messages sous la forme de « une erreur s’est produite à la ligne 5 de la fonction anonyme ». Et c’est encore pire quand la callback échoue silencieusement ! 

## C’est quoi une promise ?

C’est pour résoudre ces problèmes qu’a été inventé un objet qui comporte trois propriétés fondamentales :
1/ Il encapsule la notion de traitement asynchrone
2/ Il permet la gestion des erreurs qui en résultent 
3/ Il permet un traitement en chaine sans avoir besoin d’imbriquer

Cet objet, c’est la *Promise*. 

Une Promise comporte deux fonctions : then et catch. 

La fonction « then » prend en paramètre le résultat de la Promise, et renvoie une nouvelle promise 

La fonction « catch » prend en paramètre l’erreur, et renvoie également une nouvelle promise. 

Ce fonctionnement, ce renvoie de promise, est justement ce qui nous permet de « chainer » les Promises, c’est-à-dire de faire :  

`p.then(traitement).then(traitement2)` 

où p est une promise 

Cette fonctionnalité de chainage nous permet une lecture linéaire au lieu de faire une lecture imbriquée. 

La façon dont la Promise fonctionne est que le premier catch de la liste soit appelé quel que soit le traitement antérieur où se produit l’erreur – la gestion d’erreur est donc centralisée. 


## Comment fabriquer une promise ?

Je vous propose qu’on fabrique ensemble une promise qui attend juste pendant une durée qu’on précisera. Donc on va faire une fonction « sleep » qui revoie une promesse qui s’exécute après un delai. 

Le constructeur de la promise prend en paramètre une fonction. 

Cette fonction prend elle-même en paramètre deux fonctions, qu’on appelle communément « resolve » et « reject », et qu’on va appeler quand le processus arrive à bon terme (resolve) ou échoue (reject)

Donc à la base notre fonction sleep va ressembler à ceci :

```js
const sleep = (nb) => {
  return new Promise ((resolve, reject) => {
    setTimeout(() => resolve(), nb) ;
  })  
} ;
```

Le deuxième paramètre n’est pas utilisé dans notre cas et pourrait être omis, mais on l’a gardé pour être complet.

Du coup à présent si on fait :

`sleep(1000).then(() => console.log(« done »)) ;``

On a une promise qui déclenche une fonction au bout d’un certain temps. 
(Je vous accorde qu’on n’a pas beaucoup fait avancer la technologie avec ça !) 

## Les promises c’est bien mais on peut les écrire mieux !

J’ai une bonne nouvelle : Il y a une façon d’appeler les promises qui est encore plus lisible ! 

Ce système n’est qu’une question de syntaxe, mais qui fonctionne avec les Promises.  
Ce système, c’est async/await.

Comment est-ce que ça fonctionne ? 

ET bien prenons un exemple d’un enchainement basique de promesse :

```js
const wait = () => {
  sleep(1000)
     .then(() => sleep(1000))
     .then(() => console.log(« 2s later ») ;
} ;
```

En utilisant la notation async/await on peut écrire la même chose :

```js
const wait = async () => {
  await sleep(1000)
  await sleep(1000))
  console.log(" 2s later ") ;
} ;
```


Concrètement il ne s'agit que d'une différence de syntaxe, il s'agit des mêmes objets qui sont manipulés. Ici on enveloppe ces deux appels dans un try catch et dans ce cas try/catch fait la gestion des erreurs. 
Tout cela transforme la façon d'écrire les promise et donne l'impression de lire du code synchrone, même si en réalité à chaque fois ce sont des promesses qui sont appellées. La fonction wait ici renvoient elle-même une promise .

## Conclusion 

Les promesses et la syntaxe en async/await nous permettent de décrire un comportement asynchrone d'une manière aussi lisible que du code asynchrone, et d'échapper ainsi à "l'enfer des callbacks".

Les Promesses en Javascript

apprendre à coder


Je me suis [lancé un défi](https://dev.to/gosev/defi-framework-ssr-next-vs-vs-nuxt-vs-sveltekit-454d) de créer un blog avec trois frameworks : Svelte/Sveltekit, Vue/Nuxt et React/Next, pour me donner un cas pratique et donc un angle d'attaque pour apprendre les frameworks. 
J'ai commencé par Svelte. Pourquoi celui-là ? Du peu que j'en ai lu, Vue a été crée par Evan You qui avait travaillé sur Angular JS. Même si Angular 2+ n'a rien à voir avec Angular JS, j'ai tout de meme l'impression à première vue que Svelte utilise des concepts complètement différents de ce que je connais déjà (à savoir React et Angular, côté framework côté client), et du coup ça m'intéresse de les apprendre, de les comprendre, et avec un peu de chance de vous aider à les comprendre aussi. 

Ma technique pour apprendre c'est de faire, donc souvent je lance, j'installe, j'essaie de regarder les exemples, de bidouiller et de comprendre, et si vraiment je galère, le lis les docs. Du coup j'ai installé Svelte (et Sveltekit), avec des exemples de base, j'ai bidouillé et...ce fut un echec cuisant. Je comprenais pas comment marchait l'état, comment il se mettait à jour. Du coup, je me suis plongé dans la documentation et le tutorial, et j'ai essayé de comprendre ce qu'est Svelte. 
*(pour ceux qui préfèrent, voici la version vidéo de cet article)*
{% youtube 5W5i5KhIeaQ %}

# C'est quoi Svelte ?

D'après la documentation, Svelte n'utilise mais de DOM virtuel, mais est un "framework UI qui compile les composants pour en faire du Javascript basique". Contrairement à React ou Vue qui embarquent le framework dans la page. Qu'est-ce que ça veut dire ?

J'ai mis du temps à comprendre ce que ça voulait dire, et à comprendre quels principes soustendent le framework. Il n'y a pas dans Svelte de setState explicite, pas d'endroit où on signale que "ceci est un état", seulement un :
```js
<script>
  let counter = 1;
</script>
```
Et je me disais que quelque part dans ma page ça allait donc donner lieu à un "let counter = 1" quelque part dans la page en sortie. Mais là réalité est bien plus étrange et plus intéressante.  

A un moment en lisant les documents et les vidéos, j'ai eu un "Aha moment", un moment d'illumination. Pourtant tout était effectivement dit dans la phrase "Svelte compile les composants". En réalité, Svelte n'est **PAS un framework**. En tout cas pas en premier lieu, et pas au sens où on l'entend avec React ou Vue. 

Avant tout, Svelte est un **compilateur**. 

Et ce compilateur *triche*. Alors certes de manière très intelligente. Mais il donne l'impression qu'on code du javascript, et ce n’est pas tout à fait vrai. 

Svelte triche en **surchargeant l'opérateur =**, en lui rajoutant un effet de bord. C'est à dire qu'il en fait une fonction, qui met à jour tous les endroits où la variable est utilisée. Puisque de la même façon, Svelte repère en avance dans le HTML, au moment du build, là ou il y a des dépendances envers cette variable. 

Et c'est là que devient intéressant le fait qu'il n'y ait pas de DOM virtuel. React garde en mémoire l’arbre des composant et toutes les variables d’état et les paramètres, et leurs valeurs. A l'étape t, tel composant avait telle classes, et tel style, et telles valeurs, et à l'étape t + 1, il a toujours tel classes, et telles valeurs, mais le style a changé, donc on recalcule les composants qui en dépendent. Chaque itération il faut comparer un à un tous les éléments de l'arbre des composants. ET ça c'est couteux. 

Svelte, à l'inverse, cable directement la variable sur le HTML, avec une fonction, en surchargeant l'opérateur d'affectation =.   

Et Svelte va plus loin, en surchargeant aussi la notion de label, qui est du [Javascript valable mais un peu exotique](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label), pour créer la notion de **dépendance entre variables**. Le nom du label fait référence à la notion d'Observable : $.  Voyons un exemple : 

```html
<script>
  let firstName = 'world';
  let greeting
  $: greeting = 'Hello ' + firstName; 
  firstName = 'Bob';
</script>

<h1> {greeting}!</h1>
```
Ici, le code sort **Hello Bob!**, alors que la ligne avec le $ a lieu avant l'affectation de "Bob" à la variable firstName. Comme si le lien entre greeting et firstName n'était pas juste une relation éphémère mais un lien durable. Un mariage au lieu d'un plan Q, en somme.   

Si on loggue ce qui se passe, on y voit plus clair. Avec un log placé à cet endroit : 

```html
<script>
  let firstName = 'world';
  let greeting
  $: greeting = 'Hello ' + firstName; 
  firstName = 'Bob';
  console.log(greeting);
</script>

<h1> {greeting}!</h1>
```
On a juste un "undefined" dans la console - le code dans le $ n'a pas encore été appelé, apparemment. Mais ce qui est intéressant avec cette notation c'est qu'il est possible d'y mettre un bloc de code 
```html
<script>
  let firstName = 'world';
  let greeting
  $: {
   greeting = 'Hello ' + firstName; 
   console.log(greeting);
  }
  firstName = 'Bob';
  console.log(greeting);
</script>

<h1> {greeting}!</h1>
```

Et dans ce cas on dans la console "undefined", puis "Hello Bob". Ca parait logique. 

Mais ce qui est intéressant c'est qu'on peut mettre *plusieurs* $. Et si on s'amuse à les mettre dans le désordre, avec le console.log *avant* l'affectation à la nouvelle valeur, que se passe-t-il ?

```js
<script>
  let firstName = 'world';
  let greeting
  $: console.log(1, greeting);
  $: {
   greeting = 'Hello ' + firstName; 
   console.log(2, greeting);
  } 
  firstName = 'Bob';
  console.log(3, greeting);
</script>

<h1> {greeting}!</h1>
```
Ici, on pourrait s'attendre (merci React avec l'ordre des hooks) à ce que les $ soient exécutés dans l'ordre où ils sont déclarés. 

Et bien non, pas du tout. Dans la console on voit les logs 3 (avec "undefined"), puis 2 puis 1. Et en réalité Svelte a détecté une sorte de graphe de dépendances. Le block où il y a le log 2 a une dépendance sur firstName, et met à jour la variable greeting. Le blog 3 a une dépendance sur la variable greeting, et est donc exécuté après, une fois que greeting est changé. 

Bon et évidemment comme j'ai l'esprit tordu j'ai tout de suite essayé de faire une dépendance cyclique: 

```js
let firstName = 'world';
let greeting
$: firstName = greeting + 'hum';
$ :greeting = 'Hello ' + firstName; 
firstName = 'Bob';
```
Mais le compilateur l'a détecté et a sorti une erreur, donc tout va bien :D

Pour info, si vous voulez écouter un gars qui explique ça bien mieux que moi, mais en Anglais, voici le créateur de Svelte qui explique les concepts sous jascents que je viens d'exposer : 

{% youtube AdNJ3fydeao %}

Voyons à présent plus en détail le fonctionnement de Svelte, voici quelque points saillants que j'ai notés. Je ne peux évidemment pas expliquer *in extenso* comment coder en Svelte, mais juste sousligner quelques éléments marquants. 

# Comment coder avec Svelte, premier pas

## Les composants 
Les composants sont dans des fichiers .svelte, et ressemblent à une page HTML, avec des balises `<script>`, des balises `<style>` et du code de template HTML :

```html
<script>
  let count = 0;
  function handleClick() {
    count += 1;
  }
</script>

<style>
 button {
  color: red;
 }
</style>

<button on:click={handleClick}>
  Clicked {count} {count === 1 ? 'time' : 'times'}
</button>
```

(Comme vu plus haut, le script qui apparait dans le fichier compilé n'est pas exactement ce qui a dans les balises script). 

On peut inclurer ses composant dans d'autres composants, en utilisant une notation comme celle du JSX: 

```html
<script>
 import OtherComponent from './Component.svelte';
</script>

<OtherComponent />
```
Le style d'un composant n'impacte pas le style des composants qu'il inclut. 

## Props, Etat & Changement d'Etat

L'état est défini dans des blocks, en utilisant comme  :

```html
<script>
 let counter = 0; // ceci déclare un état !
</script>
```

C'est pareil pour les props, c'est à dire les paramètres d'entrée des composants :

```html
<script>
 export let counter = 0; // ceci déclare un props !
</script>
```

Attention: Svelte a besoin **d'immutabilité** pour gérer les changements d'état (ce qui est logique), ou plus exactement, j'ai l'impression qu'il a besoin qu'il y ait l'utilisation de l'opérateur = sur une variable qui a été déclarée avec un let, et que le compilateur sait qu'il doit surveiller. Si on change la valeur d'une des clefs dans un dictionnaire ou un array, le changement n'est pas détecté.    

## Le templating html 

Svelte a une logique de templating dans le html. Il y a comme dans le JSX l'injection de valeurs, (`<p>Value is {x}</p>`), Mais aussi des blocks, qui commencent avec des  `{#}`, finiseent avec des `{/}` et comportent eventuellement des éléments intermédiaires en `{:}` Ces blocks permettent d'écrire des conditions des boucles (`{#each}`)  et des conditions `{#if ...}`), Par exemple :

```html
{#if x > 10}
	<p>{x} is greater than 10</p>
{:else if 5 > x}
	<p>{x} is less than 5</p>
{:else}
	<p>{x} is between 5 and 10</p>
{/if}
```

Dans les boucles, on a le meme probleme de clef unique que la boucle d'objets de react : il faut spécifier l'id de la clef unique: ```{#each items as item (item.id)}```

Il y a un troisième type de block, qui consiste à déclarer qu'on attent le retour d'une fonction asynchrone (une Promise, quoi) avec le bloc `{#await}`.

## Evenements & Bindings

Autre particularité, pour gérer les clicks & co, on définit des event listeners sur les elements html avec des on: on:click, on:mousemove. On peut modifier ces events listeners avec par ex. |once ou |self (ne trigger qu'une seule fois, ne trigger que sur soi). On peut définir des event listeners pour connecter deux éléments, avec un émetteur et un récepteur. Ca me rappelle la joie de coder en ActionScript / Flash, au bon vieux temps des jeux sur Facebook !

On utilise le même genre de notation pour dire qu'un élément HTML (comme un input par exemple) va impacter une variable, ce qui nous permet de faire une liaison à double sens entre l'affichage et l'état : 
```html
<input bind:value={name}>
```
(Je crois que Vue a une notation un peu similaire)

# En conclusion 

Pour être complet il y aurait évidemment tout un tas d'autre choses à mentionner comme les *stores* (au sens anglais, pas français !) ou les transitions ou le *context* (qui pour le coup ressemble un peu à celui de React). 

Pour moi il y a deux questions qui se posent. Est-ce que j'ai envie de continuer à apprendre ce framework ? Et est-ce que j'ai envie de m'en servir sur le plus long terme. 

Et pour moi, c'est l'originalité de Svelte, avec l'impact de la phase de compilation, qui me donne envie de l'apprendre, de comprendre comment il marche. 

Je ne sais par contre pas comment mes équipes, si je leur mettais du Svelte entre les mains, réagiraient. 

C'est quoi Svelte ?

Je me suis donné comme objectif en début d'année d'essayer de voir comment marche Vue. Comme vous le savez peut-être, je suis un fan de NextJS, et dès mes premières recherches sur Vue j'ai vu qu'il y avait un équivalent de NextJS chez Vue, qui s'appelle Nuxt. C'est ce que j'appelle des "méta-framework" (et surement pas que moi d'ailleurs) puisque ce sont des framework qui se construisent par dessus d'autres framework. Je me suis dit qu'un bon point cas d'usage pour apprendre ces méta-framework serait d'essayer de faire un blog. J'ai conscience de 3 méta frameworks principaux, à savoir : NextJS, NuxtJS et Sveltekit, qui est la version dans Svelte. Cependant Sveltekit est encore trop jeune pour que je puisse le recommander même si il a l'air très intéressant, donc on va laisser Sveltekit pour plus tard. 

Aujourd'hui nous allons donc nous poser deux questions :
- **Qu'est-ce que Nuxt**, qu'est-ce qu'apportent les framework fullstack comme Nuxt et Next ? Quels sont les points communs entre Nuxt et Next ?
- Que **vaut Nuxt**, comparé à NextJS, notamment en termes de "DX", d'expérience dévelopeur. Quels sont les différences entre Nuxt et Next ?

## Qu'est-ce que Nuxt ? (les points communs) 

Nuxt est l'équivalent de Next, dans le monde de Vue. Une fois qu'on a dit ça, on à à la fois rien dit et tout dit. 

Comme vous le savez peut-être, le principal intérêt des frameworks de type Vue ou React c'est qu'ils permettent d'implémenter côté client une partie de la **logique et de la navigation traditionnellement été réalisés côté serveur**. 

Ca a pour avantage de permettre une **ergonomie plus fluide**, mais ça a pour inconvénient que ça demande du coup un effort au navigateur pour interpréter le contenu qu'on lui envoie, puisqu'il faut télécharger et interpréter le Javascript en plus d'afficher le HTML qu'on lui fournir. En termes d'optimisation pour les moteurs de recherche, un React "de base" marche moins bien que des technologies côté serveur. 

La solution qu'implémentent Nuxt et Next (et je crois, Sveltekit) consiste à faire du **rendu JavaScript côté serveur** (ou SSR: server-side rendering), pour faciliter la tache au "crawler" de Google. En plus de lui cela, ce système permet aussi de gérer et générer les méta-datas pour chaque page (le title, la meta-description etc.) ce qui permet 

Cette solution permet aussi, dans le cas où il n'y a pas de données dynamiques, à faire des rendus de page statiques, c'est à dire qui peuvent être hébergés sur une solution de type S3 qui se contente juste d'envoyer des fichiers sans avoir de code qui tourne. 

Les framework fullstack comme Next comme Nuxt fonctionnent en deux phases. Dans première phase, le serveur génère une première version de la page qui contient toute la structure HTML de la page, ainsi que du code javascript qui permet de la rendre interactive après coup, après qu'elle soit affichée. 

Ainsi on a une page qui s'affiche rapidement mais qui devient interactive par la suite. Ce fonctionnement optimise donc à la fois le référencement et l'expérience utilisateur, et permet d'avoir des méta-datas optimisés pour les moteurs de recherche. De plus, il permet de créer des fichiers statiques qui permettent d'avoir des coûts d'hébergement qui sont plus faibles, et tout un tas de choses comme ça qui sont appréciables comme l'AMP, ce genre de choses. Et c'est pour ça qu'existent ces framework fullstack. A mon sens, ils représentent l'avenir du développement, notamment en raison de l'amélioration qu'ils apportent à l'expérience développeur:  les changements apparaissent tout de suite à l'écran, sans avoir besoin de rafraîchir manuellement. 

## Quelles sont les particularités de Nuxt en termes de DX ?
Pour comparer ces deux frameworks j'ai choisi un angle un peu particulier, un cas pratique : le développement d'un blog. Comment est-ce qu'on peut comparer Next et Nuxt sous l'angle de l'expérience développeur. J'ai comparé les deux solutions sur trois étapes du développement. 1. Premièrement, l'installation : que se passe-t-il quand on installe, quel est l'expérience de l'installation ? 2. Deuxièmement, la création de la page index, et la récupération du contenu. 3. Troisièmement, la création d'une page d'u article

### L'installation
A l'installation, Nuxt propose plus d'options. Avec Next, il y a besoin d'installer les pièces supplémentaires par la suite, là où Nuxt propose directement d'installer Typescript, ou des frameworks CSS comme Bootstrap, Bulma, Tailwind et d'autres encore. De la même façon, Nuxt prend en charge l'installation de mécanismes de test (et propose différentes solutions) ou de lint. 
Nuxt me tient par la main : tout est déjà préparé. Il n'y a pas besoin de fouiller sur internet pour trouver des informations de pertinence et de fraicheur douteuses, et qui proposent des manipulations fastidieuses. De ce fait, l'expérience développeur est meilleure à l'installation sur Nuxt. 

### La recherche de contenu (création de la page index) 
Nuxt dispose d'un accesseur particulier ($content) qui permet de gérer directement le contenu, et ce grâce à une syntaxe ostensiblement de celle de MongoDB. La librairie permet de chercher directement du contenu avec des filtres, des tris, ou en sélectionnant qui sont juste après ou juste avant. Tout cela rend la gestion du contenu beaucoup plus facile et que ce que nous avons dans Next, où il faut coder l'accès au contenu soi-même. Sur ce point la Nuxt est devant. 

### Création d'une page d'un article
Comme le fait Next, le routage (l'association d'une url et d'un contenu) se fait en fonction des noms de fichiers sur le disque dur. La mise en page se fait de manière très similaire dans les deux solution. Deux choses particulières sont à souligner. Première chose: Nuxt s'installe un testeur Tailwind qui permet de voir directement quels sont les styles qui ont été activés par la configuration sur cette page. C'est très agréable de ne pas avoir à combiner mentalement la documentation de tailwind et les modifications spécifiques dans le fichier de configuration : On a directement le résultat dans un testeur. La deuxième différence sympathique : Nuxt propose un éditeur intégré pour modifier à la volée le contenu texte. Nul besoin d'aller chercher dans le code source, l'opération est directe et facile. Ici aussi Nuxt propose une meilleure expérience développeur
## Les à côtés
De manière générale la documentation de Nuxt est très bien faite et propose beaucoup d'exemples. Il y a notamment l'exemple de comment utiliser Typography de Tailwind, un plugin de Tailwind qui permet de faire une mise en page d'article de blog déjà bien configurée. 

## Conclusions... que choisir ?
Sur les trois points, Nuxt a été devant. Si je partais de zéro, si je maitrisais autant Vue que React, je choisirai Nuxt. Seulement ce n'est pas le cas, je suis déjà bien familier avec Next et React, et je ne maitrise pas Vue (qui ressemble trop à Angular pour attiser mon appétit d'apprentissage). J'espère juste que Nuxt va inspirer les développeurs de Next, que les deux solutions vont s'inspirer mutuellement. 


Pourquoi utiliser Nuxt ? Que vaut Nuxt vs. Next ?


Angular ou React.js : Lequel est-il préférable d'apprendre ? Laquelle est la meilleure à utiliser pour un projet ? Et surtout, quelles sont les différences structurelles et fondamentales entre ces deux solutions ?
Je travaille avec Angular depuis 2016 et avec React depuis 2019 (et par Angular, j'entends Angular 2 et plus, pas AngularJs). Et pour moi, bien que les deux servent un objectif similaire, ils se sentent radicalement différents à coder avec.

Le premier point à souligner est qu'Angular est utilisé sur Gmail et sur les produits Google en général, sur Microsoft Office Online, sur UpWork, sur Sony et sur Forbes. Alors que React est utilisé chez Facebook, Instagram, Netflix, Dropbox et Uber. Donc Angular et React sont tous deux des solutions matures avec de solides références. Cependant, ces noms racontent l'histoire de deux mondes très différents et donnent un premier indice sur la différence sous-jacente entre les deux solutions.

## Une différence de philosophie incarnée visuellement

Les logos racontent une histoire similaire. Le logo d'Angular est un bouclier, symbole de solidité et de sécurité. En revanche, le logo de React est un atome. Si vous combinez la sémantique de React et un atome, vous obtenez une explosion, une réaction atomique. Le contraire de la sécurité.
Les énoncés de mission internes de ces deux entreprises montrent la même opposition. Google, où Angular a été créé, vise à "Ne pas faire de mal". Facebook, berceau de React, veut "Move fast and break things". Alors que Google semble très respectueux de la loi, la devise interne de Facebook dégage une atmosphère rebelle de mauvais garçon. Leurs deux solutions (Angular et React) incarnent ces deux mentalités. Et les entreprises qui utilisent ces deux solutions reflètent cet état d'esprit : les entreprises solides et sensées sont vantées du côté d'Angular tandis que les champions de React sont disruptifs. Si vous deviez traduire cela en termes de jeu de rôle, Angular aurait un alignement Lawful Good et React un alignement Chaotic Neutral.

## Quelle structure ?
En termes de structure interne, la même opposition s'applique : il n'y a pas de structure préimposée du côté de React. Dans Angular, il existe une convention de codage et de nommage dérivée du modèle MVC (model view controller). La structure du système de fichiers reflète cela, chaque module a un dossier, dans les dossiers des modules, on a des dossiers pour chaque composant. Et tout cela doit être respecté pour que l'application compile.
React n'a pas de structure MVC, juste des fonctions qui rendent le code directement (du moins si nous utilisons des composants fonctionnels). La manière de structurer le code et le système de fichiers est laissée fermement à la discrétion du développeur.

## L'impact pratique

En quoi Angular et React sont-ils différents en pratique ? D'après mon expérience, les différences de structure conduisent à des composants plus gros et de plus grande portée dans Angular, alors que React est propice à des composants plus ciblés. La réutilisation des composants est également plus complexe dans Angular, alors que le faire dans React demande un effort minimal.
Angular étant un framework à part entière avec un champ d'application plus large (il fournit plus de fonctionnalités d'emblée, comme le routage, l'internationalisation ou la gestion bidirectionnelle de l'état) et une structure prédéfinie, sa courbe d'apprentissage est plus raide.
React, en revanche, est une bibliothèque ciblée, avec moins de structure et moins de portée, ce qui facilite l'apprentissage car il y a moins de choses à apprendre, du moins au début. Vous pouvez couvrir les principaux concepts en un après-midi. Cette focalisation unique est également ce qui lui confère une plus grande flexibilité.
Angular offre sécurité et structure, alors que React offre agilité et rapidité.

## En conclusion : Lequel dois-je recommander ?
Pour commencer, je recommande d'apprendre JavaScript et Typescript avant d'apprendre l'un ou l'autre. Une fois que c'est fait, si vous le pouvez, apprenez les deux. Si ce n'est pas le cas, ma recommandation dépendrait de vos traits de personnalité, de votre aversion au risque et du degré de structure dont vous avez besoin. Si vous avez besoin que les choses soient standardisées et sécurisées, je conseillerais Angular. Si vous avez besoin d'action et de flexibilité, je recommanderais React. Si vous souhaitez une carrière de développeur dans le secteur bancaire ou un environnement de travail stable, privilégiez Angular. Si vous préférez travailler plutôt dans une start-up où tout bouge dans tous les sens, je recommande React. Les deux sont de bons choix, mais vous seul pouvez répondre à celui qui correspond le mieux à l'endroit où vous voulez aller.

Angular vs React : lequel choisir ?

Le site de blog Medium a beaucoup de qualités. J’adore l'ergonomie de son interface d'écriture. Malheureusement le site n'est pas fait pour du contenu francophone. J’ai un blog anglophone sur Medium, mais pas de blog francophone. Je me dis que c’est l’occasion de tester des framework de génération de site statique que je ne connaissais pas, pour voir s'il y a mieux que Next.Js (que je considère meilleur que Gatsby, j'expliquerai pourquoi dans un autre article). 

**Pourquoi un blog ?** Pour plusieurs raisons : c'est un cas d'usage "de la vraie vie", qui est à la fois concrêt et tout de même relativement simple (plus simple en tout cas qu'un jeu vidéo ou qu'un site de vente en ligne). Précisons tout de meme tout de suite que je n'ai aucune idée si je vais maintenir le blog en question une fois mon choix fait, c'est un autre débat :D

## Comment choisir ?

Dans un framework, je voudrais pouvoir :
* avoir du **contenu dynamique** : écrire des articles en markdown, les lister automatiquement dans une page index et les injecter dans une page blog générique
* générer des **pages statique, et les héberger sur S3**, et s'il y a besoin de logique serveur fonctionner en serverless
* utiliser [Tailwind](https://tailwindcss.com), qui est mon framework CSS préféré en ce moment
* inclure des videos YouTube 
* afficher du code, évidemment, il faut pouvoir faire un...

```js
console.log('hello world');
```


Idéalement j'aimerais pouvoir en profiter pour mieux comprendre un framework que je ne connais pas encore. A première vue j'ai deux choix, qui sont des équivalents de Next: *Nuxt.JS*, sur la base de Vue 3, ou *Sveltekit*, sur la base de Svelte. 
J'ai donc suivi les guides de démarrage de ces deux framework pour (éventuellement) en choisir un. 
Avec bien sur l'option de rester sur NextJS si aucun des deux ne me convainc, évidemment !

Mes critères de choix prendront principalement en compte :
* la facilité d'apprentissage et d'arriver à mes fins
* la documentation
* le "DX", c'est-à-dire l'expérience développeur

Du peu que j'en ai lu, Vue a été crée par un certain Evan You qui avait travaillé sur Angular JS. Même si Angular 2+ n'a pas grand chose à voir avec Angular JS, j'ai l'impression que Svelte utilise des concepts complètement différents de ce que je connais déjà (à savoir React et Angular, côté framework côté client), donc je vais commencer avec Svelte et Sveltekit 

(Ah oui, petit détail, au cas où ce ne serait pas évident : j'utilise cet article - pendant que je suis en train de l'écrire en Markdown - comme contenu initial pour tester les deux systèmes de blog).

Un petit point de détail : je ne connais aucun des deux framework, c'est vraiement juste une première impression. Et les premières impressions peuvent être erronées. Donc si je me trompe n'hésitez pas à me le signaler !

Sur ce, c'est parti pour la découverte de SvelteKit


Premier pas avec SvelteKit 
=========================

Pour commencer une appli Sveltkit, il faut faire :

```cli
npm init svelte@next mon-appli
```

Quand je lance la commande, on me propose plusieurs choix : de créer un projet vide ou une démo, d'utiliser Typescript, d'utiliser ESLint, d'utiliser Prettier. Je dis oui à tout. La démo est relativement sommaire : un compteur, une liste de todos, et un lien vers la documentation.

La doc de Svelte est intéressante mais je sais pas toujours si ce qu'elle dit est valable dans SvelteKit. Elle parle de rollup et webpack mais pas vite, qui est utilisé (si j'ai bien compris) dans SvelteKit.

Voici Les premières choses qu'on nous dit dans la doc de SvelteKit : 

SvelteKit n'est pas encore en version stable, il pourrait y avoir des changements avant la version 1.

Sveltekit repose sur Svelte qui est un "framework UI qui compile les composants pour en faire du Javascript basique".

Sveltekit ne suppose pas l'existence d'un serveur contrairement à Sapper (qui était l'itération précédente du concept), il utilise des "adaptateurs" qui permettent de faire tourner dans différents *contextes* (sur un serveur, en statique, en serverless, ...)

Contraiement à Next, les routes API ne sont pas isolées dans un dossier `api/` mais regroupées par feature" avec les fichiers qui servent à faire la présentation (les fichiers .svelte, si j'ai bien compris). D'ailleurs les fichiers correspondants ne sont pas dans un dossier `pages/` mais dans un dossier `routes/`

Comme Next, le chemin du fichier se traduit en URL, donc le fichier /route/contact.svelte va être rendu sur la route /contact. Par ailleurs comme sur Next il y a la possibilité de faire des routes dynamiques, de telle sorte que /route/blog/[slug].svelte permette de rendre toutes les routes de type /blog/titre-article (ou titre-article est le titre de l'article)

Il y a aussi la possibilité de rendre directement des fichiers Markdown, par contre je n'arrive pas à trouver comment appliquer un style à ces fichiers, ni à en récupérer dynamiquement la liste. J'imagine qu'il faut faire une manipulation similaire à celle de next, où on utilise la librairie fs (qui lit dans le filesysteme) pour faire la liste des fichiers dans un dossier, mais la doc n'est pas très claire là dessus (pour le moment en tout cas). 

SvelteKit introduit d'ailleurs la notion de adders, en utilisant une commande "npx-apply" qui va rechercher du contenu dans un repos git (et non sur NPM) et peut-être même l'exécuter (ou exécuter un script qui modifie ou crée des fichiers de configuration, c'est pas encore très clair pour moi)

Parmis ces adders il y a Tailwind, 


D'autres points que j'ai glanés dans la documentation ou dans mes recherches :
*  Apparemment SvelteKit ne marche pas bien avec Yarn.
* Ce lien est aussi utile que les docs : https://sk-incognito.vercel.app/learn/what-is-sveltekit
* Parmis ces adders

Adders : "npx apply svelte-add/tailwindcss  - This is a community experiment to add integrations! `npx apply` uses GitHub repositories, not NPM. You can check out the list of adders"



Le choix d'un framework de blog



Je commence par installer Next.JS. 
```cli
npx create-next-app nextjs-blog
```

Je crée un fichier tsconfig.json pour indiquer qu'on veut etre sous Typescript (et j'installe directement Typescript)

```cli
touch tsconfig.json
yarn add --dev typescript @types/react
```

Ensuite c'est parti pour installer et initialiser Tailwind :
```cli
npm install -D tailwindcss@latest postcss@latest autoprefixer@latest
npx tailwindcss init -p
```

Puis j'édite le fichier globals.css pour inclure les fichiers de style de Tailwind.

```css
/* ./styles/globals.css */
@tailwind base;
@tailwind components;
@tailwind utilities;
```


J'aime bien changer les fichier index.js et app.js en .tsx (mais ça ne change pas grand chose)

Maintenant que la base est posée, posons les bases de notre blog.

La première étape consiste à définir le type de l'article de blog, au sens Typescript. 
Pour cela je crée un dossier shared/, à la racine, dans lequel je met un fichier types.d.ts qui va servir à contenir les différents types. Je vais supposer qu'on veut charger d'autres types de données que juste des articles de blog (mais je ne sais pas encore quoi à ce stade, donc j'en fais peut etre un peu trop). Néanmoins je crée un type de base pour mon contenu, que je spécialise pour l'article de blog.


```ts
interface item {
  id: string|number;
  content: string;
};

interface BlogPost extends item {
  title: string;
}
```

A présent je crée la page d'accueil du blog, en créant un fichier index.tsx, dans un dossier blog/ que je crée dans /pages. Ce fichier va servir à lister tous les articles de blog (quand il y en aura !)


```tsx
// pages/blog/index.tsx

interface BlogPagesProps {
  blogs: Array<BlogPost>
}

const BlogPages:React.FC<BlogPagesProps> = ({blog}) => {
  return <>Blog Posts</>
}
export default BlogPages;
```

A présent, allons chercher le contenu que nous allons lister. Pour ça, je commence par créer un dossier content, dans le quel je mets pour le moment un dossier blog/ (une fois de plus, ça suppose que j'ai d'autre contenu)

Comment est-ce que ça fonctionne ? Dans une page on peut définir une fonction getStaticProps. Cette fonction sert pour le rendu côté serveur. Elle sert à récupérer toutes les données statiques qui utiles pour rendre la page. Typiquement si on voulait faire un appel à une base de données pour lister le contenu pertinent, c'est ici qu'on le ferait. Dans notre cas, nous allons lister tous les fichiers markdown (en .md) qui sont dans le dossier content/blog, et c'est ça qui nous servira de contenu. 

Le nom de fichier servira d'identifiant (de champ id), mais on veut pouvoir aussi définir un titre, qui servira dans la liste sur l'accueil du blog.  

Un petit détail qui est sympa avec Markdown : on peut définir des (méta)données en entête, et les lire. Ca s'appelle le *front matter*. C'est typiquement avec ça qu'on va pouvoir dire qui est l'auteur, ou quelle est l'image qu'on veut mettre en avant. 

Une lib existe pour les lire : gray-matter

Ajouter gray-matter : yarn add gray-matter

Créer les fonction de récupération des données :


On va créer une fonction de récupération générique, qui lit un dossier et qui retourne bah.. un type de contenu.

On va commencer par lister et lire tous les fichiers md qui sont dans un dossier donné:

```ts
async function _getAllData<T extends item>(directory: string): Promise<Array<T>> {
  // Get file names under folder
  const fileNames = fs.readdirSync(directory);
  return await Promise.all (fileNames.map(async fileName => {
    // Remove ".md" from file name to get id
    const id = fileName.replace(/\.md$/, '');

    // Read markdown file as string
    const fullPath = path.join(directory, fileName);
    const fileContents = fs.readFileSync(fullPath, 'utf8');

    // Use gray-matter to parse the post metadata section
    const matterResult = matter(fileContents);

    let content = matterResult.content;

    return {
      id,
      ...matterResult.data,
      content,
    } as unknown as T;
  }));

}
```

Alors je crée une fonction "factory", qui me fabrique la fonction en fonction du répertoire injecté :

```tsx
export function makeGetters<T extends item> (directory: string) {

  return {
    getAllData: async () => _getAllData<T>(directory),
  };
}
```
En suite on crée la version spécifique pour le blog :

On crée un fichier /shares/blog.ts tout simple 

```ts
import path from 'path';
import { makeGetters } from './content';

const directory = path.join(process.cwd(), 'content/blog');

export default makeGetters<BlogPost>(directory);
```

Maintenant on référence cette page dans l'index du blog

```tsx
import BlogData from '../../shared/blog';

export async function getStaticProps() {
  const blogs = await BlogData.getAllData();

  return {
    props: {
      blogs,
    }
  };
}

interface BlogPagesProps {
  blogs: Array<BlogPost>
}

const BlogPages:React.FC<BlogPagesProps> = ({blogs}) => {
  return <><h1>Blog Posts</h1>
    {blogs.map((itm) => {
      return <><a key={itm.id}>{itm.title}</a><br/></>
    })}
  
  </>
}


```

Et on teste : wundershön 


Et du coup maintenant on va aller créer la page qui va servir à faire les articles de blog eux mêmes 

Pour ça on crée un fichier [id].tsx dans le dossier pages/blog

En suite on fait la fonction qui récupère les données statiques en fonction de l'id

Autrement dit cette fois ci au lieu de récupérer tous les fichiers on récupère le seul fichier dont l'id est dans le slug, le chemin.


```ts
async function _getItemData<T extends item> (directory: string, id: string, extended?: boolean): Promise<T> {

  const fullPath = path.join(directory, `${id}.md`);
  const fileContents = fs.readFileSync(fullPath, 'utf8');

  // Use gray-matter to parse the post metadata section
  const matterResult = matter(fileContents);
  let content = matterResult.content;

  return {
    id,
    ...matterResult.data,
    content,
  } as unknown as T;
}

/* *** */

export function makeGetters<T extends item> (directory: string) {

  return {
    getItemData: async (id: string) => _getItemData<T>(directory, id),
    getAllData: async () => _getAllData<T>(directory),
  };

}
```

Ensuite on définit dans types un paramètre

```ts
interface StaticRouteProps {
  params: {
    id: string;
  };
}
```

Et on crée le get static props de la page :

```tsx

interface PageProps {
  data: BlogPost;
}

export async function getStaticProps({params}:StaticRouteProps) {
  const data = await BlogData.getItemData(params.id);
  return {
    props: {
      data,
    }
  };
}

```

Ici il y a une petite particularité. Dans la mesure ou c'est un chemin dynamique, on a besoin de savoir quels sont tous les contenus qu'il faut générer. Pour ça on a une fontion "getStaticPaths" qui en gros liste tous les contenus

On retourne du coup dans content :

```ts
const _getAllIds = (directory: string) => {
  const fileNames = fs.readdirSync(directory);

  return fileNames.map(fileName => {
    return {
      params: {
        id: fileName.replace(/\.md$/, '')
      }
    };
  });
};

/***/

export function makeGetters<T extends item> (directory: string) {

  return {
    getAllIds: () => _getAllIds(directory),
    getItemData: async (id: string) => _getItemData<T>(directory, id),
    getAllData: async () => _getAllData<T>(directory),
  };

}
```

A présent dans le blog on définit la fonction getStaticPaths 

```ts
export async function getStaticPaths() {
  const paths = BlogData.getAllIds();
  return {
    paths,
    fallback: false
  };
}
```

A présent tout est prêt pour faire la page :

On commence par importer Head, tout en haut : 
```ts
import Head from 'next/head';
```

Puis on crée la fin de la page :

```tsx
interface BlogPageProps {
  data: BlogPost;
}

const BlogPage: React.FC<BlogPageProps> = ({data}) => {

  return <>
    <Head> <title> {data.title} </title></Head>
    <main>
      <h1>{data.title}</h1>
      <div>
        {data.content}
      </div>
    </main>
  </>;
};

export default BlogPage;
```

Maintenant... il ne reste plus qu'à y accéder !

Mettons à jour la page index du blog :

```tsx
const BlogPages:React.FC<BlogPagesProps> = ({blogs}) => {
  return <><h1>Blog Posts</h1>
    {blogs.map((itm) => {
      return <><a key={itm.id} href={'/blog/'+itm.id}>{itm.title}</a><br/></>
    })}
  
  </>
}
```


On teste et ... c'est très moche.

On va essayer d'améliorer ça un peu avec tailwind 

1/ On rajoute le typography :
yarn add @tailwindcss/typography


Tuto Next.JS + Tailwind : créer un blog

Tutorial Next.JS +  : Effet de Zoom style medium sur l'image principale

Photo by <a href="https://unsplash.com/@cytonn_photography?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Cytonn Photography</a> on <a href="https://unsplash.com/s/photos/hiring?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>
  

  

Le Blog