Pixi.js: HILFE GESUCHT: ES6 Konvertierungsaufwand

Welche Route möchten Sie mit let und const gehen? Standardmäßig const, und let nur für Eigenschaften verwenden, deren Referenz geändert werden soll
Oder
Lassen Sie standardmäßig zu und verwenden Sie const nur als Hinweis für den Entwickler, dass sie dies, ich meine es ernst, nicht ändern.

Die frühere Option. Standardmäßig wird const verwendet. Ich habe alle internen vars in let konvertiert und offensichtliche Scoping-Probleme behoben und die Verwendung von var mit jshint untersagt. Benötigt einen weiteren Durchgang mit const.

Dinge, die ich empfehlen würde:

• [x] Verwenden Sie babel-preset-es2015-loose , ich hatte eine schlechte Leistung mit nur babel-preset-es2015 allein.
• [x] Wechseln Sie zu eslint , es hat eine bessere ES6-Unterstützung und ist im Allgemeinen einfach besser als jshint. Hier ist ein guter Ausgangspunkt für Pixis Stil. Es wird sich auch über Orte beschweren, an denen Sie const verwenden könnten, aber let verwendet haben. Macht es einfach, alle Stellen zu finden, die Sie für const reparieren müssen.
• [x] Verwenden Sie den neuesten Master von jsdoc, es enthält viele ES6-Korrekturen, die noch nicht veröffentlicht wurden.
• Wechseln Sie zum Webpaket.

Danke @englercj. Gute Liste.

@englercj Das babel-preset-es2015-loose hat eine Verfallswarnung, hast du babel-preset-es2015 mit der Option {"loose": true} ausprobiert, wie es vorschlägt?

Ich bevorzuge auch Webpack gegenüber Browserify, ein paar nützliche Links:
https://github.com/webpack/webpack/tree/master/examples/multi-part-library
http://krasimirtsonev.com/blog/article/javascript-library-starter-using-webpack-es6

Meine Vorlieben sind, auf Webpack zu warten und das nicht zu stapeln. Möglicherweise für eine weitere kleinere PR. Diese Änderung stellt eine Änderung des Build-Prozesses dar, aber nicht unbedingt eine Verbesserung von ES6. Außerdem müsste sichergestellt werden, dass Sourcemaps, Header usw. funktionieren. Ich verstehe, wie es besser ist, aber warten wir erst einmal darauf.

Das babel-preset-es2015-loose hat eine Deprecation-Warnung, hast du babel-preset-es2015 mit der Option {"loose": true} wie vorgeschlagen ausprobiert?

Ha, das wurde _nur_ vor 2 Wochen hinzugefügt. Ich habe das nicht ausprobiert, weil es zu dem Zeitpunkt, als ich anfing, es zu benutzen, noch nicht existierte.

Hallo allerseits,

Nur ein kurzer Schrei, um Chads Gedanken über den lockeren Modus wiederzugeben und meinen Senf hier hinzuzufügen.
Wie wir zuvor mit @GoodBoyDigital besprochen haben, müssen wir wirklich auf die Leistung achten, daher denke ich, dass der Loose-Modus ein guter Ausgangspunkt ist.

Außerdem bin ich mir nicht sicher, wie aktuell diese Tabelle ist: https://kpdecker.github.io/six-speed/ kennt ihr das?

Wenn es immer noch so ist, müssen wir aufpassen, dass wir nicht in den ES2015-Wahnsinn verfallen und Dinge konvertieren, die nicht sein müssen, dh: Wenn for-of immer noch die Leistung senkt, wie es auf dem Tisch steht, sollten wir nicht. Verwenden Sie es nicht, wenn Sie Kinder von Szenengraphen iterieren.

Babel sollte jetzt for-of für Arrays optimieren (siehe: Optimierung ), diese Tests scheinen ziemlich alt zu sein .

Wie auch immer, @alvinsight du hast recht, es muss nicht alles ES2015 sein.

Gute Liste @englercj !

Auch mit @alvinsight abgesprochen. Wir sehen bereits viel saubereren Code mit es6-Syntax, also gewinnen wir rundum :)

Jede andere Entscheidung sollte auf Leistung basieren – „Sieht es besser aus, läuft aber langsamer – mach es nicht“

Array-Looping ist ein gutes Beispiel - es besteht keine Notwendigkeit, Dinge zu ersetzen, die bereits schnell und lesbar sind, nur weil wir es können.

Auch ja zum Webpack! @bigtimebuddy ist richtig, das sollte Teil zwei dieser Umstellung auf es6 sein.

Einverstanden!
Es ist so viel schöner endlich class Sprite extends Container lesen und schreiben zu können!

Aktualisiert

• jshint durch eslint ersetzt (und Linting-Fehler behoben, eslint für den Sieg!)
• Verwendung loose: true mit babel-preset-es2015

Abend alle!

Schlagen Sie mit unseren Mixins einen kleinen Schnaps..

Object.assign(
    core.DisplayObject.prototype,
    require('./interactiveTarget')
);

Das Obige funktioniert derzeit nicht im ES6-Zweig, so dass Dinge wie Interaktion kaputt sind.

Gibt es eine gute Möglichkeit, dies mit es6-Klassen zu tun?

Antworten bitte per Postkarte!

Ok, ich hatte beim ersten Mal Recht - der obige Code funktioniert derzeit nicht ... (Kann ich das auf die Tatsache schieben, dass es Freitagabend ist?)

Ich denke, hier glänzt die Komposition!

Hm, was funktioniert nicht? Das hat bei mir funktioniert:

class MyThing {}
Object.assign(MyThing.prototype, { newFn: function () { console.log('mix'); } });
var mything = new MyThing();
mything.newFn(); // logs: "mix"

Kopieren Sie das und fügen Sie es in die Chrome-Konsole ein, und es scheint gut zu funktionieren.

Interessant! Derzeit funktioniert die Interaktion nicht und interaktive Eigenschaften scheinen zu fehlen. Vielleicht ein anderer Grund? Werde weiter graben...

Ah ha! Fand es

Object.assign(
    core.DisplayObject.prototype,
    require('./interactiveTarget') <--- this is a require!
);

import interactiveTarget from './interactiveTarget';

Object.assign(
    core.DisplayObject.prototype,
    interactiveTarget
);

Könnte sein?

Jep!

PR 1 hier: https://github.com/pixijs/pixi.js/pull/2960

Es behebt ein paar Bits wie die Mixins und den Text.

Filter schaue ich mir morgen an...

Sieht wirklich gut aus, Jungs!

Gute Arbeit! Yah, die Verwendung von require() würde ein Objekt mit einem einzigen Standardschlüssel zurückgeben, der alles andere enthält, was Sie erwartet haben.

Filter sehen jetzt gut aus! Ich habe dies bei einem aktuellen Projekt ausgeführt, an dem ich arbeite und das ziemlich komplex ist - und alles scheint zu 100% zu funktionieren!

Könnte es in ein paar anderen Spielen testen, aber es sollte bald gut sein, es zusammenzuführen!

@bigtimebuddy hast du diesen Build mit pixi-animate ausprobiert?

Werfen Sie das hier raus. Traceur scheint schneller als Babel zu sein?
Eine Untersuchung wert?

https://kpdecker.github.io/six-speed/

Diese Tests sind alt und laufen nicht mit babel loose. Außerdem könnte man auch argumentieren, dass Typoskript in vielen Fällen schneller ist als beides :)

Ich schlage Ihnen vor, TypeScript als Teil dieser großen Neufassung/Anpassung zu verwenden. Nur einige Punkte zu TypeScript:

• Die Verwendung des Typsystems in JavaScript wird zum neuen Standard, es ist nur eine Frage der Zeit.
• Es IST JavaScript. Kein Unterschied in der Syntax außer dem Typsystem.
• Verbessert die Codequalität. Möglicherweise finden Sie eine beträchtliche Menge an Code, der leicht umstrukturiert werden muss, um die Typen an den richtigen Stellen abzugleichen.
• Erhöhen Sie die Pull-Request-Qualitätsprüfung – wenn es ein Typproblem gibt, kann der Patch einfach nicht zusammengeführt werden.

Ich weiß, dass dies keine leichte Aufgabe ist, aber ich glaube, dass es große Vorteile für die Codebasis und die Community bringen kann.
Beifall!

@endel Ich stelle pixi-spine auf Typoskript um, es wird Demos von TS-Plugins für pixi geben.

@endel nur neugierig, aber hat TS das Problem gelöst, das es hatte, als ich es mir das letzte Mal angesehen habe: dass es eine Alles-oder-Nichts-Situation ist, wenn es um die Ausgabe geht, dh _alles_ wird zurück zu ES5 transpiliert, oder nichts, basierend auf dem Ziel ?

Ich erinnere mich, dass überhaupt keine Polyfills verwendet wurden. Wenn Sie also möchten, dass eine einzelne Codebasis auf einer Vielzahl von Browsern ausgeführt wird, von modernsten bis hin zu älteren, müssen Sie immer noch auf ES5 abzielen, und all die netten neuen Funktionen, die moderne Browser jetzt nativ unterstützen, werden ignoriert, weil wird es trotzdem auf ES5 heruntergestuft? Oder ist es immer noch der Fall, dass Sie eine ES6-Polyfüllung auf der TS-Ausgabe verwenden müssen, um alle Basen abzudecken?

dass es eine Alles-oder-Nichts-Situation ist, wenn es um die Ausgabe geht, dh alles wird zurück zu ES5 transpiliert, oder nichts, basierend auf dem Ziel?

Nicht sicher, was Sie damit meinen. Wenn Sie auf ES5 abzielen, wird die Syntax in ES5 transpiliert. Aber auch babel, tracuer, et al. Gibt es etwas Bestimmtes, auf das Sie sich beziehen?

Ich erinnere mich, dass überhaupt keine Polyfills verwendet wurden.

Er tut es nicht, aber auch nicht babel, tracuer oder andere Transpiler; also bin ich mir nicht sicher worauf du hinaus willst? Wir müssten Core-js-Polyfills so oder so verwenden (Babel oder TS).

Ich denke, die Diskussion ist babel, um ES6 -> ES5 oder TypeScript umzuwandeln, um TS -> ES5 zu transformieren. Wir müssen ES5 so oder so gehen. TS kann auf ES6 abzielen, und wir könnten einen ES6-Build liefern, wenn wir wollten, aber es wäre zusätzlich zum ES5-Build.

@photonstorm Mit TypeScript können Sie nach meinem besten Wissen keine Funktionen auswählen, die auf ES5 transpiliert werden sollen, wie Sie es mit Babel können.

Ich benutze TypeScript und finde es genial. Würde gerne sehen, wie Pixi irgendwann adoptiert. Google ermutigt jetzt Entwickler, TypeScript mit Angular zu verwenden, was ein gutes Zeichen für eine weit verbreitete Akzeptanz ist. Bei einer so komplexen Codebasis wie Pixi wäre mit Strict-Typings gut gedient.

Einige Probleme, die mit TypeScript behoben werden müssten, wären jsdocs (hat jemand Erfahrung damit?) und Upstream-Abhängigkeiten, die möglicherweise den src verwenden, wenn require('pixi.js') (braucht jemand so etwas?).

Als erster Schritt ist der Umstieg auf ES6 immer noch eine gute Option, da wir sowieso auf Klassen umstellen müssen. Wir könnten TypeScript als weiteren „Durchgang“ zur Modernisierung der Codebasis betrachten, sobald wir sicher sind, dass alle Bedenken angegangen werden können.

Mit TypeScript können Sie nach meinem besten Wissen keine Funktionen auswählen, die auf ES5 transpiliert werden sollen, wie Sie es mit Babel können.

Ich hatte keine Ahnung, dass man das mit babel machen kann. Ich bin mir nicht sicher, ob ich den Vorteil für uns sehe, da wir ohnehin auf ES5 abzielen müssen. Aber das ist ordentlich!

Zu einigen Problemen, die mit TypeScript behoben werden müssten, gehören jsdocs

https://github.com/TypeStrong/typedoc

Upstream-Abhängigkeiten, die möglicherweise den src verwenden, wenn require('pixi.js') (braucht jemand so etwas?).

Wir können "main" auf alles verweisen, was wir wollen, und mit Typoskript verweisen Sie auf die gebauten Dateien (nicht auf das _bundle_). Beispielsweise gehen TS-Dateien in src/ und Sie transpilieren jede Datei in js/ oder so und zeigen dann auf main dorthin. Dann bündeln wir auch alles und legen die Bündel in dist/ oder w/e. Das npm-Paket wird mit den js/tsd-Dateien geliefert, aber normalerweise nicht mit der TS-Quelle (umstritten).

Als erster Schritt ist der Umstieg auf ES6 immer noch eine gute Option, da wir sowieso auf Klassen umstellen müssen. Wir könnten TypeScript als weiteren „Durchgang“ zur Modernisierung der Codebasis betrachten, sobald wir sicher sind, dass alle Bedenken angegangen werden können.

👍

Mit TypeScript können Sie nach meinem besten Wissen keine Funktionen auswählen, die auf ES5 transpiliert werden sollen, wie Sie es mit Babel können.

Sie haben diese Funktion in TypeScript 2.0 hinzugefügt: https://github.com/Microsoft/TypeScript/wiki/What 's-new-in-TypeScript#inclusive-built-in-type-declarations-with---lib

Es ist üblich, ES5 als Ziel zu verwenden, aber ES6 als Bibliotheken einzuschließen, um die Typdefinitionen für Dinge wie Symbol , Map usw. zu haben.

Tatsächlich müssen Sie, wie @englercj sagte, Shims einfügen, nachdem Ihr Code kompiliert wurde, unabhängig davon, welchen Compiler Sie verwenden. Babel enthält zum Beispiel nicht automatisch ein Symbol Polyfill für IE9.

Ich hatte keine Ahnung, dass man das mit babel machen kann. Ich bin mir nicht sicher, ob ich den Vorteil für uns sehe, da wir ohnehin auf ES5 abzielen müssen. Aber das ist ordentlich!

Für Pixi nicht so nützlich, aber ja, Sie können Babel-Voreinstellungen auswählen, um nur bestimmte Funktionen zum Transpilieren auszuwählen. Dies kann nützlich sein, wenn Sie auf ES6 bauen möchten, aber nur die neuesten V8-Funktionen in Node 6, Electron 1 usw. unterstützen möchten.

Es ist wirklich ein interessantes Paradoxon. Verwenden Sie ES6 zum Erstellen, da es sauber und schön ist und von modernen Browsern sehr gut unterstützt / intern optimiert wird. Aber haben Sie all diese harte Arbeit zerstört, indem Sie transpilieren, als wäre es 1995 :) (und mit Änderungen der Sprachsyntax können Sie das nicht umgehen).

Ich weiß, dass das Problem universell ist und nichts mit TS oder Pixi zu tun hat. Nur eine etwas seltsame Situation, in der man sich befindet.

@photonstorm Es ist eine unglückliche Ironie 😞 hoffentlich können wir ES6- und ES5-Builds haben, damit sie für gepackte Apps (wie Elektron) den ES6-Build verwenden können.

Ich steige einfach in die Diskussion hier ein :) Ich habe Leute gesehen, die TS auf ES6 transpiliert haben und dann Babel benutzt haben, um es auf ES5 zu transpilieren. Ich denke, wenn Sie so etwas wie bestimmte Funktionen transpilieren möchten, wäre das ganz nett?

Außerdem gibt es (noch einen anderen ...) Modul-Bundler, aber ich denke, dieser scheint ziemlich raffinierten Code zu produzieren, mit der Möglichkeit mehrerer Ausgaben.
http://rollupjs.org/ Es bündelt die ES6/ES2015-Modulsyntax, was meiner Meinung nach ziemlich nett ist, wenn Sie den Code zukunftssicher machen möchten.

Ich bin +1 dafür, dass PIXI in Typoskript geschrieben wird. Aus meiner Erfahrung hilft Typ wirklich sehr bei der Strukturierung solcher Projekte. Wenn es nur performant bleiben kann :)

RollUp ist fantastisch, ich benutze es sehr gerne. Sein Baumschütteln ist ernsthaft schlau. Zusammen mit bubel (anstelle von babel) sorgt es für einen wirklich _wirklich_ schnellen Arbeitsablauf.

Interessant, hier so viel TS-Liebe zu sehen. Vor einem Jahr war das sicherlich nicht der Fall :) Es gibt Möglichkeiten, ES2015 zu tippen, was eine Überlegung wert sein könnte.

@photonstorm hat bubel nicht gefunden, aber es gibt "buble"

Ja ja, Tippfehler. http://buble.surge.sh/

BubleTape ist ein nettes Testgeschirr dafür https://github.com/snuggs/buble-tape

Ist #2936 der Grund, warum Mitglieder die Dokumente abgegeben haben? Dies hat ein exponiertes Mitglied, wobei dieses 25+ hat.

Muss ihnen jetzt @memberof hinzugefügt werden, oder gibt es etwas Magie, das angewendet werden kann?

@staff0rd Ich denke, wir sind immer noch dabei, die Dinge zu bereinigen, sobald es sich ein wenig stabilisiert hat, werden wir uns mit der Bereinigung der Dokumente befassen. Höchstwahrscheinlich liegt es nur daran, dass die von uns verwendete jsdoc-Version ES6-Fehler aufweist. Wir sollten in der Lage sein, dies bald zu bereinigen.

ES6 wurde mit dev zusammengeführt, vielen Dank an alle, die mitgeholfen haben. Es wird sehr geschätzt!

Schließe dies vorerst.

Dieser Thread wurde automatisch gesperrt, da es nach seiner Schließung keine Aktivitäten mehr gegeben hat. Bitte öffnen Sie ein neues Problem für verwandte Fehler.