Comment faire pour utiliser les travailleurs de service pour communiquer sur les onglets du navigateur –

Cette interview a été republiée à partir de Versioning le bulletin d'abonnement quotidien de SitePoint qui aide les développeurs à rester informés et à jour en leur proposant des liens vers l'essentiel en front-end, back-end, design et UX. , nouvelles, affaires et plus encore. En savoir plus et inscrivez-vous ici .

Tim Evko est un développeur front-end, gérant une base de code principalement React, et chef d'équipe chez ExecThread, un entreprise axée sur la création d'emplois pour les professionnels. Quand il n'est pas à ExecThread, il passe le reste de son temps dans un gymnase local, travaillant à être un meilleur athlète Crossfit compétitif.

Quelle idée ou tendance technologique vous excite le plus en ce moment?

Dernièrement, j'ai été fasciné par la technologie Service Worker en particulier lorsqu'il est utilisé pour aider les sites à se charger rapidement et devenir rapidement interactif. J'adore les performances et les fonctionnalités Web hors application, et je pense que la communauté peut bénéficier de l'attention accrue portée à la création d'applications résilientes, polyvalentes et rapides.

Travailleurs de service sont particulièrement agréables à travailler en raison de tout ce que vous pouvez faire avec eux. Récemment, j'ai appris que vous pouviez utiliser un technicien de maintenance pour communiquer entre les onglets d'un navigateur, permettant à chaque onglet de se recharger si le cache était obsolète. Ce n'est pas une technologie facile à utiliser, mais je suis très heureux que ce soit là!

Je ne pense pas avoir déjà entendu parler de cela auparavant – pourriez-vous entrer dans les détails?

Dans un navigateur, Service Workers avoir le contrôle sur tous les clients qui sont dans la portée disponible, pas seulement sur l'onglet actif actuel. Cela signifie que lorsqu'un technicien de service communique avec un site de votre navigateur, il communique toujours avec tous les onglets qui affichent actuellement ce site. Vous pouvez tirer parti de cette fonctionnalité lorsque vous utilisez l'API postMessage fournie avec Service Worker. Un exemple détaillé de cela peut être trouvé ici . Chez ExecThread, nous utilisons cette fonctionnalité pour recharger tous les onglets dans le cas où un travailleur du service sert un ancien fichier CSS sur une page avec un nouveau balisage dessus

Décrivez (ou liez vers!) Quelque chose de cool que vous avez construit, conçu ou produit récemment. Pourquoi en êtes-vous fier?

J'ai récemment entrepris de comprendre comment fonctionnaient les algorithmes DOM virtuels et, ce faisant, j'ai construit mon propre moteur de rendu de composants: BadDom [github]. C'est 600 octets et vous pouvez construire votre application web entière avec. Je suis fier de cela parce que c'est 600 octets et que vous pouvez construire votre application web entière avec elle.

BadDOM est vraiment très simple, et c'est ce que j'aime. Si vous lui donnez un noeud (un div sur une page par exemple) et une chaîne de template ES6, il mettra à jour le premier div pour qu'il corresponde à la chaîne du template. Essentiellement c'est une fonction de DOM-diffing qui s'assure que sa cible ressemblera à la chaîne de template.

Comme c'est une chaîne de template ES6 cependant, vous pouvez ajouter de la logique à votre diffing. Cela signifie que vous pouvez appeler la fonction diffing chaque fois que vous mettez à jour l'état de votre logique et que votre cible DOM d'origine correspond au nouvel état. Le tout fonctionne en créant un élément invisible avec votre chaîne de modèle, et en comparant l'élément cible (et ses enfants) pour trouver, supprimer ou modifier tous les nœuds DOM jusqu'à ce que l'élément basé sur la chaîne modèle et l'élément cible soient identiques. C'est efficace car il ne met jamais à jour un élément qui n'a pas besoin d'être mis à jour, empêchant ainsi le navigateur de faire un travail inutile. Si vous avez 100 éléments imbriqués et qu'un seul nom de classe change sur l'un d'entre eux, BadDom trouvera le seul et unique changement de classe.

Comment l'avez-vous construit?

Comme la plupart de mes projets, j'ai construit ça CodePen. J'aime me concentrer sur garder les choses aussi simples que possible avec aussi peu d'outils de construction / configuration que possible. De cette façon, il est plus facile pour quiconque de comprendre et de contribuer, quelles que soient les plates-formes ou les appareils qu'ils utilisent. CodePen est génial car je n'ai pas besoin de configurer un IDE pour travailler sur les bibliothèques frontales. Je pourrais parler toute la journée de CodePen, de la communauté, et de ce que j'ai appris des autres, mais je dirais plutôt que tout le monde devrait chercher par lui-même.

JavaScript en utilisant le modèle Module, que j'ai fait ici. Le modèle de module est un moyen d'écrire du JavaScript pour que tout le code soit à l'intérieur d'un objet autonome. Les méthodes à l'intérieur de l'objet sont stockées en tant que fonctions-as-properties, et les valeurs de configuration peuvent être stockées en tant qu'objets-en-propriétés. J'aime utiliser ce pattern car il est facile d'organiser le code (en particulier les bibliothèques). Vous pouvez en savoir plus sur le modèle ici .

Quelle est la meilleure chose que vous avez lue récemment, et pourquoi?

Resilient Web Design par Jeremy Keith – Jeremy est un excellent auteur, et ce livre est écrit exactement comme le code des états du livre doit être écrit.

Quel était le lien hors-sujet le plus drôle ou intéressant que vous avez envoyé à un ami récemment?

Sur la côte Est, États-Unis , c'est en quelque sorte encore l'hiver. J'ai envoyé ceci à ma femme l'autre jour:

C'est très bien, en effet! Il y a cette semaine, grâce à Tim pour avoir partagé la technologie qui le passionne le plus.

        

          
            

Adam est responsable des newsletters de SitePoint, qui écrit principalement Versioning un bulletin d'information quotidien couvrant tout ce qui est nouveau et intéressant dans le monde du développement web. Il a une barbe et vous parlera de la bière et de Star Wars, si vous le laissez faire.

Tim Evko est un développeur Web de New York, avec une passion pour le développement web réactif, Sass et JavaScript. Il vit du café, des démos CodePen et des chemises de flanelle.