Three.js: ES6クラスを評価する

では、代わりにこのパターンを使用することを提案していますか？

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

class PointLight extends Light

hehe😄そして問題ありません...

@ sasha240100いつか...

@mrdoobは完全ではありません-あなたが言及する2つの方法は直接同等です。 OPは比較していると思います

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 };

ES2015 +。 同じコードですが、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;
  }
}

three.jsコードを簡素化するES6の機能：

• デフォルトのパラメータ値。
  
  
  
  • コードのそのような部分を簡単に置き換えることができます
  
  
• プロパティの省略形
  
  
  
  • ここで使用できます
  
  
• 矢印機能
  
  
  
  • https://github.com/mrdoob/three.js/blob/dev/src/loaders/JSONLoader.js#L36
  
  

ES2015 +に移行することにしました。現在のコードと同様のコードを出力する方法を見つける必要があるだけなので、すべての場合でパフォーマンスは同じままです。

クラスの文脈で質問があります。 Vector3.unprojectのようなメソッドをクラス構文にどのように転送しますか？ このメソッドは、実際には、新しいスコープを作成するためにクロージャを使用します。 これは、オブジェクトの作成量を可能な限り少なく保つ重要なメカニズムです。

このような場合、 Object.assignが必要ですか？

@ Mugen87 @ mrdoobes6のパフォーマンスに関する興味深い情報。 特にObject.assign ：

この記事から

Vector3.unprojectのようなメソッドをクラス構文にどのように転送しますか？ このメソッドは、実際には、新しいスコープを作成するためにクロージャを使用します。

@ Mugen87エクスポートされていないモジュールスコープのオブジェクトだけではいけませんか？ このようなもの;

const tempMatrix = new Matrix();    

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

はい、これでうまくいくと思います😊

先月、これはツイッターで提案されました：

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

@mrdoobうわー！ すでに機能しているようです。 ブランチを作成し、いくつかのクラスをes6に変換して、それがどのようにコンパイルされるかを確認することはできませんか？

@ satori99グローバルの問題を回避するためにVector3コード内にtempMatrixを保持する方法のアイデアとして：

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

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

@mrdoobうわー！ すでに機能しているようです。 ブランチを作成し、いくつかのクラスをes6に変換して、それがどのようにコンパイルされるかを確認することはできませんか？

いいですね！ 私は現在WebVRに焦点を合わせているので、それは私以外の誰かである必要があります。

@ sasha240100モジュールスコープの変数を使用する利点は、それらが通常のユーザーコードから隠されたままになることです。これは、一時変数に適しているようです。

プライベート変数に関しては、「私たちはすべてここで大人です」というpythonisticアプローチを気にしませんが、一時変数が名前空間を不必要に汚染することはありません。

また、ブラウザでネイティブモジュールのサポートを有効にしている人がsrcファイルを直接ロードできると便利です。 これは、ウォッチャーを必要とせず、編集のたびにトランスパイルすることなく、開発するためのはるかに快適な方法です。 クラスプロパティを使用するということは、それらが現在のクラス仕様の一部ではないため、これが不可能であることを意味します。

お詫び申し上げます。スレッドが完全に異なるものに変更されたため、おそらく問題のタイトルを「ES6クラスの評価」のようなものに変更する必要があります。

なぜパターンを変更するのですか@ Mugen87 @ satori99 ？

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

typescriptを試してみませんか。他のバージョンのjsにコンパイルできます。

TypeScriptは、トランスパイラー+タイプチェッカーであり、JavaScriptのスーパーセットであるため、考えるのに最適なオプションです。コードベースを.tsファイルに移動し、タイプチェックを使用してES6に徐々にリファクタリングするのは簡単です。

TypeScriptを使用したことがない場合は恐ろしいように聞こえるかもしれませんが、実際には大きな学習曲線ではなく、それがもたらすメリットを支払うのに少額の費用がかかります。 TypeScriptコミュニティは、この移行を支援し、現在のライブラリに対してパフォーマンステストを作成して、ライブラリがダウングレードされていないことを確認できることを非常に喜んでいます。

いくつかの有用な記事：

• TypeScriptを怖がってはいけない理由
• TypeScript vs ES6 vs ES2015
• TypeScriptが勝ちました
• TypeScriptとは何ですか？AndersHejlsbergを使用する理由

コア開発者のAndersHejlsbergの言葉を引用すると、TypeScriptは、JavaScriptが大規模なアプリケーションに適していないというクライアントや内部チームからの苦情に応えて生まれました。

目標は、オープンスタンダードとクロスプラットフォームであるという利点を犠牲にすることなく、「クラス、モジュール、静的型付けなどでJavaScriptを強化する」ことでした。 その結果、言語のスーパーセットとして構築された「アプリケーションスケールのJavaScript開発用言語」が生まれました。

ブラウザがTypeScriptをネイティブに実行できるようになるまで、私はJavaScriptを使い続けることを好みます。

@mrdoob

TypeScriptをブラウザで直接実行できないという理由だけで使用しない正当な理由として、それを理解することはできません。 コンパイル時のチェックのみを目的とした余分なコード行があるため、ブラウザーで実行することは望ましくありません。 現在、ランタイムチェック言語ではありません。 したがって、ブラウザで使用されたことがあれば、パフォーマンスに影響を与えるため、入力されたコードがすべて削除される可能性が高く、これはバニラJavaScriptコードになります。

型付き言語を使用することのポイントと、大規模なコードベースでの開発におけるその利点を完全に見逃していると思います。 あなたはまだJavaScriptを作成して使用していますが、TypeScriptの要点は、JavaScriptのスーパーセットであるということです。 コンパイラオプションで構成可能な指定されたECMAScriptターゲットバージョンでJavaScriptにコンパイルされるタイプを使用してJavaScriptを記述します。許可される値は、「es3」、「es5」、「es2015」、「es2016」、「es2017」、または「」です。 esnext '。

TypescriptはJavaScriptであるため、一度にすべてをリファクタリングするという大きな頭痛の種を抱えることなく、段階的に移行することができます。 それはコミュニティによって徐々に行われ、改善される可能性があります。 ES6クラスを使用するためのリファクタリングについてここで説明していること以上の作業はありません。 それが、新しい問題を開く代わりに、ここで言及する唯一の理由です。

優れた例については、以下のTypeScriptプレイグラウンドリンクを参照してください。

• 古典的なJavaScriptの例
• タイプの追加の例
• エラーのあるタイプの追加例
• クラスの使用例
• エラーのあるクラスの使用例

@joejordanbrown

タイプスクリプトがこの特定の問題に対する最良の解決策であるということについて、あなたに同意できない可能性のある人を思い浮かべることができますか？

グーグルにtypescript vsと入力すると、いくつかの用語がポップアップ表示されます。そのうちの1つはフローです。 それを検索すると、人々がこれら2つの長所と短所について議論している多くの記事が得られるようです。

これらのいずれかを選択することほど妥協のように思われるタイプはありません。

作成した結果よりも複雑なプロジェクトのTypescriptを保存します。特に、最初からHTMLで実装できたフロントエンドフレームワークです。 私の当初のポイントは、JavaScriptの病気を取り除くことであり、悪化させることではありませんでした。 JavaScriptは単純なほとんどおもちゃの言語であり、three.jsのような複雑な結果に使用されることがあります。 Typescriptは無意味です。

2017年9月6日午後1時55分、 Joenotifications @ github.comは次のように書いています。

@mrdoob

TypeScriptをブラウザで直接実行できないという理由だけで使用しない正当な理由として、それを理解することはできません。 コンパイル時のチェックのみを目的とした余分なコード行があるため、ブラウザーで実行することは望ましくありません。 現在、ランタイムチェック言語ではありません。 したがって、ブラウザで使用されたことがあれば、パフォーマンスに影響を与えるため、入力されたコードがすべて削除される可能性が高く、これはバニラJavaScriptコードになります。

型付き言語を使用することのポイントと、大規模なコードベースでの開発におけるその利点を完全に見逃していると思います。 あなたはまだJavaScriptを作成して使用していますが、TypeScriptの要点は、JavaScriptのスーパーセットであるということです。 コンパイラオプションで構成可能な指定されたECMAScriptターゲットバージョンでJavaScriptにコンパイルされるタイプを使用してJavaScriptを記述します。許可される値は、「es3」、「es5」、「es2015」、「es2016」、「es2017」、または「」です。 esnext '。

TypescriptはJavaScriptであるため、一度にすべてをリファクタリングするという大きな頭痛の種を抱えることなく、段階的に移行することができます。 それはコミュニティによって徐々に行われ、改善される可能性があります。 ES6クラスを使用するためのリファクタリングについてここで説明していること以上の作業はありません。 それが、新しい問題を開く代わりに、ここで言及する唯一の理由です。

例については、TypeScriptプレイグラウンドのリンクを参照してください。

古典的なJavaScriptの例
タイプの追加の例
エラーのあるタイプの追加例
クラスの使用例
エラーのあるクラスの使用例
—
スレッドを作成したため、これを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

^一貫している限り、巨大なパターンでも大丈夫です。

@joejordanbrownは、typescriptが大好きなようです。 プロジェクトをフォークして、typescriptに移植してください。 three.ts！ 🙌

@pailhead

それは選択の問題です、私は多くの人が賛成と反対をするだろうと確信しています、それは正しいですが正常です！ あなたはいつも「これ対あれ」、「私のものはあなたのものよりも優れている」を見るでしょう。 それぞれに独自のメリットがあることを理解しています。 それは、利用可能なオプションを比較検討し、それらがプロジェクトに利益をもたらすことができるかどうかを確認することです。 比較は良いことです、それはプロジェクトをさらに推し進めます。

あなたはフローについて言及します、それに関して私が見る問題は次のとおりです：

• フローライセンスはBSD3条項「 FacebookBSD +特許ライセンス」であり、Apache SoftwareFoundationは新しいプロジェクトでのこのライセンスの使用を禁止しました。 詳細については、こちらをご覧ください。

• TypeScriptと比較してIDEサポートが不足しています。

• TypeScriptに比べてユーザーベースは小さいですが、

• 公共図書館で利用できるタイピングは不完全であり、TypeScriptにはよく管理されたタイピングがたくさんあります。

• ドキュメントとリソースは見つけるのが難しく、TypeScriptと比較するとあいまいです。優れたドキュメント、書籍、ビデオ、その他の多くのeラーニングリソースがあります。

• Flowは// @flowのフラグが付いた.jsファイルを使用します。 .js拡張子が表示されるため、これは混乱を招く可能性があります。JavaScriptを期待しますが、実際にはFlowTypeです。 TypeScriptは独自の拡張子.tsを使用しますが。 これにより、同じディレクトリに同じ名前のTypeScript出力ファイルとJavaScript出力ファイルを含めることもできます。これは、ビルドを使用するため、大規模なプロジェクトには当てはまらない、小さなプロジェクトには理想的です。ビルドプロセスを管理するシステム。

グーグルでさえTypeScriptを大いに支持しており、それは彼らがTypeScriptに自信を持っていることを示しています。 ここまたはここの投稿を読んでください。

Typescriptは、2017年3月に無制限のクライアント開発が可能になりました。TypeScriptとAngular on TypeScriptは、Google Analytics、Firebase、Google Cloud Platform、およびバグトラッキング、従業員レビュー、製品承認および起動ツールなどの重要な内部ツールで使用されます。

型付き言語の使用についてのディスカッションを開き、他の人がそのアイデアについてどう思っているかを確認したいと思いました。 @mrdoobは、アイデアについて話し合うことすら完全に反対しているようです。

@arctwelve
このプロジェクトがどのように複雑でなく、型付き言語を使用するとプロジェクトに悪影響が及ぶかはわかりません。

@mrdoob
まったくそうではありませんが、ES6クラスに更新するために新しいブランチが作成されている場合は特に、そのメリットを確認できます。 three.tsと呼ばれる独自のフォークを作成して答えるのはばかげていると思います。 1つのプロジェクトに焦点を合わせて最高のものにするのではなく、誰もがOSSプロジェクトをフォークして独自のソースコードを変更しただけの場合、これはOSSの優れた慣行に反します。 どういうわけか、本当に貧弱なソフトウェアやコミュニティが分割され、彼らが好むプロジェクトに集中することになります。 なぜあなたは賛否両論についてオープンな議論をすることができないのですか？

悪魔の代弁者を演じないでください、しかし彼がしたようです

オープンディスカッション

本当に短かったです:)

私も同じような見方をしています。それはJSライブラリであり、JSは標準化されています。 JSライブラリにJSを選択することは間違いありませんが、他の何かを選択する場合は間違いありません。 私は、Typescriptの代替手段の1つとしてFlowを採用しましたが、他にある場合はわかりません。

とにかく、私たちは本当に話題から外れたようです。

Mugen87はタイトルをから変更しました
ES6クラスを評価するためにJavaScriptの病気を削除します

元のタイトルは（私が理解している限り）スタイルの一貫性の欠如に言及していました。 特に、ある場所ではObject.assign()を使用し、他の場所では別のパターンを使用します。
ここで何かを評価すると、それが問題の現在のタイトルになります。 一貫性の問題が新しい言語の使用についての議論に引き上げられるのはなぜですか？

typescriptとes6の両方で、コードはかなり一貫しているはずだと思います。

このページを更新することで、この問題に対処します。

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

そして、次のいずれかを追加します。

A）「... Object.assign ...を使用してください」
B）「... Object.assignを使用しないでください」

ライブラリ全体で1つのスタイル。 変更する必要はありません。

たとえば、Materialsクラスの忠実な2行スタイルは、はるかに明確でクリーンです。

それは最初の投稿にあります。

私は提案します：

1. この文を反映するようにタイトルを編集し、ライブラリ全体で1つのスタイルを使用すること、スタイルガイドを編集することなどについて話し合います。
2. 「es6クラスの評価」というタイトルの新しいディスカッションを開始します。ここで、es6クラスが評価されます。
3. 「3つを型付き言語で書いていることを評価する」というタイトルの新しいディスカッションを開始します。ここでは、typescriptなどがディスカッションされます。

とにかく、私たちは本当に話題から外れたようです。

それはそう。 @joejordanbrownは、TypeScriptについて議論するための新しいトピックを自由に作成してください。

ところで、以前の会話を無視することもOSSの悪い習慣です... https：//github.com/mrdoob/three.js/issues/341#issuecomment -47000692

トピックに戻ります。 私たちはすでにこの問題を解決したと思いましたか？

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

試してみる人が必要です。

わかりました...まず第一に

最初のパターン（最高のIMO）：

function MyClass() {...}

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

    constructor: MyClass,

    prop1: 'something',

    method1: function someFunction() { .. },

    ...

});

2番目のパターン：

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の多くの行で継承されたオブジェクトを失うことはできません。
第二に、多重継承の場合、これもはるかに明確です。
第三に、クラスのコンストラクターは読み取り可能であり、最初のポイントのように多くの行で失われることはありません。
第4に、これにより、プロパティとメソッドを同じ場所（角かっこ内）にグループ化できます。これは、同じファイルに3、4、5 ...などのクラスがある場合に非常に明確になります。
第5に、このパターンにより、いくつかの「継承された」プロパティの正しいコピーをチェックできます。

最後に（ @looeee ）、これもパフォーマンスのためです。 最初のバージョンは、プロトタイプへの複数回の呼び出しではなく、ファイル解析が発生したときにさらに最適化されます。

ともかく ！

今日は、ES6構文に渡す必要があります！

@mrdoob

いいですね！ 私は現在WebVRに焦点を合わせているので、それは私以外の誰かである必要があります。
試してみる人が必要です。

es6ブランチを作成しますか？ それとも私たち自身ですか？

最初のバージョンは、プロトタイプへの複数回の呼び出しではなく、ファイル解析が発生したときにさらに最適化されます。

よろしいですか？ Object.Assignは、どちらかといえば遅くなると思います。 しかし、どちらの場合でも、心配するのに十分なパフォーマンスのオーバーヘッドがあるとは思えません。

絶対に： https ：//jsperf.com/inline-prototype-vs-assign-prototype/1

chromeバージョン61.0.3163.100（Build officiel）（64ビット）で割り当てられたプロトタイプは約60％高速です

面白い。 テストをしてくれてありがとう。

ただし、その結果はすべてのブラウザに当てはまるわけではありません。 Firefoxではそれらはほぼ同じです（ Object.Assign 〜3％速い）が、EdgeではObject.Assignは〜33％遅くなります。

しかし、いずれにせよ、これはどのスタイルが優れているかについての議論としてはまだ適切ではないと思います-全体的に最も遅い（Chromeのインラインプロト）でも、1秒あたり18万回以上の操作で実行されており、おそらく数千回の操作がありますこれらの設定はコードで行われます。 したがって、ここではおそらく数ミリ秒の違いについて話しているのでしょう。

私にとって、 Object.Assignスタイルはよりクリーンで読みやすく、それがそれを支持する主な議論です。

はい、これはファイルあたり約数ミリ秒であり、ファイルがjavascriptエンジンによって初めて解析される場合のみです...しかし、threejsのような大きなライブラリの場合、ページの読み込み時にゲインは約200ミリ秒になる可能性があります。
これ以上待つことができないフロントユーザーのための3scdの制限を忘れないでください！

私はthreejsでAngularプロジェクトを作成しようとしていますが、常にthreejsのすべての部分をハッキングしているように見えます。
まず第一に、たとえばOrbitalControlsが必要な場合に存在しなければならないのは、3つの定数を持つes5構文です。
threejsタイピングがありますが、同じパッケージに入れる方が便利です。 タイピングにはOrbitalControlsがありますが、 import { OrbitalControls } from 'three;のように単純にインポートすることはできません。
Webpackにはツリーの揺れがあるため、es6の場合、必要なものをすべて1つのプロジェクトに含め、それらを別々のプロジェクトに移動しないようにすることができます。
@mrdoobでは、なぜTypescriptがそれほど悪いのでしょうか。 とにかくタイピングを使用して、任意のバージョンのESにコンパイルされます。
また、Reactのような他の多くのフレームワークでも使用されます。

@FriOne @mrdoobがTypescriptが本当に悪いと思っているかどうかはわかりませんが、このスレッドのトピックではないため、この問題/スレッドでTypescriptについて議論することに反対していると思います。 ES6クラスはTypescriptに対して、またはTypescriptに対しては機能しないと思います。 コードベースをES6に変換すると、構文が非常に似ているため、コードベースをTypescriptに移植するのがさらに簡単になります。 はい、Typescriptは多くの新しいオプションを有効にできると思います。 たとえば、より最適化されたコードを「トランスパイル」するのに役立ち、新しい開発者がライブラリをより速く学習するのに役立ちます。たとえば、 https：//github.com/AssemblyScript/assemblyscriptのように、将来の実験への扉が開かれるかもしれません。 Typescript @ joejordanbrownが長所を詳細に説明したことには多くの利点があると思います。

しかし、トピックに戻ります。ES6クラスを採用することは一歩前進であり、その後、Typescriptについて議論することができます。 では、次々と一歩進んでいきましょう

@ tschoartschi 、typescriptがes6クラスへの移行やその他のリファクタリングに役立つと思います。 私はそのような移行の経験がありません、それは私が間違っているかもしれません。

@FriOne依存します😉もちろん、コンパイラはすべてのエラーや間違いを教えてくれるので、Typescriptは役に立ちますが、Typescriptを使用するには、最初にビルドパイプ全体を設定する必要があります。 さらに、Typescriptが適切かどうかを評価する必要があります。 最初にES6クラスに変換してから、Typescriptについて考えるのは問題ないと思います。

ねえ、私たちはKTHの5人の学生のグループで、コースのオープンソースプロジェクトに貢献したいと考えており、プロジェクトの一部を新しいES6構文に変換してみたいと考えています。

概念実証として、Three.jsをいくつかの例とともにTypeScript（r82）に移植しました。

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

TypeScriptソースはオンザフライでトランスパイルされるため、例のロードには少し時間がかかります。 トランスパイルされたJavaScriptを使用すると、元のJavaScriptと同じ速度でロードされます。

three.jsがtypescriptに移植されるのを見たいです。 次のウェブ世代のために時の試練に耐えたいのであれば、プロジェクトを近代化する必要があると私は感じています。 ある日、AssemblyScriptで動作し、WASMで実行されることさえあるかもしれません。 threejsでなければ、他の何かがきっとそうなるでしょう。

これは@WestLangleyと@mrdoobで完了します

@bhoustonここでの結論は何ですか？

@pkieltykaはい、TypeScriptはThree.jsのようなライブラリにとって非常に理にかなっていると思います。 すべての技術的な専門家に加えて、ライブラリの使用を容易にし、初心者がAPIを探索するのに役立ちます。 しかし、最初にすべてのES6スタッフを終了してから、TypeScriptを検討することも重要だと思います。 最新のJavaScriptから、TypeScriptの形式で型を追加するのはそれほど複雑ではないと思います。

@flyover niceも、TypeScriptバージョンのThree.jsの概念実証を参照してください。 Three.jsのメンテナからフィードバックをもらいましたか？

three.jsのtypescriptもサポートしています。 typescirptは基本的に最高です
練習と生のJavaScriptはもうありません。

2019年1月5日土曜日、午前4時13分tschoartschi < [email protected]は次のように書いています。

@pkieltykahttps ：//github.com/pkieltykaはい私もTypeScriptだと思います
Three.jsのようなライブラリにとっては非常に理にかなっています。 すべての横に
技術的な専門家はまた、ライブラリの使用を容易にし、初心者を助けます
APIを探索します。 しかし、ES6をすべて完成させることも重要だと思います
最初に詰め込み、次にTypeScriptを検討します。 最新から思う
JavaScriptTypeScriptの形式で型を追加するのはそれほど複雑ではありません。

@flyover https://github.com/flyoverも、概念実証を参照してください。
Three.jsのTypeScriptバージョン。 メンテナからフィードバックをもらいましたか
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リファクタリングが終了した後ではなく、「ビッグバン」の書き換えは必要ありません。

TypeScriptに対する@mrdoobのスタンスが変わったかどうか聞いてみると面白いでしょう。 TypeScriptは「型付きJavaScript」の「デファクト」スタンダードになっているようです（これは難しい事実ではないので、私の主張をアポストロフィの下に置いていることに注意してください）

最初のステップは、ES6機能、特にクラス、矢印関数、「let」、および「const」を採用することです。

@ roomle-buildが指摘しているように、必要に応じてES6コードの上にタイプスクリプト機能を段階的に追加するのは簡単なので、タイプスクリプトのサポートについて適切に話し合うことができます。

両方を同時に行うと、物事が複雑になりすぎるように思えます。

TypeScriptが将来のある時点でオプションになる可能性があると聞いてうれしいです： -）@ flyoverによって行われた作業の一部を再利用できるかもしれません

しかし、私は@looeeeに完全に同意し、最初にすべてのES6を完了してから、次のステップに集中します。

ES6のものをすべて終了する

少なくとも始められたら嬉しいです😅

TypeScript woudlへの良い中間ステップは、すべてのJavaScriptファイルの横にタイプファイルを追加することです。 したがって、次の両方があります。

Vector3.js
Vector3.d.ts

これにより、サイドカーファイルとしてのTypeScriptのすべての利点が得られます。

現在、@ types / threeファイルがありますが、古く、個別に管理されているため、常にデータが不足しています。

Three.JSの主な競争相手はBabylongであり、完全にタイプスクリプトであり、これから恩恵を受けると私は信じています。

しかし、@ types / threeを削除し、サイドカータイプ定義ファイルをThreeに統合することは、すばらしい最初のステップです。

また、ある種のツリーシェイクを使用して、すべての例を/ srcに統合する必要があります。

現在、Three.JSのコード構造は2014年なので、作業するのが面倒です。

すべての例？

例/ js

2019年1月7日月曜日、午前10時25分Dusan Bosnjak < [email protected]は次のように書いています。

すべての例？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451970482 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAj6_Q3Kakb5Qn2DqGbMVvLkW_28cOyaks5vA2b5gaJpZM4N9vH8
。

@bhouston

TypeScript woudlへの良い中間ステップは、すべてのJavaScriptファイルの横にタイプファイルを追加することです。 したがって、次の両方があります。

Vector3.js
Vector3.d.ts

.d.tsファイルはcの.hファイルとして機能しますか？

.d.tsファイルはcの.hファイルとして機能しますか？

これは非常に良い例えです。 興味深い人は、これのほとんどをすでにここで行っています： https ：//github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/threeしたがって、実際には、これらのタイプファイルの所有権を取得してThree.jsに統合するだけです。 必要に応じて、これをThree.jsに統合し、適切に分割するPRを作成できます。

Typescriptがどれほど人気が​​あるかを示すには、1週間にダウンロードされる@ Type / 3の数を確認します。

https://www.npmjs.com/package/@types/three-1週間あたり63,000ダウンロード。

印象的！

必要に応じて、これをThree.jsに統合し、適切に分割するPRを作成できます。

私にはいいですね👍

eslintと同様に、タイプファイルとソース.jsファイルが整列していることを確認するコマンドラインチェックを実行することは可能ですか？ d.tsファイルの所有権を取得する場合は、それらが一致することを定期的に確認する方法を用意することを強くお勧めします。

Typescriptがどれほど人気が​​あるかを示すには、1週間にダウンロードされる@ Type / 3の数を確認します。

https://www.npmjs.com/package/@types/three-1週間あたり63,000ダウンロード。

これは、Visual Studio Codeを使用すると、自動タイプ取得機能を介して自動的に行われるため、Visual StudioCodeの人気に起因すると考えられます。
とはいえ、無視することはできません。

@flyover @ bunnybones1 @mrdoob @looeee @donmccurdy @bhouston @ roomle-build @pkieltyka @FriOne @joejordanbrown皆さんはTypeScriptに興味を持っているようですので、TypeScriptに関する新しい問題を作成したことに注意してください。 TSのすべての議論をそこに移すことは理にかなっていると思います。 興味がある場合は、 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. Modularize.jsスクリプトを使用して、元のファイルをESモジュールに変換します。
2. 必要に応じて問題をクリーンアップします。
3. ある時点（このリリース、または近い将来）で、 rollup-examples.config.jsを使用してESモジュールをUMDモジュールに変換し始めます。この時点で、 examples/jsのバージョンはによって維持されなくなります。手。
4. それが安定したら、ES6機能の導入などの他の変更を検討できます。

@mrdoobは確認のために、それらをESモジュールに変換することを意味しますが、他のES6機能はまだ使用していません。

ええ、ごめんなさい。 指定すべきだった。

私と@bhoustonは、ほとんどのThree.JSプロジェクトの* .d.tsファイルに貢献する約束されたPRを作成しました。 https://github.com/mrdoob/three.js/pull/15597

ES6クラスとTypescript定義が待ちきれません。 three.jsを使用するたびに、アクセスできないスコープにある1つの関数を再実装するために、数百行のコード行をコピーして貼り付ける必要があります。 シーンを最適化する必要がある場合、これは実際にはエレガントな作業方法ではありません。 最終的に関数を拡張およびオーバーライドできるようになるには、ワークフローが新しいレベルになります。
したがって、クラス関数を少なくとも「保護」し、例外なくアクセスできるようにしてください🤗

three.jsを使用するたびに、アクセスできないスコープにある1つの関数を再実装するために、数百行のコード行をコピーして貼り付ける必要があります。 ...したがって、クラス関数を少なくとも「保護」し、例外なくアクセスできるようにしてください。

@dionysiusmarquisここでの意味がわかりません...既存のTSタイピングには、使用したい関数が誤ってプライベートとしてマークされていますか？ または、現在のプロトタイプスタイルのクラス定義について、TSで使用するのは難しいですか？ 例を教えていただけますか？

three.jsを使用するたびに、アクセスできないスコープにある1つの関数を再実装するために、数百行のコード行をコピーして貼り付ける必要があります。 ...したがって、クラス関数を少なくとも「保護」し、例外なくアクセスできるようにしてください。

@dionysiusmarquisここでの意味がわかりません...既存のTSタイピングには、使用したい関数が誤ってプライベートとしてマークされていますか？ または、現在のプロトタイプスタイルのクラス定義について、TSで使用するのは難しいですか？ 例を教えていただけますか？

特定のシナリオに対して特定のシャドウマップを実装したかっただけです。 たとえば、 getDepthMaterialをオーバーライドできると便利です。 現時点では、ビルドプロセスに自分のWebGLShadowMapを挿入し、必要な変更を含むコピー/貼り付けバージョンを使用しています。
すべてのthree.jsクラスが可能な限り公開されるといいですね。 typescriptを使用すると、関数にprivateまたはprotectedのフラグを付けて、目的を簡単に説明できます。 たとえば、私のES6クラス/ TypescriptShadowMapは次のようになります。

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はい私もmodule-scopeをうまく利用すべきだと思います。 これは、ツリーの揺れなどにも役立ちます。 これは、このような他の多くの問題ですでに議論されています： https ：//github.com/mrdoob/three.js/issues/6241#issuecomment -398703521

申し訳ありませんが、このコードはアンチパターンのように見えるため、プロジェクトでこれを適応させるべきではありません。 モジュールスコープで変数を管理するための適切なソリューションがあります。 このルートに行くことをお勧めします。

問題ない。 可能性について触れました。 より良い/よりクリーンなソリューションが進行中の場合、私はそれが実際に動作するのを見たいと思っています。 Three.jsプロジェクト（使用法、ソース、ディスカッションなど）はJSの知識の主な情報源であるため、Three.jsに新しくより優れたプログラミングパターンを導入することは、私と私のプロジェクトにも役立つでしょう。 申し訳ありません。 ;-)

@ 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. Modularize.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の非推奨と削除に焦点を当てる必要があります。 次のステップでは、クラスの移行に進むことをお勧めします。 例から始めて、コアを移行します。

完全。 ありがとうございます。 それらの方法を詳しく見ていきます

クローズされた問題から再投稿されました。
やあ、

この問題を作成して、クラスの移行をどのように進めたいかについて、皆さんの考えを引き出してみたかったのです。

私がこれまでに遭遇したことの簡単な要約：

• 他のことをする前に、examplesフォルダーを廃止する必要があります
• 変換できる例のいずれによっても拡張されていないsrc /の部分があります
• Modularize.jsスクリプトにいくつかの変更を加えることで、対応するexamples / jsmスクリプトを生成するexamples / js /を開始できます。

私は何かを逃したことがありますか？

他のことをする前に、examplesフォルダを廃止する必要があります

examples/jsフォルダーの特定の次のステップの責任者がわかりません。 その計画を明確に表現できない限り、ESクラスへの変換を妨げないようにしたいと思います。 そのため、 https： //github.com/mrdoob/three.js/issues/11552#issuecomment-592768708には多少同意しません。 🙂

さらに、日付が設定されるのを待っているようです。

また、私が行った少しの改訂の一環として、現在のロールアップビルドプロセスを介して他のES2015機能をどのように導入できるかについてのこのコメントを見つけました。 与えられた例さえあります。

編集：ここに別の簡単な例の要点があります

変換トレインを開始しましょう。
ファイルの依存関係のコメント。

@Definitelyたぶん私には時間があり、助けたいと思っています。 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

Imが正しく覚えていれば、遭遇した問題についてファイルの先頭にメモをとるつもりでした。

AudioListenerで何が起こっているのか誤解しました...デバッグした後、 bubleCleanupトランスフォームに一致する問題があると思います。 詳細については、 https： //github.com/mrdoob/three.js/pull/19934#issuecomment-667411997を参照してください。 私はいくつかの異なるクラスでこれに遭遇したので、さらに先に進む前に、おそらくそれをソートする必要があります。

これは一部のファイルに当てはまりますが、すべてではありません。 私たちはそのような問題を予期していました。

以下の方は、こちらのディスカッションをお読みください。

それまでの間、 src/loadersを試してみてください。