R3.01 - dev. web - côté client (vuejs)

Préambule

• L'objectif de Vuejs est de prendre en charge l'affichage et le rafraîchissement automatique d'éléments d'une page HTML quand la valeur de variables JS change.
• Pour cela, vuejs met en place des mécanismes d'observation de ces variables et déclenche la mise à jour du DOM quand leur valeur change.
• Les valeurs de ces variables peuvent aussi bien venir d'un script JS qui est chargé localement dans le navigateur, que de requêtes à un serveur qui va répondre au navigateur avec par exemple des données au format JSON.
• Le principe de création d'une application Web avec vuejs repose donc clairement sur le principe de séparation strict entre la visualisation des données et le contrôle des actions utilisateur, qui est entièrement géré par le navigateur, et la fourniture des données qui est gérée par des serveurs.
• Dans cette optique, les serveurs ne génèrent aucun code HTML, comme c'est le cas avec un serveur Web qui interprète du PHP pour produire du HTML.
• Avec vuejs, le serveur Web se contente d'envoyer au navigateur un unique fichier html, des scripts JS, du css. Cet ensemble de fichiers peut être entièrement écrit "à la main", ou bien partiellement généré grâce à un environnement de développement tel que vue-cli.
• Contrairement à l'approche php, les scripts JS exécutés par la navigateur contiennent toute la logique de fonctionnement de l'application Web.
• Quand des données externes sont nécessaires, les scripts JS peuvent aller les récupérer avec une requête asynchrone au serveur qui les héberge. Le navigateur n'a donc pas besoin de demander au serveur Web une autre page.
• Cette approche est la même que pour une application client/serveur basée sur des sockets.
• Son énorme avantage est de pouvoir développer la partie front-end (navigateur) et le back-end (serveurs) en parallèle.
• La seule chose qui doit être réglée avant est de spécifier le format des requêtes et des données échangées entre le navigateur et les serveurs.

 

• Pour créer et tester une application vuejs, il suffit d'avoir à sa disposition un éditeur de texte et un navigateur.
• En effet, il n'y a pas spécialement besoin d'héberger les fichiers créés sur un serveur Web, à part quand on passe en phase de déploiement/production.
• Un exemple est donné ci-après.
• Pour autant, en milieu professionnel, la création d'applications web de type SPA (Single Page Application) avec Vuejs ne se fait pas en codant tout "à la main".
• En effet, vuejs repose sur la définition de composants. Un composant contient généralement une partie décrivant son aspect visuel (HTML) et une autre partie décrivant son aspect fonctionnel (en JS).
• Or, écrire des composants et les assembler sans passer par un environnement de dev. tel que vue-cli est relativement verbeux et fastidieux.
• C'est pourquoi on passe par des environnements pour se faciliter la tâche.
• Premièrement, vue-cli comporte des outils permettant de créer une application web à partir de fichiers dont la syntaxe n'est pas du pur javascript. Il y a donc des logiciels associés à vue-cli permettant de faire la traduction en pur js.
• L'organisation du code de l'application est modulaire, à savoir qu'un fichier constitue un module qui va "exporter" des variables/fonctions que d'autres fichiers (donc modules) vont pouvoir importer pour les manipuler. En terme de résultat, c'est un peu similaire au include du php.
• Deuxièmement, vue-cli est un gestionnaire de projet :
  • on peut créer facilement un arborescence basique d'application,
  • on peut ajouter des modules/plugins au projet,
  • on peut tester rapidement l'application,
  • on peut créer (et tester) une version de production, prête à être déployée sur un serveur Web.
  • etc.
• Enfin, vue-cli permet de profiter de composants écrits par d'autres développeurs. En effet, ces composants suivent la syntaxe particulière mentionnée ci-dessus et qui sera décrite plus loin.

 

1°/ installation des outils (node - npm - vue-cli - serve)

 

• cette partie est disponible librement sur le serveur dans un article séparé, pour que les étudiants puissent faire la manipulation en TP (ou chez eux)

 

2°/ hello world en Vuejs "pur"

 

2.1°/ organisation et structuration basique des fichiers.

• Même si l'on utilise pas vue-cli, il convient de structurer son application en séparant le code dans différents fichiers.
• Il faut donc au moins créer :
  • un fichier html représentant la page principale de l'application SPA (i.e. dans un modèle MVC : la partie vue)
  • un fichier js permettant de mettre en place la "mécanique" de vuejs, c.a.d. créer l'instance de la classe Vue, de la raccrocher à un des éléments de la page html, et ensuite de réagir à des interactions de l'utilisateur (i.e. dans un modèle MVC : la partie contrôle).
• Il est également conseillé de créer :
  • un ou plusieurs fichier js contenant les données gérées par l'application (i.e. dans MVC : le "modèle")
  • un ou plusieurs fichier js décrivant les composants nécessaires pour créer l'application. NB : un tel fichier décrit les trois parties modèle, vue contrôle du composant.
• Pour l'exemple ci-dessous, il n'y pas de composants, juste le fichier HTML, le modèle et la partie contrôle.

Exemple  (sources à télécharger [ ici ]) :

• le fichier modèle de données : model.js

var messages = [
  {lang:"fr", text: "bonjour le monde"},
  {lang:"en", text: "hello world"}
]

•  le fichier html : index.html

<html>
<head>
  <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"> </script>
  <script src="/model.js"> </script>
</head>
<body>
  <div id="myapp">    
    <p> {{ msg }} </p>
    <button @click="toggleLang">Change language</button>
  </div>
  <script src="/index.js"> </script>
</body>
</html>

• le fichier de la partie contrôle, créant la vue : index.js

var app = new Vue({
    el: '#myapp',
    data: {
        messages,
        msg:'salut',
        lang: 'fr'
    },
    methods: {
        toggleLang() {
            if (this.lang === 'fr') {
                this.lang = 'en'
            }
            else {
                this.lang = 'fr'
            }
            let m = messages.find(e => e.lang === this.lang)
            this.msg = m.text;      
        }
    },
})

 Remarques :

• Dans la partie HTML, on voit apparaître des syntaxes qui sont étrangères : {{ }}, @click. Cela vient de vuejs
• L'instance de vue contient 3 attributs :
  • el : permet d'indiquer à quel élément HTML on raccroche l'instance, en l'occurence à la balise <div> qui a pour id myapp.
  • data : permet d'indiquer un ensemble de variables qui sont observées. Si la valeur de ces variables change, tous les éléments HTML qui en dépendent seront rafraîchit
  • methods : permet de définir des fonctions, notamment celles qui vont modifier l'état des variables observées.
• Une des variables observée est messages, qui est déclarée dans model.js. Il est donc bien possible d'observer des variables "externes" à l'instance de vue.
• Chaque fois que l'on veut accéder à un variable observée en JS, on doit la préfixer par this.

 

• Cet exemple montre deux choses :
  • plus besoin d'écrire du code pour intervenir sur le DOM = super !
  • il y a toujours besoin d'écrire le code qui manipule les données = pas de miracle !

 

3°/ Un projet basique avec vue-cli

3.1°/ Créer le projet

• Créer un projet vue est très facile : vue create nom_projet
• Le profil par défaut crée un projet basé sur vuejs v2, sans module spécial. Il est cependant possible de créer un projet basé sur vuejs v3, ou bien d'inclure des modules "classiques" tels que vue-router.
• Exemple : vue create exo1
• Cela crée un répertoire exo1 avec notamment dedans :
  • package.json : fichier décrivant les différent modules nodejs utilisés, leur dépendances et certaines options de configuration.
  • node_modules : où est stocké le code des modules.
  • public : contient le patron de fichier html utilisé pour l'applcation SPA
  • src : les sources de l'application.
• Sauf exception, on a besoin d'intervenir uniquement sur les fichiers de src.

• src contient :
  • App.vue : décrit la page principale de l'application. Le fichier est structuré comme tous les fichiers .vue, avec une partie <template> décrivant le html, une partie <script> contenant du javascript et notamment tout ce qui est associé à vuejs (data, methods, ...), et enfin une partie <style> avec le CSS pour formater l'affichage. 
  • main.js : crée l'instance de vue. On modifie ce fichier quand on veut ajouter à la vue des modules/plugins après la création (par ex, vue-router, vuetity, ...). 
  • components : le répertoire contenant les composants de l'application, généralement sous forme de fichier .vue. Par défaut, vue-cli crée un composant HelloWorld.vue qui permet seulement de personnaliser le titre principal du composant.

 

3.2°/ Analyse des fichiers créés par défaut.

 

3.2.1°/ Les fichiers .vue

• Un fichier .vue sert à définir un composant.
• Il peut contenir 3 parties :
  • <template> : contient le code HTML décrivant le visuel du composant.
  • <script> : contient du javascript décrivant les données manipulées par le composant (via les champs props et data), ainsi que les fonctions de contrôle.
  • <style> : contient du CSS, pour formater l'affichage donné dans le template.
• Seul <template> est obligatoire. Si un composant n'a pas de données propres, ou des fonctions de contrôle, alors pas besoin de partie script.

 

• La partie template est implicitement "exportée", ce qui permet de l'importer dans d'autres composants.
• Si le composant contient une partie script, il faut explicitement l'exporter, avec l'instruction export.
• Le mécanisme import/export est illustré ci-dessous.

 

3.2.2°/ index.html

• Le seul point à remarquer est que le fichier contient une balise <div id="app"> qui va constituer le point de montage de l'instance de Vue.
• Mais contrairement à ce que l'on a fait dans l'exemple hello world, il n'y a pas de code dans <div>.
• C'est normal : le contenu de cette balise va être créer dynamiquement lorsque l'instance de Vue est créée (cf. ci-après).

 

3.2.3°/ main.js

• La façon d'instancier la vue est relativement différente de l'exemple hello world.
• Sans trop entrer dans les détails, on remarque que l'on importe le fichier App.vue, qui est un composant représentant la page principale de l'application.
• On remarque également que App est utilisé comme paramètre d'une fonction h(). Cette fonction traduit le template de App en éléments HTML.
• Ces éléments sont affectés à l'attribut render de la vue.
• Il faut ensuite raccrocher render au DOM. Pour spécifier à quel élément HTML on l'accroche, on appelle la fonction $mount, prenant en paramètre l'id de l'élément.

 

3.2.4°/ App.vue

• D'un point de vue syntaxique, ce fichier décrit un composant. Comme c'est le composant racine de l'application, on ne le met pas dans le répertoire components.
• On remarque que le template commence par <div id="app"> . En fait, on peut mettre la valeur que l'on veut dans id, puisque cette balise va remplacer celle définie dans le HTML. Dans le cas présent, id est seulement utile pour fixer un style à la balise (cf. #app dans la partie style).
• Le template contient aussi une balise <HelloWorld>, qui permet d'intégrer une instance du composant HelloWorld. Ce dernier doit bien entendu être importé localement pour que cela fonctionne (cf. ci-dessous).

 

• La partie script commence par une instruction import dont le comportement ressemble à celle du python.
• D'une manière générale, elle permet d'importer dans le fichier courant des variables/fonctions qui ont été exportées par un autre fichier (NB : on parle de module plutôt que fichier, mais dans la pratique, c'est généralement 1 module = 1 fichier).
• Si cet autre fichier est un fichier .vue, alors le template qu'il contient est lui aussi importé.

 

ATTENTION : quand bien même certains navigateurs savent interpréter cette instruction import (et export), c'est sous certaines conditions, qui sont plus strictes que celles de vue-cli. Le code produit par vue-cli est donc impossible à utiliser directement dans un navigateur. Il faut le transformer (cf. section Tester/Déployer)

 

• Dans un projet vuejs, on code généralement les modules pour qu'ils n'exportent qu'un seul objet json, regroupant tout ce que l'on veut exporter. On utilise alors l'instruction export default var_objet pour faire l'export. Ce type d'export (dit par défaut) permet ensuite de faire l'importation de l'objet en lui donnant le nom que l'on veut.

• Dans le cas présent, on importe l'objet (+ le template) qui a été exporté dans components/HelloWorld.vue sous le nom HelloWorld. On pourrait tout aussi bien l'appeler Banane, du moment qu'on utilise Banane dans la suite.

 

• Le fichier continue avec une instruction export default qui permet d'exporter (en plus du template) la partie données/contrôle du composant. C'est obligatoire pour que main.js puisse l'importer. Sans cela, main.js ne pourrait instancier correctement la Vue.
• Enfin, le fichier se termine avec la partie <style> permettant d'associer du CSS au composant. En l'occurence, on indique le style des balises ayant un id égal à app.

 

 3.2.5°/ HelloWorld.vue

• Ce fichier représente un composant, donc utilisable par d'autres composants de l'application. C'est le cas pour App.vue qui l'importe et l'instancie dans son template en utilisant une balise <HelloWorld>.
• Comme ce composant a une partie script, on doit l'exporter explicitement, d'où le export default.
• Rq : le champ name sert uniquement pour le déboguage. Dans cet exemple, sa valeur est la même que celle utilisée par l'importation dans App.vue. Mais on peut changer sa valeur, cela n'aura aucune répercussion sur l'import/export.
• La balise <style> a un attribut scoped. Conformément au commentaire, cela permet de limiter la portée du css : chaque instance du composant aura son propre style.
• Rq : l'utilisation des styles sera abordée dans un autre TD.

 

 3.3°/ Tester/déployer

• Comme dit plus haut, le code produit n'est pas utilisable directement dans un navigateur. Il faut donc utiliser les outils de vue-cli pour créer une version utilisable.
• Il existe deux solutions :
  • créer une version de développement, non optimisée,
  • créer une version de production, compacte, prête à êre mise en ligne sur un serveur web.

3.3.1°/ Tester

• Le principe est de compiler les sources puis de lancer un mini-serveur web local, à même de servir le résultat.
• Pour cela, il suffit d'être dans l'arborescence du projet et lancer :

npm run serve

• Après compilation, un message indique l'URL permettant d'accéder au serveur, généralement http://localhost:8080
• A noter que si on laisse le serveur tourner et que l'on modifie les fichiers, le serveur en tien compte.

3.3.2°/ Déployer

• La compilation optimisée se fait avec la commande

npm run build

• Un répertoire dist est créé, avec tous les fichiers nécessaires dedans.
• Pour tester le résultat rapidement localement, il faut se placer à la racine du projet et lancer la commande

server -l 12345 dist

•  Cela suppose que la paquet nodejs serve a bien été installé, comme décrit dans la procédure ci-dessus.
• Le paramètre -l permet de spécifier le port sur lequel le serveur web écoute.
• Si tout fonctionne correctement, on peut mettre en place un vrai serveur web et copier les fichier dans un répertoire servi (NB : sujet non abordé ici)