Three.js: Оцените классы ES6

Итак, вы предлагаете использовать этот шаблон вместо этого?

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

class PointLight extends Light

хехе 😄 И никаких проблем...

@sasha240100 когда-нибудь...

@mrdoob не совсем - два упомянутых вами способа полностью эквивалентны. Я думаю, что ОП сравнивает

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

с участием

function PointLight () { ... };

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

PointLight.prototype.constructor = PointLight;

PointLight.prototype.prop1 = 'something';

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

...

Вот как это делается, например.
Насколько я вижу, эти стили эквивалентны - я что-то упускаю?
Или стиль был изменен на использование Object.Assign после того, как он стал доступен и не обновлялся в кодовой базе?

@looeee @bfred-it @mrdoob Почему бы просто не использовать rollup-babel ?

Сравнение :
Текущий. Модули гармонии 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 };

ЕС2015+. Тот же код, но es2015+ с 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, которые упростили бы код three.js:

• Значения параметров по умолчанию.
  
  
  
  • Может легко заменить такие части кода
  
  
• Сокращение свойства
  
  
  
  • Здесь можно использовать
  
  
• Функция стрелки
  
  
  
  • https://github.com/mrdoob/three.js/blob/dev/src/loaders/JSONLoader.js#L36
  
  

Я полностью за переход на ES2015+, нам просто нужно найти способ выводить код, аналогичный тому, что у нас есть в настоящее время, чтобы производительность оставалась неизменной во всех случаях.

У меня вопрос в контексте классов. Как бы мы переносили такие методы, как Vector3.unproject , в синтаксис класса? Метод фактически использует замыкание для создания новой области. Это важный механизм, который сводит к минимуму количество создаваемых объектов.

Нужны ли нам Object.assign в этих случаях?

@ Mugen87 @mrdoob Немного интересной информации о производительности es6. Особенно на Object.assign :

Из этой статьи

Как бы мы переносили такие методы, как Vector3.unproject, в синтаксис класса? Метод фактически использует замыкание для создания новой области.

@ Mugen87 Mugen87 Разве они не могут быть просто неэкспортируемыми объектами в области модуля? Что-то вроде этого;

const tempMatrix = new Matrix();    

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

Ах да, я думаю, это должно сработать 😊

В прошлом месяце это было предложено в твиттере :

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

@mrdoob Вау! Вроде уже работает. Нельзя ли сделать ветку, трансформировать некоторые классы в es6 и посмотреть, как это компилируется?

@ satori99 В качестве идеи о том, как сохранить tempMatrix внутри кода Vector3, чтобы избежать проблем с глобальными переменными:

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

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

@mrdoob Вау! Вроде уже работает. Нельзя ли сделать ветку, трансформировать некоторые классы в es6 и посмотреть, как это компилируется?

Звучит хорошо для меня! В настоящее время я сосредоточен на WebVR, поэтому это должен быть кто-то другой, кроме меня.

@ sasha240100 Преимущество использования переменных с областью действия модуля заключается в том, что они остаются скрытыми от обычного пользовательского кода, что кажется подходящим для временных переменных.

Я не возражаю против питонистского подхода «Мы все здесь взрослые» в отношении частных переменных, но временные переменные не должны без необходимости загрязнять пространство имен.

Кроме того, было бы неплохо, если бы те из нас, у кого включена поддержка собственных модулей в наших браузерах, могли напрямую загружать файлы src. Это гораздо более приятный способ разработки, без наблюдателей и транспиляции после каждого редактирования. Использование свойств класса означает, что это невозможно, поскольку они не являются частью текущей спецификации класса.

Приносим извинения за вмешательство. Вероятно, нам следует изменить название проблемы на что-то вроде «Оценить классы ES6», так как теперь тема изменилась на что-то совершенно другое.

Зачем менять шаблон @Mugen87 @satori99 ?

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

Почему бы не попробовать typescript, его можно скомпилировать в другие версии js

TypeScript действительно был бы отличным вариантом для размышлений, потому что это транспилятор + проверка типов и надмножество JavaScript, поэтому легко перенести кодовую базу в файлы .ts и постепенно рефакторить до ES6 с проверкой типов.

Это может показаться пугающим, если вы никогда не использовали TypeScript, но на самом деле это не большая кривая обучения, и это будет небольшая цена за преимущества, которые он принесет. Сообщество TypeScript будет очень радо помочь с этим переходом и созданием тестов производительности для текущей библиотеки, чтобы убедиться, что она не будет понижена.

Несколько полезных статей:

• Почему не стоит бояться TypeScript
• TypeScript против ES6 против ES2015
• TypeScript выиграл
• Что такое TypeScript и почему с Андерсом Хейлсбергом

По словам основного разработчика Андерса Хейлсберга, TypeScript родился в ответ на жалобы клиентов и внутренних команд на то, что JavaScript плохо подходит для больших приложений.

Цель заключалась в том, чтобы «усилить JavaScript такими вещами, как классы, модули и статическая типизация», не жертвуя при этом преимуществом его открытых стандартов и кроссплатформенности; результатом стал «язык для разработки javascript в масштабе приложения», созданный как надмножество языка.

Пока браузеры не смогут выполнять TypeScript нативно, я предпочитаю продолжать использовать JavaScript.

@мрдуб

Я не вижу в этом уважительной причины не использовать TypeScript исключительно по той причине, что его нельзя запустить непосредственно в браузере. Вы бы не хотели, чтобы он запускался в браузере из-за всех дополнительных строк кода, предназначенных только для проверки времени компиляции. В настоящее время это не язык проверки во время выполнения. Поэтому, если он когда-либо использовался в браузере, скорее всего, весь типизированный код будет удален, потому что он влияет на производительность, и тогда это будет ванильный код JavaScript.

Я думаю, вы совершенно упускаете из виду смысл использования типизированного языка и преимущества, которые он дает при разработке в большой базе кода. Вы все еще пишете и используете JavaScript, вся суть TypeScript в том, что это надмножество JavaScript. Вы пишете JavaScript с типами, которые скомпилированы в JavaScript в указанной целевой версии ECMAScript, которая настраивается в параметрах компилятора, допустимые значения: «es3», «es5», «es2015», «es2016», «es2017» или « следующий'.

Поскольку Typescript — это JavaScript, он позволяет постепенно мигрировать без головной боли, связанной с рефакторингом всего сразу. Это может быть постепенно сделано и улучшено сообществом. Это не больше работы, чем то, что обсуждается здесь с рефакторингом для использования классов ES6. Это единственная причина, по которой я упоминаю об этом здесь, а не открываю новую тему.

См. ссылки на игровую площадку TypeScript ниже для отличных примеров:

• Классический пример JavaScript
• Пример добавления типов
• Пример добавления типов с ошибкой
• Пример использования классов
• Пример использования классов с ошибкой

@joejordanbrown

Можете ли вы назвать кого-нибудь, кто мог бы не согласиться с вами в том, что машинописный текст является лучшим решением этой конкретной проблемы?

Если вы введете typescript vs в Google, появится несколько терминов, одним из которых является Flow. Поиск этого, кажется, приводит к ряду статей, в которых люди обсуждают плюсы и минусы этих двух.

Никакие типы не кажутся большим компромиссом, чем выбор одного из них.

Сохраняйте Typescript для проектов, которые более сложны, чем результат, который они создают — особенно интерфейсные фреймворки, которые в первую очередь могли быть реализованы в HTML. Моя первоначальная цель состояла в том, чтобы избавиться от болезни JavaScript, а не усугубить ее. JavaScript — это простой, почти игрушечный язык, который иногда используется для сложных результатов, таких как three.js. Машинопись бессмысленна.

6 сентября 2017 г., в 13:55, [email protected] написал:

@мрдуб

Я не вижу в этом уважительной причины не использовать TypeScript исключительно по той причине, что его нельзя запустить непосредственно в браузере. Вы бы не хотели, чтобы он запускался в браузере из-за всех дополнительных строк кода, предназначенных только для проверки времени компиляции. В настоящее время это не язык проверки во время выполнения. Поэтому, если он когда-либо использовался в браузере, скорее всего, весь типизированный код будет удален, потому что он влияет на производительность, и тогда это будет ванильный код JavaScript.

Я думаю, вы совершенно упускаете из виду смысл использования типизированного языка и преимущества, которые он дает при разработке в большой базе кода. Вы все еще пишете и используете JavaScript, вся суть TypeScript в том, что это надмножество JavaScript. Вы пишете JavaScript с типами, которые скомпилированы в JavaScript в указанной целевой версии ECMAScript, которая настраивается в параметрах компилятора, допустимые значения: «es3», «es5», «es2015», «es2016», «es2017» или « следующий'.

Поскольку Typescript — это JavaScript, он позволяет постепенно мигрировать без головной боли, связанной с рефакторингом всего сразу. Это может быть постепенно сделано и улучшено сообществом. Это не больше работы, чем то, что обсуждается здесь с рефакторингом для использования классов ES6. Это единственная причина, по которой я упоминаю об этом здесь, а не открываю новую тему.

Примеры см. в ссылках на игровые площадки TypeScript:

Классический пример JavaScript
Пример добавления типов
Пример добавления типов с ошибкой
Пример использования классов
Пример использования классов с ошибкой
—
Вы получаете это, потому что вы создали тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите ветку.

^ я был бы в порядке даже с чудовищным шаблоном, если бы он был последовательным.

@joejordanbrown звучит так, будто ты влюблен в машинопись. не стесняйтесь разветвлять проект и портировать его на машинопись. три.тс! 🙌

@ведерко

Это вопрос выбора, я уверен, что многие согласятся и не согласятся, это нормально, хотя и правильно! Вы всегда будете видеть "это против того", "мое лучше, чем ваше". Я понимаю, что у каждого свои преимущества. Речь идет о том, чтобы взвесить доступные варианты и посмотреть, могут ли они принести пользу проекту. Сравнения — это хорошо, они продвигают проекты дальше.

Вы упомянули Flow, проблемы, которые я вижу в этом:

• Потоковое лицензирование — это BSD 3-пункт « Facebook BSD + Patents License », Apache Software Foundation запретила использование этой лицензии в новых проектах. Вы можете прочитать более подробную информацию здесь .

• Поддержка IDE отсутствует по сравнению с TypeScript.

• База пользователей мала по сравнению с TypeScript,

• Доступные типизации для публичных библиотек неполные, у TypeScript есть много хорошо поддерживаемых типизаций.

• Документацию и ресурсы трудно найти, и они расплывчаты по сравнению с TypeScript, вы найдете отличную документацию, книги, видео и множество других ресурсов для электронного обучения.

• Flow использует файлы .js, помеченные // @flow , это может сбивать с толку, потому что вы видите расширение .js , поэтому ожидайте JavaScript, но на самом деле это FlowType. Где, поскольку TypeScript использует собственное расширение .ts . Это также позволяет вам иметь выходные файлы TypeScript и JavaScript с одинаковыми именами в одном и том же каталоге, что идеально подходит для небольшого проекта, очевидно, что это не будет иметь место в большом проекте, потому что вы будете использовать сборку система для управления процессом сборки.

Даже Google активно поддерживает TypeScript, что свидетельствует об их уверенности в TypeScript. Читайте пост здесь или здесь .

С марта 2017 года TypeScript разрешен для неограниченной клиентской разработки. TypeScript и Angular на TypeScript используются в Google Analytics, Firebase и Google Cloud Platform, а также в критически важных внутренних инструментах, таких как отслеживание ошибок, обзоры сотрудников, а также средства утверждения и запуска продукта.

Я просто решил открыть дискуссию об использовании типизированного языка и посмотреть, что все остальные думают об этой идее. Однако похоже, что @mrdoob категорически против даже обсуждения этой идеи.

@arctwelve
Я не понимаю, насколько этот проект не сложен и как использование типизированного языка повлияет на него негативно.

@мрдуб
Вовсе нет, я просто вижу преимущества, которые это может иметь, особенно если создается новая ветка для обновления до классов ES6. Я думаю, что отвечать созданием собственной вилки под названием three.ts просто глупо. Это действительно противоречит хорошей практике OSS, если бы все просто разветвляли проекты OSS и модифицировали свой собственный исходный код вместо того, чтобы сосредоточиться на одном проекте и сделать его как можно лучше. В конечном итоге вы получите действительно плохое программное обеспечение или сообщества, разделившиеся и сосредоточившиеся на проекте, который они предпочитают по какой-либо причине. Почему нельзя открыто обсудить плюсы и минусы?

Не для того, чтобы играть в адвоката дьявола, но, похоже, он это сделал.

провести открытое обсуждение

это было просто очень коротко :)

Я разделяю аналогичную точку зрения, это библиотека JS, а JS стандартизирован. Вы не ошибетесь, выбрав JS для библиотеки JS, но можете, если выберете что-то другое. Я просто взял Flow как одну из альтернатив машинописи, не знаю, есть ли другие.

В любом случае, похоже, мы действительно отошли от темы.

Mugen87 изменил название с
Удалить болезнь JavaScript для оценки классов ES6

Первоначальное название относилось (насколько я понимаю) к отсутствию единообразия стиля. В частности, использование Object.assign() в некоторых местах и ​​другой шаблон в других.
Если бы я что-то здесь оценивал, то это было бы текущее название номера. Почему вопрос согласованности поднимается до обсуждения использования нового языка?

Я предполагаю, что как с typescript, так и с es6 код должен быть достаточно последовательным.

Я бы решил эту проблему, обновив эту страницу:

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

и добавив либо:

А) "...используйте Object.assign..."
Б) "... не используйте Object.assign"

Единый стиль во всей библиотеке. Нет необходимости менять его.

Верный двухстрочный стиль, который все еще используется, например, в классах материалов, намного понятнее и чище.

Это в первом посте.

Я предлагаю:

1. отредактируйте заголовок, чтобы отразить это предложение, обсудите использование единого стиля во всей библиотеке, отредактируйте руководство по стилю и т. д.
2. начать новую дискуссию под названием «оценить классы es6», где будут оцениваться классы es6
3. начать новую дискуссию под названием «оцените наличие трех написанных на типизированном языке», где будут обсуждаться машинописные тексты и тому подобное.

В любом случае, похоже, мы действительно отошли от темы.

Верно. @joejordanbrown не стесняйтесь создавать новую тему для обсуждения TypeScript.

Кстати, это также плохая практика OSS - игнорировать предыдущие разговоры... https://github.com/mrdoob/three.js/issues/341#issuecomment -47000692

Вернемся к теме. Я думал, мы уже решили этот вопрос?

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

Нам просто нужен кто-то, кто попробует.

Итак... во-первых

Первый шаблон (лучший ИМО):

function MyClass() {...}

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

    constructor: MyClass,

    prop1: 'something',

    method1: function someFunction() { .. },

    ...

});

Второй узор:

function MyClass() {...}

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

MyClass.prototype.constructor = PointLight;

MyClass.prototype.prop1 = 'something';

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

...

@arctwelve Этот шаблон был введен по многим причинам. Это не мастурбация!

Прежде всего, это позволяет четко прочитать о наследовании объекта. Object.assign явно здесь о наследовании объектов. Тогда вы не можете потерять унаследованный объект во многих строках MyClass.prototype .
Во-вторых, в случае множественного наследования это тоже намного понятнее.
В-третьих, конструктор класса читабелен и не теряется во многих строках, как первый пункт.
В-четвертых, это позволяет группировать свойства и методы в одном месте (внутри квадратных скобок), что намного понятнее, когда у вас есть 3, 4, 5... и т. д. классов в одном файле.
В-пятых, этот паттерн позволяет проверить корректность копии на наличие некоторых «унаследованных» свойств.

Наконец ( @looeee ), это тоже для производительности. Первая версия более оптимизирована, когда происходит парсинг файла, а не множественный и многократный вызов прототипа.

Так или иначе !

Теперь мы должны перейти на синтаксис ES6!

@мрдуб

Звучит хорошо для меня! В настоящее время я сосредоточен на WebVR, поэтому это должен быть кто-то другой, кроме меня.
Нам просто нужен кто-то, кто попробует.

Вы бы создали ветку es6? Или это самостоятельно?

Первая версия более оптимизирована, когда происходит парсинг файла, а не множественный и многократный вызов прототипа.

Вы уверены, что? Я ожидаю, что Object.Assign будет медленнее, если что. Но в любом случае я сомневаюсь, что накладных расходов на производительность достаточно, чтобы беспокоиться о них.

Абсолютно: https://jsperf.com/inline-prototype-vs-assign-prototype/1

В версии Chrome 61.0.3163.100 (официальная сборка) (64 бита) назначенный прототип работает примерно на 60% быстрее.

Интересный. Спасибо, что сделали тест.

Однако этот результат подходит не для всех браузеров. В Firefox они почти одинаковы ( Object.Assign ~3% быстрее), а в Edge Object.Assign на ~33% медленнее .

Но в любом случае я по-прежнему не думаю, что это уместно в качестве аргумента в пользу того, какой стиль лучше — даже самый медленный в целом (встроенный прототип в Chrome) по-прежнему работает со скоростью> 180 000 операций в секунду, и может быть пара тысяч операций. эти настройки сделаны в коде. Так что речь тут, наверное, о разнице в несколько миллисекунд.

Для меня стиль Object.Assign чище и легче читается, и это главный аргумент в его пользу.

Да, это около нескольких миллисекунд на файл и только тогда, когда файл анализируется в первый раз движком javascript... но для большой библиотеки, такой как threejs, выигрыш может составлять около 200 миллисекунд при загрузке страницы.
Не забывайте о лимите в 3scd для переднего пользователя, который не может больше ждать!

Я пытаюсь сделать проект Angular с помощью threejs, и всегда кажется, что я взламываю каждую часть threejs.
Во-первых, это синтаксис es5 с константой THREE, которая должна существовать, например, если мне нужны OrbitalControls.
У нас есть типизации threejs, но будет удобнее иметь их в одном пакете. У типов есть OrbitalControls, но мы не можем просто импортировать как import { OrbitalControls } from 'three; .
В вебпаке есть древовидная тряска, так что в случае с es6 мы могли включить все, что нам нужно, в один проект, а не выносить их в отдельный проект.
@mrdoob , так почему Typescript такой плохой? В любом случае он будет скомпилирован в ES любой версии с типизацией.
Он также используется во многих других фреймворках, таких как React.

@FriOne Я не уверен, что @mrdoob действительно считает Typescript плохим, но я думаю, что он против обсуждения Typescript в этом выпуске/ветке, потому что это не тема этой темы. Я думаю, что классы ES6 не работают против или для Typescript. Если вы преобразуете кодовую базу в ES6, будет еще проще перенести кодовую базу в Typescript, потому что ее синтаксис очень похож. Да, я думаю, что Typescript может включить множество новых опций. Например, это может помочь «транспилировать» более оптимизированный код, это поможет новым разработчикам быстрее изучить библиотеку, возможно, это откроет двери для экспериментов в будущем, например: https://github.com/AssemblyScript/assemblyscript. Я думаю, что у Typescript есть много преимуществ . @joejordanbrown подробно описал плюсы.

Но вернемся к теме: я думаю, что принятие классов ES6 было бы шагом вперед, и после этого мы могли бы обсудить вещь Typescript. Итак, давайте делать один шаг друг за другом

@tschoartschi , думаю, машинописный текст может помочь с переходом на классы es6 и другим рефакторингом. У меня нет такого опыта миграции, может я ошибаюсь.

@FriOne это зависит 😉 конечно, Typescript может помочь, потому что компилятор может сообщить вам обо всех ваших ошибках и ошибках, но вам нужно будет сначала настроить весь канал сборки для работы с Typescript. Кроме того, вам необходимо оценить, подходит ли вам Typescript. Я думаю, что нормально сначала преобразовать в классы ES6, а затем подумать о Typescript.

Привет, мы группа из 5 студентов из KTH, которые хотят внести свой вклад в проект с открытым исходным кодом для курса, и хотели бы попытаться преобразовать часть проекта в новый синтаксис ES6.

Некоторое время назад (r82) я портировал Three.js на TypeScript вместе с несколькими примерами в качестве доказательства концепции.

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

Примеры загружаются немного, так как исходный код TypeScript транспилируется на лету. Они загружаются так же быстро, как и оригиналы, при использовании транспилированного JavaScript.

Я бы хотел, чтобы three.js перенесли на машинописный текст. Я чувствую, что проект остро нуждается в модернизации, если он хочет выдержать испытание временем для следующих веб-поколений. Однажды мы можем даже увидеть, как он работает с AssemblyScript и работает в WASM. Если не threejs, то что-то еще обязательно будет.

Это завершено @WestLangley и @mrdoob

@bhouston какой здесь вывод?

@pkieltyka да, я также думаю, что TypeScript будет иметь большое значение для такой библиотеки, как Three.js. Помимо всех технических плюсов, это также упростит использование библиотеки и поможет новичкам изучить API. Но я также думаю, что важно сначала закончить весь материал ES6, а затем уже рассматривать TypeScript. Я думаю, что из последнего JavaScript не так уж сложно добавлять типы в форме TypeScript.

@flyover тоже приятно увидеть доказательство концепции TypeScript-версии Three.js. Получили ли вы отзывы от сопровождающих Three.js?

Я также поддерживаю машинопись для three.js. typecipt в основном лучший
практики и необработанного JavaScript больше нет.

В субботу, 5 января 2019 г., 4:13 tschoartschi < [email protected] написал:

@pkieltyka https://github.com/pkieltyka да, я тоже думаю, что TypeScript
будет иметь смысл для такой библиотеки, как Three.js. Помимо всех
технические плюсы, это также упростит использование библиотеки и поможет новичкам
изучить API. Но я также думаю, что важно закончить все ES6.
Сначала напишите, а потом рассмотрите TypeScript. думаю из последнего
JavaScript не так уж сложно добавить типы в виде TypeScript.

@flyover https://github.com/flyover тоже приятно увидеть доказательство концепции для
TypeScript-версия Three.js. Получили ли вы обратную связь от сопровождающих
из Three.js?

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451639995 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAj6_bkdND7I0_F4AJcBV0DYLpToUIVhks5vAGykgaJpZM4N9vH8
.

@bhouston Я согласен с тем, что TypeScript - отличная технология, но я бы не сказал так, как вы. Я думаю, что мы всегда должны оставаться как можно ближе к сырому JavaScript и добавлять функции TypeScript поверх него. Поскольку TypeScript очень близко следует спецификации JavaScript, TypeScript действительно читается как ES6 с типами.

Для такой библиотеки, как three.js, TypeScript может быть действительно полезным, и его можно внедрять постепенно. Так что нам не нужно было бы переделывать «большой взрыв», особенно после того, как все рефакторинги ES6 завершены.

Было бы интересно узнать, изменилась ли позиция @mrdoob в отношении TypeScript. TypeScript, похоже, стал стандартом «де-факто» для «типизированного JavaScript» (обратите внимание, что я поставил свои утверждения под апострофом, поскольку это не неопровержимые факты)

Первым шагом должно быть внедрение функций ES6, особенно классов, стрелочных функций, let и const.

Как только мы это сделали, мы можем должным образом обсудить поддержку машинописного текста, поскольку, как указывает @roomle-build, легко постепенно добавлять функции машинописного текста поверх кода ES6, если мы решим.

Делать и то, и другое одновременно кажется мне слишком сложным.

Приятно слышать, что TypeScript может быть вариантом в какой-то момент в будущем :-) может быть, мы могли бы повторно использовать часть работы, проделанной @flyover.

Но я полностью согласен с @looeee , что нужно сначала закончить все, что связано с ES6, а затем сосредоточиться на следующих шагах.

закончить все материалы ES6

Я был бы счастлив, если бы мы могли хотя бы начать это 😅

Хорошим полушагом к TypeScript будет добавление файлов типов рядом с каждым файлом JavaScript. Таким образом, будут оба:

Vector3.js
Vector3.d.ts

Это дает нам все преимущества TypeScript в качестве дополнительных файлов.

Прямо сейчас есть файл @types/three, но он устарел и поддерживается отдельно, поэтому в нем всегда будут отсутствовать данные.

Основным конкурентом Three.JS является Babylong, он полностью машинописный, и я считаю, что он выигрывает от этого.

Но убить @types/three и интегрировать его как файлы определения типов боковых машин в Three было бы отличным первым шагом.

Нам также нужно интегрировать все примеры в /src с каким-то встряхиванием дерева.

Прямо сейчас структура кода для Three.JS настолько 2014 года, что с ней просто больно работать.

Все примеры?

Примеры/JS

В понедельник, 7 января 2019 г., 10:25 Душан Босняк < [email protected] написал:

Все примеры?

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451970482 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAj6_Q3Kakb5Qn2DqGbMVvLkW_28cOyaks5vA2b5gaJpZM4N9vH8
.

@бхьюстон

Хорошим полушагом к TypeScript будет добавление файлов типов рядом с каждым файлом JavaScript. Таким образом, будут оба:

Vector3.js
Vector3.d.ts

Будут ли файлы .d.ts действовать как файлы .h в c?

Будут ли файлы .d.ts действовать как файлы .h в c?

Это очень хорошая аналогия. Интересно, что кто-то уже сделал большую часть этого здесь: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/three Таким образом, на самом деле он просто взял бы эти файлы типов и интегрировал их в Three.js. Если вы хотите, мы можем создать PR, который интегрирует это в Three.js и разделит его на части.

Чтобы показать, насколько популярен Typescript, посмотрите, сколько @Types/three загружается в неделю:

https://www.npmjs.com/package/@types/three — 63 000 загрузок в неделю.

Впечатляющий!

Если вы хотите, мы можем создать PR, который интегрирует это в Three.js и разделит его на части.

Звучит хорошо для меня 👍

Можно ли запустить проверку командной строки, аналогичную eslint, чтобы убедиться, что файлы типов и исходные файлы .js совпадают? Если мы берем на себя ответственность за файлы d.ts , было бы крайне желательно иметь какой-либо способ регулярно проверять их соответствие.

Чтобы показать, насколько популярен Typescript, посмотрите, сколько @Types/three загружается в неделю:

https://www.npmjs.com/package/@types/three — 63 000 загрузок в неделю.

Я бы приписал это больше популярности кода Visual Studio, потому что это происходит автоматически, когда вы используете код Visual Studio, через их функцию автоматического получения типа.
Тем не менее, это нельзя игнорировать.

@flyover @bunnybones1 @mrdoob @looeee @donmccurdy @bhouston @roomle-build @pkieltyka @FriOne @joejordanbrown , так как вы все, кажется, интересуетесь TypeScript, я хотел бы отметить, что я создал новую проблему, касающуюся TypeScript. Я думаю, имеет смысл перенести туда все обсуждения ТС. Если вам интересно, вы можете найти его здесь: https://github.com/mrdoob/three.js/issues/15545 .

Я готов выделить время для переноса на классы ES6. Я думаю, что это будет хорошим промежуточным решением для поддержки Typescript.

Первый шаг — преобразовать некоторые надстройки в ES6.

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

Контроллеры, загрузчики и экспортеры — хорошие кандидаты. Не стесняйтесь помочь!

@mrdoob просто для подтверждения, вы имеете в виду преобразование их в модули ES, но пока не используете другие функции ES6, верно?

Я предполагаю, что процесс выполнения этого преобразования:

1. Используйте скрипт moduleize.js , чтобы преобразовать исходный файл в модуль ES.
2. При необходимости устраните проблемы.
3. В какой-то момент (в этом выпуске или в ближайшем будущем) мы начнем использовать rollup-examples.config.js для преобразования модулей ES в модули UMD, после чего версия в examples/js больше не поддерживается рука.
4. Как только это станет стабильным, мы сможем рассмотреть другие изменения, такие как введение функций ES6.

@mrdoob просто для подтверждения, вы имеете в виду преобразование их в модули ES, но пока не используете другие функции ES6, верно?

Да извини. Я должен был уточнить.

Я и @bhouston создали обещанный PR, который предоставляет файлы *.d.ts для большей части проекта Three.JS. https://github.com/mrdoob/three.js/pull/15597

Я просто не могу дождаться классов ES6 и определений Typescript. Каждый раз, когда я работаю с three.js, мне приходится копировать сотни строк кода, чтобы заново реализовать одну функцию, лежащую в недоступной области. Это действительно не элегантный способ работы, если вам нужно оптимизировать свои сцены. Это выведет рабочий процесс на новый уровень, чтобы, наконец, появилась возможность расширять и переопределять функции.
Поэтому, пожалуйста, сделайте функции класса как минимум «защищенными» и доступными без исключения 🤗

Каждый раз, когда я работаю с three.js, мне приходится копировать сотни строк кода, чтобы заново реализовать одну функцию, лежащую в недоступной области. ... Поэтому, пожалуйста, сделайте функции класса как минимум «защищенными» и доступными без исключения.

@dionysiusmarquis Я не уверен, что понимаю, что вы здесь имеете в виду ... в существующих типах TS есть функции, которые вы хотите использовать, неправильно помеченные как частные? Или что-то в текущих определениях классов в стиле прототипа трудно использовать в TS? Не могли бы вы поделиться примером?

Каждый раз, когда я работаю с three.js, мне приходится копировать сотни строк кода, чтобы заново реализовать одну функцию, лежащую в недоступной области. ... Поэтому, пожалуйста, сделайте функции класса как минимум «защищенными» и доступными без исключения.

@dionysiusmarquis Я не уверен, что понимаю, что вы здесь имеете в виду ... в существующих типах TS есть функции, которые вы хотите использовать, неправильно помеченные как частные? Или что-то в текущих определениях классов в стиле прототипа трудно использовать в TS? Не могли бы вы поделиться примером?

Я просто хотел реализовать конкретную карту теней для конкретного сценария. Например, было бы полезно иметь возможность переопределить getDepthMaterial . На данный момент я добавляю свои собственные WebGLShadowMap в процесс сборки с копией/вставкой версии, включая желаемые изменения.
Было бы так здорово, если бы каждый отдельный класс three.js открывал как можно больше. С помощью машинописного текста вы можете легко помечать функции как private или protected для описания предполагаемой цели. Мой ES6 Class/Typescript ShadowMap, например, выглядит так:

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 }

Это просто как дома, если вам разрешено изменять классы «низкого уровня».

У меня вопрос в контексте классов. Как бы мы переносили такие методы, как Vector3.unproject , в синтаксис класса? Метод фактически использует замыкание для создания новой области. Это важный механизм, который сводит к минимуму количество создаваемых объектов.

Нужны ли нам Object.assign в этих случаях?
@Mugen87

Теперь вы можете делать замыкания с классами. Просто не очевидно, как ориентироваться в этом синтаксическом сахаре. См. мой ответ на StackOverflow: https://stackoverflow.com/questions/39297258/iife-in-es6-class-literal/56077521#56077521 (должен быть скромным и признать, что я не совсем понимаю, как/почему это работает .)

Извините, но этот код выглядит как антипаттерн и нам не следует адаптировать это в проекте. Существуют правильные решения для управления переменными в области модуля. Предлагаю пойти по этому пути.

@ Mugen87 Mugen87 да, я также думаю, что мы должны эффективно использовать область модуля. Это также помогло бы для таких вещей, как встряхивание дерева. Это уже обсуждалось во многих других проблемах, подобных этой: https://github.com/mrdoob/three.js/issues/6241#issuecomment -398703521.

Извините, но этот код выглядит как антипаттерн и нам не следует адаптировать это в проекте. Существуют правильные решения для управления переменными в области модуля. Предлагаю пойти по этому пути.

Без проблем. Я лишь упомянул возможность. Если у вас есть лучшее/более чистое решение, мне не терпится увидеть его в действии. Проект Three.js (использование, исходный код, обсуждения и т. д.) был моим основным источником знаний о JS, поэтому внедрение новых и лучших шаблонов программирования в Three.js, вероятно, принесет пользу мне и моим проектам. Не о чем сожалеть. ;-)

@ Mugen87 Mugen87 Можете ли вы немного пояснить, почему вы считаете класс IIFE анти-шаблоном, хотя бы для того, чтобы я мог узнать и понять немного больше? Я понимаю, что переменные области видимости модулей по своей природе, но это ничем не отличается от того, как ядро ​​строилось ранее. И с таким количеством функций, использующих переменные кеша, будет очень важно убедиться, что ни одна из функций не сталкивается и не использует переменные одновременно - область действия функции упрощает управление и поддержку, поэтому я не вижу это как анти-шаблон (по крайней мере, по сравнению с броском всех переменных кеша в область модуля).

Не могли бы вы немного пояснить, почему вы считаете класс IIFE анти-паттерном?

Я бы не стал использовать подход, потенциально препятствующий встряхиванию деревьев, как упомянуто здесь: https://github.com/mrdoob/three.js/pull/14695. Кроме того, я думаю, что весь шаблон выглядит как хак. Использование менее «причудливых» подходов обычно работает лучше. Избегание ненужных замыканий также должно улучшить производительность выполнения кода в целом (не могу доказать это ссылкой, но я слышал об этом некоторое время назад).

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

IIFE в основном используются на уроках математики. Поскольку у нас есть большое количество тестов ( @gero3 недавно проделал большую работу, добавив больше модульных тестов), должно быть проще сделать их удаление надежными.

Можно удалить IIFE. Я думаю, что я ответственен за это еще в 2013 году. Это должно было избавиться от шаблона статической переменной, который было трудно поддерживать. Это было сделано в этом PR:

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

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

И обсуждалось еще раньше здесь:

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

Интересный факт: когда мы их вставили, разницы в производительности кода не было.

Я предполагаю, что процесс выполнения этого преобразования:

1. Используйте скрипт moduleize.js , чтобы преобразовать исходный файл в модуль ES.
2. При необходимости устраните проблемы.
3. В какой-то момент (в этом выпуске или в ближайшем будущем) мы начнем использовать rollup-examples.config.js для преобразования модулей ES в модули UMD, после чего версия в examples/js больше не поддерживается рука.
4. Как только это станет стабильным, мы сможем рассмотреть другие изменения, такие как введение функций ES6.

Привет. возможно, пропустил это, но что это были за наши дополнительные шаги к классам?

1. [x] Используйте скрипт moduleize.js для преобразования исходного файла в модуль ES.
2. [x] При необходимости устраните проблемы.
3. [ ] В какой-то момент (в этом выпуске или в ближайшем будущем) мы начнем использовать rollup-examples.config.js для преобразования модулей ES в модули UMD, после чего версия в examples/js больше не будет поддерживаться рука.
4. [ ] Как только это станет стабильным, мы можем рассмотреть другие изменения, такие как введение функций ES6.

На шагах выше мы по существу завершили шаги (1) и (2).

Шаг (3) мы больше не делаем этого, но вместо этого в какой-то момент устарели и удалили папку examples/js (см. https://github.com/mrdoob/three.js/pull/18749) .

Я думаю , это означает, что шаг (4), введение классов ES6 в examples/jsm , может быть выполнен (на данный момент) только для очень немногих примеров, которые не созданы из исходных версий examples/js . Как только examples/js будет удалено, мы сможем сделать все остальное.

^ Но, возможно, я слишком много читаю между строк, может @Mugen87 или @mrdoob могут подтвердить?

IMO, проект должен быть сосредоточен на устаревании и удалении examples/js , чтобы получить кодовую базу только для модулей. На следующем этапе я бы рекомендовал перейти к миграции классов. Начиная с примеров, а затем перенося ядро.

идеально. Спасибо. присмотрюсь к этим путям

Репост из закрытой темы.
Всем привет,

Я хотел создать этот выпуск, чтобы попытаться выяснить все мысли о том, как мы хотели бы двигаться вперед с миграцией классов.

Мое краткое изложение того, с чем я столкнулся до сих пор:

• Мы должны отказаться от папки с примерами, прежде чем делать что-либо еще
• Есть части src/, которые не расширены ни одним из примеров, которые можно было бы преобразовать
• С некоторыми изменениями в скрипте moduleize.js мы могли бы начать с examples/js/, который генерирует соответствующие скрипты examples/jsm.

Я ничего не пропустил?

Мы должны отказаться от папки с примерами, прежде чем делать что-либо еще

Я не уверен, кто отвечает за какой-либо конкретный следующий шаг в папке examples/js . Если мы не сможем сформулировать этот план, я бы предпочел, чтобы это не блокировало преобразование вещей в классы ES. По этой причине я несколько не согласен с https://github.com/mrdoob/three.js/issues/11552#issuecomment -592768708. 🙂

кроме того, кажется, что мы просто ждем , когда будет назначена дата

Кроме того, в рамках небольшого пересмотра, который я сделал, я нашел этот комментарий о том, как другие функции ES2015 могут быть представлены с помощью текущего процесса сборки накопительного пакета. Приведен даже пример .

редактировать: вот суть еще одного быстрого примера

Запустим конверсионный поезд .
Комментарий к зависимостям файлов .

@DefinitelyMaybe У меня есть немного времени, и я бы хотел помочь. Могу ли я взять некоторые предметы из списка dependencies.json ?

👍

давайте назовем бабки на вещи

@DefinitelyMaybe Как лучше всего справиться с наследованием от глубокого предка, такого как Object3D ? Например, я столкнулся с поломкой при преобразовании 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

мы собирались сделать пометку в верхней части файла о любых проблемах, с которыми мы столкнулись, если я правильно помню.

Я неправильно понял, что происходит с AudioListener... После некоторой отладки я думаю, что в преобразовании bubleCleanup возникла проблема соответствия. См. https://github.com/mrdoob/three.js/pull/19934#issuecomment -667411997 для получения дополнительной информации. Я столкнулся с этим с несколькими разными классами, поэтому нам, вероятно, придется разобраться, прежде чем идти дальше.

это будет иметь место для некоторых файлов, но не для всех. Мы предвидели такую ​​проблему.

Для тех, кто следит за этим, пожалуйста, быстро прочитайте обсуждение здесь .

А пока ставлю src/loaders !