Three.js: Évaluer les classes ES6

Donc, vous suggérez d'utiliser ce modèle à la place ?

PointLight.prototype = Object.create( Light.prototype );
Object.assign( PointLight.prototype, {

class PointLight extends Light

hé hé 😄 Et aucun problème...

@sasha240100 un jour...

@mrdoob pas tout à fait - les deux façons que vous mentionnez sont directement équivalentes. Je pense que l'OP compare

PointLight.prototype = Object.assign( Object.create( Light.prototype ), { 
    constructor: PointLight,
    prop1: 'something',
    method1: function someFunction() { .. },
    ...
});

avec

function PointLight () { ... };

PointLight.prototype = Object.create( Light.prototype );

PointLight.prototype.constructor = PointLight;

PointLight.prototype.prop1 = 'something';

PointLight.prototype.method1 = function someFunction() { .. };

...

C'est comme ça que ça se passe ici par exemple.
Autant que je sache, ces styles sont équivalents - y a-t-il quelque chose qui me manque?
Ou le style a-t-il été modifié pour utiliser Object.Assign une fois qu'il est devenu disponible et non mis à jour dans la base de code ?

@looeee @bfred-it @mrdoob Pourquoi ne pas simplement utiliser rollup-babel ?

Comparatif :
Courant. modules d'harmonie es5 + es6.

import { LineBasicMaterial } from './LineBasicMaterial';
import { Color } from '../math/Color';

function LineDashedMaterial( parameters ) {

    LineBasicMaterial.call( this );

    this.type = 'LineDashedMaterial';

    this.scale = 1;
    this.dashSize = 3;
    this.gapSize = 1;

    this.setValues( parameters );

}

LineDashedMaterial.prototype = Object.create( LineBasicMaterial.prototype );
LineDashedMaterial.prototype.constructor = LineDashedMaterial;

LineDashedMaterial.prototype.isLineDashedMaterial = true;

LineDashedMaterial.prototype.copy = function ( source ) {

    LineBasicMaterial.prototype.copy.call( this, source );

    this.scale = source.scale;
    this.dashSize = source.dashSize;
    this.gapSize = source.gapSize;

    return this;

};


export { LineDashedMaterial };

ES2015+. Même code, mais es2015+ avec babel-plugin-transform-class-properties :

import { LineBasicMaterial } from './LineBasicMaterial';
import { Color } from '../math/Color';

export class LineDashedMaterial extends LineBasicMaterial {
  type = 'LineDashedMaterial';

  scale = 1;
  dashSize = 3;
  gapSize = 1;
  isLineDashedMaterial = true;

  constructor(parameters) {
    super();
    this.setValues( parameters );
  }

  copy(source) {
    super.copy(source);

    this.scale = source.scale;
    this.dashSize = source.dashSize;
    this.gapSize = source.gapSize;

    return this;
  }
}

Fonctionnalités ES6 qui simplifieraient le code three.js :

• Valeurs de paramètre par défaut.
  
  
  
  • Le peut facilement remplacer ces parties de code
  
  
• Raccourci de propriété
  
  
  
  • Peut être utilisé ici
  
  
• Fonction flèche
  
  
  
  • https://github.com/mrdoob/three.js/blob/dev/src/loaders/JSONLoader.js#L36
  
  

Je suis tout à fait d'accord pour passer à ES2015+, nous avons juste besoin de trouver un moyen de produire un code similaire à celui que nous avons actuellement, afin que les performances restent les mêmes dans tous les cas.

J'ai une question dans le contexte des cours. Comment transférerions-nous des méthodes comme Vector3.unproject dans la syntaxe de la classe ? La méthode utilise en fait une fermeture afin de créer une nouvelle portée. Il s'agit d'un mécanisme important qui maintient le nombre de créations d'objets aussi bas que possible.

Avons-nous besoin Object.assign dans ces cas ?

@Mugen87 @mrdoob Quelques informations intéressantes sur les performances d'es6. Surtout sur Object.assign :

De cet article

Comment transférerions-nous des méthodes comme Vector3.unproject dans la syntaxe de la classe ? La méthode utilise en fait une fermeture afin de créer une nouvelle portée.

@ Mugen87 Ne peuvent-ils pas simplement être des objets de portée de module non exportés? Quelque chose comme ça;

const tempMatrix = new Matrix();    

export default class Vector3{
    unproject() {
        // uses tempMatrix
    }
}

Ah oui, je pense que ça devrait marcher 😊

Le mois dernier, cela a été suggéré sur Twitter :

https://astexplorer.net/#/gist/9db8b707e3f69f94ded4af737f879fa7/b12fb12806e97df96278ec8b7d52018c8421872f

@mrdoob Wow ! Il semble déjà fonctionner. Ne pouvons-nous pas créer une branche, transformer certaines classes en es6 et voir comment cela se compile ?

@ satori99 Comme idée de la façon de conserver tempMatrix dans le code Vector3 pour éviter les problèmes avec les globales :

export default class Vector3 {
    static tempMatrix = new Matrix();

    unproject() {
        // uses Vector3.tempMatrix
    }
}

@mrdoob Wow ! Il semble déjà fonctionner. Ne pouvons-nous pas créer une branche, transformer certaines classes en es6 et voir comment cela se compile ?

Cela me paraît bien! Je me concentre actuellement sur WebVR, il faudra donc que ce soit quelqu'un d'autre que moi.

@ sasha240100 L'avantage d'utiliser des variables de portée de module est qu'elles restent cachées du code utilisateur normal, ce qui semble approprié pour les variables temporaires.

Cela ne me dérange pas l'approche pythonistique "Nous sommes tous des adultes ici" en ce qui concerne les variables privées, mais les variables temporaires ne devraient pas vraiment polluer inutilement l'espace de noms.

De plus, ce serait bien si ceux d'entre nous qui ont activé le support des modules natifs dans nos navigateurs pouvaient charger directement les fichiers src. C'est une façon bien plus agréable de développer, sans avoir besoin de watchers et de transpiler après chaque montage. L'utilisation de propriétés de classe signifie que cela n'est pas possible car elles ne font pas partie de la spécification de classe actuelle.

Toutes mes excuses pour l'intervention. Nous devrions probablement changer le titre du problème en quelque chose comme - "Évaluer les classes ES6", puisque maintenant le fil a changé en quelque chose de complètement différent.

Pourquoi changer le motif @Mugen87 @satori99 ?

method =(()=>{ 
    const vec3forThisScope =...; 
    return (arg)=>{...}
})()

Pourquoi ne pas essayer le tapuscrit, il peut être compilé dans d'autres versions de js

TypeScript serait vraiment une excellente option à considérer car il s'agit d'un transpiler + vérificateur de type et d'un sur-ensemble de JavaScript, il est donc facile de déplacer une base de code vers des fichiers .ts et de refactoriser progressivement vers ES6 avec vérification de type.

Cela peut sembler effrayant si vous n'avez jamais utilisé TypeScript, mais ce n'est vraiment pas une grande courbe d'apprentissage et ce serait un petit prix à payer pour les avantages que cela apporterait. La communauté TypeScript serait très heureuse d'aider à cette transition et de créer des tests de performances par rapport à la bibliothèque actuelle pour s'assurer qu'elle n'est pas rétrogradée.

Quelques articles utiles :

• Pourquoi vous ne devriez pas avoir peur de TypeScript
• TypeScript contre ES6 contre ES2015
• TypeScript a gagné
• Qu'est-ce que TypeScript et pourquoi avec Anders Hejlsberg

Pour citer le développeur principal Anders Hejlsberg, TypeScript est né en réponse aux plaintes des clients et des équipes internes selon lesquelles JavaScript ne se prêtait pas bien aux grandes applications.

L'objectif était de "renforcer JavaScript avec des éléments tels que les classes, les modules et le typage statique", sans sacrifier l'avantage d'être aux normes ouvertes et multiplateforme ; le résultat était un "langage pour le développement javascript à l'échelle des applications", construit comme un sur-ensemble du langage.

Jusqu'à ce que les navigateurs puissent exécuter nativement TypeScript, je préfère continuer à utiliser JavaScript.

@mrdoob

Je ne vois pas cela comme une raison valable de ne pas utiliser TypeScript uniquement parce qu'il ne peut pas être exécuté directement dans le navigateur. Vous ne voudriez pas qu'il s'exécute dans le navigateur à cause de toutes les lignes de code supplémentaires destinées uniquement à la vérification du temps de compilation. Ce n'est pas actuellement un langage de vérification d'exécution. Donc, s'il a déjà été utilisé dans le navigateur, il est plus que probable que tout le code tapé sera supprimé car cela a un impact sur les performances et il s'agirait alors de code JavaScript vanille.

Je pense que vous passez totalement à côté de l'intérêt d'utiliser un langage typé et des avantages qu'il présente dans le développement dans une grande base de code. Vous écrivez et utilisez toujours JavaScript, tout l'intérêt de TypeScript est qu'il s'agit d'un sur-ensemble de JavaScript. Vous écrivez du JavaScript avec des types, qui sont compilés en JavaScript dans la version cible ECMAScript spécifiée, qui est configurable dans les options du compilateur, les valeurs autorisées sont 'es3', 'es5', 'es2015', 'es2016', 'es2017' ou ' essuivant'.

Parce que Typescript est JavaScript, il permet de migrer progressivement sans avoir à se soucier de tout refactoriser en même temps. Cela peut être fait progressivement et amélioré par la communauté. Ce n'est pas plus de travail que ce qui est discuté ici avec la refactorisation pour utiliser les classes ES6. C'est la seule raison pour laquelle je le mentionne ici au lieu d'ouvrir un nouveau sujet.

Voir les liens de terrain de jeu TypeScript ci-dessous pour d'excellents exemples :

• Exemple JavaScript classique
• Exemple d'ajout de types
• Ajout de types avec erreur Exemple
• Exemple d'utilisation de classes
• Utilisation de classes avec erreur Exemple

@joejordanbrown

Pouvez-vous penser à quelqu'un qui pourrait être en désaccord avec vous sur le fait que le tapuscrit est la meilleure solution à ce problème particulier ?

Si vous tapez typescript vs dans Google, quelques termes apparaissent, l'un d'eux étant Flow. La recherche de cela semble donner un certain nombre d'articles où les gens débattent des avantages et des inconvénients de ces deux.

Aucun type ne semble être plus un compromis que de choisir l'un d'entre eux.

Enregistrez Typescript pour les projets plus compliqués que le résultat qu'ils créent - en particulier les frameworks frontaux qui auraient pu être implémentés en HTML en premier lieu. Mon point de départ était de se débarrasser de la maladie JavaScript, pas de l'aggraver. JavaScript est un langage simple presque jouet qui est parfois utilisé pour des résultats complexes comme three.js. Le tapuscrit est inutile.

Le 6 septembre 2017, à 13h55, Joe [email protected] a écrit :

@mrdoob

Je ne vois pas cela comme une raison valable de ne pas utiliser TypeScript uniquement parce qu'il ne peut pas être exécuté directement dans le navigateur. Vous ne voudriez pas qu'il s'exécute dans le navigateur à cause de toutes les lignes de code supplémentaires destinées uniquement à la vérification du temps de compilation. Ce n'est pas actuellement un langage de vérification d'exécution. Donc, s'il a déjà été utilisé dans le navigateur, il est plus que probable que tout le code tapé sera supprimé car cela a un impact sur les performances et il s'agirait alors de code JavaScript vanille.

Je pense que vous passez totalement à côté de l'intérêt d'utiliser un langage typé et des avantages qu'il présente dans le développement dans une grande base de code. Vous écrivez et utilisez toujours JavaScript, tout l'intérêt de TypeScript est qu'il s'agit d'un sur-ensemble de JavaScript. Vous écrivez du JavaScript avec des types, qui sont compilés en JavaScript dans la version cible ECMAScript spécifiée, qui est configurable dans les options du compilateur, les valeurs autorisées sont 'es3', 'es5', 'es2015', 'es2016', 'es2017' ou ' essuivant'.

Parce que Typescript est JavaScript, il permet de migrer progressivement sans avoir à se soucier de tout refactoriser en même temps. Cela peut être fait progressivement et amélioré par la communauté. Ce n'est pas plus de travail que ce qui est discuté ici avec la refactorisation pour utiliser les classes ES6. C'est la seule raison pour laquelle je le mentionne ici au lieu d'ouvrir un nouveau sujet.

Voir Liens de terrain de jeu TypeScript pour des exemples :

Exemple JavaScript classique
Exemple d'ajout de types
Ajout de types avec erreur Exemple
Exemple d'utilisation de classes
Utilisation de classes avec erreur Exemple
—
Vous recevez ceci parce que vous êtes l'auteur du fil.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

^ Je serais bien même avec le motif monstrueux, tant qu'il est cohérent.

@joejordanbrown a l' air d'être amoureux du tapuscrit. n'hésitez pas à bifurquer le projet et à le porter en tapuscrit. trois.ts ! 🙌

@pailhead

C'est une question de choix, je suis sûr que beaucoup seront d'accord et pas d'accord, c'est tout à fait normal ! Vous allez toujours voir "ceci contre cela", "le mien est meilleur que le vôtre". Je comprends que chacun a ses propres avantages. Il s'agit d'évaluer les options disponibles et de voir si elles peuvent bénéficier au projet. Les comparaisons sont une bonne chose, cela pousse les projets plus loin.

Vous mentionnez Flow, les problèmes que je vois avec cela sont :

• La licence Flow est une licence BSD à 3 clauses " Facebook BSD + Patents License ", Apache Software Foundation a interdit l'utilisation de cette licence dans de nouveaux projets. Vous pouvez lire plus de détails ici .

• Le support IDE fait défaut par rapport à TypeScript.

• La base d'utilisateurs est petite par rapport à TypeScript,

• Les typages disponibles pour les bibliothèques publiques sont incomplets, TypeScript a beaucoup de typages bien entretenus.

• La documentation et les ressources sont difficiles à trouver et sont vagues par rapport à TypeScript, vous trouverez une excellente documentation, des livres, des vidéos et de nombreuses autres ressources d'apprentissage en ligne.

• Flow utilise des fichiers .js qui sont marqués avec // @flow , cela peut être déroutant car vous voyez l'extension .js alors attendez-vous à JavaScript mais en fait, c'est FlowType. Où comme TypeScript utilise sa propre extension .ts . Cela vous permet également d'avoir les fichiers de sortie TypeScript et JavaScript avec des noms identiques dans le même répertoire, ce qui est idéal pour un petit projet, évidemment, ce ne serait pas le cas sur un grand projet car vous utiliseriez un build système pour gérer le processus de construction.

Même Google soutient TypeScript de manière considérable, ce qui montre la confiance qu'ils ont dans TypeScript. Lire le post ici ou ici .

Typescript est devenu autorisé pour le développement client sans restriction à partir de mars 2017. TypeScript et Angular sur TypeScript sont utilisés dans Google Analytics, Firebase et Google Cloud Platform et des outils internes critiques tels que le suivi des bogues, les évaluations des employés et les outils d'approbation et de lancement des produits.

Je pensais juste ouvrir la discussion sur l'utilisation d'un langage typé et voir ce que tout le monde pense de l'idée. Il semble que @mrdoob soit totalement opposé à la discussion de l'idée.

@arctwelve
Je ne vois pas en quoi ce projet n'est pas compliqué et en quoi l'utilisation d'un langage typé l'affecterait négativement.

@mrdoob
Pas du tout, je peux juste voir les avantages que cela pourrait avoir, surtout si une nouvelle branche est créée pour mettre à jour les classes ES6. Je pense que répondre en créant votre propre fork appelé three.ts est juste idiot. C'est vraiment contre les bonnes pratiques OSS si tout le monde se contente de forger des projets OSS et de modifier son propre code source au lieu de se concentrer sur le projet 1 et de le rendre le meilleur possible. Vous vous retrouveriez avec un logiciel vraiment médiocre ou des communautés se séparant et se concentrant sur le projet qu'elles préfèrent pour une raison quelconque. Pourquoi ne pouvez-vous pas avoir une discussion ouverte sur les avantages et les inconvénients ?

Pas pour jouer l'avocat du diable, mais on dirait qu'il l'a fait

avoir une discussion ouverte

c'était juste très court :)

Je partage un point de vue similaire, c'est une bibliothèque JS et JS est standardisé. Vous ne pouvez pas vous tromper en choisissant JS pour une bibliothèque JS, alors que vous le pouvez si vous choisissez autre chose. Je viens de prendre Flow comme l'une des alternatives au tapuscrit, je ne sais pas s'il y en a d'autres.

Quoi qu'il en soit, il semble que nous nous sommes vraiment éloignés du sujet.

Mugen87 a changé le titre de
Supprimer la maladie JavaScript pour évaluer les classes ES6

Le titre original faisait référence (pour autant que je sache) au manque de cohérence de style. En particulier en utilisant Object.assign() à certains endroits, et un autre modèle à d'autres.
Si j'évaluais quelque chose ici, ce serait le titre actuel du numéro. Pourquoi la question de la cohérence est-elle élevée au rang de discussion sur l'utilisation d'un nouveau langage ?

J'imagine qu'avec dactylographie et es6, le code devrait être assez cohérent.

Je résoudrais ce problème en mettant à jour cette page :

https://github.com/mrdoob/three.js/wiki/Mr.doob's-Code-Style%E2%84%A2

et en ajoutant soit :

A) "... utiliser Object.assign ..."
B) "... n'utilisez pas Object.assign"

Un style dans toute la bibliothèque. Pas besoin de le changer.

Le style fidèle à deux lignes toujours présent, par exemple, dans les classes de matériaux est beaucoup plus clair et plus propre.

C'est dans le premier message.

Je suggère:

1. éditez le titre pour refléter cette phrase, discutez d'avoir un style dans toute la bibliothèque, éditez le guide de style, etc.
2. démarrer une nouvelle discussion intitulée "évaluer les classes es6", où les classes es6 seraient évaluées
3. démarrer une nouvelle discussion intitulée "évaluer le fait d'avoir trois écrits dans une langue dactylographiée", où le tapuscrit et autres seraient discutés

Quoi qu'il en soit, il semble que nous nous sommes vraiment éloignés du sujet.

En effet. @joejordanbrown , n'hésitez pas à créer un nouveau sujet pour discuter de TypeScript.

Au fait, c'est aussi une mauvaise pratique OSS d'ignorer les conversations précédentes... https://github.com/mrdoob/three.js/issues/341#issuecomment -47000692

Retour au sujet. Je pensais que nous avions déjà résolu ce problème ?

https://github.com/mrdoob/three.js/issues/11552#issuecomment -319449068

Nous avons juste besoin de quelqu'un pour essayer.

Bon alors... tout d'abord

Premier modèle (le meilleur IMO):

function MyClass() {...}

MyClass.prototype = Object.assign( Object.create( MyClassToInherit.prototype ), {

    constructor: MyClass,

    prop1: 'something',

    method1: function someFunction() { .. },

    ...

});

Le deuxième modèle :

function MyClass() {...}

MyClass.prototype = Object.create( MyClassToInherit.prototype );

MyClass.prototype.constructor = PointLight;

MyClass.prototype.prop1 = 'something';

MyClass.prototype.method1 = function someFunction() { .. };

...

@arctwelve Ce modèle a été introduit pour de nombreuses raisons. Ce n'est pas se masturber !

Tout d'abord cela permet une lecture claire sur l'héritage d'objet. Le Object.assign concerne clairement l'héritage d'objet. Ensuite, vous ne pouvez pas perdre l'objet hérité dans plusieurs lignes de MyClass.prototype .
Deuxièmement, en cas d'héritage multiple, c'est beaucoup plus clair aussi.
Troisièmement, le constructeur de la classe est lisible et ne se perd pas en plusieurs lignes comme le premier point.
Quatrièmement, cela permet de regrouper les propriétés et les méthodes au même endroit (entre parenthèses), ce qui est beaucoup plus clair lorsque vous avez 3, 4, 5... etc classes dans le même fichier.
Cinquièmement, ce modèle permet de vérifier la copie correcte de certaines propriétés "héritées".

Enfin ( @looeee ), c'est aussi pour les performances. La première version est plus optimisée lors de l'analyse de fichiers, au lieu d'appels multiples et multiples au prototype.

En tous cas !

Aujourd'hui, on devrait passer à la syntaxe ES6 !

@mrdoob

Cela me paraît bien! Je me concentre actuellement sur WebVR, il faudra donc que ce soit quelqu'un d'autre que moi.
Nous avons juste besoin de quelqu'un pour essayer.

Souhaitez-vous créer une branche es6 ? Ou c'est tout seul ?

La première version est plus optimisée lors de l'analyse de fichiers, au lieu d'appels multiples et multiples au prototype.

Êtes-vous sûr de cela? Je m'attendrais à ce que Object.Assign soit plus lent, voire rien. Mais dans les deux cas, je doute qu'il y ait suffisamment de surcharge de performance pour s'inquiéter.

Absolument : https://jsperf.com/inline-prototype-vs-assign-prototype/1

Sous la version chrome 61.0.3163.100 (Build officiel) (64 bits) Les prototypes assignés sont environ 60% plus rapides

Intéressant. Merci d'avoir fait le test.

Ce résultat ne tient pas pour tous les navigateurs cependant. Sur Firefox, ils sont presque identiques ( Object.Assign ~3 % plus rapides), tandis que sur Edge, Object.Assign est ~33 % plus lent .

Mais dans tous les cas, je ne pense toujours pas que cela soit pertinent comme argument pour lequel le style est meilleur - même le plus lent dans l'ensemble (proto en ligne dans Chrome) fonctionne toujours à> 180 000 opérations par seconde, et il y a peut-être quelques milliers de ces configurations effectuées dans le code. On parle donc ici d'une différence de quelques millisecondes, probablement.

Pour moi, le style Object.Assign est plus propre et plus facile à lire, et c'est le principal argument en sa faveur.

Oui, il s'agit de quelques millisecondes par fichier et uniquement lorsque le fichier est analysé la première fois par le moteur javascript... mais pour une grande bibliothèque comme threejs, le gain pourrait être raisonnablement d'environ 200 millisecondes lors du chargement de la page.
N'oubliez pas la limite de 3scd pour les utilisateurs frontaux qui ne peuvent plus attendre !

J'essaie de créer un projet angulaire avec threejs et on dirait toujours que je pirate chaque partie de threejs.
Tout d'abord, c'est la syntaxe es5 avec TROIS constantes qui doit exister, par exemple, si j'ai besoin d'OrbitalControls.
Nous avons trois typages js, mais il sera plus pratique de les avoir dans le même package. Les typages ont OrbitalControls, mais nous ne pouvons pas simplement importer comme import { OrbitalControls } from 'three; .
Webpack a une secousse d'arbre, donc dans le cas d'es6, nous pourrions inclure tout ce dont nous avons besoin dans un projet et ne pas les déplacer vers un projet séparé.
@mrdoob alors pourquoi Typescript est si mauvais ? Il sera compilé en ES dans n'importe quelle version avec des typages de toute façon.
Il est également utilisé dans de nombreux autres frameworks comme React.

@FriOne Je ne sais pas si @mrdoob pense vraiment que Typescript est mauvais, mais je pense qu'il est contre la discussion de Typescript dans ce problème/thread car ce n'est pas le sujet de ce fil. Je pense que les classes ES6 ne fonctionnent pas contre ou pour Typescript. Si vous transformez la base de code en ES6, il est encore plus facile de porter la base de code sur Typescript car sa syntaxe est très similaire. Oui, je pense que Typescript pourrait activer beaucoup de nouvelles options. Par exemple, cela pourrait aider à "transpiler" un code plus optimisé, cela aide les nouveaux développeurs à apprendre la bibliothèque plus rapidement, peut-être cela ouvre-t-il des portes pour des expériences futures, par exemple : https://github.com/AssemblyScript/assemblyscript. Je pense qu'il y a beaucoup d'avantages avec Typescript @joejordanbrown a décrit les avantages en détail.

Mais revenons au sujet : je pense que l'adoption des classes ES6 serait un pas en avant et après cela, nous pourrions discuter de l'affaire Typescript. Alors faisons un pas après l'autre

@tschoartschi , pense que le tapuscrit peut aider à la migration vers les classes es6 et d'autres refactorisations. Je n'ai pas une telle expérience de migration, il se peut que je me trompe.

@FriOne cela dépend 😉 bien sûr, Typescript pourrait vous aider car le compilateur pourrait vous indiquer toutes vos erreurs et fautes, mais vous devrez d'abord configurer l'ensemble du tube de construction pour travailler avec Typescript. De plus, vous devez évaluer si Typescript convient ou non. Je pense que c'est bien de convertir d'abord en classes ES6, puis de penser à Typescript.

Salut, nous sommes un groupe de 5 étudiants de KTH qui cherchent à contribuer à un projet open source pour un cours et aimerions essayer de convertir une partie du projet vers la nouvelle syntaxe ES6.

J'ai porté Three.js sur TypeScript il y a quelque temps (r82) avec quelques exemples, comme preuve de concept.

https://github.com/flyover/three.ts

Les exemples prennent un peu de temps à charger, car la source TypeScript est transpilée à la volée. Ils se chargent aussi vite que les originaux lors de l'utilisation du JavaScript transpilé.

J'aimerais voir three.js porté sur dactylographié. Je pense que le projet a grandement besoin d'être modernisé s'il veut résister à l'épreuve du temps pour les prochaines générations Web. Un jour, nous le verrons peut-être même fonctionner avec AssemblyScript et s'exécuter dans WASM. Si ce n'est pas trois, alors quelque chose d'autre le fera sûrement.

Ceci est terminé @WestLangley et @mrdoob

@bhouston quelle est la conclusion ici?

@pkieltyka oui, je pense aussi que TypeScript aurait beaucoup de sens pour une bibliothèque comme Three.js. Outre tous les avantages techniques, cela faciliterait également l'utilisation de la bibliothèque et aiderait les débutants à explorer l'API. Mais je pense aussi qu'il est important de terminer d'abord tous les trucs ES6, puis d'envisager TypeScript. Je pense que depuis le dernier JavaScript, il n'est pas trop compliqué d'ajouter des types sous forme de TypeScript.

@flyover bien aussi voir une preuve de concept pour une version TypeScript de Three.js. Avez-vous reçu des commentaires des responsables de Three.js ?

Je supporte également le tapuscrit pour three.js. le typescript est fondamentalement le meilleur
pratique et JavaScript brut n'est plus.

Le samedi 5 janvier 2019 à 04h13, tschoartschi < [email protected] a écrit :

@pkieltyka https://github.com/pkieltyka oui je pense aussi TypeScript
aurait beaucoup de sens pour une bibliothèque comme Three.js. A côté de tous les
pros techniques, cela faciliterait également l'utilisation de la bibliothèque et aiderait les débutants
pour explorer l'API. Mais je pense aussi qu'il est important de finir toutes les ES6
Remplissez d'abord, puis envisagez TypeScript. Je pense depuis le dernier
JavaScript ce n'est pas trop compliqué d'ajouter des types sous forme de TypeScript.

@flyover https://github.com/flyover sympa aussi voir une preuve de concept pour
une version TypeScript de Three.js. Avez-vous eu des retours des mainteneurs
de Three.js ?

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451639995 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAj6_bkdND7I0_F4AJcBV0DYLpToUIVhks5vAGykgaJpZM4N9vH8
.

@bhouston Je suis d'accord que TypeScript est une excellente technologie mais je ne le dirais pas comme vous l'avez fait. Je pense que nous devrions toujours rester aussi proches que possible du JavaScript brut et ajouter les fonctionnalités TypeScript en plus. Étant donné que TypeScript suit de très près la spécification JavaScript, TypeScript se lit vraiment comme ES6 avec des types.

Pour une bibliothèque comme three.js, TypeScript pourrait être vraiment bénéfique et pourrait être adopté progressivement. Nous n'aurions donc pas besoin d'une réécriture "big bang", surtout pas après que tous les refactors ES6 soient terminés.

Ce serait intéressant d'entendre si la position de @mrdoob sur TypeScript a changé. TypeScript semble devenir la norme "de facto" pour "JavaScript typé" (notez que je mets mes affirmations sous apostrophe car ce ne sont pas des faits concrets)

La première étape devrait consister à adopter les fonctionnalités ES6, en particulier les classes, la fonction fléchée, « let » et « const ».

Une fois que nous avons fait cela, nous pouvons discuter correctement de la prise en charge du dactylographie car, comme le souligne @roomle-build, il est facile d'ajouter progressivement des fonctionnalités de dactylographie au-dessus du code ES6 si nous le décidons.

Faire les deux à la fois me semble compliquer les choses.

C'est bien d'entendre que TypeScript pourrait être une option à un moment donné dans le futur :-) peut-être pourrions-nous réutiliser une partie du travail effectué par @flyover

Mais je suis totalement d'accord avec @looeee pour finir d'abord tous les trucs ES6 et ensuite me concentrer sur les prochaines étapes

finir tous les trucs ES6

Je serais heureux si nous pouvions au moins le démarrer 😅

Une bonne étape intermédiaire vers TypeScript consisterait à ajouter des fichiers de type à côté de chaque fichier JavaScript. Il y aurait donc les deux :

Vector3.js
Vecteur3.d.ts

Cela nous donne tous les avantages de TypeScript en tant que fichiers annexes.

À l'heure actuelle, il existe un fichier @types/three mais il est obsolète et maintenu séparément - il sera donc toujours à court de données.

Le principal concurrent de Three.JS est Babylong et il est entièrement dactylographié et je pense qu'il en profite.

Mais tuer @types/three et l'intégrer en tant que fichiers de définition de type side-cars dans Three proprement dit serait un excellent premier pas.

Nous devons également intégrer tous les exemples dans /src avec un certain type de tree shaking.

À l'heure actuelle, la structure de code pour Three.JS est tellement 2014 et c'est juste une douleur à travailler.

Tous les exemples ?

Exemples/js

Le lundi 7 janvier 2019 à 10 h 25, Dusan Bosnjak < [email protected] a écrit :

Tous les exemples ?

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451970482 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAj6_Q3Kakb5Qn2DqGbMVvLkW_28cOyaks5vA2b5gaJpZM4N9vH8
.

@bhouston

Une bonne étape intermédiaire vers TypeScript consisterait à ajouter des fichiers de type à côté de chaque fichier JavaScript. Il y aurait donc les deux :

Vector3.js
Vecteur3.d.ts

Les fichiers .d.ts agiraient-ils comme des fichiers .h en c ?

Les fichiers .d.ts agiraient-ils comme des fichiers .h en c ?

C'est une très bonne analogie. Quelqu'un d'intéressant a déjà fait la plupart de cela ici: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/three Ainsi, il suffirait de s'approprier ces fichiers de type et de les intégrer dans Three.js. Si vous le souhaitez, nous pouvons créer un PR qui l'intègre dans Three.js et le divise proprement.

Pour montrer à quel point Typescript est populaire, regardez combien de @Types/three sont téléchargés par semaine :

https://www.npmjs.com/package/@types/three - 63 000 téléchargements par semaine.

Impressionant!

Si vous le souhaitez, nous pouvons créer un PR qui l'intègre dans Three.js et le divise proprement.

Ça me tente bien 👍

Est-il possible d'exécuter une vérification en ligne de commande, similaire à eslint, en s'assurant que les fichiers de type et les fichiers source .js sont alignés ? Si nous nous approprions les fichiers d.ts , il serait fortement préférable d'avoir un moyen de vérifier régulièrement qu'ils correspondent.

Pour montrer à quel point Typescript est populaire, regardez combien de @Types/three sont téléchargés par semaine :

https://www.npmjs.com/package/@types/three - 63 000 téléchargements par semaine.

J'attribuerais cela davantage à la popularité de Visual Studio Code, car cela se produit automatiquement lorsque vous utilisez Visual Studio Code, via leur fonction d'acquisition automatique de type.
Cela dit, il ne peut être ignoré.

@flyover @bunnybones1 @mrdoob @looeee @donmccurdy @bhouston @roomle-build @pkieltyka @FriOne @joejordanbrown puisque vous semblez tous intéressés par TypeScript, je voulais noter que j'ai créé un nouveau problème concernant TypeScript. Je pense qu'il est logique de déplacer toutes les discussions TS là-bas. Si vous êtes intéressé, vous pouvez le trouver ici : https://github.com/mrdoob/three.js/issues/15545

Je suis prêt à consacrer du temps au portage vers les classes ES6. Je pense que ce sera une bonne solution de pont pour un jour prendre en charge Typescript.

La première étape consiste à convertir certains des modules complémentaires en ES6.

https://github.com/mrdoob/three.js/tree/dev/examples/jsm

Les Contrôleurs, les Chargeurs et les Exportateurs sont de bons candidats. N'hésitez pas à aider !

@mrdoob juste pour confirmer, vous voulez dire les convertir en modules ES mais pas encore utiliser d'autres fonctionnalités ES6, n'est-ce pas ?

Je suppose que le processus de faire cette conversion est:

1. Utilisez le script modularize.js pour convertir le fichier d'origine en module ES.
2. Nettoyez les problèmes si nécessaire.
3. À un moment donné (cette version ou dans un futur proche), nous commencerons à utiliser rollup-examples.config.js pour convertir les modules ES en modules UMD, auquel cas la version dans examples/js n'est plus maintenue par main.
4. Une fois que cela est stable, nous pouvons envisager d'autres changements comme l'introduction de fonctionnalités ES6.

@mrdoob juste pour confirmer, vous voulez dire les convertir en modules ES mais pas encore utiliser d'autres fonctionnalités ES6, n'est-ce pas ?

Ouais désolé. J'aurais dû préciser.

Moi et @bhouston avons créé le PR promis qui fournit les fichiers *.d.ts pour la plupart du projet Three.JS. https://github.com/mrdoob/three.js/pull/15597

Je ne peux tout simplement pas attendre les classes ES6 et les définitions Typescript. Chaque fois que je travaille avec three.js, je dois copier-coller des centaines de lignes de code pour réimplémenter une fonction qui se trouve dans une portée inaccessible. Ce n'est vraiment pas une façon élégante de travailler si vous devez optimiser vos scènes. Cela amènerait le flux de travail à un nouveau niveau pour pouvoir enfin étendre et remplacer les fonctions.
Veuillez donc rendre les fonctions de classe au moins "protégées" et accessibles sans exception 🤗

Chaque fois que je travaille avec three.js, je dois copier-coller des centaines de lignes de code pour réimplémenter une fonction qui se trouve dans une portée inaccessible. ... Veuillez donc rendre les fonctions de classe au moins „protégées“ et accessibles sans exception.

@dionysiusmarquis Je ne suis pas sûr de comprendre ce que vous voulez dire ici ... les typages TS existants ont des fonctions que vous souhaitez utiliser incorrectement marquées comme privées? Ou quelque chose à propos des définitions de classe de style prototype actuelles rend l'utilisation difficile dans TS ? Pourriez-vous partager un exemple ?

Chaque fois que je travaille avec three.js, je dois copier-coller des centaines de lignes de code pour réimplémenter une fonction qui se trouve dans une portée inaccessible. ... Veuillez donc rendre les fonctions de classe au moins „protégées“ et accessibles sans exception.

@dionysiusmarquis Je ne suis pas sûr de comprendre ce que vous voulez dire ici ... les typages TS existants ont des fonctions que vous souhaitez utiliser incorrectement marquées comme privées? Ou quelque chose à propos des définitions de classe de style prototype actuelles rend l'utilisation difficile dans TS ? Pourriez-vous partager un exemple ?

Je voulais juste implémenter une carte d'ombre spécifique pour un scénario spécifique. Il aurait été utile de pouvoir remplacer getDepthMaterial par exemple. Pour le moment, j'injecte mon propre WebGLShadowMap dans le processus de construction avec une version copier/coller incluant les modifications souhaitées.
Ce serait tellement bien si chaque classe three.js exposait autant que possible. Avec le tapuscrit, vous pouvez facilement marquer les fonctions comme private ou protected pour décrire le but recherché. Mon ES6 Class/Typescript ShadowMap par exemple ressemble à ceci :

interface MaterialCache {
  [uuid: string]: {[uuid: string]: MeshDepthMaterial}
}

class ShadowMap {
  public enabled: boolean = false
  public autoUpdate: boolean = true
  public needsUpdate: boolean = false
  public type: ShadowMapType

  …

  protected depthMaterials: MeshDepthMaterial[]
  protected materialCache: MaterialCache

  constructor (renderer: WebGLRenderer, objects: WebGLObjects, maxTextureSize: any) {
    …
  }

  protected getDepthMaterial (object: Object3D, material: Material) {
    …
  }
}

export { ShadowMap as WebGLShadowMap }

On se sent comme à la maison si vous êtes autorisé à modifier les classes "de bas niveau"

J'ai une question dans le contexte des cours. Comment transférerions-nous des méthodes comme Vector3.unproject dans la syntaxe de la classe ? La méthode utilise en fait une fermeture afin de créer une nouvelle portée. Il s'agit d'un mécanisme important qui maintient le nombre de créations d'objets aussi bas que possible.

Avons-nous besoin Object.assign dans ces cas ?
@Mugen87

Vous pouvez faire des fermetures avec les classes maintenant. Il n'est tout simplement pas évident de naviguer dans ce sucre syntaxique. Voir ma réponse sur StackOverflow : https://stackoverflow.com/questions/39297258/iife-in-es6-class-literal/56077521#56077521 (je dois être humble et admettre que je ne comprends pas bien comment/pourquoi cela fonctionne .)

Désolé, mais ce code ressemble à un anti-modèle et nous ne devrions pas l'adapter dans le projet. Il existe des solutions appropriées pour gérer les variables dans la portée du module. Je suggère d'aller dans cette voie.

@ Mugen87 oui, je pense aussi que nous devrions faire bon usage de module-scope. Cela aiderait également pour des choses comme le secouage des arbres. Cela a déjà été discuté dans de nombreux autres problèmes comme celui-ci : https://github.com/mrdoob/three.js/issues/6241#issuecomment -398703521

Désolé, mais ce code ressemble à un anti-modèle et nous ne devrions pas l'adapter dans le projet. Il existe des solutions appropriées pour gérer les variables dans la portée du module. Je suggère d'aller dans cette voie.

Aucun problème. Je viens d'évoquer la possibilité. Si vous avez une solution meilleure/plus propre en cours, je suis impatient de la voir en action. Le projet Three.js (utilisation, source, discussions, etc.) a été ma principale source de connaissances JS, donc l'introduction de nouveaux et meilleurs modèles de programmation dans Three.js sera probablement bénéfique pour moi et mes projets aussi. Rien à regretter. ;-)

@ Mugen87 Pouvez-vous expliquer un peu pourquoi vous considérez les class-IIFE comme un anti-modèle, ne serait-ce que pour que je puisse apprendre et comprendre un peu plus? Je comprends que les variables de portée des modules sont inhérentes, mais ce n'est pas différent de la façon dont le noyau était construit auparavant. Et avec autant de fonctions utilisant des variables de cache, il sera vraiment important de s'assurer qu'aucune des fonctions n'entre en collision ou n'utilise de variables en même temps - la portée de la fonction facilite la gestion et la maintenance, c'est pourquoi je ne vois pas comme un anti-modèle (au moins par rapport au lancement de toutes les variables de cache dans la portée du module).

Pouvez-vous expliquer un peu pourquoi vous considérez les classes IIFE comme un anti-modèle

Je n'utiliserais pas une approche susceptible d'empêcher le tremblement des arbres comme mentionné ici : https://github.com/mrdoob/three.js/pull/14695. De plus, je pense que l'ensemble du modèle ressemble à un hack. L'utilisation d'approches moins "fantaisistes" fonctionne généralement mieux. Éviter les fermetures inutiles devrait également améliorer les performances d'exécution du code en général (je ne peux pas le prouver avec une référence, mais je l'ai entendu lors d'une conférence il y a quelque temps).

Et avec autant de fonctions utilisant des variables de cache, il sera vraiment important de s'assurer qu'aucune des fonctions n'entre en collision ou n'utilise de variables en même temps.

Les IIFE sont principalement utilisés dans les cours de mathématiques. Étant donné que nous avons une bonne couverture de test là-bas ( @gero3 a fait un excellent travail ces derniers temps en ajoutant plus de tests unitaires), il devrait être plus facile de rendre leur suppression robuste.

Il est bon de supprimer les IIFE. Je pense que j'en suis responsable en 2013. C'était pour se débarrasser d'un modèle variable statique qui était difficile à maintenir. Cela a été fait dans ce PR:

https://github.com/mrdoob/three.js/pull/2941

https://github.com/mrdoob/three.js/issues/2936

Et discuté encore plus tôt ici:

https://github.com/mrdoob/three.js/pull/2920#issuecomment -12217793

Fait intéressant, lorsque nous les avons insérés, il n'y avait pas de différence de performance de code.

Je suppose que le processus de faire cette conversion est:

1. Utilisez le script modularize.js pour convertir le fichier d'origine en module ES.
2. Nettoyez les problèmes si nécessaire.
3. À un moment donné (cette version ou dans un futur proche), nous commencerons à utiliser rollup-examples.config.js pour convertir les modules ES en modules UMD, auquel cas la version dans examples/js n'est plus maintenue par main.
4. Une fois que cela est stable, nous pouvons envisager d'autres changements comme l'introduction de fonctionnalités ES6.

Hey. peut-être l'avez-vous manqué, mais quelles étaient nos étapes progressives vers les cours ?

1. [x] Utilisez le script modularize.js pour convertir le fichier d'origine en module ES.
2. [x] Nettoyez les problèmes si nécessaire.
3. [ ] À un moment donné (cette version ou dans un avenir proche), nous commencerons à utiliser rollup-examples.config.js pour convertir les modules ES en modules UMD, auquel cas la version dans examples/js n'est plus maintenue par main.
4. [ ] Une fois que cela est stable, nous pouvons envisager d'autres changements comme l'introduction de fonctionnalités ES6.

Dans les étapes ci-dessus, nous avons essentiellement terminé les étapes (1) et (2).

Étape (3) nous ne procédons plus de cette façon, mais nous déconseillerons et supprimerons le dossier examples/js à un moment donné (voir https://github.com/mrdoob/three.js/pull/18749) .

Je pense que cela signifie que l'étape (4), l'introduction des classes ES6 dans examples/jsm ne peut être effectuée (pour l'instant) que sur les très rares exemples qui ne sont pas générés à partir de versions source examples/js . Une fois que examples/js est supprimé, nous pouvons faire le reste.

^ Mais je lis peut-être trop entre les lignes ici, peut-être que @Mugen87 ou @mrdoob peuvent confirmer ?

IMO, le projet devrait se concentrer sur la dépréciation et la suppression de examples/js afin d'obtenir une base de code uniquement pour les modules. À l'étape suivante, je recommanderais de passer à la migration de classe. En commençant par les exemples, puis en migrant le noyau.

parfait. Je vous remercie. va regarder de plus près ces façons

Republié à partir d'un numéro clos.
Salut,

Je voulais créer ce numéro pour essayer de démêler les pensées de tout le monde sur la façon dont nous aimerions avancer avec la migration de classe.

Mon petit résumé de ce que j'ai rencontré jusqu'à présent :

• Nous devrions déprécier le dossier des exemples avant de faire quoi que ce soit d'autre
• Il y a des parties de src/ qui ne sont étendues par aucun des exemples qui pourraient être convertis
• Avec quelques modifications apportées au script modularize.js, nous pourrions commencer avec examples/js/ qui génère les scripts examples/jsm correspondants.

Ai-je raté quelque chose ?

Nous devrions déprécier le dossier des exemples avant de faire quoi que ce soit d'autre

Je ne sais pas qui est responsable de la prochaine étape spécifique du dossier examples/js . À moins que nous puissions articuler ce plan, je préférerais que cela ne bloque pas la conversion des choses en classes ES. Pour cette raison, je suis quelque peu en désaccord avec https://github.com/mrdoob/three.js/issues/11552#issuecomment -592768708. 🙂

suite à cela, il semble que nous attendons juste qu'une date soit fixée

De plus, dans le cadre d'une petite révision que j'ai faite, j'ai trouvé ce commentaire sur la façon dont d'autres fonctionnalités ES2015 pourraient être introduites via le processus de construction de cumul actuel. Il y a même un exemple donné .

edit : voici l' essentiel d'un autre exemple rapide

Commençons le train de conversion .
Commentaire sur les dépendances de fichiers .

@DefinitelyMaybe J'ai un peu de temps et j'aimerais aider. Puis-je emporter certains articles de la liste dependencies.json ?

👍

appelons dibs sur les choses

@DefinitelyMaybe Quelle est la meilleure façon de gérer l'héritage d'un ancêtre profond comme Object3D ? Par exemple, j'ai rencontré une rupture en convertissant src/audio/AudioListener.js :

[ROLLUP] bundles src/Three.js → build/three.js...
[ROLLUP] (!) Error when using sourcemap for reporting an error: Can't resolve original location of error.
[ROLLUP] src/audio/AudioListener.js: (137:1)
[ROLLUP] [!] Error: 'return' outside of function
[ROLLUP] src/audio/AudioListener.js (137:1)
[ROLLUP] 135:   };
[ROLLUP] 136: 
[ROLLUP] 137:   return AudioListener;
[ROLLUP]        ^
[ROLLUP] 138: }(Object3D));
[ROLLUP] Error: 'return' outside of function

nous allions faire une note en haut du fichier sur tous les problèmes que nous rencontrions, si je me souviens bien.

J'ai mal compris ce qui se passait avec AudioListener... Après quelques débogages, je pense qu'il y a un problème de correspondance dans la transformation bubleCleanup . Voir https://github.com/mrdoob/three.js/pull/19934#issuecomment -667411997 pour plus d'informations. J'ai rencontré cela avec quelques classes différentes, nous devrons donc probablement le trier avant d'aller beaucoup plus loin.

ce sera le cas pour certains fichiers mais pas pour tous. Nous anticipions un tel problème.

Pour ceux qui suivent, veuillez lire rapidement la discussion ici .

En attendant, dibs sur src/loaders !