Les cookies
Salut ! On va enfin voir les api dont j'entend parler tout le temps ?
Pas tout à fait, on parle souvent d'api REST, mais c'est un tout autre sujet qu'on ne va pas aborder aujourd'hui. Je vais te parler des api navigateur, et plus particulièrement de celle qui permettent de gérer du stockage de données.
Ah, je suis déçu, je pensais enfin comprendre ces api dont tout le monde parle
Ne t'inquiète pas, on aura l'occasion d'en parler une autre fois, et tu va voir, les api navigateurs sont un sujet très intéressant aussi !
Mais pour commencer, il y a les cookies, tu en a déjà entendu parler?
Oui, des biscuits aux pépites de chocolat, j'adore ça !
Evidemment...
Je plaisante! Oui j'en ai déjà beaucoup entendu parler, mais je t'avoue que je ne sais pas exactement en quoi ça consiste.
Il s'agit d'un moyen assez ancien de stocker des informations sur un navigateur pour son utilisateur. On peut y stocker à peu près tout ce que l'on veux, mais il y a un certains nombre de problème à les utiliser.
Pour commencer, il y a une place limitée dans les cookies, une données ne peut pas avoir une taille infinie, et il ne peut pas y avoir un numbre infinie de données non plus par site. Et en plus de ça, cette quantité de données peut beaucoup varier d'un navigateur à l'autre, il est donc très difficile de bien gérer ces données sans prendre le risque de dépasser un jour ou l'autre. Et en cas de dépassement, c'est l'erreur assurée.
En plus de ça, il y a des failles de sécurité assez importantes dans les cookies, qui ne garantissent donc pas toujours la confidentialité des informations. Tout dépend comment ils sont utilisés, mais une erreur est vite arrivée.
Donc si je comprend bien, il faut faire très attention quand on utilises des cookies
Effectivement, et j'irais même plus loin, en te disant de ne jamais en utiliser, sauf si vraiment tu n'as pas d'autres choix.
Mais comment on fait pour enregistrer des données s'il ne faut pas utiliser de cookies?
Le WebStorage
Depuis plus récemment, des api ont été implémentées dans les navigateurs, et ces api respectent une norme commune, donc on les utilises de la même façon, quel que soit le navigateur.
Il y en a une qui s'appelle le WebStorage, elle permet de stocker de deux façon des données liées à l'utilisateur qui se trouve sur ton site web.
Pourquoi deux?
Le localStorage
On va y venir, la première est le localStorage, on peut y enregistrer des informations textuelles, il s'agit s'implement d'un enregistrement clé/valeur, c'est à dire que l'on précise au localStorage que l'on souhaite enregistrer une données, on donne un nom à cette données, ce sera la clé, et on lui précise sa valeur. Comme ça on pourra ensuite récupérer la données en précisant au localStorage sa clé. Les deux premières méthodes importantes à voir sont, le setItem pour enregistrer une données, et le getItem pour la récupérer :
Ok, c'est pas très compliqué
En effet, et l'avantage du localStorage est que cette données sera conservée, même si l'utilisateur change de page ou raffraichit sa page, contrairement aux variables javascript qui sont détruites à chaque nouveau chargement de page.
Ah pas mal !
On peut bien entendu y stocker aussi des variables
Et des tableaux ou objets on peut aussi?
Tel quel, non ce n'est pas prévu. La valeur doit rester un contenu textuel, et un tableau ou un objet est une données complexe. Mais on peut sérialiser cette donnée, c'est à dire la transformer en une chaine de caractère, grâce à JSON.stringify, et la désérialiser avec JSON.parse. Par exemple :
Ok, ça utilise la mise en forme JSON pour les données !
Tout à fait, et cette données est une chaine de caractère, donc on peut l'enregistrer dans le localStorage :
C'est génial !
Il reste deux méthode à connaitre sur le localStorage, la première est le removeItem, elle permet de ...
... Retirer un élément du storage
Tu comprend de plus en plus vite toi. Un exemple :
Et oui, une chose à retenir, si un élément n'existe pas dans le localStorage, le getItem ne va pas générer d'erreur, mais simplement retourner "null", le type de valeur dont on avait parlé quand je t'expliquais les variables.
Donc si je comprend bien, pour vérifier si une valeur existe dans le localStorage, il faut faire if(localStorage.getItem("cle") != null)
Tout à fait, tu as compris. Je passe donc à la dernière méthode, c'est le clear, celle ci ne prend aucun paramètre et va tout simplement effacer tous les enregistrements du localStorage.
Mais... Si d'autres sites utilisent aussi le localStorage, on va supprimer leur données?
J'aurais du préciser ça avant, quand tu utilises le localStorage, tu ne peux manipuler que les données enregistrées pour ton site. Celle ci sont automatiquement associés à ton nom de domaine, et tu ne peux en aucun cas récupérer, modifier ou supprimer des données d'autres sites, tu n'y a tout simplement pas accès. C'est une sécurité qui a été mise en place par la norme du WebStorage.
Ok, tant mieux alors ! Mais si jamais on veux communiquer des informations entre deux sites, on fait comment?
Il existe d'autres moyens, le WebStorage n'est absolument pas fait pour ça. Maintenant on va passer à la suite.
Le sessionStorage
Il existe aussi dans le WebStorage, une autre façon d'enregistrer des données, c'est le sessionStorage.
Oula, ça va faire beaucoup de nouvelles choses à apprendre ça, on ne peut pas s'arrêter au localStorage?
En fait il n'y a presque rien de plus à apprendre, le sessionStorage fonctionne de la même façon que le localStorage, avec les mêmes méthodes setItem, getItem, removeItem et clear.
Mais... Quel est l'intérêt alors?
Il y a une nuance entre les deux, le sessionStorage n'est valable que pendant la durée de ce que l'on appelle la session navigateur, alors que le localStorage continue à être valable même après la fin de la session.
Euh, ok, mais c'est quoi la session?
Je ne vais pas rentrer dans le détail technique, mais c'est en quelque sorte un élément de ton navigateur qui retiens qu'un onglet ouvert correspond à l'utilisation par un utilisateur d'un site en particulier. Pour simplifier ça, c'est un identifiant unique qui est crée quand tu arrives sur un site, et qui est détruit quand tu quitte le site ou que tu ferme ton onglet de navigateur.
Il peut y avoir des cas d'utilisation spécifiques, mais le principal à retenir, c'est qu'une donnée enregistrée dans le sessionStorage sera perdue si l'utilisateur quitte le site ou ferme son onglet/navigateur, alors qu'une donnée dans le localStorage sera toujours présente après réouverture du site dans le navigateur.
Ok j'ai compris. Pour résumer tout ça c'est du cache des données
Le cacheStorage
Et bien non, il ne faut pas confondre le WebStorage avec du cache. Quand on parle de cache, on parle indirectement d'optimisation des performances. Imaginons une page de recherche sur un site, quand tu va saisir un texte pour rechercher quelque chose, ça va envoyer une requête au serveur, qui l'exécutera, recherchera les correspondances en base de données,et formatera le résultat pour l'envoyer au navigateur qui l'affichera. Si tu reclique à nouveau sur rechercher, tu va de nouveau envoyer la même requête au serveur qui recommence tout le processus.
Avec le cacheStorage, tu peux enregistrer le résultat de cette requête, et si l'utilisateur la reproduit une deuxième fois, cette fois le serveur ne sera pas appelé, le résultat sera récupéré directement du cacheStorage pour être affiché, on économise donc des performances sur le serveur.
Je ne vais pas te donner d'exemple pour celui ci, car il est un peu plus compliqué à mettre en place et on va généralement l'utiliser avec ce que l'on appelle les services worker. Mais ce qu'il faut retenir, c'est que le WebStorage sert à retenir des informations sur l'utilisateur et sa navigation sur le site, alors que le cacheStorage sert à contenir des résultats de données pour éviter une consommation inutiles de ressources.
Ok, je retiens tout ça, encore merci à toi.
Ne me dit pas merci tout de suite, demain on verra la programmation orienté objet en javascript et on va réutiliser absolument tout ce que l'on a vu cette semaine, donc révise bien tout ça pour être prêt !
D'accord je vais potasser tout ça.
J'ai terminé cette partie