Stockage et récupération d'objets JavaScript dans localStorage

Écrit par Nelson Michael✏️

Note de l'éditeur : Cet article a été mis à jour pour la dernière fois par Rahul Chhodde le 7 août 2024 pour proposer une exploration plus approfondie du stockage d'objets dans localStorage, comme les techniques de sérialisation d'objets JavaScript à l'aide de JSON.stringify, et les situations où il est nécessaire de travailler avec et de stocker plusieurs objets dans localStorage.

L'API Web Storage fournit des mécanismes basés sur JavaScript pour stocker et accéder en toute sécurité aux données sous forme de paires clé-valeur dans le navigateur du client. Ceci est utile pour stocker des données non sensibles telles que les préférences utilisateur, les états des applications et même les réponses API dans certains cas.

Les deux mécanismes de l'API Web Storage, localStorage et sessionStorage, permettent aux développeurs de stocker des données de manière persistante et temporaire. Ces données stockées peuvent être facilement récupérées ultérieurement et utilisées pour faciliter l'utilisation de l'utilisateur.

Dans cet article, nous apprendrons comment chaîner et analyser des objets JavaScript dans des chaînes JSON pour les enregistrer dans localStorage, puis inverser le processus pour récupérer les données. Nous aborderons également brièvement les principales différences entre les cookies localStorage, sessionStorage et HTTP, en soulignant les avantages et les inconvénients de l'utilisation de localStorage par rapport aux deux autres.

Qu’est-ce que le stockage local ?

L'objet localStorage est l'un des deux mécanismes de stockage Web qui permettent aux développeurs de stocker des données sur le navigateur du client qui persistent même après la fermeture de la fenêtre du navigateur. Ces données stockées sont accessibles dans un domaine particulier à l'aide de méthodes API faciles à utiliser, dont certaines sont présentées ci-dessous :

localStorage.setItem("myDataKey", "My data");
localStorage.getItem("myDataKey"); // "My data"
localStorage.removeItem("myDataKey");

Notez que les données stockées dans l'objet localStorage à partir d'un domaine ne peuvent être consultées ou modifiées que par des pages de même origine, qui - dans ce cas - signifie collectivement protocole, domaine et port. Vous pouvez vérifier ce comportement en utilisant ces méthodes dans la console de développement de votre navigateur.

Selon W3Schools, l'objet localStorage stocke les données sans date d'expiration. Les données ne seront pas supprimées même lorsque l'utilisateur quitte la page ou ferme la fenêtre du navigateur ; il sera disponible pour les prochaines sessions. Cette capacité à conserver les données est connue sous le nom de persistance des données dans le développement de logiciels et de sites Web.

Utilisation de sessionStorage par rapport à localStorage

Le deuxième mécanisme de stockage Web, sessionStorage, est presque identique à localStorage mais diffère de deux manières : il stocke temporairement les données pour l'onglet spécifié (ou actuel) et ce pour une période limitée seulement.

L'objet sessionStorage reste actif tant que l'onglet correspondant est ouvert et conserve les données lors des rechargements et des restaurations de pages. Lorsqu'une page Web est chargée dans un onglet du navigateur, sessionStorage, s'il est utilisé, crée une nouvelle session de page et l'attribue à cet onglet. Cette session de page n'est valide que pour cette origine particulière accessible dans cet onglet spécifique.

Remarque : les données stockées dans chaque type de stockage Web sont distinctes pour chaque protocole d'une page donnée. Cela signifie que les données stockées sur un site accessible via HTTP sont stockées sur un objet sessionStorage différent des données stockées sur le même site accessible via HTTPS.

Principales différences entre sessionStorage et localStorage

localStorage et sessionStorage fonctionnent de la même manière, mais la principale différence est que les données stockées dans localStorage sont persistantes, partagées entre les onglets de la même origine et durent éternellement pour cette origine spécifique, à moins que le stockage du navigateur ne soit effacé ou que nous effacions localStorage à l'aide de JavaScript ou manuellement.

À l'aide de Chrome DevTools, vous pouvez afficher les données dans les objets localStorage et sessionStorage et observer les distinctions que nous venons de couvrir. Voici une capture d'écran illustrant la localisation des deux objets dans l'onglet Application de DevTools :

Pour stocker et réutiliser des informations telles que les préférences utilisateur, les états des applications, la réponse de l'API et des morceaux de données plus importants afin de faciliter les performances perçues, nous choisissons localStorage plutôt que sessionStorage, car ces informations doivent persister pour être utilisées occasionnellement pour personnaliser et mettre à jour l'expérience utilisateur. .

Remarque : Lorsque le dernier onglet privé est fermé, les données stockées dans l'objet localStorage d'un site ouvert en onglet privé ou en mode navigation privée sont effacées, ce qui est logique car il s'agit d'une session de navigation privée.

Stockage Web et cookies HTTP

Les cookies HTTP sont un mécanisme conventionnel permettant de stocker de petits bits de données échangés entre le client et le serveur lors de chaque requête HTTP.

Une fois connecté à un client, le serveur génère certaines informations, les enregistre dans un fichier cookie et les envoie au navigateur du client. Ces informations sont étiquetées avec un identifiant unique pour chaque utilisateur et son ordinateur, ce qui aide le serveur à identifier l'utilisateur chaque fois qu'une connexion est établie.

Les cookies contiennent des informations telles que des données d'authentification et de session, des jetons CSRF, des données de suivi et de minuscules préférences utilisateur spécifiques au site pour aider à personnaliser l'expérience utilisateur. Cependant, ils peuvent constituer un cauchemar en matière de confidentialité. Nous en discuterons dans le segment suivant.

Pourquoi et quand utiliser les cookies ?

Les cookies ne sont pas la solution recommandée pour stocker des volumes de données plus importants côté client. Ils sont mieux adaptés à la gestion de sessions et constituent l’une des solutions les plus largement prises en charge pour ce faire.

À chaque requête, les cookies sont envoyés au serveur dans les en-têtes HTTP du navigateur, par opposition à l'utilisation de localStorage ou sessionStorage, qui ne sont accessibles par l'application que comme stockage de données côté client et sont ouverts aux vulnérabilités.

Pour la sécurité de la session, les cookies marqués comme Secure et HttpOnly peuvent minimiser les risques de piratage de session, limitant les attaques XSS (cross-site scripting) et CSRF (cross-side request forgery) sur le navigateur de l'utilisateur pendant la session.

Quand ne pas utiliser de cookies

Les cookies HTTP sont une norme de longue date, et il n'est pas toujours possible de conserver vos applications 100 % sans cookies. Cependant, il existe quelques cas où vous souhaiterez peut-être les éviter :

• Les cookies sont censés être transmis à chaque requête faite au serveur, c'est pourquoi ils sont conservés en petite taille et ne peuvent pas contenir de données supérieures à 4 Ko. Cela les rend impropres à la mise en cache de valeurs importantes telles que d'énormes données sur les préférences des utilisateurs, les états des applications, les documents créés par les utilisateurs, etc.
• Les cookies tiers soulèvent un sérieux problème de confidentialité, car le site que vous avez visité ne les crée pas et n’en est pas propriétaire. Ces cookies sont généralement liés au suivi des données des utilisateurs, ce qui les rend suspects, et de nombreux navigateurs se préparent à les restreindre pour protéger la vie privée des utilisateurs

Ces points nous obligent à stocker nos tas de données non sensibles dans localStorage. De telles situations nécessitent souvent de sauvegarder localement des données complexes telles que des objets JavaScript, ce qui nécessite une approche légèrement différente.

Comment stocker un objet JavaScript dans localStorage

Les applications Web modernes nécessitent souvent d'enregistrer les objets JavaScript localement pour fournir un accès hors ligne, restaurer l'état de l'application ou mettre en cache une réponse API pour les avantages perçus en termes de performances.

Notez que ces données ne doivent pas contenir d'informations sensibles, car une fois stockées dans Web Storage, elles deviennent accessibles à tout code JavaScript exécuté sur la même origine.

Commençons par acquérir une compréhension de base de la façon de travailler avec localStorage en explorant ses méthodes et propriétés pour divers cas d'utilisation :

• setItem() : ajoute des données à un objet Web Storage en utilisant ses deux arguments, une clé et une valeur : localStorage.setItem("key", "value")
• getItem() : renvoie la valeur du nom de clé qui lui est transmis : localStorage.getItem("key")
• **removeItem()** : Supprime une clé qui lui est transmise avec sa valeur correspondante : localStorage.removeItem("key")
• clear() : efface toutes les paires clé-valeur dans le stockage associé et doit être utilisé avec prudence : localStorage.clear()
• **key()** : renvoie la clé à l'index spécifié dans le stockage : localStorage.key(0)
• length : renvoie le nombre total de paires clé-valeur stockées dans le stockage associé : localStorage.length

Vous pouvez en savoir plus sur ces méthodes dans la documentation de l'API Web Storage de MDN.

L'exemple ci-dessous démontre la persistance des données obtenue à l'aide de certaines de ces méthodes de l'API Web Storage. Cliquez sur le bouton Compte actuel, réexécutez le CodePen et voyez les données de comptage persistantes à l'aide de localStorage :

Voir le Pen localStorage en action par Rahul (@_rahul) sur CodePen.

Dans la démo ci-dessus, chaque fois que vous cliquez sur le nombre ou sur le bouton Effacer, plusieurs éléments localStorage sont créés, lus ou modifiés et les modifications apportées aux valeurs correspondantes sont reflétées dans l'interface.

Sérialisation d'objets JavaScript

Le stockage des données d'objets JavaScript dans Web Storage est un peu délicat, car il vous permet de stocker uniquement des valeurs de chaîne. Si nous essayons de stocker un objet JavaScript sans le convertir au préalable en chaîne, nous obtiendrons une réponse [object Object], comme le montre l'image ci-dessous :
[object Object] est une représentation sous forme de chaîne d'une instance d'objet dont la valeur n'a jamais été lue au moment du stockage des données, ce qui entraînera une perte de données.

The correct way to store object data to localStorage is to first convert it to a string. Then, we can move on to the storage procedure.

This object-to-string conversion of object data is known as serialization, and turning this converted string back to object data is called deserialization. Let’s briefly discuss two important JSON methods that are responsible for object data serialization and deserialization:

• JSON.stringify: Converts any object value into a string JSON (serialization)
• JSON.parse: Turns a JSON string into its corresponding object or value (deserialization)

Now, utilizing the setItem method with JSON stringify, we can easily convert a JavaScript object to a JSON string and push it to the localStorage object. Here’s a quick example to demonstrate this:

const userObj = {
  name: "John Doe",
  age: 32,
  gender: "Male",
  profession: "Optician" 
};

localStorage.setItem("userObj", JSON.stringify(myObject));

Now, if we try to retrieve the object data without deserializing it, we will receive a JSON string instead of an object, which makes sense, as it is what we stored to localStorage.

We need to deserialize this JSON string data using the JSON parse method to turn it back into a JavaScript object:

let newObject = localStorage.getItem("myObject");
console.log(JSON.parse(newObject));

Here, we retrieved our previously set JavaScript object using the getItem method on the localStorage object and saved it into a variable. Next, we parsed that string into a JavaScript object and finally logged it to the console:

More examples of storing objects in localStorage

• Storing Date objects: Constructing an object using the current timestamp using the Date object and a random value, and saving it to or clearing it from the localStorage using button inputs
• Persisting remote data: Fetching remote data from a dummy API and storing it in localStorage; the network fetch in this example is only triggered when no associated data in localStorage is found

Storing multiple objects in localStorage

Let’s say we have a bunch of similar objects, and we want to group all of them and store them as one JSON string in the localStorage. We can turn them into an object array and then serialize them as shown below:

const todos = [todo1, todo2, todo3];
localStorage.setItem("todos", JSON.stringify(todos));

If you have bigger chunks of data to work with, you might want to store each of them with separate keys, but accessing all of them quickly can be done using this namespace approach:

// Storing
localStorage.setItem('todos:1', JSON.stringify(todo1));
localStorage.setItem('todos:2', JSON.stringify(todo2));

// Retrieving
const keys = Object.keys(localStorage).filter(key => key.startsWith('todos:'));
const todos = keys.map(key => JSON.parse(localStorage.getItem(key)));

Limitations of storing objects to localStorage

localStorage is one of the mechanisms of the Web Storage API. The API provides 5-10MB of storage per origin, and the exact storage may vary depending on the browser. Respecting this size limit, you should avoid storing more than 3-4MB of data per origin in Web Storage objects.

Keep in mind that Web Storage API operations are synchronous and block the main thread, therefore performing heavy operations using it may block other resources from loading in the browser.

Types of data that can be stored as a JSON string

Primitive data types like numbers, Booleans, and strings are JSON-safe, while values like functions, undefined, symbols, and Date objects are not JSON-safe. If no JSON-safe values are found during conversion, they are either excluded from an object or changed to null in an array.

Note: Some of these such values can be made JSON-safe, for example, we used the toISOstring method with the Date object in this example to make it JSON-safe before pushing it to Web Storage.

Conclusion

In this article, we learned a useful technique for storing multiple bits of information in a single localStorage key and using the JSON stringify and parse methods. We also covered some working demonstrations that apply this approach to different tasks, as well as storing and retrieving multiple JavaScript objects from localStorage.

In summary, we should be mindful of the data we store locally, and take advantage of the localStorage object to store JavaScript objects by first converting them to JSON strings with the JSON.stringify method and then turning them back to objects with the JSON.parse method.

LogRocket: Debug JavaScript errors more easily by understanding the context

Debugging code is always a tedious task. But the more you understand your errors, the easier it is to fix them.

LogRocket allows you to understand these errors in new and unique ways. Our frontend monitoring solution tracks user engagement with your JavaScript frontends to give you the ability to see exactly what the user did that led to an error.

LogRocket enregistre les journaux de la console, les temps de chargement des pages, les traces de pile, les requêtes/réponses réseau lentes avec les corps d'en-tête, les métadonnées du navigateur et les journaux personnalisés. Comprendre l'impact de votre code JavaScript n'aura jamais été aussi simple !

Essayez-le gratuitement.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!