Comment personnaliser les employés de service avec create-react-app

Personnaliser, ne pas éjecter!

Ceci fait suite à mon précédent article sur la création d'un PWA avec create-react-app (CRA). Dans l'article lié, j'ai discuté de la manière dont nous pourrions créer un agent de service tout en restant dans le shell create-react-app.

Si vous aviez suivi le post (et l'aviez fait fonctionner, espérons-le), vous auriez remarqué une faille critique. Il est encore extrêmement difficile de développer un logiciel dans un environnement de développement. Pour l’essentiel, vous devez modifier votre code SW, exécuter un processus de construction, le tester, résoudre tous les bugs, actualiser et répéter. Parlant d'expérience, c'est un processus épuisant.

Continuons et trouvons comment résoudre ce problème.

Travailler en mode Dev

Bon, alors comment pouvons-nous faire fonctionner un logiciel en mode dev, afin que nous puissions rapidement écrire du mauvais code et déterminer ce qui fonctionne et ce qui ne fonctionne pas?

Tout d’abord, voyons pourquoi cela ne fonctionne pas en mode dev. Créez un nouveau projet CRA et ouvrez le fichier registerServiceWorker.js sous le répertoire src.

Dans l’essentiel ci-dessus, je n’ai que le code pertinent. Vous remarquerez une vérification conditionnelle process.env.NODE_ENV === 'production'. Ceci vérifie si vous exécutez une version de production. Si vous n’exécutez pas de version de production, le logiciel sera remplacé par un fichier no-op.

Le raisonnement derrière cette décision est fourni dans ce numéro de GitHub.

Commencez par essayer de lancer yarn start sur votre application et de rechercher un fichier SW dans la fenêtre de la barre d’outils. Si vous cliquez sur le lien service-worker.js dans la barre d'outils, le fichier suivant s'affichera:

Heureusement, il existe une solution simple à cela. C’est un processus simple en deux étapes.

Tout d'abord, dans le fichier registerServiceWorker.js, recherchez l'appel de fonction window.addEventListener ('load'). La première ligne est une déclaration pour swUrl qui dit:

const swUrl = `$ {process.env.PUBLIC_URL} / service-worker.js`;

Renommez le membre du personnel de service avec n'importe quoi d'autre. Je vais nommer mine service-worker-custom.js.

Deuxièmement, créez un fichier dans votre répertoire public avec exactement le même nom que le nom personnalisé que vous venez de créer. Je créerais donc un fichier appelé service-worker-custom.js dans le répertoire public.

Maintenant, dans le service-worker-custom.js, placez une instruction de journal simple. Quelque chose comme: console.log ('Mon opérateur de service personnalisé').

Maintenant, lancez à nouveau votre application avec start et vous devriez voir l’instruction log apparaître dans la console de votre navigateur. Vous aurez peut-être besoin de désenregistrer un ouvrier de service précédent si vous avez déjà démarré le fil auparavant.

Donc là vous l'avez. Un technicien de service personnalisé que vous pouvez exécuter en toute sécurité dans le mode dev.

Remarque: Il est déconseillé de tester un technicien de service dans un env. Dev en dehors du mode de navigation privée de votre navigateur. Assurez-vous également que la case Mettre à jour lors du rechargement est cochée dans la fenêtre de vos outils de développement lorsque vous testez en mode dev.

Combinant Dev et Prod

Nous avons maintenant compris comment tester un logiciel en mode dev. Cependant, nous devons également trouver un moyen d'injecter notre code personnalisé dans le logiciel généré par l'ARC dans une version de production.

Si vous conservez tout tel quel avec les configurations que nous avons effectuées jusqu’à présent, lancez un processus de construction et vérifiez la construction dans votre navigateur, vous remarquerez que le fichier SW généré est celui que nous avons personnalisé. C'est un problème, car nous voulons pouvoir combiner la qualité de ce que l'ARC a à nous offrir avec notre propre code.

Nous pouvons le faire avec la bibliothèque esw-precache. J'ai introduit cette bibliothèque dans mon post précédent. Voici le lien GitHub vers la bibliothèque sw-precache.

Installez la bibliothèque avec le fil add sw-precache. Une fois cela fait, créez un fichier sw-precache-config.js dans votre répertoire racine. Voici mon dossier:

J'ai introduit la plupart de ce fichier dans le post précédent. Le seul nouveau bit est l'option importScripts. Ceci est assez explicite, il importe simplement le fichier spécifié par le chemin, et nous essayons d'importer notre fichier SW personnalisé.

Vous remarquerez que le chemin du fichier ne contient pas le préfixe ./public, alors que le fichier est présent dans notre répertoire public. Je vais expliquer cela dans un instant.

Maintenant, mettez à jour votre fichier package.json avec une modification de la commande de construction. Faites votre commande de construction les éléments suivants:

react-scripts build && sw-precache --config = sw-precache-config.js

Revenons maintenant au chemin de fichier que nous avons fourni à l’option importScripts. Si vous remarquez, sw-precache s’exécute essentiellement en tant que processus de post-génération. Désormais, si vous exécutez simplement un processus de construction et ouvrez le répertoire de construction créé, vous remarquerez que votre fichier de travailleur de service personnalisé se trouve dans le dossier de construction. Lorsque nous fournissons un chemin d'accès à l'option importScripts, nous le fournissons par rapport au répertoire de construction!

Une fois que tout est terminé, lancez la version de construction de votre application et vous remarquerez que l’instruction du journal s’affiche de nouveau dans la console de votre navigateur.

Bien, tu l'as maintenant! Vous pouvez maintenant injecter du code personnalisé dans le logiciel par défaut généré par l'ARC!