À peu près comme avant, choisissons cette fois la production:
Ouvrez un autre onglet du navigateur, entrez:
about:debugging#/runtime/this-firefox
Cliquez à nouveau sur «Inspecter» pour le travailleur App:
Eh bien, comme mentionné, dist / production est minifié et sans source-maps 🙂
Aperçu rapide de dist / développement:
À peu près la même que dans Chrome et raisonnable pour le débogage, car il vous suffit de travailler sur les différences dans Chrome et FF.
D’après ce que j’ai trouvé sur le Web, l’équipe Webkit a commencé à travailler sur SharedWorkers puis chuté intentionnellement.
Il y a un nouveau ticket ouvert:
Si vous vous en souciez (vous devriez vraiment!), S’il vous plaît assurez-vous d’y ajouter du poids. Plus les développeurs votent pour cela, plus les chances que cela se produise sont élevées. J’ai également ajouté un commentaire.
Cela me rendrait triste de voir Safari se transformer en IE6 du Web moderne.
neo.mjs est maintenant suffisamment intelligent pour vérifier si un navigateur prend en charge SharedWorkers ou non. Vous pouvez donc ouvrir la démo Covid pour les travailleurs partagés à l’aide de Safari, mais elle se contentera d’utiliser des travailleurs non partagés à la place.
Étant donné que toutes les applications pour tous les navigateurs Windows vivent au sein de l’application partagée, elles peuvent communiquer directement entre elles. Nous n’avons même pas besoin de postMessages.
Le travailleur d’application partagé utilise un seul IdGenerator, donc tous les composants de toutes les applications ont des ID de composant uniques.
Étant donné que nous utilisons également un travailleur Vdom partagé, cela garantit que tous les nœuds DOM sur tous les Windows ont également des ID uniques.
Cela rend tout à fait trivial de simplement déplacer des composants ou des arborescences de composants entières comme vous le souhaitez.
Encore mieux: les événements DOM sont découplés dès le début, car leurs fonctions de gestionnaire vivent à l’intérieur du travailleur de l’application. Donc, si vous vous déplacez, par exemple un bouton d’une fenêtre à une autre, le gestionnaire de clics fonctionnera toujours.
Dans le cas où le travailleur VDom deviendrait un goulot d’étranglement à un moment donné, nous pourrions simplement en ajouter un deuxième, puis utiliser des ID impairs pour le premier et même des ID pour le second. Vous avez eu l’idée. Facile, non?
Nous pourrions également penser à plusieurs travailleurs de l’application, mais cela rendrait les choses beaucoup plus compliquées. Mieux vaut déplacer des tâches coûteuses ailleurs (par exemple, le travailleur de données est encore à un stade précoce).
À l’heure actuelle, la plupart des parties (uniquement celles dont vous avez besoin pour vos applications) du framework s’exécutent déjà à l’intérieur du travailleur de l’application, de sorte que les threads principaux sont assez légers. À ce point 37 Ko pour dist / production côté JS, hors addons. Nous pourrions encore réduire cela si nécessaire.
Une fois que cela est en place, je souhaite améliorer l’application Covid basée sur SharedWorkers pour utiliser plusieurs fenêtres.
Idée:
- Ouvrez la fenêtre 1 => l’application est comme avant
- Ouvrez la fenêtre 2 => déplacez le panneau de graphiques de la fenêtre 1 vers 2 et rendez-le en plein écran
- Ouvrez la fenêtre 3 => supprimez l’onglet Helix et ajoutez-le dans la fenêtre 3, en plein écran
- Ouvrez la fenêtre 4 => supprimez l’onglet Galerie et ajoutez-le à la fenêtre 4, en plein écran
Imaginez maintenant ce qui se passe si nous sélectionnons les pays dans Window1?
Si ce n’est qu’à moitié aussi bon que je pense qu’il devrait l’être, nous pouvons nous attendre à un beau feu d’artifice d’animation.
Cela devrait être la prochaine version et un nouveau billet de blog.
Je veux également terminer la partie 2 du didacticiel sur la façon de créer l’application Covid, pour vous donner une meilleure chance de vous mettre au courant.
Un élément épique consiste à prendre en charge les importations dynamiques pour le domaine de l’application. Bien que cela fonctionne dès le départ pour le mode de développement, il faudra beaucoup de travail pour que cela se produise à l’intérieur du dist env basé sur le webpack. Pensez aux morceaux séparés.
Je parie donc que beaucoup d’entre vous ont une question en tête à ce stade:
« Où est le code? »
Et voilà:
https://github.com/neomjs/neo/blob/dev/src/core/Base.mjs#L225
