Adapter localStorage

@siteping/adapter-localstorage persiste les feedbacks dans le navigateur du visiteur. Combiné à l'option store du widget, vous obtenez une boucle de feedback complète sans aucun backend — idéal pour les démos, les prototypes et les sites de documentation (ce site l'utilise).

npm i @siteping/adapter-localstorage

import { initSiteping } from "@siteping/widget";
import { LocalStorageStore } from "@siteping/adapter-localstorage";

initSiteping({
  store: new LocalStorageStore(),
  projectName: "ma-demo",
});

Options

Notes de comportement

• Les données restent sur une seule machine. Chaque visiteur ne voit que ses propres feedbacks — c'est voulu. Rien ne quitte le navigateur.
• Des données corrompues ne font jamais planter — et ne sont jamais perdues en silence. Un enregistrement sans annotations — ou sans comments, comme tout enregistrement sauvé avant les fils — est lu avec une liste vide ; une entrée illisible — un champ manquant, un type ou un statut inconnu, une date impossible à analyser, des commentaires qui ne forment pas une liste — est ignorée sans masquer les autres, et un JSON stocké impossible à analyser se lit comme une liste vide. Avant que la prochaine écriture ne remplace la clé, ce qui a été ignoré — ces entrées, ou le contenu entier quand ce n'est pas un tableau JSON — est ajouté à un tableau JSON sous <key>.corrupt (par ex. siteping_feedbacks.corrupt), que le store ne supprime jamais. Si cette copie échoue, l'écriture échoue avec une StorePersistenceError et la clé reste telle quelle.
• Sous pression de quota, les captures sautent en premier. Si une écriture dépasse le quota de stockage du navigateur (~5 Mo par origine), l'adapter réessaie une fois sans la capture avant d'abandonner avec une StorePersistenceError — le commentaire survit même quand l'image ne peut pas.
• Les actions en masse sont sûres dans un même onglet. Le store applique ses écritures une par une : sélectionner plusieurs feedbacks puis les résoudre ou les supprimer ensemble les modifie tous. La garantie s'arrête à l'instance : deux onglets — ou deux LocalStorageStore sur la même key — réécrivent chacun le tableau entier, et la dernière écriture l'emporte.
• Les dates survivent à l'aller-retour — createdAt et consorts reviennent en vrais objets Date, pas en chaînes.
• Compatible SSR : sans localStorage, les lectures renvoient une liste vide et toute écriture — clear() compris — échoue avec une StorePersistenceError, jamais une exception brute.
• Les envois avec un clientId en double renvoient l'enregistrement existant, comme pour tous les autres adapters.