Créez des interfaces utilisateur multi-thread ultra rapides en dehors de Node.js

Online Coding Courses for Kids

Créez des interfaces utilisateur multi-thread ultra rapides en dehors de Node.js

La plupart des développeurs frontaux passent à côté du niveau supérieur de ce qui est possible dans les navigateurs modernes

photo par Luca Bravo sur Unsplash

Contenu

  1. introduction
  2. Comment WebWorkers peut-il aider?
  3. Applications multi-écrans
  4. Applications multi-écrans sur mobile
  5. Comment pouvons-nous inclure le code de notre application dans un travailleur?
  6. Que sont les méthodes à distance?
  7. Quel est le problème avec les modèles?
  8. Réduction du DOM de 80% + en moyenne
  9. Code ES8 + directement dans le navigateur
  10. Obtenez la documentation de votre application prête à l’emploi
  11. Vous êtes curieux? Qu’est-ce que neo.mjs?
  12. Comment se mettre à niveau?
  13. Qu’est-ce qui va suivre?

1. Introduction

Le Web avance à une vitesse élevée – mais vous?

Lorsque Angular et React ont été introduits, les navigateurs ne supportaient pas les fonctionnalités ES6 +. En conséquence, tout le développement de l’interface utilisateur a été déplacé dans node.js.

Les navigateurs ont rattrapé leur retard et peuvent désormais gérer seuls les modules JavaScript ainsi que plusieurs fonctionnalités ESnext. Il est donc temps de changer.

Bien qu’il puisse être pratique d’utiliser des fichiers personnalisés tels que .vue, votre navigateur ne peut pas les comprendre. Vous avez besoin d’un processus de construction, d’une transpilation ou au moins d’un remplacement de module à chaud pour obtenir vos modifications de code dans le navigateur. Cela prend du temps et vous ne pouvez pas déboguer votre vrai code.

La plupart des applications utilisent encore aujourd’hui la configuration suivante:

Certains utilisent WebWorkers pour déplacer des tâches coûteuses uniques, mais ce n’est pas suffisant. Le thread principal est responsable des manipulations DOM – la file d’attente de rendu. L’objectif principal doit être d’obtenir le moins d’inactivité et de légèreté possible.

2. Comment WebWorkers peut-il aider?

Ce que nous voulons sortir de ce dilemme, ce sont les configurations suivantes:

Un framework et la logique de votre application peuvent et doivent s’exécuter à l’intérieur d’un worker.

Avec cette configuration, il n’y a aucune tâche d’arrière-plan dans le thread principal. Rien ne peut ralentir ou même geler vos transitions d’interface utilisateur.

Avec un simple commutateur pour utiliser SharedWorkers au lieu de travailleurs normaux, nous pouvons même connecter plusieurs threads principaux.

3. Applications multi-écrans

Bien qu’il s’agisse d’une utilisation de niche, il peut créer une expérience utilisateur incroyable pour développer des applications d’une seule page dans plusieurs fenêtres de navigateur.

Regardez cette vidéo de démonstration des années 95:

https://medium.com/media/c4abbcfaa4ea1017bde3ca79ecf261f1/href

  • Toutes les fenêtres de navigateur partagent les données du backend.
  • Toutes les fenêtres peuvent communiquer directement (sans connexion backend).
  • Vous pouvez déplacer des arborescences de composants entières, même en conservant les mêmes instances JavaScript.

4. Applications multi-écrans sur mobile

Ce sera un gros problème. De nombreuses applications mobiles utilisent un shell natif, contenant plusieurs WebViews. La configuration de SharedWorkers peut également fonctionner ici, ce qui entraîne le chargement du framework et du code lié à l’application une seule fois et, plus important encore, le déplacement des arborescences de composants autour des WebViews.

L’équipe Webkit (Safari) envisage de reprendre ce sujet. GitHub a ajouté du poids au ticket:

149850 – Rétablir le support pour SharedWorkers

Vous devriez vraiment faire la même chose!

5. Comment pouvons-nous inclure notre code d’application dans un travailleur?

Votre fichier index.html ressemblera à ceci (mode dev):

Il vous suffit d’extraire le code du thread principal du framework (40 Ko).

Vous n’avez pas besoin de créer ce fichier manuellement. Tout ce que vous avez à faire est:

npx neo-app

Ou clonez le dépôt et utilisez le programme create-app. Cela importera le WorkerManager et générera les travailleurs pour vous, enregistrera les méthodes à distance et chargera le code de votre application dans le travailleur de l’application.

https://github.com/neomjs/neo/blob/dev/src/worker/Manager.mjs

Si vous examinez de plus près les fichiers, vous remarquerez que toutes les mises à jour de dom virtuel sont mises en file d’attente dans requestAnimationFrame. Vous pouvez créer vous-même une configuration similaire ou laisser neo.mjs s’en occuper pour vous.

6. Que sont les méthodes à distance?

Dans le cas où vous souhaitez communiquer entre Workers ou avec le thread principal, vous aurez peut-être besoin d’une couche d’abstraction autour des postMessages requis.

Cela peut demander beaucoup de travail, surtout si vous souhaitez également prendre en charge SharedWorkers.

Si vous exécutez votre propre code à l’intérieur d’un Worker (dans le contexte neo.mjs, l’application worker), vous remarquerez que:

  • la fenêtre n’est pas définie
  • window.document n’est pas défini

Vous ne pouvez tout simplement pas accéder au vrai DOM. Cela rend l’utilisation d’un DOM virtuel obligatoire.

Pourtant, il existe des cas d’utilisation marginaux où vous souhaitez accéder directement au DOM. Le défilement est bon:

https://github.com/neomjs/neo/blob/dev/src/main/DomAccess.mjs#L402

Comme son nom l’indique, Neo.main.DomAccess n’est disponible que dans le thread principal. Il n’est pas importé dans l’application Worker.

Tout ce que vous avez à faire est d’ajouter les méthodes que vous souhaitez exposer à différents nœuds de calcul ou au thread principal.

Maintenant, dans votre champ d’application (le travailleur de l’application), vous pouvez appeler ces méthodes distantes comme des promesses. Ils seront mappés à l’espace de noms Neo dès la sortie de la boîte.

https://github.com/neomjs/neo/blob/dev/src/calendar/view/MonthComponent.mjs#L216

C’est aussi simple que ça.

7. Quel est le problème avec les modèles?

Angular, React et Vue utilisent tous des modèles basés sur des chaînes pseudo XML. Ces modèles doivent être analysés, ce qui coûte cher. Vous pouvez le faire au moment de la construction (par exemple, Svelte), mais vous ne pouvez plus les modifier facilement au moment de la construction. C’est possible (par exemple, manipuler manuellement une sortie JSX), mais à ce stade, il n’est plus cohérent à utiliser.

Les modèles sont un mélange de balisage dom, de boucles, d’instructions if et de variables. Ils peuvent ralentir votre productivité (par exemple, le cadrage) et vous limiter.

Bien que ce sujet soit certainement controversé, neo.mjs s’est débarrassé des modèles. Au lieu de cela, des structures persistantes de type JSON sont en place:

https://github.com/neomjs/neo/blob/dev/src/calendar/view/MonthComponent.mjs#L99

JSON-like signifie: des objets et tableaux JS imbriqués, que vous pouvez modifier comme vous le souhaitez pendant le cycle de vie complet du composant. Ils ne contiennent pas de variables, d’instructions if ou de boucles.

Vous pouvez convenir que JavaScript est parfait pour travailler avec ces structures.

Vous n’avez jamais besoin de les analyser:

https://github.com/neomjs/neo/blob/dev/src/calendar/view/MonthComponent.mjs#L232

Le mappage des changements de configuration sur le vdom est assez simple. Vous pouvez ajouter des indicateurs à des nœuds spécifiques et utiliser VdomUtil pour les récupérer.

Vous pouvez ajouter l’indicateur removeDom à n’importe quel nœud, ce qui supprimera le nœud (ou l’arborescence) du vrai DOM tout en gardant votre structure vdom en place.

8. Réduction du DOM de 80% + en moyenne

Cet attribut removeDom que nous venons de mentionner est incroyablement puissant. Je l’ai juste utilisé pour améliorer la disposition des cartes afin de supprimer toutes les cartes inactives du DOM par défaut.

Vous pouvez également le modifier à l’aide d’une configuration, si c’est quelque chose que vous souhaitez faire.

Alors que les nœuds dont le style affiche “aucun” seront exclus des calculs de mise en page du navigateur, ils sont toujours présents.

Leur suppression réduit le DOM, ce qui réduit considérablement l’empreinte mémoire de votre thread principal.

C’est un moyen simple d’améliorer encore les performances.

Comme vous pouvez le voir, le calendrier a 4 vues principales (jour, semaine, mois, année), mais une seule est à l’intérieur du DOM.

La barre latérale sera supprimée après sa réduction.

Le SettingsContainer sera supprimé après sa réduction.

Les paramètres contiennent un TabPanel avec cinq onglets. Un seul corps d’onglet se trouve à tout moment dans le DOM.

Vos instances JavaScript de toutes les vues existent toujours. Vous pouvez toujours mapper les modifications apportées au DOM virtuel et le remettre à tout moment – à différents endroits de votre application si vous le souhaitez.

Votre état restera en place, ce qui signifie que, dans ce cas, nous pouvons modifier les paramètres des vues, qui ne sont plus à l’intérieur du DOM.

9. Code ES8 + directement dans le navigateur

Jetez un œil à la capture d’écran suivante:

Les choses importantes à noter ici sont:

  • Vous pouvez voir les threads (Main, App, Data, Vdom).
  • Le fichier WeekComponent.mjs se trouve dans App Worker.
  • Tu peux voir le réel code (ce n’est pas une carte source).
  • Vous pouvez voir les améliorations du système de classe personnalisé: Un système de configuration complet.

Cela conduit à une expérience de débogage inégalée:

  • Changez votre code, rechargez le navigateur et c’est tout.
  • Aucune compilation ou transpilation n’est nécessaire.
  • Bien que les modules JavaScript soient entièrement pris en charge dans tous les principaux navigateurs, ils ne sont toujours pas pris en charge dans le cadre de travail pour Firefox et Safari. Les équipes de développement y travaillent.
  • Pour neo.mjs, il existe des versions dist basées sur Webpack, qui fonctionnent correctement dans Firefox et Safari.

La partie importante est que Chrome le prend entièrement en charge, vous pouvez donc utiliser le mode de développement là-bas et une fois qu’il est exempt de bogues, testez la version dist / development dans d’autres navigateurs.

10. Obtenez la documentation de votre application hors de la boîte

Alors que de nombreuses bibliothèques ou frameworks fournissent une application Docs, celle-ci ne fournira que des vues de documentation pour les fichiers framework.

En utilisant neo.mjs, vous obtiendrez également des vues de documentation pour votre propre code lié à l’application. Tout ce que vous avez à faire est d’ajouter des commentaires doc à vos configurations, méthodes et événements.

11. Qu’est-ce que neo.mjs?

neo.mjs est un projet open source (toute la base de code, ainsi que tous les exemples et applications de démonstration, utilisent la licence MIT).

Application de site Web:

neo.mjs – Site Web

Dépôt:

neomjs / neo

Cela signifie que vous pouvez l’utiliser gratuitement et qu’il restera ainsi. Cependant, le projet a besoin de plus de contributeurs ainsi que de sponsors.

Beaucoup plus d’articles et d’idées sont sur la feuille de route.

Si vous souhaitez contribuer à un fantastique projet open source, nous vous serions reconnaissants.

Si le projet a ou aura une valeur commerciale pour votre entreprise, m’inscrire en tant que sponsor me permettra d’y consacrer plus de temps, ce qui se traduira par un délai de livraison plus rapide pour les nouvelles choses.

12. Comment se mettre à niveau?

Le moyen le plus simple d’apprendre neo.mjs consiste à suivre les 2 premiers tutoriels sur la création de l’application Covid Dashboard à partir de zéro.

  • Comment créer une application multithreading pilotée par les webworkers – Partie 1
  • Comment créer une application multithreading pilotée par les webworkers – Partie 2

12. Qu’est-ce qui va suivre?

En ce moment, je me concentre sur le nouveau composant de calendrier pour la version v1.4. Le but est de créer une excellente UX, en avance sur les calendriers GMail ou natifs MacOS.

Vous pouvez consulter les progrès actuels ici:

neo.mjs Calendar Basic

À l’étape suivante, je peaufinerai un peu plus les événements et commencerai par la mise en œuvre du glisser-déposer par la suite.

Une fois le glisser-déposer en place, l’élément suivant est les boîtes de dialogue dans l’application. Nous devons pouvoir les saisir par l’en-tête pour les déplacer ou les redimensionner. Une démo pour déplacer les boîtes de dialogue dans différentes fenêtres de navigateur est possible et devrait être époustouflante.

Une fois que cela sera fait, j’améliorerai davantage les implémentations de grille / table – accès plus facile au filtrage des colonnes, déplacement des colonnes, masquage des colonnes, etc.

Vous pouvez certainement influencer la feuille de route!

N’hésitez pas à utiliser le suivi des problèmes. Tous les commentaires sont appréciés!

Meilleures salutations et bon codage!


Créer des interfaces utilisateur multi-thread ultra rapides en dehors de Node.js a été initialement publié dans Better Programming on Medium, où les gens poursuivent la conversation en mettant en évidence et en répondant à cette histoire.

Close Menu