Three.js: Evaluasi kelas ES6

Jadi Anda menyarankan menggunakan pola ini saja?

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

class PointLight extends Light

hehe Dan tidak ada masalah...

@sasha240100 suatu hari nanti...

@mrdoob tidak cukup - dua cara yang Anda sebutkan secara langsung setara. Saya pikir OP membandingkan

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

dengan

function PointLight () { ... };

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

PointLight.prototype.constructor = PointLight;

PointLight.prototype.prop1 = 'something';

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

...

Yang merupakan cara itu dilakukan di sini misalnya.
Sejauh yang saya bisa melihat gaya ini setara - apakah ada sesuatu yang saya lewatkan?
Atau apakah gaya diubah untuk menggunakan Object.Assign setelah tersedia dan tidak diperbarui di seluruh basis kode?

@looeee @bfred-it @mrdoob Mengapa tidak menggunakan rollup-babel saja?

Perbandingan :
Saat ini. modul harmoni 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+. Kode yang sama, tetapi es2015+ dengan 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;
  }
}

Fitur ES6 yang akan menyederhanakan kode three.js:

• Nilai parameter default.
  
  
  
  • Dapat dengan mudah mengganti bagian kode tersebut
  
  
• Singkatan properti
  
  
  
  • Bisa digunakan disini
  
  
• Fungsi panah
  
  
  
  • https://github.com/mrdoob/three.js/blob/dev/src/loaders/JSONLoader.js#L36
  
  

Saya siap untuk pindah ke ES2015+, kami hanya perlu menemukan cara untuk menghasilkan kode yang serupa dari yang kami miliki saat ini, sehingga kinerjanya tetap sama dalam semua kasus.

Saya punya pertanyaan dalam konteks kelas. Bagaimana kita mentransfer metode seperti Vector3.unproject ke dalam sintaks kelas? Metode ini sebenarnya menggunakan penutupan untuk membuat ruang lingkup baru. Ini adalah mekanisme penting yang menjaga jumlah kreasi objek serendah mungkin.

Apakah kita membutuhkan Object.assign dalam kasus ini?

@Mugen87 @mrdoob Beberapa info menarik tentang kinerja es6. Terutama pada Object.assign :

Dari artikel ini

Bagaimana kita mentransfer metode seperti Vector3.unproject ke dalam sintaks kelas? Metode ini sebenarnya menggunakan penutupan untuk membuat ruang lingkup baru.

@ Mugen87 Tidak bisakah mereka menjadi objek cakupan modul yang tidak diekspor? Sesuatu seperti ini;

const tempMatrix = new Matrix();    

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

Ah ya, saya pikir ini harus berhasil 😊

Bulan lalu ini disarankan di twitter :

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

@mrdoob Wow! Sepertinya sudah bekerja. Tidak bisakah kita membuat cabang, mengubah beberapa kelas menjadi es6 dan melihat bagaimana kompilasinya?

@satori99 Sebagai gagasan tentang cara menyimpan tempMatrix di dalam kode Vector3 untuk menghindari masalah dengan global:

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

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

@mrdoob Wow! Sepertinya sudah bekerja. Tidak bisakah kita membuat cabang, mengubah beberapa kelas menjadi es6 dan melihat bagaimana kompilasinya?

Kedengarannya bagus untuk saya! Saat ini saya berfokus pada WebVR sehingga harus orang lain selain saya.

@sasha240100 Manfaat menggunakan modul scoped vars adalah mereka tetap tersembunyi dari kode pengguna biasa, yang tampaknya sesuai untuk variabel temp.

Saya tidak keberatan dengan pendekatan pythonistic "Kita semua dewasa di sini" sehubungan dengan vars pribadi, tetapi variabel temp seharusnya tidak benar-benar mencemari namespace secara tidak perlu.

Juga, Alangkah baiknya jika kita yang telah mengaktifkan dukungan modul asli di browser kita dapat memuat file src secara langsung. Ini adalah cara yang jauh lebih menyenangkan untuk dikembangkan, tanpa perlu pengamat dan transpiling setelah setiap pengeditan. Menggunakan properti kelas berarti ini tidak mungkin karena mereka bukan bagian dari spesifikasi kelas saat ini.

Maaf karena ikut campur. Kami mungkin harus mengubah judul masalah menjadi sesuatu seperti - "Evaluate ES6 class", karena sekarang utasnya telah berubah menjadi sesuatu yang sama sekali berbeda.

Mengapa mengubah pola @Mugen87 @satori99 ?

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

Mengapa tidak mencoba TypeScript, itu dapat dikompilasi ke dalam versi js lainnya

TypeScript benar-benar akan menjadi pilihan yang bagus untuk dipikirkan karena ini adalah transpiler + pemeriksa tipe dan superset JavaScript, jadi mudah untuk memindahkan basis kode ke file .ts dan secara bertahap refactor ke ES6 dengan pemeriksaan tipe.

Mungkin terdengar menakutkan jika Anda belum pernah menggunakan TypeScript, tetapi sebenarnya ini bukan kurva pembelajaran yang besar dan akan menjadi harga yang kecil untuk membayar manfaat yang akan dihasilkannya. Komunitas TypeScript akan sangat senang membantu transisi ini dan membuat pengujian kinerja terhadap pustaka saat ini untuk memastikan tidak diturunkan versinya.

Beberapa artikel bermanfaat:

• Mengapa Anda Tidak Perlu Takut dengan TypeScript
• TypeScript vs ES6 vs ES2015
• TypeScript menang
• Apa itu TypeScript dan mengapa dengan Anders Hejlsberg

Mengutip pengembang inti Anders Hejlsberg, TypeScript lahir sebagai tanggapan atas keluhan dari klien dan tim internal bahwa JavaScript tidak cocok untuk aplikasi besar.

Tujuannya adalah untuk "memperkuat JavaScript dengan hal-hal seperti kelas, modul, dan pengetikan statis", tanpa mengorbankan keunggulannya sebagai standar terbuka dan lintas platform; hasilnya adalah "bahasa untuk pengembangan javascript skala aplikasi", dibangun sebagai superset dari bahasa tersebut.

Sampai browser dapat mengeksekusi TypeScript secara native, saya lebih memilih untuk tetap menggunakan JavaScript.

@mrdoob

Saya tidak dapat melihatnya sebagai alasan yang sah untuk tidak menggunakan TypeScript hanya karena alasan itu tidak dapat dijalankan langsung di browser. Anda tidak ingin menjalankannya di browser karena semua baris kode tambahan yang dimaksudkan hanya untuk pemeriksaan waktu kompilasi. Saat ini bukan bahasa pemeriksaan runtime. Jadi jika pernah digunakan di browser, kemungkinan besar semua kode yang diketik akan dihapus karena memengaruhi kinerja dan ini akan menjadi kode JavaScript vanilla.

Saya pikir Anda benar-benar kehilangan gunanya menggunakan bahasa yang diketik dan manfaatnya dalam pengembangan dalam basis kode yang besar. Anda masih menulis dan menggunakan JavaScript, inti dari TypeScript adalah bahwa itu adalah superset dari JavaScript. Anda menulis JavaScript dengan tipe, yang dikompilasi ke dalam JavaScript dalam versi target ECMAScript yang ditentukan, yang dapat dikonfigurasi dalam opsi kompiler, nilai yang diizinkan adalah 'es3', 'es5', 'es2015', 'es2016', 'es2017' atau ' selanjutnya'.

Karena TypeScript adalah JavaScript, memungkinkan untuk bermigrasi secara progresif tanpa harus pusing memikirkan refactoring semuanya sekaligus. Secara bertahap dapat dilakukan dan ditingkatkan oleh masyarakat. Tidak ada pekerjaan lebih dari apa yang sedang dibahas di sini dengan refactoring untuk menggunakan kelas ES6. Itulah satu-satunya alasan saya menyebutkannya di sini daripada membuka edisi baru.

Lihat tautan taman bermain TypeScript di bawah ini untuk contoh yang bagus:

• Contoh JavaScript Klasik
• Menambahkan Jenis Contoh
• Menambahkan Jenis dengan Contoh kesalahan
• Menggunakan Contoh Kelas
• Menggunakan Kelas dengan Contoh kesalahan

@joejordanbrown

Dapatkah Anda memikirkan seseorang yang mungkin tidak setuju dengan Anda tentang TypeScript menjadi solusi terbaik untuk masalah khusus ini?

Jika Anda mengetikkan typescript vs di google, beberapa istilah akan muncul, salah satunya adalah Flow. Menelusuri hal itu, nampaknya menghasilkan sejumlah artikel di mana orang-orang memperdebatkan pro dan kontra dari keduanya.

Tidak ada tipe yang sepertinya lebih merupakan kompromi daripada memilih salah satu dari ini.

Simpan TypeScript untuk proyek yang lebih rumit daripada hasil yang mereka buat -- khususnya kerangka kerja frontend yang sebenarnya bisa diimplementasikan dalam HTML. Maksud awal saya adalah menyingkirkan penyakit JavaScript, bukan memperburuknya. JavaScript adalah bahasa mainan sederhana yang terkadang digunakan untuk hasil yang rumit seperti three.js. TypeScript tidak ada gunanya.

Pada 6 September 2017, pukul 13.55, Joe [email protected] menulis:

@mrdoob

Saya tidak dapat melihatnya sebagai alasan yang sah untuk tidak menggunakan TypeScript hanya karena alasan itu tidak dapat dijalankan langsung di browser. Anda tidak ingin menjalankannya di browser karena semua baris kode tambahan yang dimaksudkan hanya untuk pemeriksaan waktu kompilasi. Saat ini bukan bahasa pemeriksaan runtime. Jadi jika pernah digunakan di browser, kemungkinan besar semua kode yang diketik akan dihapus karena memengaruhi kinerja dan ini akan menjadi kode JavaScript vanilla.

Saya pikir Anda benar-benar kehilangan gunanya menggunakan bahasa yang diketik dan manfaatnya dalam pengembangan dalam basis kode yang besar. Anda masih menulis dan menggunakan JavaScript, inti dari TypeScript adalah bahwa itu adalah superset dari JavaScript. Anda menulis JavaScript dengan tipe, yang dikompilasi ke dalam JavaScript dalam versi target ECMAScript yang ditentukan, yang dapat dikonfigurasi dalam opsi kompiler, nilai yang diizinkan adalah 'es3', 'es5', 'es2015', 'es2016', 'es2017' atau ' selanjutnya'.

Karena TypeScript adalah JavaScript, memungkinkan untuk bermigrasi secara progresif tanpa harus pusing memikirkan refactoring semuanya sekaligus. Secara bertahap dapat dilakukan dan ditingkatkan oleh masyarakat. Tidak ada pekerjaan lebih dari apa yang sedang dibahas di sini dengan refactoring untuk menggunakan kelas ES6. Itulah satu-satunya alasan saya menyebutkannya di sini daripada membuka edisi baru.

Lihat tautan taman bermain TypeScript untuk contoh:

Contoh JavaScript Klasik
Menambahkan Jenis Contoh
Menambahkan Jenis dengan Contoh kesalahan
Menggunakan Contoh Kelas
Menggunakan Kelas dengan Contoh kesalahan
—
Anda menerima ini karena Anda yang menulis utas.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

^ Saya akan baik-baik saja bahkan dengan pola mengerikan, selama itu konsisten.

@joejordanbrown terdengar seperti Anda jatuh cinta dengan TypeScript. jangan ragu untuk fork proyek dan port ke TypeScript. tiga.ts! 🙌.

@pailhead

Itu soal pilihan, saya yakin banyak yang akan setuju dan tidak setuju, itu normal meski kan! Anda akan selalu melihat "ini vs itu", "milik saya lebih baik dari Anda". Saya mengerti bahwa masing-masing memiliki kelebihannya sendiri. Ini tentang menimbang pilihan yang tersedia dan melihat apakah mereka dapat menguntungkan proyek. Perbandingan adalah hal yang baik, itu mendorong proyek lebih jauh.

Anda menyebutkan Flow, masalah yang saya lihat adalah:

• Aliran lisensi BSD adalah 3-klausul " Facebook BSD + Lisensi Paten ", Apache Software Foundation melarang penggunaan lisensi ini dalam proyek baru. Anda dapat membaca lebih detail di sini .

• Dukungan IDE kurang dibandingkan dengan TypeScript.

• Basis pengguna kecil dibandingkan dengan TypeScript,

• Pengetikan yang tersedia untuk perpustakaan umum tidak lengkap, TypeScript memiliki banyak pengetikan yang terpelihara dengan baik.

• Dokumentasi dan sumber daya sulit ditemukan dan tidak jelas dibandingkan dengan TypeScript. Anda akan menemukan dokumentasi, buku, video, dan banyak sumber e-learning lainnya yang bagus.

• Flow menggunakan file .js yang ditandai dengan // @flow , ini dapat membingungkan karena Anda melihat ekstensi .js jadi harapkan JavaScript tetapi sebenarnya, itu FlowType. Sedangkan TypeScript menggunakan ekstensinya sendiri .ts . Ini juga memungkinkan Anda untuk memiliki file keluaran TypeScript dan JavaScript dengan nama yang sama di direktori yang sama, yang ideal untuk proyek kecil, tentu saja, itu tidak akan terjadi pada proyek besar karena Anda akan menggunakan build sistem untuk mengelola proses pembangunan.

Bahkan google sangat mendukung TypeScript, yang menunjukkan kepercayaan mereka terhadap TypeScript. Baca postingannya di sini atau di sini .

TypeScript telah diizinkan untuk pengembangan klien tanpa batas mulai Maret 2017. TypeScript dan Angular pada TypeScript digunakan di Google Analytics, Firebase, dan Google Cloud Platform serta alat internal penting seperti pelacakan bug, ulasan karyawan, serta alat persetujuan dan peluncuran produk.

Saya hanya berpikir saya akan membuka diskusi tentang menggunakan bahasa Ketik dan melihat apa yang orang lain pikirkan tentang ide itu. Tampaknya @mrdoob benar-benar menentang bahkan mendiskusikan gagasan itu.

@artwelve
Saya tidak melihat bagaimana proyek ini tidak rumit dan bagaimana menggunakan bahasa yang diketik akan mempengaruhinya secara negatif.

@mrdoob
Tidak sama sekali, saya hanya bisa melihat manfaatnya terutama jika cabang baru sedang dibuat untuk memperbarui ke kelas ES6. Saya pikir menjawab dengan membuat garpu Anda sendiri yang disebut three.ts hanya konyol. Itu benar-benar bertentangan dengan praktik OSS yang baik jika setiap orang hanya mem-fork proyek OSS dan memodifikasi kode sumber mereka sendiri alih-alih berfokus pada proyek 1 dan menjadikannya yang terbaik. Anda akan berakhir dengan perangkat lunak atau komunitas yang sangat buruk yang membelah dan berfokus pada proyek yang mereka sukai untuk alasan apa pun. Mengapa Anda tidak bisa berdiskusi secara terbuka tentang pro dan kontra?

Bukan untuk berperan sebagai pendukung iblis, tapi sepertinya dia melakukannya

diskusi terbuka

itu hanya sangat pendek :)

Saya berbagi sudut pandang yang sama, ini adalah perpustakaan JS dan JS distandarisasi. Anda tidak bisa salah memilih JS untuk perpustakaan JS, sementara Anda bisa jika Anda memilih yang lain. Saya hanya mengambil Flow sebagai salah satu alternatif untuk TypeScript, tidak tahu apakah ada yang lain.

Bagaimanapun, sepertinya kita benar-benar keluar dari topik.

Mugen87 mengubah judul dari
Hapus Penyakit JavaScript untuk Mengevaluasi kelas ES6

Judul asli mengacu (sejauh yang saya mengerti) kurangnya konsistensi gaya. Khususnya menggunakan Object.assign() di beberapa tempat, dan pola lain di tempat lain.
Jika saya akan mengevaluasi apa pun di sini, itu akan menjadi judul masalah saat ini. Mengapa masalah konsistensi diangkat ke diskusi tentang penggunaan bahasa baru?

Saya membayangkan bahwa dengan TypeScript dan es6, kodenya harus cukup konsisten.

Saya akan mengatasi masalah ini dengan memperbarui halaman ini:

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

dan menambahkan:

A) "... gunakan Object.assign ..."
B) "...jangan gunakan Object.assign"

Satu gaya di seluruh perpustakaan. Tidak perlu mengubahnya.

Gaya dua garis yang setia masih ada, misalnya, kelas Material jauh lebih jelas dan bersih.

Ada di postingan pertama.

Saya menyarankan:

1. edit judul untuk mencerminkan kalimat ini, diskusikan memiliki satu gaya di seluruh perpustakaan, mengedit panduan gaya, dll.
2. memulai diskusi baru berjudul "evaluasi kelas es6", di mana kelas es6 akan dievaluasi
3. memulai diskusi baru berjudul "evaluasi memiliki tiga yang ditulis dalam bahasa yang diketik", di mana TypeScript dan semacamnya akan dibahas

Bagaimanapun, sepertinya kita benar-benar keluar dari topik.

Memang. @joejordanbrown jangan ragu untuk membuat topik baru untuk membahas TypeScript.

Btw, itu juga praktik OSS yang buruk untuk mengabaikan percakapan sebelumnya... https://github.com/mrdoob/three.js/issues/341#issuecomment -47000692

Kembali ke topik. Saya pikir kita sudah memecahkan masalah ini?

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

Kami hanya membutuhkan seseorang untuk mencobanya.

Oke jadi ... pertama-tama

Pola pertama (IMO terbaik):

function MyClass() {...}

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

    constructor: MyClass,

    prop1: 'something',

    method1: function someFunction() { .. },

    ...

});

Pola kedua:

function MyClass() {...}

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

MyClass.prototype.constructor = PointLight;

MyClass.prototype.prop1 = 'something';

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

...

@arctwelve Pola ini diperkenalkan karena berbagai alasan. Ini bukan masturbasi!

Pertama-tama memungkinkan pembacaan yang jelas tentang pewarisan objek. Object.assign jelas di sini tentang pewarisan objek. Maka Anda tidak dapat kehilangan objek yang diwarisi dalam banyak dan banyak baris MyClass.prototype .
Kedua, dalam kasus pewarisan berganda, ini juga jauh lebih jelas.
Ketiga, konstruktor kelas dapat dibaca dan tidak hilang di banyak baris seperti poin pertama.
Keempat, ini memungkinkan untuk mengelompokkan properti dan metode di lokasi yang sama ( di dalam braket ) yang jauh lebih jelas ketika Anda memiliki 3, 4, 5... dll kelas dalam file yang sama.
Kelima, pola ini memungkinkan untuk memeriksa salinan yang benar untuk beberapa properti "diwariskan".

Akhirnya ( @looeee ), ini juga untuk kinerja. Versi pertama lebih dioptimalkan ketika penguraian file terjadi, daripada banyak dan banyak panggilan ke prototipe.

Bagaimanapun !

Saat ini, kita harus melewati sintaks ES6!

@mrdoob

Kedengarannya bagus untuk saya! Saat ini saya berfokus pada WebVR sehingga harus orang lain selain saya.
Kami hanya membutuhkan seseorang untuk mencobanya.

Apakah Anda akan membuat cabang es6? Atau itu milik kita sendiri?

Versi pertama lebih dioptimalkan ketika penguraian file terjadi, daripada banyak dan banyak panggilan ke prototipe.

Apa kamu yakin akan hal itu? Saya berharap Object.Assign akan lebih lambat, jika ada. Tapi dalam kedua kasus saya ragu itu cukup dari overhead kinerja yang perlu dikhawatirkan.

Tentu saja: https://jsperf.com/inline-prototype-vs-assign-prototype/1

Di bawah versi chrome 61.0.3163.100 (Build officiel) (64 bit) Prototipe yang ditetapkan sekitar 60% lebih cepat

Menarik. Terima kasih telah membuat tes.

Hasil itu tidak berlaku untuk semua browser. Di Firefox mereka hampir sama ( Object.Assign ~3% lebih cepat), sedangkan di Edge Object.Assign ~33% lebih lambat .

Tetapi bagaimanapun saya masih tidak berpikir ini relevan sebagai argumen untuk gaya mana yang lebih baik - bahkan keseluruhan yang paling lambat (proto sebaris di Chrome) masih berjalan pada> 180.000 operasi per detik, dan mungkin ada beberapa ribu pengaturan ini dilakukan dalam kode. Jadi kita berbicara tentang perbedaan beberapa milidetik di sini, mungkin.

Bagi saya, gaya Object.Assign lebih bersih dan lebih mudah dibaca, dan itulah argumen utama yang mendukungnya.

Ya ini sekitar beberapa milidetik per file dan hanya ketika file diurai pertama kali oleh mesin javascript ... tetapi untuk perpustakaan besar seperti threejs, keuntungannya bisa cukup sekitar 200 milidetik pada pemuatan halaman.
Jangan lupa batas 3scd untuk pengguna depan yang tidak bisa menunggu lebih lama !

Saya mencoba membuat proyek Angular dengan threejs dan sepertinya saya selalu meretas setiap bagian dari threejs.
Pertama-tama sintaks es5 dengan TIGA konstanta yang harus ada, misalnya, jika saya membutuhkan OrbitalControls.
Kami memiliki pengetikan threejs, tetapi akan lebih mudah untuk memilikinya dalam paket yang sama. Pengetikan memiliki OrbitalControls, tetapi kita tidak bisa begitu saja mengimpor seperti import { OrbitalControls } from 'three; .
Webpack memiliki goyangan pohon, jadi dalam kasus es6 kami dapat memasukkan semua yang kami butuhkan di dalam satu proyek dan tidak memindahkannya ke proyek yang terpisah.
@mrdoob jadi mengapa TypeScript sangat buruk? Itu akan dikompilasi ke ES versi apa pun dengan pengetikan.
Ini juga digunakan di banyak kerangka kerja lain seperti Bereaksi.

@FriOne Saya tidak yakin apakah @mrdoob benar-benar menganggap TypeScript buruk, tetapi saya pikir dia menentang pembahasan TypeScript dalam masalah/utas ini karena itu bukan topik utas ini. Saya pikir kelas ES6 tidak berfungsi melawan atau untuk TypeScript. Jika Anda mengubah basis kode menjadi ES6, akan lebih mudah untuk memindahkan basis kode ke TypeScript karena sintaksnya sangat mirip. Ya, saya pikir TypeScript dapat mengaktifkan banyak opsi baru. Misalnya, ini dapat membantu untuk "mengubah" kode yang lebih optimal, membantu pengembang baru untuk mempelajari perpustakaan lebih cepat, mungkin membuka pintu untuk eksperimen di masa mendatang, misalnya: https://github.com/AssemblyScript/assemblyscript. Saya pikir ada banyak keuntungan dengan TypeScript @joejordanbrown menjelaskan kelebihannya secara rinci.

Tapi kembali ke topik: Saya pikir mengadopsi kelas ES6 akan menjadi langkah maju dan setelah itu, kita bisa mendiskusikan hal TypeScript. Jadi mari kita lakukan satu langkah setelah satu sama lain

@tschoartschi , pikir TypeScript dapat membantu dengan migrasi ke kelas es6 dan refactoring lainnya. Saya tidak memiliki pengalaman migrasi seperti itu, mungkin saya salah.

@FriOne itu tergantung tentu saja TypeScript dapat membantu karena kompiler dapat memberi tahu Anda semua kesalahan dan kesalahan Anda, tetapi Anda harus mengatur seluruh pipa build terlebih dahulu untuk bekerja dengan Typescript. Selanjutnya, Anda perlu menilai apakah TypeScript cocok atau tidak. Saya pikir tidak apa-apa untuk mengonversi ke kelas ES6 terlebih dahulu dan kemudian memikirkan TypeScript.

Hai, kami adalah sekelompok 5 siswa dari KTH yang ingin berkontribusi pada proyek sumber terbuka untuk kursus dan ingin mencoba dan mengonversi sebagian proyek ke sintaks ES6 yang baru.

Saya mem-porting Three.js ke TypeScript beberapa waktu lalu (r82) bersama dengan beberapa contoh, sebagai bukti konsep.

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

Contoh membutuhkan sedikit waktu untuk dimuat, karena sumber TypeScript ditranspilasikan dengan cepat. Mereka memuat secepat aslinya saat menggunakan JavaScript yang ditranspilasikan.

Saya ingin melihat three.js porting ke TypeScript. Saya merasa proyek ini sangat perlu dimodernisasi jika ingin bertahan dalam ujian waktu untuk generasi web berikutnya. Suatu hari, kita bahkan mungkin melihatnya bekerja dengan AssemblyScript dan berjalan di WASM. Jika bukan threejs, maka sesuatu yang lain pasti akan melakukannya.

Ini selesai @WestLangley dan @mrdoob

@bhouston apa kesimpulannya di sini?

@pkieltyka ya saya juga berpikir TypeScript akan sangat masuk akal untuk perpustakaan seperti Three.js. Selain semua pro teknis, itu juga akan memudahkan penggunaan perpustakaan dan membantu pemula untuk menjelajahi API. Tapi saya juga berpikir penting untuk menyelesaikan semua ES6 Stuff terlebih dahulu dan kemudian mempertimbangkan TypeScript. Menurut saya dari JavaScript terbaru tidak terlalu rumit untuk menambahkan tipe dalam bentuk TypeScript.

@flyover bagus juga lihat bukti konsep untuk versi TypeScript dari Three.js. Apakah Anda mendapat umpan balik dari pengelola Three.js?

Saya juga mendukung TypeScript untuk three.js. Typescipt pada dasarnya adalah yang terbaik
praktek dan JavaScript mentah tidak lagi.

Pada Sabtu, 5 Januari 2019, 04:13 tschoartschi < [email protected] menulis:

@pkieltyka https://github.com/pkieltyka ya saya juga berpikir TypeScript
akan sangat masuk akal untuk perpustakaan seperti Three.js. Di samping semua
pro teknis itu juga akan memudahkan penggunaan perpustakaan dan membantu pemula
untuk menjelajahi API. Tapi saya juga berpikir penting untuk menyelesaikan semua ES6
Hal pertama dan kemudian pertimbangkan TypeScript. Saya pikir dari yang terbaru
JavaScript tidak terlalu rumit untuk menambahkan tipe dalam bentuk TypeScript.

@flyover https://github.com/flyover Bagus juga lihat bukti konsep untuk
versi TypeScript dari Three.js. Apakah Anda mendapat umpan balik dari pengelola?
dari Three.js?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451639995 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAj6_bkdND7I0_F4AJcBV0DYLpToUIVhks5vAGykgaJpZM4N9vH8
.

@bhouston Saya setuju bahwa TypeScript adalah teknologi yang hebat tetapi saya tidak akan mengatakannya seperti yang Anda lakukan. Saya pikir kita harus selalu sedekat mungkin dengan JavaScript mentah dan menambahkan fitur TypeScript di atas. Karena TypeScript mengikuti spesifikasi JavaScript dengan sangat dekat, TypeScript benar-benar membaca seperti ES6 dengan tipe.

Untuk perpustakaan seperti three.js TypeScript bisa sangat bermanfaat dan dapat diadopsi secara bertahap. Jadi kita tidak perlu menulis ulang "big-bang", terutama setelah semua refactor ES6 selesai.

Akan menarik untuk mendengar jika sikap @mrdoob pada TypeScript berubah. TypeScript tampaknya menjadi standar "defacto" untuk "JavaScript yang diketik" (perhatikan bahwa saya meletakkan klaim saya di bawah tanda kutip karena ini bukan fakta yang sulit)

Langkah pertama yang harus dilakukan adalah mengadopsi fitur ES6, terutama class, arrow function, 'let', dan 'const'.

Setelah kami selesai melakukannya, kami dapat mendiskusikan dukungan TypeScript dengan benar karena, seperti yang ditunjukkan oleh @roomle-build, mudah untuk menambahkan fitur TypeScript secara bertahap di atas kode ES6 secara bertahap jika kami memutuskan untuk melakukannya.

Melakukan keduanya sekaligus sepertinya akan memperumit banyak hal, bagiku.

Senang mendengar bahwa TypeScript bisa menjadi opsi di beberapa titik di masa depan :-) mungkin kita bisa menggunakan kembali beberapa pekerjaan yang dilakukan oleh @flyover

Tapi saya sangat setuju dengan @looeee untuk menyelesaikan semua hal ES6 terlebih dahulu dan kemudian fokus pada langkah selanjutnya

selesaikan semua barang ES6

Saya akan senang jika kita setidaknya bisa memulainya

Langkah setengah jalan yang baik untuk TypeScript adalah menambahkan file tipe di samping setiap file JavaScript. Dengan demikian akan ada keduanya:

Vektor3.js
Vektor3.d.ts

Ini memberi kita semua manfaat TypeScript sebagai file sespan.

Saat ini ada @types/three file tetapi sudah kedaluwarsa dan dikelola secara terpisah -- sehingga akan selalu kehabisan data.

Pesaing utama Three.JS adalah Babylong dan sepenuhnya TypeScript dan saya percaya itu mendapat manfaat dari ini.

Tetapi membunuh @types/three dan mengintegrasikannya sebagai file definisi tipe mobil samping ke dalam Tiga yang tepat akan menjadi langkah pertama yang bagus.

Kita juga perlu mendapatkan semua contoh yang terintegrasi ke /src dengan beberapa jenis goyangan pohon.

Saat ini struktur kode untuk Three.JS begitu 2014 dan hanya sulit untuk dikerjakan.

Semua contoh?

Contoh/js

Pada Senin, 07 Januari 2019, 10:25 Dusan Bosnjak < [email protected] menulis:

Semua contoh?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451970482 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAj6_Q3Kakb5Qn2DqGbMVvLkW_28cOyaks5vA2b5gaJpZM4N9vH8
.

@bhouston

Langkah setengah jalan yang baik untuk TypeScript adalah menambahkan file tipe di samping setiap file JavaScript. Dengan demikian akan ada keduanya:

Vektor3.js
Vektor3.d.ts

Apakah file .d.ts akan bertindak sebagai file .h di c?

Apakah file .d.ts akan bertindak sebagai file .h di c?

Itu adalah analogi yang sangat bagus. Seseorang yang menarik telah melakukan sebagian besar dari ini di sini: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/three Jadi sebenarnya itu hanya akan mengambil kepemilikan file jenis ini dan mengintegrasikannya ke dalam Three.js. Jika Anda mau, kami dapat membuat PR yang mengintegrasikan ini ke dalam Three.js dan membaginya dengan benar.

Untuk menunjukkan seberapa populer TypeScript, lihat berapa banyak @Types/three yang diunduh per minggu:

https://www.npmjs.com/package/@types/three - 63.000 unduhan per minggu.

Menakjubkan!

Jika Anda mau, kami dapat membuat PR yang mengintegrasikan ini ke dalam Three.js dan membaginya dengan benar.

Kedengarannya bagus untuk saya 👍

Apakah mungkin menjalankan pemeriksaan baris perintah, mirip dengan eslint, memastikan bahwa jenis file dan file sumber .js sejajar? Jika kita mengambil kepemilikan dari file d.ts , akan sangat lebih baik untuk memiliki beberapa cara untuk secara teratur memverifikasi bahwa mereka cocok.

Untuk menunjukkan seberapa populer TypeScript, lihat berapa banyak @Types/three yang diunduh per minggu:

https://www.npmjs.com/package/@types/three - 63.000 unduhan per minggu.

Saya akan mengaitkan ini lebih pada popularitas Visual Studio Code, karena itu terjadi secara otomatis ketika Anda menggunakan Visual Studio Code, melalui fitur Akuisisi Tipe Otomatis mereka.
Yang mengatakan, itu tidak bisa diabaikan.

@flyover @bunnybones1 @mrdoob @looeee @donmccurdy @bhouston @roomle-build @pkieltyka @FriOne @joejordanbrown karena Anda semua tampaknya tertarik dengan TypeScript Saya ingin mencatat bahwa saya membuat masalah baru tentang TypeScript. Saya pikir masuk akal untuk memindahkan semua diskusi TS di sana. Jika Anda tertarik, Anda dapat menemukannya di sini: https://github.com/mrdoob/three.js/issues/15545

Saya bersedia memberikan waktu untuk port ke kelas ES6. Saya pikir ini akan menjadi solusi jembatan yang baik untuk suatu hari mendukung TypeScript.

Langkah pertama adalah mengonversi beberapa add-on ke ES6.

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

Kontrol, Loader dan Eksportir adalah kandidat yang baik. Jangan ragu untuk membantu!

@mrdoob hanya untuk mengonfirmasi, maksud Anda mengonversinya menjadi modul ES tetapi belum menggunakan fitur ES6 lainnya, bukan?

Saya berasumsi proses melakukan konversi itu adalah:

1. Gunakan skrip modularize.js untuk mengonversi file asli ke modul ES.
2. Bersihkan masalah jika diperlukan.
3. Pada titik tertentu (rilis ini, atau dalam waktu dekat) kami akan mulai menggunakan rollup-examples.config.js untuk mengonversi modul ES ke modul UMD, di mana versi di examples/js tidak lagi dipertahankan oleh tangan.
4. Setelah stabil, kami dapat mempertimbangkan perubahan lain seperti memperkenalkan fitur ES6.

@mrdoob hanya untuk mengonfirmasi, maksud Anda mengonversinya menjadi modul ES tetapi belum menggunakan fitur ES6 lainnya, bukan?

Ya, maaf. saya harus telah ditentukan.

Saya dan @bhouston telah membuat PR yang dijanjikan yang menyumbangkan file *.d.ts untuk sebagian besar proyek Three.JS. https://github.com/mrdoob/three.js/pull/15597

Saya tidak sabar menunggu kelas ES6 dan definisi TypeScript. Setiap kali saya bekerja dengan three.js saya harus menyalin ratusan baris kode untuk mengimplementasikan kembali satu fungsi yang terletak pada lingkup yang tidak dapat diakses. Ini benar-benar bukan cara yang elegan untuk bekerja jika Anda harus mengoptimalkan adegan Anda. Ini akan membawa alur kerja ke tingkat yang baru untuk akhirnya dapat memperluas dan mengganti fungsi.
Jadi tolong buat fungsi kelas setidaknya "dilindungi" dan dapat diakses tanpa kecuali

Setiap kali saya bekerja dengan three.js saya harus menyalin ratusan baris kode untuk mengimplementasikan kembali satu fungsi yang terletak pada lingkup yang tidak dapat diakses. ... Jadi tolong buat fungsi kelas setidaknya "dilindungi" dan dapat diakses tanpa kecuali.

@dionysiusmarquis Saya tidak yakin saya mengerti apa yang Anda maksud di sini ... pengetikan TS yang ada memiliki fungsi yang ingin Anda gunakan salah ditandai sebagai pribadi? Atau sesuatu tentang definisi kelas gaya prototipe saat ini yang sulit digunakan di TS? Bisakah Anda berbagi contoh?

Setiap kali saya bekerja dengan three.js saya harus menyalin ratusan baris kode untuk mengimplementasikan kembali satu fungsi yang terletak pada lingkup yang tidak dapat diakses. ... Jadi tolong buat fungsi kelas setidaknya "dilindungi" dan dapat diakses tanpa kecuali.

@dionysiusmarquis Saya tidak yakin saya mengerti apa yang Anda maksud di sini ... pengetikan TS yang ada memiliki fungsi yang ingin Anda gunakan salah ditandai sebagai pribadi? Atau sesuatu tentang definisi kelas gaya prototipe saat ini yang sulit digunakan di TS? Bisakah Anda berbagi contoh?

Saya hanya ingin menerapkan peta bayangan tertentu untuk skenario tertentu. Akan membantu untuk dapat menimpa getDepthMaterial misalnya. Saat ini saya menyuntikkan WebGLShadowMap saya sendiri dalam proses pembuatan dengan versi salin/tempel termasuk perubahan yang saya inginkan.
Akan sangat bagus jika setiap kelas three.js akan mengekspos sebanyak mungkin. Dengan TypeScript Anda dapat dengan mudah menandai fungsi sebagai private atau protected untuk menjelaskan tujuan yang dimaksud. ES6 Class/Typescript ShadowMap saya misalnya terlihat seperti ini:

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 }

Rasanya seperti di rumah sendiri jika Anda diizinkan untuk mengubah kelas "tingkat rendah"

Saya punya pertanyaan dalam konteks kelas. Bagaimana kita mentransfer metode seperti Vector3.unproject ke dalam sintaks kelas? Metode ini sebenarnya menggunakan penutupan untuk membuat ruang lingkup baru. Ini adalah mekanisme penting yang menjaga jumlah kreasi objek serendah mungkin.

Apakah kita membutuhkan Object.assign dalam kasus ini?
@Mugen87

Anda dapat melakukan penutupan dengan kelas sekarang. Hanya saja tidak jelas bagaimana menavigasi gula sintaksis itu. Lihat jawaban saya di StackOverflow: https://stackoverflow.com/questions/39297258/iife-in-es6-class-literal/56077521#56077521 (Saya harus rendah hati dan mengakui bahwa saya tidak sepenuhnya mengerti bagaimana/mengapa itu bekerja .)

Maaf, tetapi kode ini terlihat seperti anti-pola dan kita tidak boleh mengadaptasi ini dalam proyek. Ada solusi yang tepat untuk mengelola variabel dalam lingkup modul. Saya sarankan untuk pergi rute ini.

@ Mugen87 ya saya juga berpikir kita harus memanfaatkan ruang lingkup modul dengan baik. Ini juga akan membantu untuk hal-hal seperti goyangan pohon. Ini sudah dibahas dalam banyak masalah lain seperti ini: https://github.com/mrdoob/three.js/issues/6241#issuecomment -398703521

Maaf, tetapi kode ini terlihat seperti anti-pola dan kita tidak boleh mengadaptasi ini dalam proyek. Ada solusi yang tepat untuk mengelola variabel dalam lingkup modul. Saya sarankan untuk pergi rute ini.

Tidak masalah. Saya baru saja menyebutkan kemungkinannya. Jika Anda memiliki solusi yang lebih baik/bersih yang sedang berjalan, saya ingin melihatnya beraksi. Proyek Three.js (penggunaan, sumber, diskusi, dll.) telah menjadi sumber utama pengetahuan JS saya, jadi memperkenalkan pola pemrograman baru dan lebih baik ke Three.js mungkin akan bermanfaat bagi saya dan proyek saya juga. Tidak ada yang perlu disesali. ;-)

@ Mugen87 Bisakah Anda menjelaskan sedikit tentang mengapa Anda menganggap kelas-IIFE sebagai pola anti kalau saja agar saya bisa belajar dan memahami sedikit lebih banyak? Saya mengerti bahwa modul mencakup variabel secara inheren tetapi itu tidak berbeda dari bagaimana inti sedang dibangun sebelumnya. Dan dengan begitu banyak fungsi yang menggunakan variabel cache, akan sangat penting untuk memastikan tidak ada fungsi yang bertabrakan atau menggunakan variabel pada saat yang sama -- pelingkupan fungsi membuatnya lebih mudah untuk dikelola dan dipelihara, itulah sebabnya saya tidak melihat itu sebagai anti-pola (setidaknya jika dibandingkan dengan membuang semua variabel cache dalam lingkup modul).

Bisakah Anda menjelaskan sedikit mengapa Anda menganggap kelas-IIFE sebagai pola anti

Saya tidak akan menggunakan pendekatan yang berpotensi menghambat goyangan pohon seperti yang disebutkan di sini: https://github.com/mrdoob/three.js/pull/14695 . Selain itu, saya pikir seluruh pola terlihat seperti retasan. Menggunakan pendekatan yang kurang "mewah" biasanya bekerja lebih baik. Menghindari penutupan yang tidak perlu juga harus meningkatkan kinerja eksekusi kode secara umum (tidak dapat membuktikan ini dengan referensi tetapi saya pernah mendengarnya pada pembicaraan beberapa waktu lalu).

Dan dengan begitu banyak fungsi yang menggunakan variabel cache, sangat penting untuk memastikan tidak ada fungsi yang bertabrakan atau menggunakan variabel secara bersamaan.

IIFE terutama digunakan di kelas matematika. Karena kami memiliki jumlah cakupan pengujian yang baik di sana ( @gero3 melakukan pekerjaan yang baik akhir-akhir ini dengan menambahkan lebih banyak pengujian unit), akan lebih mudah untuk membuat penghapusannya menjadi kuat.

Tidak apa-apa untuk menghapus IIFE. Saya pikir saya bertanggung jawab untuk itu pada tahun 2013. Itu untuk menyingkirkan pola variabel statis yang sulit dipertahankan. Itu dilakukan dalam PR ini:

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

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

Dan dibahas lebih awal di sini:

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

Fakta menarik, ketika kami memasukkan ini, tidak ada perbedaan kinerja kode.

Saya berasumsi proses melakukan konversi itu adalah:

1. Gunakan skrip modularize.js untuk mengonversi file asli ke modul ES.
2. Bersihkan masalah jika diperlukan.
3. Pada titik tertentu (rilis ini, atau dalam waktu dekat) kami akan mulai menggunakan rollup-examples.config.js untuk mengonversi modul ES ke modul UMD, di mana versi di examples/js tidak lagi dipertahankan oleh tangan.
4. Setelah stabil, kami dapat mempertimbangkan perubahan lain seperti memperkenalkan fitur ES6.

Hai. mungkin melewatkannya tetapi apa ini langkah tambahan kami menuju kelas?

1. [x] Gunakan skrip modularize.js untuk mengonversi file asli ke modul ES.
2. [x] Bersihkan masalah jika diperlukan.
3. [ ] Di beberapa titik (rilis ini, atau dalam waktu dekat) kami akan mulai menggunakan rollup-examples.config.js untuk mengonversi modul ES ke modul UMD, di mana versi dalam contoh/js tidak lagi dipertahankan oleh tangan.
4. [ ] Setelah stabil, kita dapat mempertimbangkan perubahan lain seperti memperkenalkan fitur ES6.

Pada langkah-langkah di atas, pada dasarnya kita telah menyelesaikan langkah (1) dan (2).

Langkah (3) kami tidak melakukan cara itu lagi, tetapi sebaliknya akan mencela dan menghapus folder examples/js di beberapa titik (lihat https://github.com/mrdoob/three.js/pull/18749) .

Saya pikir itu berarti langkah (4), memperkenalkan kelas ES6 ke examples/jsm hanya dapat dilakukan (untuk saat ini) pada beberapa contoh yang tidak dihasilkan dari versi sumber examples/js . Setelah examples/js dihapus, kita dapat melakukan sisanya.

^Tapi saya mungkin terlalu banyak membaca yang tersirat di sini, mungkin @Mugen87 atau @mrdoob dapat mengonfirmasi?

IMO, proyek harus fokus pada penghentian dan penghapusan examples/js untuk mencapai basis kode modul saja. Pada langkah selanjutnya, saya akan merekomendasikan untuk melanjutkan dengan migrasi kelas. Dimulai dengan contoh dan kemudian memigrasikan inti.

sempurna. Terima kasih. akan melihat lebih dekat cara-cara itu

Diposting ulang dari edisi tertutup.
Hai, yang di sana,

Saya ingin membuat masalah ini untuk mencoba dan menghilangkan pemikiran semua orang tentang bagaimana kami ingin bergerak maju dengan migrasi kelas.

Ringkasan singkat saya tentang apa yang saya temukan sejauh ini:

• Kita harus menghentikan folder contoh sebelum melakukan hal lain
• Ada bagian dari src/ yang tidak diperpanjang oleh salah satu contoh yang dapat dikonversi
• Dengan beberapa perubahan pada skrip modularize.js kita dapat memulai contoh/js/ yang menghasilkan skrip contoh/jsm yang sesuai.

Apakah saya melewatkan sesuatu?

Kita harus menghentikan folder contoh sebelum melakukan hal lain

Saya tidak yakin siapa yang bertanggung jawab atas langkah spesifik berikutnya pada folder examples/js . Kecuali kita dapat mengartikulasikan rencana itu, saya lebih suka ini tidak menghalangi konversi ke kelas ES. Untuk alasan itu, saya agak tidak setuju dengan https://github.com/mrdoob/three.js/issues/11552#issuecomment -592768708. 🙂.

lebih jauh dari itu, tampaknya kita hanya menunggu tanggal yang akan ditentukan

Juga, sebagai bagian dari sedikit revisi yang saya lakukan, saya menemukan komentar ini tentang bagaimana fitur ES2015 lainnya dapat diperkenalkan melalui proses rollup build saat ini. Bahkan ada contoh yang diberikan .

edit: inilah inti dari contoh cepat lainnya

Mari kita mulai kereta konversi .
Komentar dependensi file .

@PastiMungkin saya punya waktu dan saya ingin membantu. Dapatkah saya mengambil beberapa item pada daftar dependencies.json ?

👍

sebut saja dibs pada hal-hal

@DefinitelyMungkin Apa cara terbaik untuk menangani warisan dari leluhur yang dalam seperti Object3D ? Misalnya, saya mengalami kerusakan saat mengonversi 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

kami akan membuat catatan di bagian atas file tentang masalah apa pun yang kami hadapi, jika saya mengingatnya dengan benar.

Saya salah memahami apa yang terjadi dengan AudioListener... Setelah beberapa debug, saya rasa ada masalah yang cocok dalam transformasi bubleCleanup . Lihat https://github.com/mrdoob/three.js/pull/19934#issuecomment -667411997 untuk info lebih lanjut. Saya mengalami ini dengan beberapa kelas yang berbeda, jadi kami mungkin harus menyelesaikannya sebelum melangkah lebih jauh.

ini akan menjadi kasus untuk beberapa file tetapi tidak semua. Kami mengantisipasi masalah seperti itu.

Bagi mereka yang mengikuti, silakan baca diskusi singkat di sini .

Sementara itu, gunakan src/loaders !