Three.js: Evaluieren Sie ES6-Klassen

Sie schlagen also vor, stattdessen dieses Muster zu verwenden?

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

class PointLight extends Light

hehe 😄 Und keine Probleme...

@sasha240100 eines Tages...

@mrdoob nicht ganz - die beiden von Ihnen erwähnten Möglichkeiten sind direkt gleichwertig. Ich denke, der OP vergleicht

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

mit

function PointLight () { ... };

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

PointLight.prototype.constructor = PointLight;

PointLight.prototype.prop1 = 'something';

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

...

So wird es zum Beispiel hier gemacht.
Soweit ich sehen kann, sind diese Stile gleichwertig - gibt es etwas, das ich vermisse?
Oder wurde der Stil geändert, um Object.Assign zu verwenden, sobald er verfügbar wurde, und nicht in der gesamten Codebasis aktualisiert?

@looeee @bfred-it @mrdoob Warum nicht einfach rollup-babel verwenden?

Vergleich :
Strom. es5 + es6 Harmony-Module.

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+. Gleicher Code, aber es2015+ mit 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;
  }
}

ES6-Funktionen, die Three.js-Code vereinfachen würden:

• Standardparameterwerte.
  
  
  
  • Sie können solche Codeteile leicht ersetzen
  
  
• Immobilien Kurzschrift
  
  
  
  • Kann hier verwendet werden
  
  
• Pfeilfunktion
  
  
  
  • https://github.com/mrdoob/three.js/blob/dev/src/loaders/JSONLoader.js#L36
  
  

Ich bin absolut dafür, zu ES2015+ zu wechseln, wir müssen nur einen Weg finden, ähnlichen Code auszugeben, als den, den wir derzeit daraus haben, damit die Leistung in allen Fällen gleich bleibt.

Ich habe eine Frage im Zusammenhang mit dem Unterricht. Wie würden wir Methoden wie Vector3.unproject in die Klassensyntax übertragen? Die Methode verwendet tatsächlich eine Schließung, um einen neuen Geltungsbereich zu erstellen. Dies ist ein wichtiger Mechanismus, der die Anzahl der Objekterstellungen so gering wie möglich hält.

Brauchen wir in diesen Fällen Object.assign ?

@Mugen87 @mrdoob Einige interessante Informationen zur Leistung von es6. Besonders bei Object.assign :

Aus diesem Artikel

Wie würden wir Methoden wie Vector3.unproject in die Klassensyntax übertragen? Die Methode verwendet tatsächlich eine Schließung, um einen neuen Geltungsbereich zu erstellen.

@ Mugen87 Können sie nicht einfach nicht exportierte Objekte mit Modulbereich sein? Etwas wie das;

const tempMatrix = new Matrix();    

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

Ah ja, ich denke das sollte funktionieren 😊

Letzten Monat wurde dies auf Twitter vorgeschlagen :

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

@mrdoob Wow! Es scheint schon zu funktionieren. Können wir nicht eine Verzweigung machen, einige Klassen in es6 umwandeln und sehen, wie es kompiliert wird?

@satori99 Als Idee, wie man tempMatrix im Vector3-Code behält, um Probleme mit Globals zu vermeiden:

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

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

@mrdoob Wow! Es scheint schon zu funktionieren. Können wir nicht eine Verzweigung machen, einige Klassen in es6 umwandeln und sehen, wie es kompiliert wird?

Hört sich gut an! Ich konzentriere mich derzeit auf WebVR, also muss es jemand anderes als ich sein.

@sasha240100 Der Vorteil der Verwendung von modulbezogenen Variablen besteht darin, dass sie vor regulärem Benutzercode verborgen bleiben, was für temporäre Variablen angemessen erscheint.

Ich habe nichts gegen den pythonistischen Ansatz "Wir sind alle Erwachsene hier" in Bezug auf private Vars, aber temporäre Variablen sollten den Namespace nicht unnötig verschmutzen.

Außerdem wäre es schön, wenn diejenigen von uns, die die native Modulunterstützung in ihren Browsern aktiviert haben, die src-Dateien direkt laden könnten. Dies ist eine viel angenehmere Art zu entwickeln, ohne Beobachter zu benötigen und nach jeder Bearbeitung zu transpilieren. Die Verwendung von Klasseneigenschaften bedeutet, dass dies nicht möglich ist, da sie nicht Teil der aktuellen Klassenspezifikation sind.

Entschuldigung für die Einmischung. Wir sollten den Titel des Problems wahrscheinlich in etwas wie „ES6-Klassen bewerten“ ändern, da sich der Thread jetzt in etwas völlig anderes geändert hat.

Warum das Muster @Mugen87 @satori99 ändern ?

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

Warum versuchen Sie es nicht mit Typoskript, es kann in andere Versionen von js kompiliert werden

TypeScript wäre wirklich eine großartige Option, über die man nachdenken sollte, da es ein Transpiler + Type Checker und eine Obermenge von JavaScript ist, sodass es einfach ist, eine Codebasis auf .ts-Dateien zu verschieben und mit Typprüfung schrittweise auf ES6 umzugestalten.

Es mag beängstigend klingen, wenn Sie TypeScript noch nie verwendet haben, aber es ist wirklich keine große Lernkurve und wäre ein kleiner Preis für die Vorteile, die es bringen würde. Die TypeScript-Community hilft Ihnen gerne bei diesem Übergang und erstellt Leistungstests für die aktuelle Bibliothek, um sicherzustellen, dass sie nicht herabgestuft wird.

Ein paar nützliche Artikel:

• Warum Sie keine Angst vor TypeScript haben sollten
• TypeScript vs. ES6 vs. ES2015
• TypeScript hat gewonnen
• Was ist TypeScript und warum mit Anders Hejlsberg

Um den Kernentwickler Anders Hejlsberg zu zitieren, wurde TypeScript als Reaktion auf Beschwerden von Kunden und internen Teams geboren, dass sich JavaScript nicht gut für große Anwendungen eignet.

Das Ziel war es, "JavaScript mit Dingen wie Klassen, Modulen und statischer Typisierung zu stärken", ohne den Vorteil zu opfern, dass es offene Standards und plattformübergreifend ist; Das Ergebnis war eine "Sprache für die Entwicklung von JavaScript im Anwendungsmaßstab", die als Obermenge der Sprache erstellt wurde.

Bis Browser TypeScript nativ ausführen können, ziehe ich es vor, weiterhin JavaScript zu verwenden.

@mrdoob

Ich kann das nicht als triftigen Grund dafür sehen, TypeScript nicht zu verwenden, nur weil es nicht direkt im Browser ausgeführt werden kann. Sie möchten nicht, dass es im Browser ausgeführt wird, da all die zusätzlichen Codezeilen nur für die Überprüfung der Kompilierzeit vorgesehen sind. Es ist derzeit keine Laufzeitprüfungssprache. Wenn es also jemals im Browser verwendet wurde, wird höchstwahrscheinlich der gesamte eingegebene Code entfernt, da dies die Leistung beeinträchtigt, und dies wäre dann Vanilla-JavaScript-Code.

Ich denke, Sie vermissen völlig den Sinn der Verwendung einer typisierten Sprache und die Vorteile, die sie bei der Entwicklung in einer großen Codebasis hat. Sie schreiben und verwenden immer noch JavaScript, der springende Punkt bei TypeScript ist, dass es eine Obermenge von JavaScript ist. Sie schreiben JavaScript mit Typen, die in JavaScript in der angegebenen ECMAScript-Zielversion kompiliert werden, die in den Compileroptionen konfigurierbar ist, die zulässigen Werte sind „es3“, „es5“, „es2015“, „es2016“, „es2017“ oder „ esweiter'.

Da Typescript JavaScript ist, ist es möglich, schrittweise zu migrieren, ohne massive Kopfschmerzen zu haben, alles auf einmal umzugestalten. Es kann schrittweise von der Community durchgeführt und verbessert werden. Es ist nicht mehr Arbeit als das, was hier mit der Umgestaltung zur Verwendung von ES6-Klassen besprochen wird. Das ist der einzige Grund, warum ich es hier erwähne, anstatt ein neues Thema zu eröffnen.

Gute Beispiele finden Sie unten unter den TypeScript Playground-Links:

• Klassisches JavaScript-Beispiel
• Beispiel zum Hinzufügen von Typen
• Hinzufügen von Typen mit Fehler Beispiel
• Beispiel für die Verwendung von Klassen
• Verwenden von Klassen mit Fehler Beispiel

@joejordanbrown

Fällt Ihnen jemand ein, der Ihnen möglicherweise widersprechen könnte, dass Typoskript die beste Lösung für dieses spezielle Problem ist?

Wenn Sie typescript vs in Google eingeben, werden einige Begriffe angezeigt, darunter Flow. Die Suche danach scheint eine Reihe von Artikeln zu ergeben, in denen die Leute die Vor- und Nachteile dieser beiden diskutieren.

Kein Typ scheint ein größerer Kompromiss zu sein, als einen von diesen zu wählen.

Speichern Sie Typescript für Projekte, die komplizierter sind als das Ergebnis, das sie erstellen – insbesondere Frontend-Frameworks, die überhaupt in HTML hätten implementiert werden können. Mein ursprüngliches Ziel war es, die JavaScript-Krankheit loszuwerden, nicht sie zu verschlimmern. JavaScript ist eine einfache, fast spielzeughafte Sprache, die manchmal für komplexe Ergebnisse wie three.js verwendet wird. Typoskript ist sinnlos.

Am 6. September 2017 um 13:55 Uhr schrieb Joe [email protected] :

@mrdoob

Ich kann das nicht als triftigen Grund dafür sehen, TypeScript nicht zu verwenden, nur weil es nicht direkt im Browser ausgeführt werden kann. Sie möchten nicht, dass es im Browser ausgeführt wird, da all die zusätzlichen Codezeilen nur für die Überprüfung der Kompilierzeit vorgesehen sind. Es ist derzeit keine Laufzeitprüfungssprache. Wenn es also jemals im Browser verwendet wurde, wird höchstwahrscheinlich der gesamte eingegebene Code entfernt, da dies die Leistung beeinträchtigt, und dies wäre dann Vanilla-JavaScript-Code.

Ich denke, Sie vermissen völlig den Sinn der Verwendung einer typisierten Sprache und die Vorteile, die sie bei der Entwicklung in einer großen Codebasis hat. Sie schreiben und verwenden immer noch JavaScript, der springende Punkt bei TypeScript ist, dass es eine Obermenge von JavaScript ist. Sie schreiben JavaScript mit Typen, die in JavaScript in der angegebenen ECMAScript-Zielversion kompiliert werden, die in den Compileroptionen konfigurierbar ist, die zulässigen Werte sind „es3“, „es5“, „es2015“, „es2016“, „es2017“ oder „ esweiter'.

Da Typescript JavaScript ist, ist es möglich, schrittweise zu migrieren, ohne massive Kopfschmerzen zu haben, alles auf einmal umzugestalten. Es kann schrittweise von der Community durchgeführt und verbessert werden. Es ist nicht mehr Arbeit als das, was hier mit der Umgestaltung zur Verwendung von ES6-Klassen besprochen wird. Das ist der einzige Grund, warum ich es hier erwähne, anstatt ein neues Thema zu eröffnen.

Beispiele finden Sie unter TypeScript Playground-Links:

Klassisches JavaScript-Beispiel
Beispiel zum Hinzufügen von Typen
Hinzufügen von Typen mit Fehler Beispiel
Beispiel für die Verwendung von Klassen
Verwenden von Klassen mit Fehler Beispiel
—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

^ Ich würde sogar mit dem monströsen Muster zurechtkommen, solange es konsistent ist.

@joejordanbrown hört sich an, als ob Sie in Typoskript verliebt sind. Fühlen Sie sich frei, das Projekt zu forken und auf Typoskript zu portieren. drei.ts! 🙌

@pailhead

Das ist eine Frage der Wahl, ich bin sicher, viele werden zustimmen und nicht zustimmen, das ist normal, aber richtig! Du wirst immer „dies gegen das“, „meins ist besser als deins“ sehen. Ich verstehe, dass jeder seine eigenen Vorteile hat. Es geht darum, die verfügbaren Optionen abzuwägen und zu sehen, ob sie dem Projekt nützen können. Vergleiche sind eine gute Sache, sie bringen Projekte voran.

Sie erwähnen Flow, die Probleme, die ich dabei sehe, sind:

• Flow-Lizenzierung ist BSD 3-Klausel „ Facebook BSD + Patents License “, die Apache Software Foundation hat die Verwendung dieser Lizenz in neuen Projekten verboten. Weitere Einzelheiten können Sie hier nachlesen.

• IDE-Unterstützung fehlt im Vergleich zu TypeScript.

• Die Benutzerbasis ist im Vergleich zu TypeScript klein,

• Verfügbare Typisierungen für öffentliche Bibliotheken sind unvollständig, TypeScript hat viele gut gepflegte Typisierungen.

• Dokumentation und Ressourcen sind schwer zu finden und im Vergleich zu TypeScript vage. Sie werden großartige Dokumentationen, Bücher, Videos und viele andere E-Learning-Ressourcen finden.

• Flow verwendet .js-Dateien, die mit // @flow gekennzeichnet sind. Dies kann verwirrend sein, da Sie die Erweiterung .js sehen. Erwarten Sie also JavaScript, aber tatsächlich ist es FlowType. Wobei TypeScript seine eigene Erweiterung .ts verwendet. Dadurch können Sie auch die TypeScript- und JavaScript-Ausgabedateien mit identischen Namen im selben Verzeichnis haben, was natürlich ideal für ein kleines Projekt ist, aber das wäre bei einem großen Projekt nicht der Fall, da Sie einen Build verwenden würden System zur Verwaltung des Build-Prozesses.

Sogar Google unterstützt TypeScript in großem Umfang, was das Vertrauen zeigt, das sie in TypeScript haben. Lesen Sie den Beitrag hier oder hier .

Typescript ist seit März 2017 für die uneingeschränkte Client-Entwicklung zugelassen. TypeScript und Angular on TypeScript werden in Google Analytics, Firebase und der Google Cloud Platform sowie wichtigen internen Tools wie Fehlerverfolgung, Mitarbeiterbewertungen sowie Tools zur Produktgenehmigung und -einführung verwendet.

Ich dachte nur, ich würde die Diskussion über die Verwendung einer typisierten Sprache eröffnen und sehen, was alle anderen über die Idee denken. Es scheint jedoch, dass @mrdoob völlig dagegen ist, die Idee überhaupt zu diskutieren.

@arctwelve
Ich sehe nicht, wie dieses Projekt nicht kompliziert ist und wie die Verwendung einer typisierten Sprache es negativ beeinflussen würde.

@mrdoob
Überhaupt nicht, ich sehe nur die Vorteile, die es haben könnte, insbesondere wenn ein neuer Zweig erstellt wird, um auf ES6-Klassen zu aktualisieren. Ich denke, mit der Erstellung einer eigenen Gabel namens three.ts zu antworten, ist einfach albern. Das ist wirklich gegen gute OSS-Praktiken, wenn jeder nur OSS-Projekte forkt und seinen eigenen Quellcode modifiziert, anstatt sich auf das eine Projekt zu konzentrieren und es so gut wie möglich zu machen. Sie würden mit wirklich schlechter Software oder Communitys enden, die sich aufteilen und sich aus irgendeinem Grund auf das Projekt konzentrieren, das sie bevorzugen. Warum können Sie nicht offen über die Vor- und Nachteile diskutieren?

Nicht um den Anwalt des Teufels zu spielen, aber es scheint, als hätte er es getan

eine offene Diskussion führen

es war nur sehr kurz :)

Ich teile einen ähnlichen Standpunkt, es ist eine JS-Bibliothek und JS ist standardisiert. Sie können nichts falsch machen, wenn Sie JS für eine JS-Bibliothek auswählen, während Sie dies können, wenn Sie sich für etwas anderes entscheiden. Ich habe Flow einfach als eine der Alternativen zu Typoskript genommen, keine Ahnung, ob es noch andere gibt.

Wie auch immer, es scheint, als wären wir wirklich vom Thema abgekommen.

Mugen87 änderte den Titel von
Entfernen Sie die JavaScript-Krankheit , um ES6-Klassen auszuwerten

Der ursprüngliche Titel bezog sich (soweit ich verstehe) auf die mangelnde Stilkonsistenz. Insbesondere die Verwendung Object.assign() an einigen Stellen und ein anderes Muster an anderen.
Wenn ich hier etwas bewerten würde, wäre es der aktuelle Titel der Ausgabe. Warum wird die Frage der Konsistenz zu einer Diskussion über die Verwendung einer neuen Sprache erhoben?

Ich stelle mir vor, dass der Code sowohl bei Typoskript als auch bei es6 ziemlich konsistent sein sollte.

Ich würde dieses Problem beheben, indem ich diese Seite aktualisiere:

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

und entweder hinzufügen:

A) "... verwenden Sie Object.assign ..."
B) "... verwenden Sie nicht Object.assign"

Ein Stil in der gesamten Bibliothek. Keine Notwendigkeit, es zu ändern.

Der originalgetreue Zwei-Linien-Stil zum Beispiel in den Materialklassen ist viel klarer und sauberer.

Das steht im ersten Beitrag.

Ich schlage vor:

1. Bearbeiten Sie den Titel, um diesen Satz widerzuspiegeln, diskutieren Sie, einen Stil in der gesamten Bibliothek zu haben, bearbeiten Sie den Styleguide usw.
2. Beginnen Sie eine neue Diskussion mit dem Titel "evaluate es6-Klassen", in der es6-Klassen evaluiert werden
3. Starten Sie eine neue Diskussion mit dem Titel "Bewerten Sie, ob drei in einer getippten Sprache geschrieben wurden", in der Typoskript und dergleichen diskutiert würden

Wie auch immer, es scheint, als wären wir wirklich vom Thema abgekommen.

In der Tat. @joejordanbrown Sie können gerne ein neues Thema erstellen, um TypeScript zu diskutieren.

Übrigens ist es auch eine schlechte OSS-Praxis, frühere Gespräche zu ignorieren ... https://github.com/mrdoob/three.js/issues/341#issuecomment -47000692

Zurück zum Thema. Ich dachte, wir hätten dieses Problem bereits gelöst?

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

Wir brauchen nur jemanden, der es versucht.

Okay... also erstmal

Erstes Muster (das beste IMO):

function MyClass() {...}

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

    constructor: MyClass,

    prop1: 'something',

    method1: function someFunction() { .. },

    ...

});

Das zweite Muster:

function MyClass() {...}

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

MyClass.prototype.constructor = PointLight;

MyClass.prototype.prop1 = 'something';

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

...

@arctwelve Dieses Muster wurde aus vielen Gründen eingeführt. Das ist kein Masturbieren!

Zunächst einmal ermöglicht es ein klares Lesen über die Objektvererbung. Das Object.assign handelt hier eindeutig von der Objektvererbung. Dann können Sie das geerbte Objekt nicht in vielen und vielen Zeilen von MyClass.prototype verlieren.
Zweitens ist dies bei Mehrfachvererbung auch viel klarer.
Drittens ist der Konstruktor der Klasse lesbar und verliert sich nicht in vielen Zeilen wie der erste Punkt.
Viertens ermöglicht dies das Gruppieren von Eigenschaften und Methoden an derselben Stelle (in Klammern), was sehr viel klarer ist, wenn Sie 3, 4, 5 ... usw. Klassen in derselben Datei haben.
Fünftens erlaubt dieses Muster, die korrekte Kopie auf einige "geerbte" Eigenschaften zu überprüfen.

Schließlich ( @looeee ) dient dies auch der Leistung. Die erste Version ist optimierter, wenn Dateiparsing auftritt, anstelle von mehrfachem und mehrfachem Aufruf des Prototyps.

Wie auch immer !

Heute sollten wir zur ES6-Syntax übergehen!

@mrdoob

Hört sich gut an! Ich konzentriere mich derzeit auf WebVR, also muss es jemand anderes als ich sein.
Wir brauchen nur jemanden, der es versucht.

Würden Sie einen es6-Zweig erstellen? Oder liegt es an uns selbst?

Die erste Version ist optimierter, wenn Dateiparsing auftritt, anstelle von mehrfachem und mehrfachem Aufruf des Prototyps.

Bist du dir da sicher? Ich würde erwarten, dass Object.Assign langsamer ist, wenn überhaupt. Aber in beiden Fällen bezweifle ich, dass der Leistungsaufwand ausreicht, um sich Sorgen zu machen.

Auf jeden Fall: https://jsperf.com/inline-prototype-vs-assign-prototype/1

Unter Chrome-Version 61.0.3163.100 (Build officiel) (64 Bit) sind zugewiesene Prototypen rund 60 % schneller

Interessant. Danke, dass du den Test gemacht hast.

Dieses Ergebnis gilt jedoch nicht für alle Browser. Auf Firefox sind sie fast gleich ( Object.Assign ~3 % schneller), während auf Edge Object.Assign ~33 % langsamer ist.

Aber auf jeden Fall denke ich immer noch nicht, dass dies als Argument dafür relevant ist, welcher Stil besser ist - selbst der langsamste insgesamt (Inline-Proto in Chrome) läuft immer noch mit> 180.000 Operationen pro Sekunde, und es gibt vielleicht ein paar Tausend davon diese Setups im Code durchgeführt. Wir sprechen hier also wahrscheinlich von einem Unterschied von wenigen Millisekunden.

Für mich ist der Object.Assign -Stil sauberer und einfacher zu lesen, und das ist das Hauptargument dafür.

Ja, es geht um wenige Millisekunden pro Datei und nur, wenn die Datei zum ersten Mal von der Javascript-Engine analysiert wird ... aber für eine große Bibliothek wie threejs könnte der Gewinn beim Laden der Seite vernünftigerweise etwa 200 Millisekunden betragen.
Vergessen Sie nicht das Limit von 3scd für Frontbenutzer, die nicht länger warten können!

Ich versuche, ein Angular-Projekt mit Threejs zu erstellen, und es sieht immer so aus, als würde ich jeden Teil von Threejs hacken.
Zunächst einmal ist es5-Syntax mit DREI Konstanten, die vorhanden sein müssen, wenn ich beispielsweise OrbitalControls benötige.
Wir haben dreijs-Typisierungen, aber es ist bequemer, sie im selben Paket zu haben. Die Typisierungen haben OrbitalControls, aber wir können nicht einfach wie import { OrbitalControls } from 'three; importieren.
Webpack hat Tree Shaking, also könnten wir im Falle von es6 alles, was wir brauchen, in ein Projekt aufnehmen und sie nicht in ein separates Projekt verschieben.
@mrdoob , warum ist Typescript so schlecht? Es wird sowieso jede Version mit Typisierungen zu ES kompiliert.
Es wird auch in vielen anderen Frameworks wie React verwendet.

@FriOne Ich bin mir nicht sicher, ob @mrdoob Typescript wirklich für schlecht hält, aber ich denke, er ist dagegen, Typescript in dieser Ausgabe/diesem Thread zu diskutieren, weil es nicht das Thema dieses Threads ist. Ich denke, ES6-Klassen funktionieren nicht gegen oder für Typescript. Wenn Sie die Codebasis auf ES6 transformieren, ist es noch einfacher, die Codebasis auf Typescript zu portieren, da die Syntax sehr ähnlich ist. Ja, ich denke, Typescript könnte viele neue Optionen ermöglichen. Zum Beispiel könnte es helfen, einen optimierteren Code zu "transpilieren", es hilft neuen Entwicklern, die Bibliothek schneller zu lernen, vielleicht öffnet es Türen für zukünftige Experimente, zB: https://github.com/AssemblyScript/assemblyscript. Ich denke, es gibt viele Vorteile mit Typescript @joejordanbrown hat die Vorteile ausführlich beschrieben.

Aber zurück zum Thema: Ich denke, die Einführung von ES6-Klassen wäre ein Schritt nach vorne, und danach könnten wir die Typoskript-Sache besprechen. Machen wir also einen Schritt nach dem anderen

@tschoartschi , denke Typoskript kann bei der Migration zu es6-Klassen und anderen Umgestaltungen helfen. Ich habe keine solche Migrationserfahrung, es könnte sein, dass ich falsch liege.

@FriOne kommt darauf an 😉 Natürlich könnte Typescript helfen, da der Compiler Ihnen alle Ihre Fehler und Irrtümer mitteilen könnte, aber Sie müssten zuerst die gesamte Build-Pipe einrichten, um mit Typescript zu arbeiten. Darüber hinaus müssen Sie beurteilen, ob Typescript für Sie geeignet ist oder nicht. Ich denke, es ist in Ordnung, zuerst in ES6-Klassen zu konvertieren und dann über Typescript nachzudenken.

Hey, wir sind eine Gruppe von 5 Studenten der KTH, die einen Beitrag zu einem Open-Source-Projekt für einen Kurs leisten möchten, und möchten versuchen, einen Teil des Projekts in die neue ES6-Syntax zu konvertieren.

Ich habe Three.js vor einiger Zeit (r82) zusammen mit einigen Beispielen als Proof-of-Concept auf TypeScript portiert.

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

Das Laden der Beispiele dauert ein wenig, da die TypeScript-Quellen im laufenden Betrieb transpiliert werden. Sie laden so schnell wie die Originale, wenn sie das transpilierte JavaScript verwenden.

Ich würde gerne sehen, dass three.js auf Typoskript portiert wird. Ich denke, das Projekt muss dringend modernisiert werden, wenn es sich für die nächsten Web-Generationen bewähren will. Eines Tages sehen wir vielleicht sogar, dass es mit AssemblyScript funktioniert und in WASM läuft. Wenn nicht dreijs, dann wird es sicherlich etwas anderes tun.

Dies wird von @WestLangley und @mrdoob abgeschlossen

@bhouston was ist hier die Schlussfolgerung?

@pkieltyka ja ich denke auch, dass TypeScript für eine Bibliothek wie Three.js sehr sinnvoll wäre. Neben all den technischen Vorteilen würde es auch die Verwendung der Bibliothek erleichtern und Neulingen helfen, die API zu erkunden. Aber ich denke auch, dass es wichtig ist, zuerst alle ES6-Sachen fertig zu stellen und dann TypeScript in Betracht zu ziehen. Ich denke, seit dem neuesten JavaScript ist es nicht zu kompliziert, Typen in Form von TypeScript hinzuzufügen.

@flyover schön, auch einen Proof-of-Concept für eine TypeScript-Version von Three.js zu sehen. Haben Sie Feedback von den Betreuern von Three.js erhalten?

Ich unterstütze auch Typoskript für three.js. Typenskript ist im Grunde am besten
Üben und rohes JavaScript gibt es nicht mehr.

Am Sa, 05.01.2019, 04:13 Uhr tschoartschi < [email protected] schrieb:

@pkieltyka https://github.com/pkieltyka ja ich denke auch TypeScript
würde für eine Bibliothek wie Three.js sehr viel Sinn machen. Neben all dem
Technischen Profis würde es auch die Nutzung der Bibliothek erleichtern und Neulingen helfen
um die API zu erkunden. Aber ich denke auch, dass es wichtig ist, alle ES6 fertig zu stellen
Erst Zeug und dann TypeScript in Betracht ziehen. Ich denke von neuem
JavaScript ist nicht zu kompliziert, um Typen in Form von TypeScript hinzuzufügen.

@flyover https://github.com/flyover schön auch einen Proof-of-Concept zu sehen
eine TypeScript-Version von Three.js. Haben Sie Feedback von den Betreuern erhalten?
von Three.js?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451639995 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAj6_bkdND7I0_F4AJcBV0DYLpToUIVhks5vAGykgaJpZM4N9vH8
.

@bhouston Ich stimme zu, dass TypeScript eine großartige Technologie ist, aber ich würde es nicht so ausdrücken, wie Sie es getan haben. Ich denke, wir sollten immer so nah wie möglich an rohem JavaScript bleiben und die TypeScript-Funktionen oben drauf setzen. Da TypeScript der JavaScript-Spezifikation sehr genau folgt, liest sich TypeScript wirklich wie ES6 mit Typen.

Für eine Bibliothek wie three.js könnte TypeScript wirklich von Vorteil sein und könnte schrittweise übernommen werden. Wir bräuchten also keine „Urknall“-Umschreibung, insbesondere nicht, nachdem alle ES6-Refaktorisierungen abgeschlossen sind.

Wäre interessant zu hören, ob sich die Haltung von @mrdoob zu TypeScript geändert hat. TypeScript scheint der "Defacto"-Standard für "typisiertes JavaScript" zu werden (beachten Sie, dass ich meine Behauptungen unter Apostroph gesetzt habe, da dies keine harten Fakten sind)

Der erste Schritt sollte darin bestehen, ES6-Funktionen zu übernehmen, insbesondere Klassen, Pfeilfunktionen, „let“ und „const“.

Sobald wir das getan haben, können wir die Unterstützung von Typoskripten ausführlich besprechen, da es, wie @roomle-build betont, einfach ist, schrittweise Typoskriptfunktionen über ES6-Code hinzuzufügen, wenn wir uns dafür entscheiden.

Beides gleichzeitig zu tun, scheint mir, als würde es die Dinge zu kompliziert machen.

Schön zu hören, dass TypeScript irgendwann in der Zukunft eine Option sein könnte :-) Vielleicht könnten wir einen Teil der Arbeit von @flyover wiederverwenden

Aber ich stimme @looeee völlig zu, zuerst alle ES6-Sachen fertig zu stellen und mich dann auf die nächsten Schritte zu konzentrieren

Beenden Sie alle ES6-Sachen

Ich würde mich freuen, wenn wir wenigstens damit anfangen könnten 😅

Ein guter halber Schritt zu TypeScript wäre, neben jeder JavaScript-Datei Typdateien hinzuzufügen. Somit gäbe es beides:

Vector3.js
Vektor3.d.ts

Dadurch erhalten wir alle Vorteile von TypeScript als Sidecar-Dateien.

Im Moment gibt es eine @types/three-Datei, aber sie ist veraltet und wird separat gepflegt – daher wird sie immer keine Daten mehr haben.

Der Hauptkonkurrent von Three.JS ist Babylong und es ist vollständig maschinengeschrieben, und ich glaube, es profitiert davon.

Aber das Töten von @types/three und das Integrieren als Beiwagentyp-Definitionsdateien in Three selbst wäre ein großartiger erster Schritt.

Wir müssen auch alle Beispiele mit einer Art Tree Shaking in /src integrieren.

Im Moment ist die Codestruktur für Three.JS so 2014 und es ist nur mühsam, damit zu arbeiten.

Alle Beispiele?

Beispiele/js

Am Montag, 7. Januar 2019, 10:25 Uhr schrieb Dusan Bosnjak < [email protected] :

Alle Beispiele?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451970482 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAj6_Q3Kakb5Qn2DqGbMVvLkW_28cOyaks5vA2b5gaJpZM4N9vH8
.

@bhouston

Ein guter halber Schritt zu TypeScript wäre, neben jeder JavaScript-Datei Typdateien hinzuzufügen. Somit gäbe es beides:

Vector3.js
Vektor3.d.ts

Würden .d.ts-Dateien in c als .h-Dateien fungieren?

Würden .d.ts-Dateien in c als .h-Dateien fungieren?

Das ist eine sehr gute Analogie. Interessanterweise hat jemand das meiste davon bereits hier getan: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/three Also würde es wirklich nur den Besitz dieser Typdateien übernehmen und sie in Three.js integrieren. Wenn Sie möchten, können wir eine PR erstellen, die dies in Three.js integriert und richtig aufteilt.

Um zu zeigen, wie beliebt Typescript ist, sehen Sie sich an, wie viele @Types/three pro Woche heruntergeladen werden:

https://www.npmjs.com/package/@types/three – 63.000 Downloads pro Woche.

Beeindruckend!

Wenn Sie möchten, können wir eine PR erstellen, die dies in Three.js integriert und richtig aufteilt.

Klingt gut für mich 👍

Ist es möglich, ähnlich wie bei eslint eine Befehlszeilenprüfung durchzuführen, um sicherzustellen, dass die Typdateien und die Quelldateien .js übereinstimmen? Wenn wir das Eigentum an den d.ts -Dateien übernehmen, wäre es dringend vorzuziehen, eine Möglichkeit zu haben, regelmäßig zu überprüfen, ob sie übereinstimmen.

Um zu zeigen, wie beliebt Typescript ist, sehen Sie sich an, wie viele @Types/three pro Woche heruntergeladen werden:

https://www.npmjs.com/package/@types/three – 63.000 Downloads pro Woche.

Ich würde dies eher auf die Popularität von Visual Studio Code zurückführen, da dies automatisch geschieht, wenn Sie Visual Studio Code über die automatische Typerfassungsfunktion verwenden.
Das heißt, es kann nicht ignoriert werden.

@flyover @bunnybones1 @mrdoob @looeee @donmccurdy @bhouston @roomle-build @pkieltyka @FriOne @joejordanbrown Da Sie alle an TypeScript interessiert zu sein scheinen, wollte ich darauf hinweisen, dass ich eine neue Ausgabe zu TypeScript erstellt habe. Ich halte es für sinnvoll, alle TS-Diskussionen dorthin zu verlegen. Bei Interesse finden Sie es hier: https://github.com/mrdoob/three.js/issues/15545

Ich bin bereit, Zeit für die Portierung auf ES6-Klassen zu investieren. Ich denke, dies wird eine gute Brückenlösung sein, um eines Tages Typescript zu unterstützen.

Der erste Schritt besteht darin, einige der Add-Ons in ES6 zu konvertieren.

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

Controls, Loader und Exporters sind gute Kandidaten. Fühlen Sie sich frei zu helfen!

@mrdoob nur zur Bestätigung, Sie meinen, sie in ES-Module zu konvertieren, aber noch keine anderen ES6-Funktionen zu verwenden, oder?

Ich nehme an, der Prozess dieser Konvertierung ist:

1. Verwenden Sie das Skript modularize.js , um die Originaldatei in ein ES-Modul zu konvertieren.
2. Beseitigen Sie bei Bedarf Probleme.
3. Irgendwann (in dieser Version oder in naher Zukunft) werden wir anfangen, rollup-examples.config.js zu verwenden, um die ES-Module in UMD-Module umzuwandeln, ab diesem Zeitpunkt wird die Version in examples/js nicht mehr von verwaltet Hand.
4. Sobald das stabil ist, können wir andere Änderungen wie die Einführung von ES6-Funktionen in Betracht ziehen.

@mrdoob nur zur Bestätigung, Sie meinen, sie in ES-Module zu konvertieren, aber noch keine anderen ES6-Funktionen zu verwenden, oder?

Ja entschuldigung. Ich hätte angeben sollen.

Ich und @bhouston haben den versprochenen PR erstellt, der die *.d.ts-Dateien für den größten Teil des Three.JS-Projekts beisteuert. https://github.com/mrdoob/three.js/pull/15597

Ich kann ES6-Klassen und Typescript-Definitionen kaum erwarten. Jedes Mal, wenn ich mit three.js arbeite, muss ich Hunderte von Codezeilen kopieren und einfügen, um eine Funktion neu zu implementieren, die in einem nicht zugänglichen Bereich liegt. Es ist wirklich keine elegante Arbeitsweise, wenn Sie Ihre Szenen optimieren müssen. Es würde den Workflow auf eine neue Ebene heben, um endlich Funktionen erweitern und überschreiben zu können.
Also Klassenfunktionen bitte mindestens „geschützt“ und ausnahmslos zugänglich machen 🤗

Jedes Mal, wenn ich mit three.js arbeite, muss ich Hunderte von Codezeilen kopieren und einfügen, um eine Funktion neu zu implementieren, die in einem nicht zugänglichen Bereich liegt. ... Machen Sie Klassenfunktionen also mindestens „geschützt“ und ausnahmslos zugänglich.

@dionysiusmarquis Ich bin mir nicht sicher, ob ich verstehe, was Sie hier meinen ... die vorhandenen TS-Eingaben haben Funktionen, die Sie verwenden möchten, die fälschlicherweise als privat gekennzeichnet sind? Oder irgendetwas an den aktuellen Klassendefinitionen im Prototypenstil macht den Gebrauch in TS schwierig? Können Sie ein Beispiel nennen?

Jedes Mal, wenn ich mit three.js arbeite, muss ich Hunderte von Codezeilen kopieren und einfügen, um eine Funktion neu zu implementieren, die in einem nicht zugänglichen Bereich liegt. ... Machen Sie Klassenfunktionen also mindestens „geschützt“ und ausnahmslos zugänglich.

@dionysiusmarquis Ich bin mir nicht sicher, ob ich verstehe, was Sie hier meinen ... die vorhandenen TS-Eingaben haben Funktionen, die Sie verwenden möchten, die fälschlicherweise als privat gekennzeichnet sind? Oder irgendetwas an den aktuellen Klassendefinitionen im Prototypenstil macht den Gebrauch in TS schwierig? Können Sie ein Beispiel nennen?

Ich wollte nur eine bestimmte Schattenkarte für ein bestimmtes Szenario implementieren. Es wäre hilfreich gewesen, zum Beispiel getDepthMaterial überschreiben zu können. Im Moment füge ich meine eigenen WebGLShadowMap in den Build-Prozess mit einer Copy/Paste-Version ein, die meine gewünschten Änderungen enthält.
Es wäre so schön, wenn jede einzelne three.js -Klasse so viel wie möglich preisgeben würde. Mit Typoskript können Sie Funktionen einfach als private oder protected , um den beabsichtigten Zweck zu beschreiben. Meine ES6 Class/Typescript ShadowMap sieht zum Beispiel so aus:

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 }

Es fühlt sich einfach wie zu Hause an, wenn man "Low-Level"-Klassen modifizieren darf

Ich habe eine Frage im Zusammenhang mit dem Unterricht. Wie würden wir Methoden wie Vector3.unproject in die Klassensyntax übertragen? Die Methode verwendet tatsächlich eine Schließung, um einen neuen Geltungsbereich zu erstellen. Dies ist ein wichtiger Mechanismus, der die Anzahl der Objekterstellungen so gering wie möglich hält.

Brauchen wir in diesen Fällen Object.assign ?
@Mugen87

Sie können jetzt Closures mit Klassen machen. Es ist einfach nicht offensichtlich, wie man in diesem syntaktischen Zucker navigiert. Siehe meine Antwort auf StackOverflow: https://stackoverflow.com/questions/39297258/iife-in-es6-class-literal/56077521#56077521 (Ich muss bescheiden sein und zugeben, dass ich nicht ganz verstehe, wie/warum es funktioniert .)

Entschuldigung, aber dieser Code sieht aus wie ein Anti-Pattern und wir sollten dies nicht im Projekt anpassen. Es gibt geeignete Lösungen für die Verwaltung von Variablen im Modulbereich. Ich schlage vor, diesen Weg zu gehen.

@ Mugen87 Ja, ich denke auch, dass wir den Modulumfang gut nutzen sollten. Dies würde auch für Dinge wie Tree-Shaking helfen. Dies wurde bereits in vielen anderen Ausgaben wie dieser diskutiert: https://github.com/mrdoob/three.js/issues/6241#issuecomment -398703521

Entschuldigung, aber dieser Code sieht aus wie ein Anti-Pattern und wir sollten dies nicht im Projekt anpassen. Es gibt geeignete Lösungen für die Verwaltung von Variablen im Modulbereich. Ich schlage vor, diesen Weg zu gehen.

Kein Problem. Ich habe nur die Möglichkeit erwähnt. Wenn Sie eine bessere/sauberere Lösung in Arbeit haben, bin ich gespannt, sie in Aktion zu sehen. Das Three.js-Projekt (Nutzung, Quelle, Diskussionen usw.) war meine Hauptquelle für JS-Wissen, daher wird die Einführung neuer und besserer Programmiermuster in Three.js wahrscheinlich auch mir und meinen Projekten zugute kommen. Nichts zu bereuen. ;-)

@Mugen87 Können Sie ein wenig erläutern, warum Sie Klasse-IIFEs als Anti-Muster betrachten, und sei es nur, damit ich ein bisschen mehr lernen und verstehen kann? Ich verstehe, dass Module von Natur aus Variablen umfassen, aber das ist nicht anders als zuvor. Und bei so vielen Funktionen, die Cache-Variablen verwenden, ist es wirklich wichtig sicherzustellen, dass keine der Funktionen kollidiert oder gleichzeitig Variablen verwendet – der Funktionsbereich erleichtert die Verwaltung und Wartung, weshalb ich das nicht sehe es als Anti-Pattern (zumindest im Vergleich zum Werfen aller Cache-Variablen im Modulbereich).

Können Sie ein wenig erläutern, warum Sie Klasse-IIFEs als Anti-Muster betrachten?

Ich würde keinen Ansatz verwenden, der das Tree-Shaking potenziell behindert, wie hier erwähnt: https://github.com/mrdoob/three.js/pull/14695. Außerdem denke ich, dass das gesamte Muster wie ein Hack aussieht. Die Verwendung weniger "ausgefallener" Ansätze funktioniert normalerweise besser. Das Vermeiden unnötiger Schließungen sollte auch die Codeausführungsleistung im Allgemeinen verbessern (kann dies nicht mit einer Referenz beweisen, aber ich habe es vor einiger Zeit in einem Vortrag gehört).

Und bei so vielen Funktionen, die Cache-Variablen verwenden, ist es wirklich wichtig sicherzustellen, dass keine der Funktionen kollidiert oder gleichzeitig Variablen verwendet.

Die IIFEs werden hauptsächlich im Mathematikunterricht eingesetzt. Da wir dort eine gute Testabdeckung haben ( @gero3 hat in letzter Zeit großartige Arbeit geleistet, indem es weitere Unit-Tests hinzugefügt hat), sollte es einfacher sein, das Entfernen dieser robust zu gestalten.

Es ist in Ordnung, IIFEs zu entfernen. Ich glaube, ich bin damals im Jahr 2013 dafür verantwortlich. Es ging darum, ein statisches Variablenmuster loszuwerden, das schwer zu pflegen war. Es wurde in dieser PR gemacht:

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

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

Und hier noch früher diskutiert:

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

Interessante Tatsache, als wir diese eingefügt haben, gab es keinen Unterschied in der Codeleistung.

Ich nehme an, der Prozess dieser Konvertierung ist:

1. Verwenden Sie das Skript modularize.js , um die Originaldatei in ein ES-Modul zu konvertieren.
2. Beseitigen Sie bei Bedarf Probleme.
3. Irgendwann (in dieser Version oder in naher Zukunft) werden wir anfangen, rollup-examples.config.js zu verwenden, um die ES-Module in UMD-Module umzuwandeln, ab diesem Zeitpunkt wird die Version in examples/js nicht mehr von verwaltet Hand.
4. Sobald das stabil ist, können wir andere Änderungen wie die Einführung von ES6-Funktionen in Betracht ziehen.

Hallo. Ich habe es vielleicht übersehen, aber was war das für unsere schrittweisen Schritte in Richtung Klassen?

1. [x] Verwenden Sie das Skript modularize.js, um die Originaldatei in ein ES-Modul zu konvertieren.
2. [x] Probleme bei Bedarf bereinigen.
3. [ ] Irgendwann (in dieser Version oder in naher Zukunft) werden wir damit beginnen, rollup-examples.config.js zu verwenden, um die ES-Module in UMD-Module zu konvertieren, ab diesem Zeitpunkt wird die Version in example/js nicht mehr von verwaltet Hand.
4. [ ] Sobald das stabil ist, können wir andere Änderungen wie die Einführung von ES6-Funktionen in Betracht ziehen.

In den obigen Schritten haben wir die Schritte (1) und (2) im Wesentlichen abgeschlossen.

Schritt (3) Wir machen das nicht mehr so, sondern werden stattdessen den Ordner examples/js irgendwann verwerfen und entfernen (siehe https://github.com/mrdoob/three.js/pull/18749) .

Ich denke , das bedeutet, dass Schritt (4), die Einführung von ES6-Klassen in examples/jsm , (vorerst) nur an den sehr wenigen Beispielen durchgeführt werden kann, die nicht aus examples/js -Quellversionen generiert wurden. Sobald examples/js entfernt ist, können wir den Rest erledigen.

^ Aber ich könnte hier zu viel zwischen den Zeilen lesen, vielleicht können @Mugen87 oder @mrdoob das bestätigen?

Meiner Meinung nach sollte sich das Projekt auf das Veralten und Entfernen von examples/js konzentrieren, um eine reine Modul-Codebasis zu erreichen. Im nächsten Schritt würde ich empfehlen, mit der Klassenmigration fortzufahren. Beginnen Sie mit den Beispielen und migrieren Sie dann den Kern.

perfekt. Danke schön. werde mir diese Wege mal genauer anschauen

Reposted von geschlossenem Thema.
Hi,

Ich wollte diese Ausgabe erstellen, um zu versuchen, alle Gedanken darüber herauszukitzeln, wie wir mit der Klassenmigration vorankommen möchten.

Meine kurze Zusammenfassung dessen, was ich bisher gefunden habe:

• Wir sollten den Beispielordner verwerfen, bevor wir irgendetwas anderes tun
• Es gibt Teile von src/, die durch keines der Beispiele erweitert wurden, die konvertiert werden könnten
• Mit einigen Änderungen am Skript modularize.js konnten wir mit example/js/ beginnen, das die entsprechenden Skripte example/jsm generiert.

Habe ich etwas verpasst?

Wir sollten den Beispielordner verwerfen, bevor wir irgendetwas anderes tun

Ich bin mir nicht sicher, wer für einen bestimmten nächsten Schritt im Ordner examples/js verantwortlich ist. Sofern wir diesen Plan nicht artikulieren können, wäre es mir lieber, wenn dies die Umwandlung von Dingen in ES-Klassen nicht blockiert. Aus diesem Grund stimme ich https://github.com/mrdoob/three.js/issues/11552#issuecomment -592768708 etwas nicht zu. 🙂

Außerdem scheinen wir nur darauf zu warten, dass ein Datum festgelegt wird

Außerdem habe ich im Rahmen einer kleinen Überarbeitung diesen Kommentar darüber gefunden, wie andere ES2015-Funktionen über den aktuellen Rollup-Build-Prozess eingeführt werden könnten. Es gibt sogar ein Beispiel .

Bearbeiten: Hier ist ein kurzer Überblick über ein weiteres Beispiel

Lassen Sie uns den Umbauzug starten .
Kommentar zu Dateiabhängigkeiten .

@DefinitelyMaybe Ich habe etwas Zeit und würde gerne helfen. Kann ich einige Gegenstände von der dependencies.json -Liste mitnehmen?

👍

Lassen Sie uns Dibs auf Dinge nennen

@DefinitelyMaybe Was ist der beste Weg, um mit der Vererbung von einem tiefen Vorfahren wie Object3D umzugehen? Zum Beispiel bin ich beim Konvertieren src/audio/AudioListener.js auf einen Bruch gestoßen:

[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

Wir wollten oben in der Datei eine Notiz über alle Probleme machen, auf die wir stoßen, wenn ich mich richtig erinnere.

Ich habe falsch verstanden, was mit AudioListener passiert ist ... Nach einigem Debuggen glaube ich, dass es ein Übereinstimmungsproblem in der bubleCleanup -Transformation gibt. Weitere Informationen finden Sie unter https://github.com/mrdoob/three.js/pull/19934#issuecomment -667411997. Ich bin bei ein paar verschiedenen Klassen darauf gestoßen, also müssen wir es wahrscheinlich sortieren, bevor wir weiter gehen.

Dies wird bei einigen Dateien der Fall sein, aber nicht bei allen. Wir haben mit einem solchen Problem gerechnet.

Für diejenigen, die mitmachen, lesen Sie bitte kurz die Diskussion hier drüben .

In der Zwischenzeit dibs auf src/loaders !