De la persistance dans notre application Meteor

Dans l’article précédent, nous avons étudié le projet par défaut de Meteor point par point. Nous avons ainsi vu que, dans l’état actuel des choses celui-ci ne communique que très peu avec le serveur et qu’un simple rafraichissement via notre navigateur réinitialise le compteur présent dans l’application. Nous allons donc modifier ce comportement en deux temps :

Rendre le compteur persistant pour un utilisateur en particulier par l’intermédiaire d’une session persistante, semblable à un cookie.
Par la suite, dans un prochain article, rendre le compteur persistant et unique, c’est-à-dire qui sera le même pour tous et qui, bien entendu, gardera en mémoire dans notre base de données MongoDB cette information.

Attaquons donc le vif du sujet !

Mise à niveau de votre projet

Bien, nous allons donc commencer par la mise en place d’une session persistante. Mais avant cela nous allons mettre à niveau notre projet. La première étape va être très simple et va consister à supprimer deux modules Meteor, installer par défaut. J’ai nommé autopublish et insecure. Pourquoi donc ? Et bien simplement car l’utilisation de ses modules est dédié à du développement, pour le simplifier mais, absolument pas pour de la production. Car leur utilisation ouvre des portes qui vont mettre à mal la sécurité de votre application, un utilisateur malveillant pouvant accéder à 100% de votre base de données.

Deux méthodes sont à votre disposition pour les supprimer :

- Soit, depuis votre éditeur de texte ouvrir le fichier présent dans .meteor/packages. Nous en avons déjà parlé précédemment, dans un autre article, c’est ici qu’est énumérée la liste des modules de votre projet. Il vous suffit donc, pour les enlever du projet de simplement supprimer les deux lignes comportant leur nom. C’est-à-dire :

[email protected] # Publish all data to the clients (for prototyping)
[email protected] # Allow all DB writes from clients (for prototyping)

- Soit depuis votre invité de commandes exécuté les commandes de suppression d’un module, donc :

meteor remove autopublish
meteor remove insecure

Votre projet est maintenant tout propre et sécurisé !

Utilisation des Sessions persistantes dans notre projet Meteor

Avant d’attaquer directement le code, voyons à quoi correspond une session dite persistante et surtout comment ça marche ? Par défaut dans Meteor, les sessions sont locales, c’est-à-dire que leur durée de vie se limite à une navigation sur votre site internet. Un rafraichissement de la page et pouf, il n’y a plus rien et tout se réinitialise avec la valeur par défaut. C’est actuellement ce qui se passe dans le projet de base.

Quel va être notre objectif ? Eh bien nous allons faire en sorte que même si l’utilisateur revient sur notre site internet plus tard ou s’il rafraîchit sa page internet les informations, en l’occurrence ici notre compteur, garde sa valeur. Une session persistante est donc un moyen de faire cela. Lorsque nous demanderons dans le code de créer une session, celui-ci s’occupera pour nous de stocker un cookie, un petit paquet d’informations, dans le navigateur du client. La donnée n’est donc pas 100% persistante car, si votre utilisateur vide son cache et ses cookies, le compteur reviendra à 0. Le système n’est donc pas parfait mais, peut servir dans certains cas.

Bien, maintenant que nous avons fait l’étape théorique, attaquons l’étape pratique. La première étape va être d’installer un nouveau module, car oui, par défaut les sessions ne sont pas persistantes mais seulement locale, il nous faut donc ajouter cette fonctionnalité. Et bonne nouvelle, quelqu’un a déjà fait ça pour nous, le module persistent-session fait exactement ce dont nous avons besoin ! Pour l’installer, comme nous avons précédemment fait dans un autre article, il nous suffit de faire, dans votre console les commandes suivantes :

meteor add session meteor add u2622:persistent-session

Initialisation et création de la session persistante

Avant toute chose nous devons créer et initialiser notre session. Nous avons vu, quand nous avions étudié précédemment l’architecture du projet que la première fonction JavaScript à laquelle nous faisons appel lors du chargement d’un template correspond à OnCreated. Et bien c’est ici que nous allons naturellement le faire.

Template.hello.onCreated(function helloOnCreated() {
    // Si la session n'existe pas déjà alors nous la créons
    Session.setDefaultPersistent('counter', 0);
});

Nous remplaçons donc ici l’ancien code qui déclare une variable Reactive. setDefaultPersistent permet de créer une session si et seulement si elle n’existe pas déjà, dans le cas contraire, rien ne sera fait (afin de ne pas réinitialiser à 0 ça valeur et de bien garder l’état précédent du compteur après un rafraichissement de la page). Le premier paramètre correspond, comme vous vous en doutez, au nom du de notre Session puis, le second paramètre, à la valeur que nous lui donnons. Ici 0 par défaut, mais cela peut aussi être une chaîne de caractères, un nombre à virgule par exemple.

Bon, maintenant à chaque fois que le template hello sera affiché, une session persistante sera créé si nécessaire et initialisé à 0. Un Cookie avec le nom counter et avec la valeur 0 est donc créé puis stocké dans votre ordinateur.

Récupérer notre session persistante pour l’afficher dans Blaze

Maintenant que notre session existe, il serait bien de faire en sorte de pouvoir récupérer la valeur de celle-ci pour l’afficher dans Blaze et donc dans notre page HTML. Aucune modification au niveau de Blaze n’est nécessaire je vous rassure (notre template). Rappellez-vous, c’est grâce au helper défini dans le JavaScript, sur notre template, que nous pouvons créer des variables pour Blaze. Il ne nous reste donc qu’à modifier cette partie du code et le tour sera joué ! Et le voici :

Template.hello.helpers({
    counter() {
         return Session.get('counter');
    }
});

La seule ligne que nous devons changer par rapport à avant concerne la valeur retournée. Précédemment, dans le projet par défaut, nous récupérions la valeur de la variable reactive mais maintenant, comme vous pouvez le voir dans le code ci-dessus, il nous suffit de récupérer par l’intermédiaire de Session.get la valeur que notre session. Le seul paramètre nécessaire est le nom de notre session.

Rien de plus, rien de moins. Maintenant, la valeur du compteur qui sera affichée dans notre page HTML correspondra bien à la valeur de notre session.

Agrémenter le compteur

Bon, nous avançons petit à petit vers notre objectif. Il ne nous reste plus qu’une seule étape, c’est l’agrémentation de la valeur contenue dans notre session lors d’un clic sur le bouton. Je ne pense pas que cela soit une surprise pour vous, oui effectivement nous allons modifier le code contenu dans la fonction events. Et sans surprise voilà le code !

Template.hello.events({
    'click button'(event, instance) {
        // Augmenter le compteur lorsque le bouton est cliqué
        Session.update('counter', Session.get('counter') + 1);
    }
});

La méthode update permet donc de mettre à jour une session, le premier paramètre correspond à son nom, son identifiant et le second paramètre la nouvelle valeur à attribuer. Dans notre cas nous récupérons sa valeur actuelle et ajoutons +1 via une addition.

Maintenant, lancer votre projet avec la commande Meteor dans votre invité de commandes, la page devrait être accessible à cette adresse, en locale http://localhost:3000/. Cliqué sur le bouton et magie, le compteur augmente, comme avant. Oui mais non ! Comme avant certes mais, maintenant, recharger la page et miracle ! Le compteur garde la même valeur que précédemment, avant le rechargement, cette donnée n’est donc maintenant plus que locale mais persistante sur votre navigateur.

Cependant, si vous l’ouvrez via un autre navigateur ou supprimer votre historique de navigation celui-ci retombe à 0. De plus, le compteur est unique à chaque individu, ce qui est assez dommage. Nous allons donc bientôt remédier au problème dans un prochain article !