Pixi.js: AIDE DEMANDÉE : effort de conversion ES6

Quelle route voulez-vous descendre avec let et const ? Const par défaut, et n'utilisez let que pour les propriétés dont la référence doit être modifiée
Ou
Par défaut, let, et n'utilisez const que comme un indice pour le développeur qu'ils, je suis sérieux, ne changent pas cela.

L'ancienne option. Const est utilisé par défaut. J'ai converti toutes les variables internes en let et corrigé des problèmes de portée évidents et interdit l'utilisation de var avec jshint. A besoin d'un autre passage avec const.

Choses que je recommanderais:

• [x] Utilisez babel-preset-es2015-loose , j'ai eu de mauvaises performances avec juste babel-preset-es2015 seul.
• [x] Passez à eslint , il a un meilleur support ES6 et est juste meilleur que jshint en général. Voici un bon point de départ pour le style de pixi. Il se plaindra également des endroits où vous pourriez utiliser const mais avez utilisé let . Facilite la recherche de tous les endroits que vous devez réparer pour const.
• [x] Utilisez le dernier maître de jsdoc, il contient de nombreux correctifs ES6 qui n'ont pas encore été publiés.
• Passez au webpack.

Merci @englercj. Bonne liste.

@englercj Le babel-preset-es2015-loose a un avertissement de dépréciation, avez-vous essayé babel-preset-es2015 avec l'option {"loose": true} comme il le suggère ?

Je préfère aussi webpack à browserify, quelques liens utiles :
https://github.com/webpack/webpack/tree/master/examples/multi-part-library
http://krasimirtsonev.com/blog/article/javascript-library-starter-using-webpack-es6

Ma préférence est d'attendre sur webpack et de ne pas l'empiler. Potentiellement pour un autre PR plus petit. Ce changement représente un changement de processus de construction mais pas nécessairement une amélioration de ES6. En outre, il faudrait s'assurer que les cartes source, les en-têtes, etc. fonctionnent. Je comprends que c'est mieux mais attendons ça pour l'instant.

Le babel-preset-es2015-loose a un avertissement de dépréciation, avez-vous essayé babel-preset-es2015 avec l'option {"loose": true} comme il le suggère ?

Ha, ça a été _just_ ajouté il y a 2 semaines. Je n'ai pas essayé car cela n'existait pas au moment où j'ai commencé à l'utiliser.

Salut à tous,

Juste un cri rapide pour faire écho à la pensée de Chad sur le mode lâche, et ajouter mes deux cents ici.
Comme nous en avons discuté avec @GoodBoyDigital avant de devoir faire très attention aux performances, je pense donc que le mode lâche est un bon point de départ.

De plus, je ne sais pas à quel point ce tableau est à jour : https://kpdecker.github.io/six-speed/ le savez-vous ?

Si c'est toujours le cas, nous devons faire attention de ne pas devenir fou ES2015 et de convertir des choses qui n'ont pas besoin de l'être, c'est-à-dire : si for-of réduit toujours les performances comme il est indiqué sur la table, nous devrions ' Ne l'utilisez pas lors de l'itération d'enfants de graphes scéniques.

Babel devrait maintenant optimiser for-of pour les tableaux (voir : Optimisation ), ces tests semblent assez anciens .

Quoi qu'il en soit, @alvinsight tu as raison, tout n'a pas besoin d'être ES2015.

Bonne liste @englercj !

Également d'accord avec @alvinsight. Nous voyons déjà un code beaucoup plus propre avec la syntaxe es6, donc gagnant à tous points de vue :)

Toute autre décision doit être basée sur la performance - "Est-ce que ça a l'air mieux mais tourne plus lentement - ne le fais pas"

La boucle de tableau est un bon exemple - il n'est pas nécessaire de remplacer des éléments qui sont déjà rapides et lisibles simplement parce que nous le pouvons.

Oui aussi au webpack ! @bigtimebuddy a raison, cela devrait être la deuxième partie de ce passage à es6.

D'accord!
C'est tellement plus agréable de pouvoir enfin lire et écrire class Sprite extends Container !

Mis à jour

• Remplacement de jshint par eslint (et correction des erreurs de peluchage, eslint pour la victoire !)
• Utiliser loose: true avec babel-preset-es2015

Soirée à tous !

Frappez un peu shnag avec nos mixins ..

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

Ce qui précède ne fonctionne pas actuellement dans la branche ES6, donc des choses comme l'interaction sont interrompues.

Existe-t-il une bonne façon de faire cela avec les classes es6?

Réponses sur une carte postale s'il vous plait !

Ok j'avais raison la première fois - le code ci-dessus ne fonctionne pas actuellement .. (Puis-je blâmer cela sur le fait que c'est vendredi soir?)

Je suppose que c'est là que la composition brille!

Hum, qu'est-ce qui ne marche pas ? Cela a fonctionné pour moi:

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

Copiez-collez cela dans la console chromée et semble fonctionner correctement.

Intéressant! Actuellement, l'interaction ne fonctionne pas et les propriétés interactives semblent manquer. Peut-être une autre raison ? Je vais continuer à creuser...

Ah ha ! Trouvé

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

import interactiveTarget from './interactiveTarget';

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

Peut-être?

Ouais!

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

Il corrige quelques bits comme les mixins et le texte.

Demain je regarderai les filtres...

Ça a l'air vraiment bien les gars!

Bon travail! Yah, utiliser require() comme ça renverrait un objet avec une seule clé par défaut contenant tout ce que vous attendiez.

Les filtres ont l'air bien maintenant ! J'ai couru ceci sur un projet en cours sur lequel je travaille qui est assez complexe - et tout semble fonctionner à 100 % !

Peut-être le tester sur quelques autres jeux mais devrait être bon de fusionner très bientôt !

@bigtimebuddy avez-vous essayé cette version avec pixi-animate ?

Lancer ça là-bas.. traceur semble plus rapide que babel?
Ça vaut le coup d'enquêter ?

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

Ces tests sont anciens et ne fonctionnent pas avec Babel en vrac. En outre, vous pourriez également affirmer que dans de nombreux cas, le tapuscrit est plus rapide que les deux :)

Je vous suggérerai d'envisager d'utiliser TypeScript dans le cadre de cette réécriture/adaptation majeure. Juste quelques points sur TypeScript :

• L'utilisation du système de type en JavaScript deviendra la nouvelle norme, ce n'est qu'une question de temps.
• C'EST JavaScript. Aucune différence de syntaxe à part le système de type.
• Améliore la qualité du code. Vous trouverez peut-être une quantité considérable de code qui doit être légèrement restructuré pour faire correspondre les types aux bons endroits.
• Augmentez la vérification de la qualité de la demande d'extraction - s'il y a un problème de type, le correctif ne peut tout simplement pas être fusionné.

Je sais que ce n'est pas une tâche facile, mais je pense que cela peut apporter des avantages majeurs à la base de code et à la communauté.
Acclamations!

@endel Je déplace pixi-spine vers tapuscrit, il y aura des démos de plugins TS pour pixi.

@endel juste curieux, mais TS a-t-il résolu le problème qu'il avait la dernière fois que je l'ai regardé: c'est une situation tout ou rien en ce qui concerne la sortie, c'est-à-dire que _tout_ est transpilé vers ES5, ou rien ne l'est, basé sur la cible ?

Je me souviens qu'il n'utilisait pas du tout de polyfills. Donc, si vous voulez qu'une seule base de code s'exécute sur un large éventail de navigateurs, de la pointe à l'héritage, vous devez toujours cibler ES5, et toutes les nouvelles fonctionnalités intéressantes, que les navigateurs modernes prennent désormais en charge de manière native, sont ignorées parce que il rétrograde à ES5 de toute façon? Ou est-ce toujours le cas où vous devez utiliser un polyfill ES6 au-dessus de la sortie TS pour couvrir toutes les bases ?

qu'il s'agit d'une situation tout ou rien en ce qui concerne la sortie, c'est-à-dire que tout est transpilé vers ES5, ou rien ne l'est, en fonction de la cible ?

Je ne sais pas ce que vous entendez par là. Si vous ciblez ES5, il transpile la syntaxe vers ES5. Mais il en va de même pour Babel, Traceur et al. Y a-t-il quelque chose de spécifique auquel vous faites référence ?

Je me souviens qu'il n'utilisait pas du tout de polyfills.

Ce n'est pas le cas, mais encore une fois, babel, traceur ou autres transpilateurs non plus; donc je ne suis pas sûr de ce que vous conduisez? Nous devrions utiliser des polyfills core-js dans les deux sens (babel ou TS).

Je pense que la discussion est babel pour transformer ES6 -> ES5 ou TypeScript pour transformer TS -> ES5. Nous devons aller ES5 de toute façon. TS peut cibler ES6, et nous pourrions livrer une version ES6 si nous le voulions, mais ce serait en plus de la version ES5.

@photonstorm Avec TypeScript, à ma connaissance, vous ne pouvez pas choisir les fonctionnalités à transpiler vers ES5 comme vous le pouvez avec Babel.

J'utilise TypeScript et je pense que c'est génial. J'adorerais voir Pixi adopter éventuellement. Google encourage désormais les développeurs à utiliser TypeScript avec Angular, ce qui est un bon signe d'adoption généralisée. Pour une base de code aussi complexe que Pixi, serait bien servi par des typages stricts.

Certains problèmes qui devraient être résolus avec TypeScript incluraient jsdocs (quelqu'un a-t-il de l'expérience avec cela?) Et les dépendances en amont qui pourraient utiliser le src quand require('pixi.js') (est-ce que quelqu'un a besoin de ça?).

Dans un premier temps, passer à ES6 est toujours une bonne option, car nous devrons de toute façon convertir en classes. Nous pourrions considérer TypeScript comme une autre "passe" pour moderniser la base de code une fois que nous sommes certains que toutes les préoccupations peuvent être résolues.

Avec TypeScript, à ma connaissance, vous ne pouvez pas choisir les fonctionnalités à transpiler vers ES5 comme vous le pouvez avec Babel.

Je ne savais pas que tu pouvais faire ça avec Babel. Je ne suis pas sûr d'en voir l'avantage pour nous puisque nous devons de toute façon viser ES5. Mais c'est chouette !

Certains problèmes qui devraient être résolus avec TypeScript incluraient jsdocs

https://github.com/TypeStrong/typedoc

dépendances en amont qui pourraient utiliser le src lorsque require('pixi.js') (est-ce que quelqu'un a besoin de ce genre ?).

Nous pouvons pointer "main" vers tout ce que nous voulons, et avec le tapuscrit, vous le pointez vers les fichiers construits (pas le _bundle_). Par exemple, les fichiers TS vont dans src/ et vous transpilez chaque fichier vers js/ ou quelque chose, puis pointez main là-bas. Ensuite, nous regroupons également le tout et mettons les lots en dist/ ou w/e. Le package npm est livré avec les fichiers js/tsd mais pas la source TS généralement (discutable).

Dans un premier temps, passer à ES6 est toujours une bonne option, car nous devrons de toute façon convertir en classes. Nous pourrions considérer TypeScript comme une autre "passe" pour moderniser la base de code une fois que nous sommes certains que toutes les préoccupations peuvent être résolues.

👍

Avec TypeScript, à ma connaissance, vous ne pouvez pas choisir les fonctionnalités à transpiler vers ES5 comme vous le pouvez avec Babel.

Ils ont ajouté cette fonctionnalité sur TypeScript 2.0 : https://github.com/Microsoft/TypeScript/wiki/What 's-new-in-TypeScript#incluant-built-in-type-declarations-with---lib

Il est habituel d'utiliser ES5 comme cible mais d'inclure ES6 en tant que bibliothèques, pour avoir les définitions de type pour des choses comme Symbol , Map , etc.

En effet, comme @englercj l' a dit, vous devez inclure des shims après la compilation de votre code, quel que soit le compilateur que vous utilisez. Babel n'inclut pas automatiquement un polyfill Symbol pour IE9, par exemple.

Je ne savais pas que tu pouvais faire ça avec Babel. Je ne suis pas sûr d'en voir l'avantage pour nous puisque nous devons de toute façon viser ES5. Mais c'est chouette !

Pour Pixi, pas si utile, mais oui, vous pouvez sélectionner les préréglages Babel pour ne sélectionner que certaines fonctionnalités à transpiler. Cela peut être utile si vous souhaitez construire sur ES6 mais que vous souhaitez uniquement prendre en charge les fonctionnalités V8 de pointe dans Node 6, Electron 1, etc.

C'est vraiment un paradoxe intéressant. Utilisez ES6 pour construire avec, car il est propre, agréable et très bien pris en charge / optimisé en interne par les navigateurs modernes. Pourtant, tout ce travail acharné est détruit en transpilant comme si c'était en 1995 :) (et avec les changements de syntaxe du langage, vous ne pouvez pas contourner cela).

J'apprécie que le problème soit universel, rien à voir avec TS ou Pixi. Juste une situation un peu bizarre dans laquelle se trouver.

@photonstorm C'est une malheureuse ironie 😞 j'espère que nous pourrons avoir des versions ES6 et ES5 afin que pour les applications packagées (comme electron), elles puissent utiliser la version ES6.

Je saute juste dans la discussion ici :) J'ai vu des gens transpiler TS vers ES6 puis utiliser Babel pour le transpiler vers ES5, je suppose que si vous voudriez quelque chose comme certaines fonctionnalités transpilées, ce serait plutôt bien?

De plus, il y a (encore un autre ...) module bundler autour, mais je pense que celui-ci semble produire un code assez astucieux, avec la possibilité de sorties multiples.
http://rollupjs.org/ il regroupe la syntaxe du module ES6/ES2015, ce qui, je suppose, est plutôt agréable si vous souhaitez pérenniser le code.

je suis +1 pour PIXI écrit en Typescript. D'après mon expérience, le type aide vraiment beaucoup avec la structure de projets comme celui-ci. Si seulement il pouvait rester performant :)

RollUp est fantastique, j'adore l'utiliser. Son secouement d'arbre est vraiment intelligent. Utilisé avec bubel (au lieu de babel), cela permet un flux de travail vraiment très rapide.

Intéressant de voir tant d'amour TS ici. Ce n'était certainement pas le cas il y a un an :) Il existe des moyens de vérifier le type ES2015 qui peuvent valoir la peine d'être envisagés.

@photonstorm n'a pas trouvé bubel, mais il y a "buble"

Ouais ouais, faute de frappe. http://buble.surge.sh/

BubleTape est un joli harnais de test pour cela https://github.com/snuggs/buble-tape

Est-ce que #2936 est la raison pour laquelle les membres ont déposé les documents ? Cela a un membre exposé, où cela a 25+.

Est-ce que @memberof doit leur être ajouté maintenant, ou y a-t-il une magie qui peut être appliquée ?

@staff0rd Je pense que nous sommes toujours en train de nettoyer les choses, une fois que cela se stabilisera un peu, nous chercherons à nettoyer les documents. C'est probablement simplement parce que la version jsdoc que nous utilisons contient des bogues ES6. On devrait bientôt pouvoir nettoyer ça.

ES6 a été fusionné avec dev , merci à tous ceux qui ont aidé. C'est très apprécié !

Fermant ceci pour l'instant.

Ce fil a été automatiquement verrouillé puisqu'il n'y a eu aucune activité récente après sa fermeture. Veuillez ouvrir un nouveau problème pour les bogues associés.