Passez offline avec Redux Persist et LocalForage

(image généreusement piquée sur http://blog.marketo.com/2016/05/live-from-marketing-nation-summit-digital-transformation-resilience-and-authenticity.html)

Le marketing vient d’avoir une idée. Une super idée même.

Une idée tellement géniale qu’il l’a déjà vendu aux clients de votre société, contacté la presse, et les investisseurs sont également très enthousiastes.

Tout va pour le mieux dans le meilleur des mondes, à un détail près : On vient tout juste de vous mettre au courant, vous, les gens de l’informatique, de cette idée. Et maintenant que le dossier de relation presse est dans les tuyaux, que le champagne est commandé et que le musée d’art contemporain de St Plessy le Boujounou a été privatisé en vue de la sortie officielle – dans 10 jours, ça va être difficile d’expliquer à tout le monde que ça aurait été sympa de vous mettre dans la boucle un petit peu avant.

Cette feature de votre app-ki-ravage tout, judicieusement appelée « Plus de 4g dans le train » par un marketeux bourré d’inspiration, consiste à pouvoir continuer à travailler avec l’application même quand la 4g part en sucette dans le train. C’est un peu comme utiliser Gmail en mode offline. Ou Google Doc en mode offline.

Bref, il va donc falloir la sortir les doigts dans le nez cette feature, en moins de dix jours. Tests compris. Validé par le marketing.

Non, aucun raison d’être aigri ou sarcastique. Vraiment. Ca ne vous ressemble pas. Vous avez fait les bons choix en amont. Votre application tourne sur React / Redux.

Ca va bien se passer. Même si on dit généralement « ça va bien se passer » dans une soirée où un truc très long en silicone et un pot de vaseline ne sont jamais bien loin.

Le contexte

Parfois on se prend la tête à vouloir proposer un mode offline. C’est surtout compliqué lorsqu’il s’agit de le faire sur une application web et que le volume de données dépasse glorieusement celui offert par le localstorage, mais c’est chiant aussi à gérer sur mobile, même avec l’async storage.

Alors on fait des compromis en utilisant une feature HTML5 désuète mais encore supportée qui est pourtant parfaite – WebSQL, ou on se prend la tête avec les indexedDb. L’idée étant de stocker les données pour pouvoir interroger ensuite la base locale comme on le ferait avec… Mysql, Mongo… enfin vous voyez l’idée.

C’est cool dans le principe, mais ça nécessite d’aller taper sur la tête du dev back pour lui demander de bosser. Et le dev back, il est un peu grognon en général. Pour un peu que ce soit un dev JAVA, non seulement il est grognon, mais en plus il a les cheveux longs. Mieux vaut éviter d’enquiquiner un gars aux cheveux longs. Encore plus s’il a un tee-shirt Hell Fest. Croyez-moi sur parole. Si si.

Fort heureusement vous avez développé votre application web en utilisant ReactJS et Redux. Du coup, l’alternative consiste non pas à vouloir sans arrêt synchroniser le back et le front, mais simplement à snapshoter votre store et à l’enregistrer localement, puis à attendre que les Internets soient disponibles pour, par exemple, envoyer le store au back, ou à envoyer certaines données à certains webservices. C’est vous et votre pote du back que ça regarde.

L’utilisateur se retrouve alors avec une copie du store en local, qu’on peut réinjecter dans l’application à l’ouverture. On peut comparer la date de dernière sauvegarde côté back à celle côté local, et synchroniser tout ce bousin si besoin.

Tout ça, on peut le faire avec Redux-Persist, LocalForage, une bière et un CD de Slipknot.

Redux Persist

L’idée est de pouvoir persister et réhydrater votre store Redux. C’est pas moi qui le dit, c’est le gars à l’origine du projet :

https://github.com/rt2zz/redux-persist

L’excellente nouvelle c’est que :

  • vous pouvez définir les reducers que vous voulez inclure ou exclure (whitelist, blacklist)
  • vous pouvez purger le store
  • vous pouvez mettre sur pause la persistance des données – pratique quand vous êtes en train de sync avec le back par exemple
  • ca s’intègre en très peu de temps sur une application Redux
  • vous pouvez crypter ce que vous persistez (la classe !!!)
  • vous pouvez définir une date d’expiration par vous même
  • ça se plug facilement à une librairie comme LocalForage, ce qui permet d’avoir un wrapper pour utiliser, par exemple, les indexedDB (qui restent à mon humble avis une API bricolée dans une usine à foutre. Voilà, c’est dit).

LocalForage

Vous connaissiez peut être Lawnchair ? Et bah LocalForage, c’est la même idée, sauf que ça fonctionne. Il s’agit de wrapper les différentes APIs qui permettent de faire du stockage local – dans le navigateur.

On a ainsi une seule API qui nous permet de profiter des volumes de stockage plus importants que le localStorage, tout en ayant un failback pour les browsers qui ne supportent pas, par exemple, les indexedDBs 

Je vous vois venir, vous croyez que j’ai quelque chose contre les indexedDB. C’est totalement sans fondement. Vraiment.

Ca se fait aussi facilement que ceci :

// web with recommended localForage
import localForage from 'localforage'
persistStore(store, {storage: localForage})

Je vous aurai bien fait une petite démo, mais Le Grand-Dieu de Redux a déjà fait un screencast qui explique parfaitement tout ça :

https://egghead.io/lessons/javascript-redux-persisting-the-state-to-the-local-storage

Pour React Native, on utilisera tout naturellement l’AsyncStorage, avec en plus la possibilité de créer une véritable application offline (ce qu’on essaie désespérément de faire pour le web avec le cache manifest depuis 5 ans).

En gros vous avez presque de facto un mode offline efficace pour toutes les applications que vous pourriez développer.

Ca va faire plaisir au marketing.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *