Passons aux SPA avec Vue Router - Introduction - Javascript

Salut Arthur ! Dans la suite logique de ton apprentissage de Vue.JS 3, maintenant que tu maitrises les bases ainsi que les composants, nous avons encore quelques points à aborder.

Salut ! Lesquels ? Mon but maintenant est de faire une SPA, une Single Page Application.
Justement, dans ce cadre, nous devons absolument voir l'utilisation de Vue Router. Nous en sommes à la version 4 (vue router 4). Il serait aussi intéressant de regarder l'API de composition, mais nous la verrons dans un second temps.

Petit rappel de ce qu'est une SPA dans un premier temps : il s'agit d'une application web qui n'a qu'une seule vraie page (qu'on va appeler point d'entrée) et qui gère côté front (côté client donc) le passage d'une page à une autre. Il n'y a donc pas de "rafraichissements" de page, on a l'impression de ne jamais changer de page :).
Les avantages d'une SPA, qui sont de plus en plus nombreux au fil des années car les technologies évoluent, sont, entre autre :
- Un temps de développement plus rapide car on se concentre sur HTML/CSS/JS
- Un chargement de l'application plus rapide qu'avec une application classique. En effet, il suffit simplement de charger des assets (HTML/CSS/JS) une fois, lors de la première visite de l'internaute. Après, ils sont mis en cache ;).
- Il est plus rapide de faire une application mobile. En effet, avec une SPA, le back sera le même pour l'application web et pour l'application mobile.

Néanmoins, il faut savoir qu'il y a encore quelques désagréments à utiliser les SPAs. Notamment, il faut absolument que Javascript soit activé sur le navigateur du client (mais il y a des techniques, comme le SSR, qui évitent ce problème). Si une SPA est mal codée, elle est plus sensible aux failles XSS, car la surface d'attaque est plus grande (beaucoup plus de javascript). Et enfin, une SPA mal codée a de lourdes conséquences quant au référencement naturel du site (par exemple, des URLs pas très user friendly, un code excessivement lourd, une ergonomie qui n'est pas adaptée...).

C'est intéressant, je ne savais pas tout ça !
En bref, une SPA c'est chouette, c'est moderne, mais il faut que cela réponde aux besoins du projet sur lequel tu travailles ! Compris ?

C'est compris ;). Du coup, pour voir les SPAs, il faut qu'on attaque Vue Routeur ?
C'est cela. Vue Routeur est développé par l'équipe de Vue.JS et permet d'associer à chaque URL un composant.

Mais je croyais qu'on ne changeait jamais vraiment de page, qu'il n'y avait pas de rechargement ?
C'est le cas. Mais l'URL change quand même ;). Si par exemple, l'URL indique "index" sur ton site, alors on peut imaginer qu'il y a derrière à afficher le composant "Index". Comme suit :



Et si, dans le composant Index, il y a un lien vers une autre page de ton site, cela signifie en réalité que :

• Le lien est de la forme http://monsite.com/nom_de_la_page


• Vue Routeur sait qu'à l'URL qui se termine par nom_de_la_page (on va appeler ça l'action), il faut associer le composant NomDeLaPage


• Vue Routeur intercepte le fait que l'URL change au clic sur le lien, et donc remplace le composant Index par NomDeLaPage


• Il n'y a donc pas de rafraichissement de la page dans le navigateur, tout a été fait sur une seule et même page, même si l'URL a bien changé ;)

Ah super, je comprends mieux !
Parfait. Qui dit Routeur dit plusieurs problématiques à aborder... Évidemment, d'abord, l'association entre une action et un composant. Cette association s'appelle la route. Ensuite, que se passe-t-il dans le cas où une route n'existe pas ? Autrement dit, s'il y a une action qui n'a pas de composant associé. Et, dans le cas où nous avons un espace d'administration, comment limiter les routes d'administration aux administrateurs ? Comment passer d'un composant à un autre (en changeant d'URL et d'action donc) de manière fluide et personnalisable ?
Toutes ces questions vont être abordées dans ce cours ;).

Comme toujours dans cette série de cours sur Vue.JS, nous allons partir d'une situation concrète qui sera le fil rouge de notre parcours d'apprentissage. Et au vu du nombre d'informations que nous entendons à longueur de journée concernant les actualités, j'ai pensé intéressant de réaliser un site qui récupère les dernières news françaises et qui permet aux gens de les commenter pour sourcer les informations citées dans ladite actualité. Pour ça, nous utiliserons l'API gratuite Mediastack. Je tiens à préciser que nous n'avons aucune affiliation avec Mediastack pour la réalisation de ce tutoriel ;).

C'est compris, ça m'a l'air super intéressant !
Merci ;).

Installation

Nous devons donc dans un premier temps générer un nouveau projet Vue. Pour ce, j'utilise vue-cli.


Il te sera demandé de choisir d'utiliser ou non le mode historique pour le router (Use history mode for router? (Requires proper server setup for index fallback in production). Si tu choisis Yes ("Y"), alors tu utiliseras le mode "classique" et recommandé. Tu auras alors le code présenté dans la suite de ce cours. Si tu choisis No ("n"), cela signifie que ce sera le mode "hash" utilisé. Ce mode est préconisé uniquement dans le cas où tu n'utilises pas de serveur web pour rendre ton application et/ou que le SEO n'est pas une de tes priorités pour ce projet.
Pour information, l'history mode est indispensable au fonctionnement de ta SPA. Avec le mode hash, un "hash" sera utilisé pour simuler chaque URL. Ainsi, la page ne sera jamais vraiment rechargée (d'où le fait qu'il n'y a pas besoin de serveur web ;)). Dans le cas où tu utilises le mode classique recommandé, tu pourras avoir des URL qui ont forme explicite car un serveur web est capable de les traiter.

Pour utiliser l'API de Mediastack, il nous faut une clé API. Pour l'obtenir, il faut s'inscrire (https://mediastack.com/). Si tu ne désires pas t'inscrire, sache que tu peux tout de même réaliser ce tutoriel avec une autre API de ton choix. Tu peux également, pour plus de simplicité, faire un fichier JSON contenant une liste d'actualités fixe ;).

C'est entendu. Ensuite, je fais quoi ?
On va travailler de manière propre. Étant donné qu'on aura des données de configuration (la clé API et l'URL de base pour les appels API), le mieux est d'avoir un fichier .env. Ce fichier, très courant dans les projets web, permet de renseigner des couples de clé/valeur qui dépendent de chaque projet. Le fichier est à la racine du projet et on le met dans le .gitignore de telle sorte qu'il n'apparaisse pas dans un repository public. En effet, vu qu'il contient des données sensibles, c'est mieux de le garder pour soi et de ne pas le publier partout !

Mais pour lire un fichier .env, il faut que j'installe quelque chose ?
Avec vue-cli 3, une solution de lecture des .env est déjà implémentée ;). Si tu n'utilises pas vue-cli 3, il faut alors installer avec npm (ou yarn) la librairie dotenv.

Voici le fichier .env que j'ai créé :


Il faut évidemment remplacer "VotreClé" par la clé API fournie après inscription sur Mediastack.

Pourquoi toutes les clés commencent par VUE_APP_ ?
C'est la convention lorsqu'on utilise vue-cli 3 et les .env ;). C'est pour éviter de publier des clés privées partout, une protection de vue-cli ;). Pour plus d'infos : https://cli.vuejs.org/guide/mode-and-env.html#modes

Ensuite, pour éviter que nos données sensibles se retrouvent sur GitHub, gitlab ou autre repository public, il faut rajouter le .env dans le .gitignore.
Ainsi, le fichier ressemble à ça :

Et voilà ! On peut faire notre premier git add / git commit ;).



Mais attends, tu es en train de me dire que du coup, je ne peux consommer aucune API côté front dès que je dois passer une clé secrète dans l'appel ?
On sort un peu du cadre du cours, mais dans la pratique, c'est ça. Sauf quand les APIs sont sécurisées avec d'autres protections que la simple clé secrète. Ces protections peuvent être, non exhaustivement :
- Une vérification de l'origine de l'appel par exemple
- Par des protocoles comme OAUTH (le plus courant)

Ok, je comprends mieux...
Du coup, on peut passer à la suite : nous allons créer nos premières routes ;).



J'ai terminé cette partie