React + IndexDb + mise à jour automatique = presque AsyncRedux

Dans cet article, je vais vous expliquer étape par étape comment préparer IndexDB (une base de données intégrée à tout navigateur moderne) pour une utilisation dans des projets écrits en ReactJS. Par conséquent, vous pouvez utiliser les données d'IndexDB aussi facilement que si elles se trouvaient dans le magasin Redux de votre application.

IndexDB est un SGBD orienté document, un outil pratique pour le stockage temporaire d'une quantité relativement petite (unités et dizaines de mégaoctets) de données structurées côté navigateur. La tâche standard pour laquelle je dois utiliser IndexDB comprend la mise en cache des données des répertoires d'entreprises côté client (noms de pays, villes, devises par code, etc.). Après les avoir copiés côté client, vous ne pouvez télécharger qu'occasionnellement des mises à jour à partir de ces répertoires depuis le serveur (ou l'ensemble - ils sont petits) et ne pas le faire à chaque fois que vous ouvrez la fenêtre du navigateur.

Il existe des méthodes non standard, très controversées, mais efficaces pour utiliser IndexDB:

• la mise en cache des données sur tous les objets métier de sorte que du côté du navigateur, utilisez les capacités de tri et de filtrage étendues
• stockage de l'état de l'application dans IndexDB au lieu de Redux Store

Trois différences clés entre IndexDB et Redux Store sont importantes pour nous:

1. IndexDB est un stockage externe qui n'est pas effacé lorsque vous quittez la page. De plus, il en va de même pour plusieurs onglets ouverts (ce qui conduit parfois à un comportement quelque peu inattendu)
2. IndexDB est un SGBD complètement asynchrone. Toutes les opérations - ouverture, lecture, écriture, recherche - asynchrone.
3. IndexDB ne peut pas (de manière triviale) être stocké dans JSON et utiliser des techniques de lavage de cerveau Redux pour créer des instantanés, faciliter le débogage et voyager dans le passé.

Étape 0: liste des tâches

Déjà un exemple classique avec une liste de tâches. Variante avec stockage d'état dans l'état du composant actuel et unique


Jusqu'à présent, toutes les opérations avec des tâches sont synchrones. Si l'ajout d'une tâche prend 3 secondes, le navigateur se fige juste pendant 3 secondes. Bien sûr, alors que nous gardons tout en mémoire, nous ne pouvons pas y penser. Lorsque nous incluons le traitement avec un serveur ou avec une base de données locale, nous devrons également nous occuper du beau traitement de l'asynchronie. Par exemple, bloquer le travail avec une table (ou des éléments individuels) lors de l'ajout ou de la suppression d'éléments.

Afin de ne pas répéter la description de l'interface utilisateur à l'avenir, nous la placerons dans un composant TaskList distinct, dont la seule tâche générera le code HTML de la liste des tâches. Dans le même temps, nous remplacerons les boutons habituels par un wrapper spécial autour du bouton d'amorçage, qui bloquera le bouton jusqu'à ce que le gestionnaire de boutons termine son exécution, même si ce gestionnaire est une fonction asynchrone.



Déjà dans l'exemple de code, vous pouvez voir les mots-clés async / wait. Les constructions asynchrones / attendent peuvent réduire considérablement la quantité de code qui fonctionne avec Promises. Le mot-clé wait vous permet d'attendre une réponse d'une fonction renvoyant Promise, comme s'il s'agissait d'une fonction régulière (au lieu d'attendre un résultat dans then ()). Bien sûr, une fonction asynchrone ne se transforme pas par magie en une fonction synchrone et, par exemple, le thread d'exécution sera interrompu lorsque l'attente est utilisée. Mais alors le code devient plus concis et compréhensible, et wait peut être utilisé à la fois dans les boucles et dans les constructions try / catch / finally.

Par exemple, TaskList appelle non seulement le gestionnaire this.props.onAdd , mais le fait à l'aide du mot clé this.props.onAdd . Dans ce cas, si le gestionnaire est une fonction normale qui ne renverra rien ou ne renverra aucune valeur autre que Promise , le composant TaskList continuera simplement la méthode handleAdd de la manière habituelle. Mais si le gestionnaire renvoie Promise (y compris si le gestionnaire est déclaré en tant que fonction asynchrone), alors la TaskList attendra la fin de l'exécution du gestionnaire, et ce n'est newTaskAdding les valeurs des newTaskText newTaskAdding et newTaskText seront réinitialisées.

Étape 1: ajouter IndexDB au composant React

Pour simplifier notre travail, nous allons d'abord écrire un composant simple qui implémente les méthodes Promise pour:

• ouverture d'une base de données avec gestion des erreurs triviale
• rechercher des éléments dans la base de données
• ajout d'éléments à la base de données

Le premier est le plus «non trivial» - jusqu'à 5 gestionnaires d'événements. Cependant, pas de science fusée:



Mettre tout cela ensemble dans une classe IndexedDbRepository


Vous pouvez maintenant accéder à IndexDB à partir du code:

  const db = new IndexedDbRepository( 'id' ); // ,     await db.save( { id: 42, text: 'Task text' } ); const item = await db.findById( 42 ); const items = await db.findAll(); 

Connectez ce «référentiel» à notre composant. Selon les règles de react, un appel au serveur doit être dans la méthode componentDidMount ():

 import IndexedDbRepository from '../common/IndexedDbRepository'; /*...*/ componentDidMount() { this.repository = new IndexedDbRepository( 'id' ); //     this.repository.findAll().then( tasks => this.setState( { tasks } ) ); } 

Théoriquement, la fonction componentDidMount() peut être déclarée async, puis les constructions async / attendent peuvent être utilisées à la place de then (). Mais componentDidMount() n'est toujours pas «notre» fonction, mais appelé par React. Qui sait comment la bibliothèque react 17.x se comportera en réponse à une tentative de retour de Promise au lieu d'être undefined ?

Maintenant, dans le constructeur, au lieu de le remplir avec un tableau vide (ou un tableau avec des données de test), nous le remplirons avec null. Et dans le rendu, il traitera ce null comme la nécessité d'attendre le traitement des données. Ceux qui souhaitent, en principe, peuvent mettre cela dans des drapeaux séparés, mais pourquoi produire des entités?

  constructor() { super( ...arguments ); this.state = { tasks: null }; /* ... */ } /* ... */ render() { if ( this.state.tasks === null ) return <><Spinner animation="border" aria-hidden="true" as="span" role="status" /><span>  ...</span></>; /* ... */ } 

Il reste à implémenter les handleAdd / handleDelete :

  constructor() { /* ... */ this.handleAdd = async( newTaskText ) => { await this.repository.save( { id: counter(), text: newTaskText } ); this.setState( { tasks: null } ); this.setState( { tasks: await this.repository.findAll() } ); }; this.handleDelete = async( idToDelete ) => { await this.repository.deleteById( idToDelete ); this.setState( { tasks: null } ); this.setState( { tasks: await this.repository.findAll() } ); }; } 

Dans les deux gestionnaires, nous nous tournons d'abord vers le référentiel pour ajouter ou supprimer un élément, puis nous effaçons l'état du composant actuel et demandons à nouveau une nouvelle liste au référentiel. Il semble que les appels à setState () se feront l'un après l'autre. Mais le mot-clé wait dans les dernières lignes des gestionnaires provoquera le deuxième appel setState () uniquement après la résolution de Promise () obtenue à partir de la méthode findAll ().

Étape 2. Écoutez les changements

Un gros défaut dans le code ci-dessus est que, premièrement, le référentiel est connecté dans chaque composant. Deuxièmement, si un composant modifie le contenu du référentiel, l'autre composant n'en est pas informé jusqu'à ce qu'il relise l'état suite à des actions de l'utilisateur. C'est gênant.

Pour lutter contre cela, nous allons introduire le nouveau composant RepositoryListener et le laisser faire deux choses. Ce composant, dans un premier temps, pourra s'abonner aux modifications du référentiel. Deuxièmement, RepositoryListener informera le composant qui l'a créé de ces modifications.

Tout d'abord, en ajoutant la possibilité d'enregistrer des gestionnaires dans IndexedDbRepository:

 export default class IndexedDbRepository { /*...*/ constructor( keyPath ) { /*...*/ this.listeners = new Set(); this.stamp = 0; /*...*/ } /*...*/ addListener( listener ) { this.listeners.add( listener ); } onChange() { this.stamp++; this.listeners.forEach( listener => listener( this.stamp ) ); } removeListener( listener ) { this.listeners.delete( listener ); } } 

( code source github )

Nous passerons un tampon aux gestionnaires, qui changera à chaque appel à onChange (). Et nous modifions la méthode _tx pour que onChange() appelé pour chaque appel dans une transaction en mode readwrite :

  async _tx( txMode, callback ) { await this.openDatabasePromise; // await db connection try { const transaction = this.dbConnection.transaction( [ OBJECT_STORE_NAME ], txMode ); const objectStore = transaction.objectStore( OBJECT_STORE_NAME ); return await callback( objectStore ); } finally { if ( txMode === 'readwrite' ) this.onChange(); // notify listeners } } 

( code source github )

Si nous utilisions toujours then() / catch() pour travailler avec Promise, nous devrions soit dupliquer l'appel à onChange() , soit utiliser des polyfills spéciaux pour Promise () qui prennent en charge final() . Heureusement, async / wait vous permet de le faire simplement et sans code inutile.

Le composant RepositoryListener lui-même connecte un écouteur d'événements dans les méthodes componentDidMount et componentWillUnmount:


Nous allons maintenant inclure le traitement des modifications du référentiel dans notre composant principal et, guidés par le principe DRY , nous supprimerons le code correspondant du handleDelete handleAdd / handleDelete :

  constructor() { super( ...arguments ); this.state = { tasks: null }; this.handleAdd = async( newTaskText ) => { await this.repository.save( { id: counter(), text: newTaskText } ); }; this.handleDelete = async( idToDelete ) => { await this.repository.deleteById( idToDelete ); }; this.handleRepositoryChanged = async() => { this.setState( { tasks: null } ); this.setState( { tasks: await this.repository.findAll() } ); }; } componentDidMount() { this.repository = new IndexedDbRepository( 'id' ); this.handleRepositoryChanged(); // initial load } 

( code source github )

Et nous ajoutons un appel à handleRepositoryChanged à partir du RepositoryListener connecté:

  render() { /* ... */ return <RepositoryListener onChange={this.handleRepoChanged} repository={this.repository}> <TaskList onAdd={this.handleAdd} onDelete={this.handleDelete} tasks={this.state.tasks} /> </RepositoryListener>; } 

( code source github )

Étape 3. Retirez le chargement des données et leur mise à jour dans un composant distinct

Nous avons écrit un composant qui peut recevoir des données du référentiel, peut changer des données dans le référentiel. Mais si vous imaginez un grand projet avec plus de 100 composants, il s'avère que chaque composant qui affiche des données du référentiel sera obligé de:

• Assurez-vous que le référentiel est correctement connecté à partir d'un seul point
• Fournir le chargement initial des données dans la méthode componentDidMount()
• Connectez le composant RepositoryListener , qui fournit un appel de gestionnaire pour recharger les modifications

Y a-t-il trop d'actions en double? Il semble que non. Et si quelque chose est oublié? Se perdre avec le copier-coller?

Ce serait formidable de s'assurer en quelque sorte que nous écrivons une fois la règle pour obtenir la liste des tâches du référentiel, et quelque chose de magique exécute ces méthodes, nous donne des données, traite les changements dans le référentiel, et pour le tas, il peut également connecter ce référentiel.

 this.doFindAllTasks = ( repo ) => repo.findAll(); /*...*/ <DataProvider doCalc={ this.doFindAllTasks }> {(data) => <span>...   -,   data...</span>} </DataProvider> 

Le seul moment non trivial dans l'implémentation de ce composant est que doFindAllTasks () est Promise. Pour faciliter notre travail, nous allons créer un composant distinct qui attend l'exécution de Promise et appelle un descendant avec une valeur calculée:


Ce composant dans sa logique et sa structure interne est très similaire à RepositoryListener. Parce que l'un et l'autre doivent «signer», «écouter» les événements et les traiter d'une manière ou d'une autre. Et gardez également à l'esprit que les événements dont vous devez écouter peuvent changer.

De plus, le composant très magique DataProvider semble jusqu'à présent très simple:

 import repository from './RepositoryHolder'; /*...*/ export default class DataProvider extends PureComponent { constructor() { super( ...arguments ); this.handleRepoChanged = () => this.forceUpdate(); } render() { return <RepositoryListener onChange={this.handleRepoChanged} repository={repository}> <PromiseComponent promise={this.props.doCalc( repository )}> {data => this.props.children( data )} </PromiseComponent> </RepositoryListener>; } } 

( code source github )

En effet, nous avons pris le référentiel (et un RepositoryHolder singlenton séparé, qui est maintenant en importation), appelé doCalc, cela vous permettra de transférer des données de tâche vers this.props.children, et donc de dresser une liste de tâches. Singlenton a aussi l'air simple:

 const repository = new IndexedDbRepository( 'id' ); export default repository; 

Remplacez maintenant l'appel de base de données du composant principal par l'appel DataProvider:

 import repository from './RepositoryHolder'; /* ... */ export default class Step3 extends PureComponent { constructor() { super( ...arguments ); this.doFindAllTasks = repository => repository.findAll(); /* ... */ } render() { return <DataProvider doCalc={this.doFindAllTasks} fallback={<><Spinner animation="border" aria-hidden="true" as="span" role="status" /><span>  ...</span></>}> { tasks => <TaskList onAdd={this.handleAdd} onDelete={this.handleDelete} tasks={tasks} /> } </DataProvider>; } } 

( code source github )

Cela pourrait s'arrêter. Cela s'est plutôt bien passé: nous décrivons la règle de réception des données, et un composant séparé surveille la réception réelle de ces données, ainsi que la mise à jour. Il y avait littéralement quelques petites choses:

• Pour chaque demande de données, quelque part dans le code (mais pas dans la méthode render() vous devez décrire la fonction d'accès au référentiel, puis transmettre cette fonction au DataProvider
• L'appel au DataProvider est grand et tout à fait dans l'esprit de React, mais très moche du point de vue de JSX. Si vous avez plusieurs composants, deux ou trois niveaux d'imbrication de différents DataProviders vous embrouilleront beaucoup.
• Il est regrettable que la réception des données se fasse dans un composant (DataProvider) et que leur modification se fasse dans un autre (composant principal). Je voudrais le décrire avec le même mécanisme.

Étape 4. connect ()

Familier avec react-redux par le titre du titre déjà deviné. Je ferai le conseil suivant au reste: ce serait bien si, au lieu d'appeler children () avec des paramètres, le composant de service DataProvider remplirait les propriétés de notre composant en fonction des règles. Et si quelque chose a changé dans le référentiel, cela changerait simplement les propriétés avec le mécanisme React standard.

Pour cela, nous utiliserons le composant d'ordre supérieur. En fait, ce n’est rien de compliqué, c’est juste une fonction qui prend une classe de composants comme paramètre et donne un autre composant plus complexe. Par conséquent, notre fonction que nous écrivons sera:

• Prenez comme argument la classe de composants où passer les paramètres
• Acceptez un ensemble de règles, comment obtenir des données du référentiel et dans quelles propriétés les mettre
• Dans son utilisation, elle sera similaire à la fonction connect () de react-redux .

L'appel à cette fonction ressemblera à ceci:

 const mapRepoToProps = repository => ( { tasks: repository.findAll(), } ); const mapRepoToActions = repository => ( { doAdd: ( newTaskText ) => repository.save( { id: counter(), text: newTaskText } ), doDelete: ( idToDelete ) => repository.deleteById( idToDelete ), } ); const Step4Connected = connect( mapRepoToProps, mapRepoToActions )( Step4 ); 

Les premières lignes Step4 mappage entre le nom de propriété du composant Step4 et les valeurs qui seront chargées à partir du référentiel. Vient ensuite le mappage des actions: que se passera-t-il si Step4 appelez this.props.doAdd(...) ou this.props.doDelete(...) partir du composant Step4 . Et la dernière ligne rassemble tout et appelle la fonction de connexion. Le résultat est un nouveau composant (c'est pourquoi cette technique est appelée composant d'ordre supérieur). Et nous n'exporterons plus du fichier le composant Step4 d'origine, mais le wrapper qui l'entoure:

 /*...*/ class Step4 extends PureComponent { /*...*/ } /*...*/ const Step4Connected = connect( /*...*/ )( Step4 ); export default Step4Connected; 

Et le composant de travail avec TaskList ressemble maintenant à un simple wrapper:

 class Step4 extends PureComponent { render() { return this.props.tasks === undefined || this.props.tasks === null ? <><Spinner animation="border" aria-hidden="true" as="span" role="status" /><span>  ...</span></> : <TaskList onAdd={this.props.doAdd} onDelete={this.props.doDelete} tasks={this.props.tasks} />; } } 

( code source github )

Et c'est tout. Aucun constructeur, aucun gestionnaire supplémentaire - tout est placé par la fonction connect () dans les accessoires du composant.

Reste à voir à quoi devrait ressembler la fonction connect ().


Le code ne semble pas non plus très compliqué ... bien que si vous commencez à plonger, des questions se poseront. Vous devez lire depuis la fin. C'est là que la fonction connect() est définie. Il prend deux paramètres, puis renvoie une fonction qui renvoie ... encore une fonction? Pas vraiment. La dernière construction d' props => <Connected... renvoie non seulement une fonction, mais un composant fonctionnel React . Ainsi, lorsque nous intégrerons ConnectedStep4 dans une arborescence virtuelle, cela inclura:

• parent -> composant fonctionnel anonyme -> Connect -> RepositoryListener -> PromisesComponent -> Step4

Jusqu'à 4 classes intermédiaires, mais chacune remplit sa fonction. Un composant sans nom prend les paramètres passés à la fonction connect(), la classe du composant imbriqué, les propriétés qui sont transférées au composant lui-même lorsqu'il est appelé (props) et les transmet déjà au composant Connect. Le composant Connectest chargé d'obtenir un ensemble à partir des paramètres transmis Promise(un objet dictionnaire avec des clés de ligne et des valeurs de promesse). PromisesComponentfournit le calcul des valeurs, en les renvoyant au composant Connect, qui, avec les propriétés transférées d'origine (accessoires), les propriétés calculées (valeurs) et les propriétés-actions (actions), les transmet au composant Step4(via un appel React.createElement(...)). Eh bien, le composantRepositoryListenermet à jour le composant, forçant à recalculer promis'y si quelque chose a changé dans le référentiel.

Par conséquent, si l'un des composants souhaite utiliser le référentiel depuis IndexDb, il lui suffira de connecter une fonction connect(), de déterminer le mappage entre les propriétés et les fonctions d'obtention de propriétés du référentiel et de les utiliser sans aucun mal de tête supplémentaire.

Étape 5. @ vlsergey / react-indexdb-repo

Enfin, nous organisons tout cela sous la forme d'une bibliothèque afin que d'autres développeurs puissent l'utiliser dans leurs projets. Le résultat de cette étape a été:

• Bibliothèque @ vlsergey / REACT-Promesse - mise en œuvre PromiseComponent et PromisesComponent soutenir les résultats de Memoization (à moins UI « tics » lorsque nous sans intérêt à des changements)
• Bibliothèque @ vlsergey / REACT-indexdb-repo - IndexedDbRepository de mise en œuvre, fonction de connexion () et certaines classes utilitaires
• Un exemple d'utilisation de cette bibliothèque pour créer une liste de tâches

Au lieu d'une conclusion: ce qui reste à la mer

Le code ci-dessus est déjà suffisamment pratique pour être utilisé dans des solutions industrielles. Mais n'oubliez pas les limitations:

• Les propriétés qui ne changent pas toujours devraient conduire à de nouvelles promesses. Ici, vous devez utiliser la fonction de mémorisation, mais prenez en compte l'indicateur de changement de base de données. C'est là que le tampon de IndexedDbRepository est utile (peut-être que ce morceau de code semblait redondant pour quelqu'un).
• La connexion du référentiel via l'importation, même en un seul endroit, est incorrecte. Il faut regarder vers l'utilisation des contextes.
• , IndexedDB .
• : . . IndexDB «» , — .
• , IndexDB Redux Storage. IndexDB , .

Online-