Three.js: Continuer à prendre en charge les bibliothèques JS aux côtés des bibliothèques JSM ES6

Si je comprends bien, le plan consiste à toujours inclure un "/build/three.js" en plus du "/build/three.module.js".

Oui. Cependant, on peut se demander si cette approche a du sens. Lorsque examples/js est supprimé, il ne reste que quelques cas d'utilisation où three.js et three.min.js sont toujours utiles.

Il serait en fait avantageux de supprimer three.js et three.min.js car cela nous permettrait de changer le point d'entrée main npm du paquet npm, voir #19575.

Si nous pouvons le faire facilement, je pense qu'il est logique de continuer à prendre en charge /examples/js en les générant automatiquement via un script de bundle ES6 dans le cadre du processus de construction.

L'idée est de déplacer examples/jsm vers des fonctionnalités de langage JavaScript plus modernes comme les classes. Étant donné que examples/js devrait toujours fonctionner avec un ancien navigateur, il serait nécessaire de configurer une nouvelle version (exemples) avec des fonctionnalités de transpilation de code. De plus, nous conserverions toujours la base de code en double ( examples/js vs examples/jsm ) ce qui est à mon avis une mauvaise approche. Cela rend la maintenance plus compliquée.

Je pense que l'utilisateur doit s'occuper de la conversion ES6 en ES5 si nécessaire. Idem pour la minification de code ou d'autres tâches liées à la construction.

Je crois que vous avez raison. Si je comprends bien, le plan est de toujours inclure un " /build/three.js " en plus du " /build/three.module.js ".

Vrai

Le problème avec les filles du dossier /examples est que vous devez utiliser les fichiers de /examples/js lorsque vous avez utilisé /build/three.js et les fichiers de /examples/jsm lorsque vous avez utilisé /build/three.module.js , c'est-à-dire garder la cohérence dans la méthode de chargement.

Pourquoi? Parce que lors de l'utilisation des importations de modules, l'objet principal THREE n'est plus un objet js simple THREE = {} mais plutôt un objet de module de navigateur interne qui est scellé (non extensible), par conséquent, les fichiers de /examples/js qui essaie d'écrire une nouvelle propriété dans l'objet THREE échoue.

Vous ne pouvez donc pas mélanger import * as THREE from '/build/three.module.js et THREE.WhateverExample = function() ...

Une façon possible est de changer le nom de la bibliothèque importée en autre chose que THREE et de recréer un objet global plain js THREE pour que des exemples y soient écrits ...

C'est typiquement le problème de

JS traditionnel comprend

cela pollue la dénomination globale de l'espace, et parce que vous ne pouvez pas modifier les noms dans le fichier chargé, vous pouvez obtenir des erreurs comme celle-ci ...
En revanche, avec les modules, l'utilisateur gagne le pouvoir de nommer lors de l'import et ce n'est plus l'auteur de la lib qui choisit le nom résultant...

ex:

<script>
// a script you can't modify already use the name THREE
var THREE = document.getElementById('div-nb-3')
</script>

<script type="module">
import * as foo from '/build/three.module.js'

THREE.appendChild( new foo.WebGLRenderer().domElement )
</script>

@ Mugen87 Vous avez 100% raison. Si nous abandonnons le /examples/js , nous pourrions aussi bien abandonner les three.js et three.min.js car ils sont essentiellement incompatibles avec l'un des modules complémentaires. Leur cas d'utilisation serait de niche et cela est presque garanti pour créer de la confusion.

@devingfx Vous avez raison de dire que les modules ont des avantages et éliminent les conflits de noms globaux potentiels. Au cours des années d'utilisation, je n'ai jamais eu de conflit avec la variable globale TROIS et je pense que c'est un scénario peu probable, mais votre point est techniquement correct.

ce qui est à mon avis une mauvaise approche. Cela rend la maintenance plus compliquée.

Je pense que l'utilisateur doit s'occuper de la conversion ES6 en ES5 si nécessaire. Idem pour la minification de code ou d'autres tâches liées à la construction.

@ Mugen87 Est-ce vraiment si terrible de maintenir un js include traditionnel qui utilise un var global en plus d'un module? De nombreuses bibliothèques prennent en charge les deux et d'après ce que je peux dire, la version traditionnelle de JS est souvent aussi populaire que les homologues de la version du module. Les deux ont des avantages/inconvénients et certains d'entre eux se résument à la préférence. N'est-il pas bon de donner aux développeurs la possibilité d'utiliser une bibliothèque dans un contexte non-module ?

Je suis prêt à m'occuper de créer/tester les fonctionnalités de transpilation de code nécessaires pour générer automatiquement three.min.js, three.js et /examples/js à partir de three.module.js et /examples/jsm . Une fois le flux de travail de transpilation affiné, il peut nécessiter une maintenance minimale, mais il != maintient deux versions parallèles. Pour la plupart, le code ne serait nécessaire que pour être mis à jour sur les fichiers du module et vous n'auriez qu'occasionnellement besoin de corriger une erreur de transpilation.

J'ai suffisamment de projets qui reposent sur la syntaxe globale traditionnelle et incluent que je vais quand même faire le travail d'automatisation de la transpilation des modules. Je pense qu'au moins nous pourrions inclure une commande dans le package.json et l'appeler "legacy-build" qui transpile les modules en three.min.js, three.js et /examples/js qui se comportent de la même manière que l'original fichiers maintenant. Ces fichiers n'ont même pas besoin d'être validés dans le dépôt ou créés par défaut. Nous pourrions également avertir qu'ils sont pour le support hérité, ils ne sont pas garantis de fonctionner, nous suggérons d'utiliser des modules à la place, etc...

De manière réaliste, je pense qu'il est plus logique de les conserver dans le dépôt et de les générer automatiquement via le transpilage lors de la construction.

une commande dans le package.json et appelez-la "legacy-build" qui transpile les modules

semble raisonnable. Babel n'a-t-il pas fusionné récemment ? donc je pense que c'est faisable tel quel

edit : pour clarifier, ne pas avoir ladite nouvelle commande à exécuter par n'importe qui sauf les utilisateurs qui veulent ladite construction

Est-ce vraiment si terrible de maintenir un js include traditionnel qui utilise un var global en plus d'un module ?

Je pense que la complexité du maintien de cela est sous-estimée. Malheureusement, je ne pense pas que ce soit si simple avec la façon dont les exemples sont mis en place dans le projet.

Regardons GLTFLoader comme exemple. À l'heure actuelle, tout GLTLFoader est contenu dans un seul fichier, ce qui facilite son inclusion en haut d'un fichier HTML. L'un des avantages des modules est que certains des fichiers les plus volumineux peuvent être divisés en fichiers séparés que GLTFLoader peut importer en tant que dépendances. À quoi devrait ressembler le script global construit une fois que GLTChargeur dépend de quatre fichiers externes dont certains sont partagés ? Les utilisateurs des scripts globaux construits devront-ils désormais inclure tous ces exemples de fichiers js individuellement ? Ou certains fichiers seront-ils regroupés, ce qui nécessiterait de maintenir manuellement une liste de fichiers qui peuvent être regroupés et qui ne le sont pas ?

Je pense que le seul cas vraiment défini et oublié est de regrouper tous les exemples de fichiers js dans un seul blob monolithique, ce qui, à mon avis, n'est pas raisonnable. Je pense qu'avec l'une de ces solutions, il y aurait également d'autres frais généraux de publication et de documentation.

Peut-être y a-t-il une meilleure façon de le faire, mais lorsque j'ai essayé de créer une version de cumul qui conservait la rétrocompatibilité ou au moins une structure cohérente avec les fichiers js existants, ce sont les problèmes que j'ai rencontrés.

Si je comprends bien, le plan consiste à toujours inclure un "/build/three.js" en plus du "/build/three.module.js".

Oui. Cependant, on peut se demander si cette approche a du sens.
Lorsque examples/js est supprimé, il ne reste que quelques cas d'utilisation où three.js et three.min.js sont toujours utiles.

@Mugen87 @mrdoob

Michael,
En fait, garder "three.min.js" pendant au moins 2 ans de plus est un MUST.
Pas parce que tous mes échantillons sont basés dessus.
Mais parce que des milliers de fichiers et les meilleurs chiens de Google sont basés dessus !
Exemple : https://www.google.com/search?source=hp&q=webgl+benchmark

D'un autre côté, de mon point de vue, "three.min.js" signifie un développement et des tests plus rapides.
Sans oublier que cela fonctionne hors ligne et que vous n'avez pas besoin de localhost.
Placez simplement tous les fichiers dans un dossier quelque part, utilisez Firefox et double-cliquez sur le fichier HTML.
J'ai toujours aimé ça pour le développement !

Ricardo devrait également penser à tout cela.
à votre santé

La suppression de three.js et three.min.js peut être discutée et planifiée lorsque examples/js aura disparu. Il était juste important pour moi de souligner leur perte de signification lorsque vous ne pouvez plus importer de fichiers à partir de examples/js .

Je pense que la complexité du maintien de cela est sous-estimée. Malheureusement, je ne pense pas que ce soit si simple avec la façon dont les exemples sont mis en place dans le projet.

J'aime beaucoup les points que vous soulevez. Il y a une complexité absolument imprévue dans le regroupement et l'exemple des modules imbriqués en est un bon. En ce qui vous concerne, je pense que nous pouvons prendre des décisions sensées sur la façon de gérer le regroupement de modules imbriqués le moment venu. Je ne dis pas qu'un script bundler sera une situation définie et oubliée, mais simplement qu'il nécessitera moins de maintenance.

Si le moment vient où c'est trop difficile à maintenir, nous pouvons toujours laisser tomber, mais je pense qu'il est idiot de ne pas essayer à cause de problèmes que nous n'avons pas encore. Il sera plus facile à mettre en œuvre maintenant tant que nous aurons toujours une parité de 1 à 1 entre /examples/jsm et examples/js . Nous ne réorganiserons probablement pas massivement la hiérarchie des modules /example/jsm et je pense que nous pouvons apporter des mises à jour incrémentielles au bundler lorsque nous le ferons. Je vais aller de l'avant et commencer à travailler sur des preuves de travail pour cela (avec babel parce que c'est déjà ajouté ?) pour mettre mon argent où ma bouche est comme on dit.

Pour Mugen, cela aiderait à garder une certaine pertinence pour three.js et three.min.js pendant que nous continuons à les maintenir. Cela pourrait également aider les centaines de sites qui pourraient rechercher une mise à jour compatible avec leur implémentation THREE non basée sur un module. La refactorisation d'un projet THREE pour utiliser des modules peut être assez importante même si vous savez ce que vous faites.

Je ne peux pas parler pour les autres collaborateurs mais je ne changerai pas d'avis sur ce sujet. Je vote pour supprimer examples/js avec la version de décembre 2020 comme discuté et engagé ici #18749.

Je vote pour supprimer les exemples/js avec la version de décembre 2020 comme discuté et engagé ici #18749.

Je n'ai aucun problème avec ça.
Tant que "three.min.js" est disponible pour encore quelques années ...

Merci pour la contribution Mugen, j'ai lu ce fil mais il apparaît plus comme une annonce que comme une explication de la décision. Mon hypothèse est que ce développement simplifié est la principale raison d'aller dans cette direction, y en a-t-il d'autres ?

Je pense qu'avoir un script de transpilation que nous pouvons exécuter pour générer des inclusions de style /examples/js devrait être un bon compromis ici. Cela devrait réduire considérablement la quantité de maintenance / complication requise ici. Je serais même d'accord s'il ne s'agissait que d'une commande dans le package.json que vous deviez exécuter vous-même et que les fichiers n'étaient pas générés par défaut. Il y a des avantages pour certains développeurs et d'autres qui devront de toute façon transpiler. Je préférerais que nous n'ayons pas tous créé séparément un flux de travail de transpilation/bundle alors que quelque chose pourrait être conservé dans le dépôt principal pour mieux nous permettre de collaborer. :)

J'ai lu ce fil, mais cela ressemble plus à une annonce qu'à une explication de la décision.

Malheureusement, nous ne pouvons pas toujours épingler tous les arguments valides dans un seul fil, soit parce que la réalisation d'un changement de conception progresse lentement sur plusieurs discussions au fil des ans, soit simplement parce que plusieurs fils sur le même sujet sont créés encore et encore (comme celui-ci ). Les collaborateurs essaient de minimiser le bruit et la segmentation, mais ce n'est pas toujours possible.

Mon hypothèse est que ce développement simplifié est la principale raison d'aller dans cette direction, y en a-t-il d'autres ?

Le plus important que je vois est la possibilité d'utiliser et d'importer des sous-modules qui minimisent le code redondant et permettent des implémentations réutilisables.

Par exemple, la plupart des chargeurs doivent créer une sorte de structure/classe d'analyse de données, car chaque chargeur doit être autonome pour que les fichiers example/js soient réutilisables. Cependant, si nous supprimons entièrement la restriction non modulaire, nous serions en mesure de créer une seule instance d'une classe DataParser et d'importer cette implémentation standard sur tous les chargeurs, facilitant immédiatement le développement et supprimant également le code redondant de tous les chargeurs.

Ouais, bon point. Nous devons déjà faire des hacks sales comme l'intégration de la classe Pass (la classe de base de toutes les passes FX) dans EffectComposer uniquement pour nous assurer que le code hérité ne se casse pas.

très bons points réalisés tout au long.

obtenir et garder les gens sur la bonne voie / à jour semble être (et d'après ma propre expérience) un problème difficile. va essayer de réfléchir à cela.

En fait, garder "three.min.js" pendant au moins 2 ans de plus est un MUST.

Il sera toujours possible de générer une version ES5 en utilisant Babel. La question à laquelle nous devrons répondre à ce sujet est de savoir si la responsabilité en incombe à nous ou au développeur utilisant three.js.

Nous avons déjà décidé qu'il appartiendra au développeur de créer des versions ES5 des fichiers d'exemple, il est donc probablement logique de faire de même pour les fichiers de construction. À mon avis, il est également logique de le faire dans toute la bibliothèque en une seule version plutôt que de l'espacer, mais garder trois.min.js un peu plus longtemps, c'est bien aussi.

Mais parce que des milliers de fichiers et les meilleurs chiens de Google sont basés dessus !
Exemple : google.com/search?source=hp&q=webgl+benchmark

C'est le meilleur site qui me vient de cette recherche, et ils utilisent R53 donc je ne pense pas que ce changement les affectera trop mal : https://www.wirple.com/bmark/

Comme vous pouvez le voir, les anciennes versions de three.js fonctionnent toujours très bien. Après avoir effectué la transition vers les modules, nous pouvons demander à quiconque souhaite une version ES5 sans utiliser Babel d'utiliser la dernière version avant la suppression des fichiers ES5. Ils peuvent consulter l'intégralité du référentiel de cette version et utiliser également les documents de cette version.

@looeee Vous touchez quelques bons points. Comme mentionné ci-dessus, je suis d'accord qu'il est logique de déprécier l'ES5 three.min.js et three.js en même temps ici. Peut-être que cela devrait être sa propre discussion séparée?

Quoi qu'il en soit, j'aimerais parvenir à un consensus sur l'inclusion d'un script babel dans le dépôt principal qui peut être utilisé pour générer des fichiers /js/example style ES5 à l'ancienne. Il ne s'agit en aucun cas de savoir si quelqu'un est responsable de fournir ce soutien. Il y a des contributeurs, comme moi, qui vont avoir besoin de cette fonctionnalité. Il y a des avantages pour certains développeurs et d'autres qui devront de toute façon transpiler. Je préférerais que nous n'ayons pas tous créé séparément un flux de travail de transpilation/bundle alors que quelque chose pourrait être conservé dans le dépôt principal pour mieux nous permettre de collaborer.

Je pense que c'est un juste compromis de nous autoriser un fichier dans le référentiel principal afin que nous puissions travailler ensemble sur le script de transpilation babel ES6 à ES5. Y a-t-il vraiment un problème ? Permettre aux contributeurs de travailler ensemble sur une fonctionnalité dont ils ont besoin dans le référentiel principal ?

Je ne demande pas d'aide ou de ressources aux collaborateurs pour ce faire, je vous demande simplement de permettre aux personnes qui en ont besoin de pouvoir travailler dessus ensemble dans le référentiel principal. Si je fais un PR pour ça et que ça marche, voteriez-vous vraiment pour le rejeter ?

Si je fais un PR pour ça et que ça marche

Je veux dire, je suis content de voir que ça commence

voteriez-vous vraiment pour le rejeter ?

tous les paris seront annulés s'il échoue la passe de peluchage 😂

Y a-t-il vraiment un problème ?

Oui, car le référentiel ne doit pas promouvoir des modèles de codage obsolètes.

Oui, car le référentiel ne doit pas promouvoir des modèles de codage obsolètes.

Ce n'est pas encore officiellement obsolète si nous ne licencions pas three.js + three.min.js (reconnu le consensus ITT est que nous devrions également les licencier) et avoir un script babel que vous devez exécuter manuellement par vous-même est à peine une approbation éclatante. Je suis d'accord que nous devrions certainement encourager les gens à utiliser des modules à la place et avoir un avertissement dans le script babel et les fichiers générés à ce sujet. Je ne suis pas d'accord pour permettre aux contributeurs de travailler ensemble sur un script babel pour les personnes dans des situations qui ne peuvent pas utiliser de modules pour quelque raison que ce soit, c'est promouvoir un modèle de codage obsolète. Principalement parce qu'il existe encore des situations où l'utilisation de modules est irréalisable/impraticable. Les docs reconnaissent ce besoin. Je pense que nous pouvons ajouter un fichier en toute sécurité pour que les personnes qui en ont besoin puissent travailler dessus ensemble.

Je suis d'accord qu'il est logique de déprécier les ES5 three.min.js et three.js en même temps ici.

Je voulais dire que nous devrions déprécier examples/js, three.min.js et three.js en même temps, c'est-à-dire supprimer tout le code ES5 dans une version plutôt que de le répartir sur plusieurs versions.

@Mugen87

Oui, car le référentiel ne doit pas promouvoir des modèles de codage obsolètes.

Vous pouvez toujours exécuter des jeux DOS dans Windows 10.
Et cela ne signifie pas que Microsoft promeut des "modèles de codage obsolètes".

Juste pour clarifier l'exemple de modules js tel que maintenu dans ce projet, il n'est pas nécessaire d'utiliser node, npm ou tout framework de construction.

Eh bien, n'oublions pas que créer une application prête pour la production signifie regrouper votre code :)

J'apprécie de regrouper des outils comme Rollup qui sont disponibles, mais je pense que nous devrions considérer quelques questions :

• Est-il juste de supposer que si les développeurs souhaitent utiliser THREE en production, ils doivent également utiliser l'un de ces outils de regroupement ?
• Est-il juste d'abandonner la prise en charge d'autres bibliothèques qui s'appuient sur les mises à jour des modules ES5/UMD dans le dossier des exemples ?

Mes sentiments personnels à ce sujet :

Cette bibliothèque a dix ans. Il existe un énorme écosystème qui s'appuie sur les modules du dossier d'exemples écrits en ES5/UMD. Je ne pense pas qu'il soit juste d'abandonner le support pour tout un écosystème.

Je pense que les gens oublient que vous pouvez toujours utiliser ES6 sans modèle de regroupement de modules. J'utilise ES6 tous les jours mais je n'utilise pas de modèles de regroupement de modules dans mes applications frontales. J'ai travaillé dans des ateliers d'entreprise où les outils de construction devenaient très personnalisés par nécessité et seraient incapables d'incorporer un modèle de regroupement de modules.

Que devrions nous faire?

Compilons les modules ES6 en modules ES5/UMD pour une distribution donnée après chaque version.

Oui, car le référentiel ne doit pas promouvoir des modèles de codage obsolètes.

Pour presque tout dans la vie, une solution peut toujours être de grande qualité en utilisant des modèles, des techniques et des outils plus anciens.

Par analogie - Pendant mon temps libre, j'aime sculpter la pierre avec des ciseaux à pointe. Les outils et les techniques sont différents des outils électriques, mais au final la sculpture sera toujours de grande qualité. J'ai exercé une préférence personnelle pour utiliser des ciseaux pointus parce que j'aime les utiliser et que j'ai les compétences nécessaires pour produire quelque chose dont moi-même ou d'autres sont satisfaits.

Je ressens la même chose pour les modules ES5/UMD. J'ai pu trouver des modèles, des techniques et des outils qui maintiennent des bases de code de très haute qualité et je souhaite continuer à exercer cette préférence personnelle.

Compilons les modules ES6 en modules ES5/UMD pour une distribution donnée après chaque version.

Je suis d'accord avec ce que looeee a dit.

Est-il juste de supposer [...]

quelle? Nous parlons de l'approche que nous préférerions, l'"hypothèse" vient après. La préférence semble être d'encourager les autres à utiliser des modules mais (en supposant que certaines personnes voudront toujours l'ancien THREE) en offrant une voie à ceux qui le souhaitent vraiment.

Compilons les modules ES6 en modules ES5/UMD pour une distribution donnée après chaque version.

Cela peut être fait par n'importe qui; ce coût n'a pas besoin d'être supporté par les mainteneurs de three.js. Je voudrais réitérer ce que @gkjohnson a dit ci-dessus, le coût de maintenance des répertoires examples/js et examples/jsm est élevé. Nous ne pouvons pas faire cela indéfiniment, et il est clair que les modules ES6 sont la plus moderne des deux approches. Considérez les coûts suivants :

• Création et maintenance de l'automatisation
• Débogage des échecs de publication lorsque l'automatisation est interrompue
• S'assurer que toutes les demandes d'extraction mettent à jour le fichier source, pas celui généré
• Maintenir une documentation expliquant comment les deux flux de travail sont utilisés
• Répondre aux rapports de bogues et aux questions d'assistance des utilisateurs essayant d'utiliser à la fois les flux de travail CJS et ES6

Ce dernier élément est probablement le plus important. Tant que deux copies de tout sont disponibles dans ce référentiel, les deux seront considérées comme entièrement prises en charge. Nous passons régulièrement du temps à aider les utilisateurs qui confondent les deux flux de travail ou essaient d'utiliser un chargeur de module ES6 avec la bibliothèque principale CJS, qui échoue de manière compliquée.

Nous pouvons reformuler le problème simplement : tous nos exemples - qui sont des parties importantes mais facultatives de la bibliothèque three.js - n'utilisent actuellement aucune syntaxe de module. Pas UMD, pas CommonJS, pas de modules ES6. Ils corrigent simplement un espace de noms global THREE . Nous aimerions mettre à jour cela, en utilisant la syntaxe d'importation/exportation ES6 à la place, et il y a eu de nombreux avertissements précoces que ce changement était prévu.

Il existe un énorme écosystème qui s'appuie sur les modules du dossier d'exemples écrits en ES5/UMD. Je ne pense pas qu'il soit juste d'abandonner le support pour tout un écosystème.

Je ne pense pas qu'il soit juste de dire que quoi que ce soit dans l'écosystème three.js dépend tellement des espaces de noms globaux THREE.* qu'il ne pourrait pas être mis à jour pour utiliser la syntaxe d'importation/exportation, ou pour transpiler vers ES5, ou utiliser un groupeur. Il existe un certain nombre de solutions de contournement ici, et nous serions heureux de travailler avec les utilisateurs pour les aider à trouver une option qui leur convient.

le coût de maintenance des répertoires examples/js et examples/jsm est élevé.

J'aimerais creuser un peu plus cela. J'ai écrit de nombreux outils personnalisés et construit des scripts d'automatisation pour les applications frontales et je serais heureux de vous aider de toutes les manières possibles.

Création et maintenance de l'automatisation
Débogage des échecs de publication lorsque l'automatisation est interrompue

Aidez-moi à comprendre un peu plus la taxe de maintenance, est-ce quelque chose d'unique à la base de code THREE ? D'après mon expérience, ce type de code est généralement celui qui dure le plus longtemps et nécessite le moins d'entretien. Ce sont des scripts que vous écrivez une fois et que vous ne revoyez pas pendant de longues périodes.

S'assurer que toutes les demandes d'extraction mettent à jour le fichier source, pas celui généré

Peut-être qu'un petit script ou un test pourrait aider à cela dans le flux de travail de publication.

Maintenir une documentation expliquant comment les deux flux de travail sont utilisés

Je voterais également pour supprimer la documentation des espaces de noms globaux. Je pense que c'est idiot de prendre en charge la documentation pour deux flux de travail. Ce n'est pas une mauvaise chose. La plupart des bibliothèques qui regroupent leur code pour différents contextes, les modules UMD/ES6 n'ont qu'un seul ensemble de documents.

Répondre aux rapports de bogues et aux questions d'assistance des utilisateurs essayant d'utiliser à la fois les flux de travail CJS et ES6.

Je pense que le volume de problèmes liés à quelque chose comme ça est relatif à la taille de la popularité de THREE. Vous et moi voyons ces types de problèmes sur Stack Overflow tout le temps. Un utilisateur qui ne peut pas faire la distinction entre les deux flux de travail est probablement un nouveau programmeur inspiré par la bibliothèque et essaie simplement d'apprendre les bases de la programmation en général.

Si l'objectif est de réduire le volume de problèmes spécifiquement liés à la confusion entre les deux flux de travail , la suppression du code ES5 aiderait probablement à cela - mais je doute que le volume global de problèmes change. Un nouveau programmeur sera toujours bloqué à la prochaine question qui peut ou non être liée à la bibliothèque.

Comment réduire globalement le volume des problèmes ?

Si le véritable objectif est de réduire le volume global des problèmes, peut-être que des politiques de problèmes plus strictes peuvent y contribuer. Je vois que vous faites un excellent travail avec cela en utilisant déjà des balises comme Help (please use the forum) mais peut-être qu'il doit y avoir plus de ce genre de choses.

Plus généralement, il serait peut-être préférable de simplement délimiter certains types de problèmes dont les TROIS contributeurs sont prêts à discuter et à enquêter s'ils se sentent actuellement dépassés par le volume total.

Quelques idées :

• Au moment de la rédaction de cet article, suggestions et enhancements ont (271) problèmes en suspens. Ces étiquettes semblent générer beaucoup de bruit. Peut-être ne prendre que PR ready / chèques passés comme suggestion réelle. Insta-fermez tout le reste et marquez comme Discussion (please use the forum) .

• Au moment de la rédaction de cet article, loaders ont (61) problèmes en suspens. Cette étiquette semble également générer beaucoup de bruit. Je vois beaucoup de problèmes avec cette étiquette liés à suggestions et enhancements ou à des rapports de bogue mal formés. Peut-être ne prendre que des rapports de bogues bien formés et PR prêts / vérifications réussies pour les suggestions. Insta-fermez tout le reste et marquez en conséquence.

Je ne pense pas qu'il soit juste de dire que quoi que ce soit dans l'écosystème three.js dépend tellement des espaces de noms globaux THREE.* qu'il ne pourrait pas être mis à jour pour utiliser la syntaxe d'importation/exportation, ou pour transpiler vers ES5, ou pour utiliser un bundler.

Je suis d'accord que tout peut être mis à jour, mais si nous pouvons trouver un moyen de faire un peu de travail pour continuer à soutenir ces utilisateurs de manière durable, je suis d'accord avec @Bug-Reaper en disant :

Je préférerais que nous n'ayons pas tous créé séparément un flux de travail de transpilation/bundle alors que quelque chose pourrait être conservé dans le dépôt principal pour mieux nous permettre de collaborer.

Nous économiserions collectivement à ces utilisateurs un temps considérable pour mettre à niveau leurs applications/bibliothèques, leurs systèmes de construction et leur documentation.

J'aimerais creuser un peu plus cela. J'ai écrit de nombreux outils personnalisés et construit des scripts d'automatisation pour les applications frontales et je serais heureux de vous aider de toutes les manières possibles.

bien.

Comment réduire globalement le volume des problèmes ?

Gardons cela sur la bonne voie s'il vous plaît. Au plaisir de discuter plus avant sur un autre fil. Cela rejoint un peu mon commentaire précédent.

Je suis d'accord avec @Bug-Reaper en disant :

Je préférerais que nous n'ayons pas tous créé un workflow de transpilation/bundle [...]

Je pense que nous sommes tous d'accord là-dessus.

Merci à tous d'avoir partagé le pour et le contre. Il est toujours bon de les partager pour s'assurer que nous prenons des décisions éclairées.

C'est quelque chose sur lequel j'ai passé quelques cycles de réflexion cette année, et j'ai même demandé aux fournisseurs de navigateurs quelles étaient leurs priorités, ce qui m'a permis de planifier à l'avance.

Je suis d'accord que les modules ES6 sont l'avenir, mais développer avec eux sans importer de cartes peut causer d'énormes maux de tête et interrompre complètement votre flux. Lorsque nous avons décidé d'abandonner examples/js , j'espérais que les cartes d'importation auraient plus de succès, mais il semble que ce ne soit actuellement pas une priorité pour les navigateurs.

Pour cette raison, j'ai décidé de suspendre l'obsolescence du dossier examples/js jusqu'à ce que les navigateurs implémentent les cartes d'importation. Je détesterais forcer les débutants à se renseigner sur les polyfills ou les bundlers afin de rendre leur premier cube.

Je suis arrivé à la même conclusion que @Bug-Reaper. Aujourd'hui, j'essaie de créer un script qui construit examples/js à partir de examples/jsm fichiers.

@mrdoob

J'ai décidé de suspendre l'obsolescence du dossier examples/js jusqu'à ce que les navigateurs implémentent les cartes d'importation.
Je suis arrivé à la même conclusion que @Bug-Reaper. Aujourd'hui, j'essaie de créer un script qui construit des exemples/js à partir de fichiers exemples/jsm.

Une sage décision.
👍

@mrdoob J'accepte bien sûr votre décision mais je pense que c'est une occasion manquée. Tôt ou tard, les développeurs devront s'éloigner des scripts globaux. Et je ne pense pas que Import Maps fera une grande différence ici. Au lieu de « forcer » les utilisateurs à adopter des flux de travail meilleurs et évolutifs, nous leur permettons de continuer à utiliser des scripts globaux. En 2020.

Et je ne pense pas que Import Maps fera une grande différence ici.

L'autre jour j'ai vu quelqu'un faire ça :

<script src="js/three.js"></script>
<script src="https://cdn.rawgit.com/mrdoob/three.js/master/examples/js/loaders/GLTFLoader.js"></script>
<script type="module" src="js/main.js"></script>

Et, à l'intérieur main.js , ils faisaient ceci :

import {OrbitControls} from "https://threejsfundamentals.org/threejs/resources/threejs/r119/examples/jsm/controls/OrbitControls.js";

Et la chose a réellement fonctionné... 😐

Nous ne pouvons pas simplement nous attendre à ce que les utilisateurs fassent ce qu'il faut, ils apprennent et essaient des choses jusqu'à ce que quelque chose fonctionne. Le défi consiste à trouver un design qui les aide à faire ce qu'il faut sans qu'ils s'en rendent compte.

Le problème avec les modules ES6 sans cartes d'importation est que l'utilisateur ne peut pas simplement copier OrbitControls.js dans un dossier /js dans son propre projet et l'importer comme avant. Cela ne fonctionnera pas car OrbitControls.js recherche ../../build/three.module.js .

Avec les cartes d'importation, OrbitControls.js importerait simplement de three . L'utilisateur peut copier le fichier où il le souhaite, puis ajuster le chemin dans la carte des importations.

L'importation de cartes nous rapproche de la facilité d'importation de fichiers comme au "vieux" jours. Ce ne sera pas aussi facile qu'avant, mais au moins l'utilisateur n'aura pas à se soucier de l'ordre lors de l'importation de fichiers. Gagner quelque chose perdre quelque chose.

Convenu que l'importation de cartes rendra l'importation configurable et donc plus flexible. Bien que l'utilisateur doive encore ajuster la carte d'importation (et donc comprendre ce qu'elle est réellement).

Je pense juste que l'ensemble "copier les fichiers JS dans un dossier" est un anti-modèle diabolique et j'espérais que nous pourrions empêcher cela en recommandant aux nouveaux utilisateurs/débutants de travailler avec les importations CDN (ce qui est également une option pour les développeurs qui ne t voulez utiliser une construction pour quelque raison que ce soit). Les applications appropriées (devraient) utiliser des outils de construction de toute façon.

Je ne vois pas vraiment comme un anti-modèle.

C'est comme ça que j'ai appris à faire des sites Web. On placerait les fichiers .css dans le dossier /css , puis les images dans /img et les fichiers .js dans /js .

Au cours des derniers mois, j'ai fait quelques expériences en utilisant l'approche Modules ES6/CDN et cela ne me fait pas plaisir que les bibliothèques viennent d'un domaine différent de celui où se trouve mon projet.

Une grande chose que nous perdons lorsque nous ne copions pas de fichiers est de pouvoir les modifier. Les fichiers dans examples/js ont toujours été censés être des exemples sur lesquels vous pouvez construire. Si je copiais OrbitControls.js dans mon projet et qu'il ne faisait pas exactement ce dont j'avais besoin, je pouvais simplement le modifier car il s'agissait simplement d'un fichier local.

Voici comment j'avais l'habitude de configurer mes projets :

<script src="js/libs/three.js"></script>
<script src="js/libs/three/OBJLoader.js"></script>
<script src="js/libs/three/OrbitControls.js"></script>
<script>
    console.log( THREE, THREE.OBJLoader, THREE.OrbitControls );
</script>

Avec les cartes d'importation, cela ressemblerait à ceci :

<script type="importmap">
{
  "imports": {
    "three": "js/libs/three.module.js",
    "OBJLoader": "js/libs/three/OBJLoader.js",
    "OrbitControls": "js/libs/three/OrbitControls.js"
  }
}
</script>
<script type="module">
    import * as THREE from 'three';
    import { OBJLoader } from 'OBJLoader';
    import { OrbitControls } from 'OrbitControls';

    console.log( THREE, OBJLoader, OrbitControls );
</script>

Pas aussi joli qu'avant, mais prend en charge les dépendances/commandes d'importation pour vous et ne nécessite pas de groupeur.

Pourtant, cela fonctionne toujours pour les personnes qui font du développement basé sur des bundles. En fait, c'est mieux pour eux car les addons importent désormais depuis three au lieu de ../../build/three.module.js .

Et la chose a réellement fonctionné... 😐

FWIW, cela ne semble fonctionner que dans un petit nombre de cas. Quand cela ne fonctionne pas, cela échoue de manière extrêmement confuse et nous avons eu plusieurs problèmes liés à cela, cela se produit également avec les processus de construction. On peut dire que si vous êtes préoccupé par le fait que le débutant lui donne plusieurs façons d'utiliser les mêmes fichiers, il est plus sujet aux erreurs et déroutant.

Peut-être tangentiel, mais cela vaut peut-être la peine d'informer les gens qu'ils ont deux copies de three.js inclus dans la page via un avertissement dans la console (même s'il s'agit de la même version) qui peut causer des problèmes à moins que l'on veille à ne pas les mélanger. ~ Je crois que React fait cela pour des raisons similaires ~ React peut en fait simplement indiquer cela comme une source possible d'erreur. Cela pourrait au moins aider les gens à ne pas mélanger ces modalités lors de l'apprentissage.

Je suis arrivé à la même conclusion que @Bug-Reaper. Aujourd'hui, j'essaie de créer un script qui construit des exemples/js à partir de fichiers exemples/jsm.

S'il s'agit du nouveau plan, je serais heureux d'aider à faire revivre #15526 / #15543 (qui ont maintenant été supprimés du projet) qui construit chaque fichier de module en un fichier ES6. Étant donné que certains exemples sont répartis sur de nombreux fichiers (Shader Nodes, par exemple) et que nous pourrions être intéressés par la division de certains modules en plusieurs fichiers, il vaut probablement la peine de mettre à jour le script de cumul pour prendre une liste explicite des fichiers que nous voulons convertir et sortie. Nous devrions également pouvoir créer automatiquement des dépendances entre les fichiers générés.

Une grande chose que nous perdons lorsque nous ne copions pas de fichiers est de pouvoir les éditer

Je suis d'accord bien que si nous pouvons suivre des cours partout, j'espère quelque chose comme:

import orbitalcontrols from  orbitalcontrolsURL

class mycontrols extends orbitalcontrols {
// do the edits I care about
}

puis plus tard

let controls = new myorbitalcontrols

Une grande chose que nous perdons lorsque nous ne copions pas de fichiers est de pouvoir les éditer

Je suis d'accord bien que si nous pouvons suivre des cours partout, j'espère quelque chose comme:

importer orbitalcontrols depuis orbitalcontrolsURL

class mycontrols extend orbitalcontrols {
// faire les modifications qui m'intéressent
}

puis plus tard

let contrôles = nouveaux contrôles myorbitaux

Vous pouvez déjà le faire... même si la "classe" parente est une simple fonction js !

Code fonctionnant réellement (dans un test rapide du débogueur) :

Promise.all([
    import('https://unpkg.com/three/build/three.module.js')
        .then( mod=> [mod.Camera, mod.WebGLRenderer] ),
    import('https://unpkg.com/three/examples/jsm/controls/OrbitControls.js')
        .then( mod=> mod.OrbitControls )
])
.then( ([
    [ Camera, WebGLRenderer ],
    OrbitControls
])=> new ( class extends OrbitControls {} )( new Camera, (new WebGLRenderer).domElement )
)
.then( console.log )

... ou syntaxe plus simple :

(async function() {

let { Camera, WebGLRenderer } = await import('https://unpkg.com/three/build/three.module.js')
,   { OrbitControls } = await import('https://unpkg.com/three/examples/jsm/controls/OrbitControls.js')

class Con extends OrbitControls { }

let my = new Con( new Camera, (new WebGLRenderer).domElement )
console.log( my )

})()

mis à part cette fonction aynom et s'inquiéter des promesses async/wait, cool

class mycontrols extend orbitalcontrols {
 // do the edits I care about
 }

Idéalement, c'est le modèle que nous devrions promouvoir, plutôt que de dire aux utilisateurs de modifier les fichiers d'origine lorsqu'ils apportent des modifications. Cependant, les exemples ne sont pas écrits dans un souci d'extensibilité, il y a donc de fortes limites à ce que vous pouvez réaliser. D'après mon expérience, vous finissez par devoir copier l'intégralité de l'exemple d'origine dans le constructeur de la classe étendue pour le faire fonctionner, il est donc inutile d'utiliser extend .

Par exemple, la modification demandée la plus courante pour OrbitControls est de limiter le pan . Ceci est facilement accompli comme démontré dans le violon de @ Mugen87 à partir de ce fil.

En bref, vous ajoutez les vecteurs minPan et maxPan et bloquez controls.target dans la méthode controls.update .

J'ai essayé de le faire en étendant OrbitControls . Vous pouvez créer une classe étendue et cela fonctionne très bien. Cependant, les problèmes deviennent apparents lorsque vous commencez à apporter des modifications. Vous ne pouvez pas simplement étendre la méthode update :

class OrbitControlsPanLimit extends OrbitControls {
    constructor(object, domElement) {
        super(object, domElement);
    }

    update() {
        super.update();
        console.log('Custom update function');
    }
}

Cette classe étendue fonctionne ( glitch ), mais cette nouvelle méthode OrbitControlsPanLimit.update est ignorée. La méthode originale OrbitControls.update est toujours utilisée.

Vous pouvez l'écraser en le redéfinissant dans le constructeur :

class OrbitControlsPanLimit extends OrbitControls {
    constructor(object, domElement) {
        super(object, domElement);

        this.update = () => {
            console.log('Custom update function');
        }
    }
}

Vous ne pouvez pas utiliser super.update() ici, donc la seule option est de copier l'intégralité de la méthode de mise à jour d'origine. Cependant, cette méthode repose sur beaucoup de ces choses à partir de OrbitControls , qui est partagée entre toutes les méthodes.

    //
    // internals
    //

    var scope = this;

    var changeEvent = { type: 'change' };
    var startEvent = { type: 'start' };
    var endEvent = { type: 'end' };

    var STATE = {
        NONE: - 1,
        ROTATE: 0,
        DOLLY: 1,
        PAN: 2,
        TOUCH_ROTATE: 3,
        TOUCH_PAN: 4,
        TOUCH_DOLLY_PAN: 5,
        TOUCH_DOLLY_ROTATE: 6
    };

    var state = STATE.NONE;

    var EPS = 0.000001;

    // current position in spherical coordinates
    var spherical = new THREE.Spherical();
    var sphericalDelta = new THREE.Spherical();

    var scale = 1;
    var panOffset = new THREE.Vector3();
    var zoomChanged = false;

    var rotateStart = new THREE.Vector2();
    var rotateEnd = new THREE.Vector2();
    var rotateDelta = new THREE.Vector2();

    var panStart = new THREE.Vector2();
    var panEnd = new THREE.Vector2();
    var panDelta = new THREE.Vector2();

    var dollyStart = new THREE.Vector2();
    var dollyEnd = new THREE.Vector2();
    var dollyDelta = new THREE.Vector2();

Le résultat final est que vous devrez copier la quasi-totalité de l'original OrbitControls dans le constructeur OrbitControlsPanLimit , ce qui va à l'encontre de l'objectif d'étendre la classe. À moins que nous n'écrivions les contrôles en tant que classe avec l'extensibilité à l'esprit, je ne pense pas que l'étendre soit viable.

merci @looeee d'être intervenu. Je pensais que j'avais peut-être raté une solution facile dans mes propres efforts, mais maintenant que vous le mentionnez, c'est à peu près là que je me suis levé.

Idéalement, c'est le modèle que nous devrions promouvoir, plutôt que de dire aux utilisateurs de modifier les fichiers d'origine lorsqu'ils apportent des modifications.

Attention, cela avance de près vers un argument héritage vs composition.

Idéalement, une bibliothèque ne devrait promouvoir aucun modèle. Il devrait promouvoir ses fonctionnalités et la façon dont il vise à résoudre vos problèmes.

Il ne devrait pas non plus supposer un flux de travail de développeurs, une pile, un système de construction, un cas d'utilisation. Une bonne bibliothèque s'adapte autant que possible aux nombreux besoins complexes de sa communauté.

Ce qui est nouveau aujourd'hui est vieux demain, les modèles vont et viennent. La seule constante serait alors un logiciel qui offre un excellent support pour les nombreux cas d'utilisation en cours de route afin de maintenir autant de compatibilité descendante que possible.

Vous pouvez toujours exécuter des jeux DOS dans Windows 10.

héritage vs argument de composition

Je t'en prie, non. la solution à cet « argument » est d'utiliser le meilleur outil pour le travail. il y a une place pour l'héritage, la composition, le fonctionnel, le test piloté... vous l'appelez.

Puisque nous parlons de la façon dont les autres développeurs (utilisent, réutilisent, modifient) three.js, il est valable de promouvoir un modèle qui serait facilement compris et utilisable sans sortir des fonctionnalités du navigateur js.

promouvoir ne signifie pas qu'on ne peut pas utiliser un style différent.

autant de rétrocompatibilité que possible

Oui et non.

Il devrait promouvoir ses fonctionnalités et comment il vise à résoudre vos problèmes

peut-être pour que nous soyons clairs, quel est l'ensemble de problèmes/fonctionnalités pour vous ?

Il ne devrait pas non plus supposer un flux de travail de développeurs, une pile, un système de construction, un cas d'utilisation

Je suis majoritairement d'accord. Le cas d'utilisation de threejs est actuellement le navigateur. la mise en garde est que certains de nos chargeurs sont utiles pour certaines applications de nœud d'après ce que j'ai entendu.

La seule constante serait alors un logiciel qui offre un excellent support pour les nombreux cas d'utilisation en cours de route

le changement est la seule constante. les développeurs utilisent l'outil qu'ils aiment et parfois nous essayons autre chose.

en aparté:

Il devrait promouvoir ses fonctionnalités et comment il vise à résoudre vos problèmes

qui est venu en premier? la caractéristique, le motif ou le problème ?
le motif a sûrement aidé à résoudre le problème et est ensuite devenu une fonctionnalité
... ou était-ce la fonctionnalité qui a créé le problème et nous avons trouvé un modèle pour le résoudre ?

qui est venu en premier? la caractéristique, le motif ou le problème ?

Lequel est arrivé en premier ? La Poule ou l'Œuf ?
Certains disent que le Coq...

Grande discussion tout autour, merci à tous pour toutes les contributions.

Je serais curieux de savoir ce que vous pensez du bundler (rollup, babel, parcel, webpack, etc.) le mieux adapté à la tâche de transpilation de nos exemples de modules ES6. Je crois que @gigablox a mentionné avoir de l'expérience ici et je suis sûr que d'autres aussi.

Le référentiel actuel contient déjà babel, rollup et quelques plugins associés. Je suis allé de l'avant et j'ai commencé à pirater cela ce soir et j'ai un script de configuration de cumul extrêmement approximatif à partager :

// jsm-transpiler.js
export default [
  {
    input: './examples/jsm/controls/OrbitControls.js',
    output: {
      banner:"//warning this file was generated automatically",
      file: './examples/js/controls/OrbitControls.js',
      name:'OC',
      footer:'THREE["OrbitControls"]=OC.OrbitControls',
      format: 'umd'
    }
  }
];

Ce script de configuration de cumul convertit en effet le module $# OrbitControls 1$#$ en un fichier include non-module .js qui attribue à THREE.OribitControls le constructeur approprié. Ça a marché, c'est cool :) ! Il a également regroupé les 40 000 lignes de THREE.js dans le fichier de sortie, pas si cool haha. Je pollue également paresseusement l'espace des variables globales en déclarant une variable globale intermédiaire appelée OC pour aider à transporter le constructeur OrbitControls sur TROIS.

Rollup semble avoir des fonctionnalités vraiment intéressantes qui, je pense, peuvent résoudre beaucoup de nos problèmes. Notamment le mappage et d'autres contrôles pour s'assurer que les modules imbriqués corrects sont inclus/exclus. La possibilité d'injecter du code avant et après la charge utile transpilée via les propriétés d'en-tête/pied de page/intro/sortie.

Je suis prudemment optimiste que nous pouvons accomplir ce dont nous avons besoin avec un script de configuration de cumul trompé. Mais ce serait formidable si quelqu'un qui a fait des recherches/comprend les différences entre les nombreux bundlers pourrait peser ici cependant. Nous aurons besoin de quelque chose d'assez robuste pour gérer les modules à mesure qu'ils deviennent plus géniaux et je parierais que certains codes de transpilation sont meilleurs que d'autres.

Voici mon point de vue :
https://github.com/mrdoob/three.js/pull/20529

Il s'agit d'un script de construction personnalisé poc qui convertit tous les modules JSM en modules à espace de noms global JS en 30 secondes environ. J'ai eu un assez bon succès avec cette méthode. A besoin de plus de tests, mais j'ai essayé quelques-uns des modules les plus complexes comme le GLTFLoader dans un monde bonjour et c'était bien.

Pourrait utiliser l'aide de n'importe quel assistant RegExp chevronné :) pour résoudre certains cas extrêmes sur lesquels vous pouvez en savoir plus dans le PR.

Intention d'expédition des cartes d'importation de Chrome :
https://groups.google.com/a/chromium.org/g/blink-dev/c/rVX_dJAJ-eI