Pixi.js: ТРЕБУЕТСЯ ПОМОЩЬ: усилия по преобразованию ES6

Какой маршрут вы хотите пройти с помощью let и const? По умолчанию используется const, и используйте let только для свойств, ссылка на которые должна быть изменена.
Или
По умолчанию разрешено, и используйте const только как намек разработчику, что они, я серьезно, не меняют это.

Прежний вариант. По умолчанию используется const. Я преобразовал все внутренние vars в let и исправил очевидные проблемы с областью действия и запретил использование var с jshint. Нужен еще один проход с const.

Вещи, которые я бы порекомендовал:

• [x] Используйте babel-preset-es2015-loose , у меня была плохая производительность только с одним babel-preset-es2015.
• [x] Переключитесь на eslint , он лучше поддерживает ES6 и просто лучше, чем jshint в целом. Вот хорошая отправная точка для стиля пикси. Он также будет жаловаться на места, где вы могли бы использовать const , но использовали let . Облегчает поиск всех мест, которые нужно исправить для const.
• [x] Используйте последний мастер jsdoc, в нем есть много исправлений ES6, которые еще не выпущены.
• Переключитесь на вебпак.

Спасибо @englercj. Хороший список.

@englercj У babel-preset-es2015-loose есть предупреждение об устаревании, вы пробовали babel-preset-es2015 с параметром {"loose": true} , как он предлагает?

Я также предпочитаю веб-пакет браузеру, пара полезных ссылок:
https://github.com/webpack/webpack/tree/master/examples/multi-part-library
http://krasimirtsonev.com/blog/article/javascript-library-starter-using-webpack-es6

Я предпочитаю ждать веб-пакета, а не накапливать его. Потенциально для другого меньшего PR. Это изменение представляет собой изменение процесса сборки, но не обязательно улучшение ES6. Кроме того, необходимо убедиться, что исходные карты, заголовки и т. д. работают. Я понимаю, как это лучше, но давайте пока подождем.

У babel-preset-es2015-loose есть предупреждение об устаревании. Пробовали ли вы babel-preset-es2015 с опцией {"loose": true}, как это предлагается?

Ха, это было _просто_ добавлено 2 недели назад. Я не пробовал это, потому что это не существовало в то время, когда я начал его использовать.

Всем привет,

Просто короткий крик, чтобы повторить мысль Чада о свободном режиме, и добавить сюда свои два цента.
Как мы уже обсуждали с @GoodBoyDigital , мы должны быть очень осторожны с производительностью, поэтому я думаю, что свободный режим — хорошая отправная точка.

Кроме того, я не уверен, насколько актуальна эта таблица: https://kpdecker.github.io/six-speed/ , ребята, вы знаете?

Если это все еще так, то мы должны быть осторожны, чтобы не сойти с ES2015 безумия и не преобразовать вещи, которые не должны быть, то есть: если for-of по-прежнему снижает производительность, как указано в таблице, мы не должны Не используйте его при повторении дочерних элементов графа сцены.

Теперь Babel должен оптимизировать for-of для массивов (см.: Оптимизация ), эти тесты кажутся довольно старыми .

В любом случае, @alvinsight , ты прав, все не обязательно должно быть ES2015.

Хороший список @englercj !

Также согласен с @alvinsight. Мы уже видим гораздо более чистый код с синтаксисом es6, так что выигрываем во всем :)

Любое другое решение должно быть основано на производительности: «Выглядит лучше, но работает медленнее — не делайте этого».

Хорошим примером является зацикливание массива - нет необходимости заменять вещи, которые уже являются быстрыми и читаемыми, только потому, что мы можем.

Также да для веб-пакета! @bigtimebuddy прав, это должно быть второй частью этого перехода на es6.

Согласованный!
Намного приятнее, наконец, уметь читать и писать class Sprite extends Container !

Обновлено

• Заменен jshint на eslint (и исправлены ошибки linting, eslint для победы!)
• Использование loose: true с babel-preset-es2015

Всем вечер!

Ударьте немного с нашими миксинами..

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

Вышеупомянутое в настоящее время не работает в ветке ES6, поэтому такие вещи, как взаимодействие, не работают.

Есть ли хороший способ сделать это с помощью классов es6?

Ответы на открытке пожалуйста!

Хорошо, я был прав в первый раз - приведенный выше код в настоящее время не работает .. (Могу ли я винить в этом тот факт, что сегодня вечер пятницы?)

Я думаю, здесь сияет композиция!

Хм, что не работает? Это сработало для меня:

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

Скопируйте и вставьте это в консоль Chrome, и, похоже, все работает нормально.

Интересный! В настоящее время взаимодействие не работает, и интерактивные свойства, похоже, отсутствуют. Может другая причина? Буду копать дальше...

Ах ха! Нашел это

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

import interactiveTarget from './interactiveTarget';

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

Может быть?

Ага!

PR 1 здесь: https://github.com/pixijs/pixi.js/pull/2960

Он исправляет несколько битов, таких как миксины и текст.

Завтра посмотрю фильтры...

Хорошо выглядишь, ребята!

Хорошая работа! Да, такое использование require() вернет объект с одним ключом по умолчанию, содержащим все остальное, что вы ожидали.

Теперь фильтры в порядке! Запустил это в текущем проекте, над которым я работаю, это довольно сложно - и все работает на 100%!

Можно протестировать его в нескольких других играх, но скоро будет неплохо объединиться!

@bigtimebuddy вы пробовали эту сборку с pixi-animate?

Бросить это туда ... traceur кажется быстрее, чем babel?
Стоит расследовать?

https://kpdecker.github.io/шесть скоростей/

Эти тесты устарели и не работают без поддержки Babel. Кроме того, вы также можете возразить, что машинописный текст во многих случаях быстрее, чем оба :)

Я предлагаю вам, ребята, рассмотреть возможность использования TypeScript как часть этого крупного переписывания/адаптации. Несколько моментов о TypeScript:

• Использование системы типов в JavaScript станет новым стандартом, это всего лишь вопрос времени.
• Это JavaScript. Никакой разницы в синтаксисе, кроме системы типов.
• Улучшает качество кода. Возможно, вы обнаружите значительный объем кода, который необходимо немного реструктурировать, чтобы он соответствовал типам в нужных местах.
• Увеличить проверку качества пулл-реквеста — если есть какая-то проблема с типом, патч просто нельзя будет слить.

Я знаю, что это непростая задача, но я считаю, что она может принести большую пользу кодовой базе и сообществу.
Ваше здоровье!

@endel Я перевожу pixi-spine на машинопись, там будут демонстрации плагинов TS для pixi.

@endel просто любопытно, но решил ли TS проблему, которая возникла, когда я последний раз смотрел на нее: это ситуация «все или ничего», когда дело доходит до вывода, то есть _все_ переносится обратно в ES5 или ничего, в зависимости от цели ?

Я помню, что он вообще не использовал полифиллы. Поэтому, если вы хотите, чтобы единая кодовая база работала в широком диапазоне браузеров, от передовых до устаревших, вам все равно придется ориентироваться на ES5, а все приятные новые функции, которые современные браузеры теперь поддерживают изначально, игнорируются, потому что он все равно переходит на ES5? Или это все еще тот случай, когда вам нужно использовать полифилл ES6 поверх вывода TS, чтобы охватить все базы?

что это ситуация «все или ничего», когда дело доходит до вывода, т.е. все переносится обратно в ES5 или ничего, в зависимости от цели?

Не уверен, что вы имеете в виду под этим. Если вы ориентируетесь на ES5, он транспилирует синтаксис в ES5. Но то же самое делают и Babel, Tracuer и др. Вы имеете в виду что-то конкретное?

Я помню, что он вообще не использовал полифиллы.

Это не так, но опять же, как и babel, tracuer или другие транспиляторы; так я и не понял к чему вы клоните? В любом случае нам пришлось бы использовать полифиллы core-js (babel или TS).

Я думаю, что обсуждение заключается в том, чтобы преобразовать ES6 -> ES5 или TypeScript в преобразование TS -> ES5. Мы должны пройти ES5 в любом случае. TS может ориентироваться на ES6, и мы могли бы выпустить сборку ES6, если бы захотели, но это было бы дополнением к сборке ES5.

@photonstorm С TypeScript, насколько мне известно, вы не можете выбирать функции для переноса в ES5, как вы можете с Babel.

Я использую TypeScript и думаю, что это круто. Хотелось бы, чтобы Пикси в конце концов удочерил. Google теперь поощряет разработчиков использовать TypeScript с Angular, что является хорошим признаком широкого распространения. Для такой сложной кодовой базы, как Pixi, строгая типизация хорошо подходила бы.

Некоторые проблемы, которые необходимо решить с помощью TypeScript, включают в себя jsdocs (у кого-нибудь есть опыт с этим?) и вышестоящие зависимости, которые могут использовать src, когда require('pixi.js') (кому-нибудь требуется подобное?).

В качестве первого шага переход на ES6 по-прежнему является хорошим вариантом, поскольку нам все равно нужно будет преобразовать его в классы. Мы могли бы рассмотреть TypeScript как еще один «проход» в модернизации кодовой базы, как только мы будем уверены, что все проблемы могут быть решены.

С TypeScript, насколько мне известно, вы не можете выбирать функции для переноса в ES5, как вы можете с Babel.

Я понятия не имел, что вы можете сделать это с Babel. Я не уверен, что вижу в этом пользу для нас, поскольку мы все равно должны ориентироваться на ES5. Но это аккуратно!

Некоторые проблемы, которые необходимо решить с помощью TypeScript, включают jsdocs.

https://github.com/TypeStrong/typedoc

upstream-зависимости, которые могут использовать src, когда требуют ('pixi.js') (кому-то требуется подобное?).

Мы можем указать «main» на все, что захотим, а с машинописным текстом вы укажете его на встроенные файлы (а не на _bundle_). Например, файлы TS помещаются в src/ , и вы транспилируете каждый файл в js/ или что-то в этом роде, а затем указываете туда main. Потом тоже все это упаковываем и кладем пучки в dist/ или ж/д. Пакет npm поставляется с файлами js/tsd, но обычно не с исходным кодом TS (спорный).

В качестве первого шага переход на ES6 по-прежнему является хорошим вариантом, поскольку нам все равно нужно будет преобразовать его в классы. Мы могли бы рассмотреть TypeScript как еще один «проход» в модернизации кодовой базы, как только мы будем уверены, что все проблемы могут быть решены.

👍

С TypeScript, насколько мне известно, вы не можете выбирать функции для переноса в ES5, как вы можете с Babel.

Они добавили эту функцию в TypeScript 2.0: https://github.com/Microsoft/TypeScript/wiki/What 's-new-in-TypeScript#включая-встроенные-в-типе-объявления-с---lib

Обычно используют ES5 в качестве цели, но включают ES6 в качестве библиотек, чтобы иметь определения типов для таких вещей, как Symbol , Map и т. д.

Действительно, как сказал @englercj , вам нужно включать прокладки после того, как ваш код скомпилирован, независимо от того, какой компилятор вы используете. Например, Babel не включает полифилл Symbol для IE9 автоматически.

Я понятия не имел, что вы можете сделать это с Babel. Я не уверен, что вижу в этом пользу для нас, поскольку мы все равно должны ориентироваться на ES5. Но это аккуратно!

Для Pixi это не так уж полезно, но да, вы можете выбрать пресеты Babel, чтобы выбрать только определенные функции для переноса. Это может быть полезно, если вы хотите собрать ES6, но хотите поддерживать только передовые функции V8 в Node 6, Electron 1 и т. д.

Это действительно интересный парадокс. Используйте ES6 для сборки, потому что он чистый, красивый и очень хорошо поддерживается/внутренне оптимизирован современными браузерами. Тем не менее, вся эта тяжелая работа уничтожена транспилированием, как будто это 1995 год :) (и с изменениями синтаксиса языка вы не можете обойти это).

Я понимаю, что проблема универсальна, ничего общего с TS или Pixi. Просто немного странная ситуация.

@photonstorm Это досадная ирония 😞 надеюсь, у нас будут сборки ES6 и ES5, чтобы для упакованных приложений (например, electronic) они могли использовать сборку ES6.

Просто присоединяюсь к обсуждению здесь :) Я видел, как люди транспилируют TS в ES6, а затем используют Babel для его транспиляции в ES5, я думаю, если бы вы хотели, чтобы что-то вроде некоторых функций было транспилировано, это было бы неплохо?

Кроме того, существует (еще один...) сборщик модулей, однако я думаю, что он создает довольно приятный код с возможностью нескольких выходов.
http://rollupjs.org/ он объединяет синтаксис модуля ES6/ES2015, что, я думаю, довольно удобно, если вы хотите проверить код в будущем.

я +1 за то, что PIXI написан на машинописном языке. По моему опыту, шрифт действительно очень помогает со структурой подобных проектов. Лишь бы работоспособность сохранилась :)

RollUp — это фантастика, мне нравится им пользоваться. Его встряхивание дерева очень умно. При использовании с bubel (вместо babel) это обеспечивает очень, очень быстрый рабочий процесс.

Интересно видеть так много любви ТС здесь. Конечно, год назад было не так :) Есть способы проверить тип ES2015, которые, возможно, стоит рассмотреть.

@photonstorm не нашел bubel, но есть buble

Да да, опечатка. http://buble.surge.sh/

BubleTape — хорошая тестовая программа для этого https://github.com/snuggs/buble-tape .

Является ли № 2936 причиной, по которой участники отказались от документации? У этого есть один открытый член, где у этого есть 25+.

Нужно ли добавлять к ним @memberof сейчас или можно применить какое-то волшебство?

@staff0rd Я думаю, что мы все еще наводим порядок, как только ситуация немного стабилизируется, мы займемся очисткой документов. Скорее всего, это просто потому, что используемая нами версия jsdoc содержит ошибки ES6. Мы должны быть в состоянии приступить к очистке этого в ближайшее время.

ES6 был объединен с dev , спасибо всем, кто помог. Это очень ценится!

Закрытие на данный момент.

Эта ветка была автоматически заблокирована, так как после ее закрытия не было никаких действий в последнее время. Пожалуйста, откройте новую проблему для связанных ошибок.