Three.js: File "eksternal" Google Closure Compiler untuk three.js?

Tidak, three.js tidak memiliki ketergantungan eksternal, jadi sejauh ini hal seperti ini tidak diperlukan.

Saya tahu, tetapi juga berguna untuk proyek sendiri untuk mengintegrasikan THREE.js dalam lingkungan yang dapat dikompilasi.

Bagaimana tampilan file seperti itu? Maaf jika sudah dijelaskan pada tautan yang Anda bagikan, saya menemukan halamannya agak berlebihan (terlalu banyak teks) dan saya tidak dapat membaca/mengerti.

@mrdoob , Anda dapat menemukan beberapa contohnya di:

http://code.google.com/p/closure-compiler/source/browse/#svn %2Ftrunk%2Fexterns

atau

http://code.google.com/p/closure-compiler/source/browse/#svn %2Ftrunk%2Fcontrib%2Fexterns

dan berikut ini juga penting:

http://code.google.com/closure/compiler/docs/js-for-compiler.html

Komentar/Header? Saya pikir itu akan membuat kode lebih sulit dibaca ...

Ya, tapi saya pikir itu hanya untuk file eksternal ini bukan untuk keseluruhan kode. Seseorang dapat melakukannya, tetapi itu tidak perlu.

Saya sudah mencobanya dengan http://www.dotnetwise.com/Code/Externs/index.html . Tapi itu tidak bekerja sepenuhnya dengan Three.js . Tidak semua definisi diekstraksi.

Berikut entri blognya:

http://blog.dotnetwise.com/2009/11/closure-compiler-externs-extractor.html

Sepertinya itu mendukung pola this.method = function(){} , tetapi bukan prototipe ...

@mrdoob , apa rekomendasi Anda untuk mengintegrasikan THREE.js dalam aplikasi sendiri dengan pengoptimal lanjutan kompiler penutupan? Benarkah saat ini tidak memungkinkan?

Sejauh yang saya pahami, pengoptimal tingkat lanjut hanya menyertakan kelas yang digunakan, bukan? Secara teori itu harus bekerja ... tidak bekerja?

Saya tidak mencoba pengoptimalan lanjutan dengan three.js, tetapi saya ingat untuk hal-hal lain yang digunakan untuk memecahkan kode. Secara umum itu tidak "aman" - dengan pengoptimalan sederhana default selalu berfungsi, dengan tingkat lanjut terkadang tidak.

Itu merusak kode jika Anda mengkompilasi sebagai perpustakaan, tetapi sebagai aplikasi (dengan metode yang dipanggil dan semua itu) itu harus berfungsi, bukan?

@mrdoob untuk menggunakan perpustakaan dengan kode yang dikompilasi (dioptimalkan), Anda memerlukan file "eksternal" untuk mendeklarasikan semua kelas dan metode perpustakaan. Ini tidak bekerja tanpa itu. Tetapi apakah ada alat lain yang berfungsi dengan three.js ? Saya membutuhkannya untuk mengaburkan (memperburuk) aplikasi three.js saya. Salah satu kandidatnya adalah: https://github.com/mishoo/UglifyJS . Tapi saya belum mencobanya.

Eksternal penutupan Google adalah file, yang menggambarkan seluruh objek, yang akan kita gunakan dalam kode yang dikompilasi.
Tanpa kompiler file ini hanya membuat dari nama fungsi sesuatu seperti a() atau b().

Misalnya, ini untuk JQuery: http://code.google.com/p/closure-compiler/source/browse/trunk/contrib/externs/jquery-1.7.js

Akan lebih bagus jika eksternal akan untuk three.js.

Aku baik-baik saja dengan itu, tapi aku tidak bisa mengatasinya sendiri. Orang lain perlu melangkah untuk yang satu ini.

@yurikor , ketika Anda menggunakan node.js, Anda dapat menggunakan node-browserify dan uglify-js bersama-sama. Maka Anda tidak perlu membangun apa pun.

@remoe Terima kasih banyak atas sarannya. Aku akan mencobanya.

Masalah ini telah tidak aktif untuk sementara waktu, tetapi jika ada yang ingin mengatasi masalah ini di masa mendatang, berikut beberapa informasi tambahan:

Untuk proyek saya, saya telah membuat file sederhana dengan ekspor threejs yang cukup untuk dapat mengkompilasi proyek saya. Muncul dengan anotasi tipe yang cukup berguna karena memungkinkan kompiler penutupan untuk memeriksa semua jenis dan menemukan beberapa bug dalam kode saya. Saya telah membuat file ini secara manual. Saya menggunakan kompiler penutupan terutama untuk pemeriksaan bug, untuk minifikasi aktual saya menggunakan uglifyjs yang kurang kuat tetapi aman.

Juga, untuk mencegah kompiler penutupan mengganti nama simbol antarmuka publik saya, saya harus menambahkan beberapa baris kode (empat fungsi itu adalah satu-satunya fungsi publik perpustakaan saya). Perhatikan bahwa kompilator penutupan mengganti nama semua properti yang diakses melalui blah.xyz , tetapi tidak menyentuh properti apa pun yang diakses melalui blah["xyz"] .

Akhirnya, baris window['ColladaLoader2'] = ColladaLoader2 (perhatikan lagi penggunaan string) diperlukan untuk memberitahu kompilator penutupan bahwa kelas ini harus diekspor ke lingkup global.

Tetapi Anda tidak menggunakan penutupan untuk produksi, dan hanya memeriksa bug? saya
tidak yakin apakah mempertahankan file eksternal layak dilakukan. Jalankan saja penutupan
tanpa optimasi agresif dan kemudian Anda tidak memerlukan file eksternal
tetapi Anda masih mendapatkan sebagian besar validasi yang saya yakini atau mungkin semuanya
validasi. Mungkin Anda bisa mengklarifikasi?

Dikirim dari ponsel saya, maaf atas tata bahasa dan kesopanan saya.
Pada 12 Februari 2013 5:19, "Robert Carnecky" [email protected] menulis:

Masalah ini telah tidak aktif untuk sementara waktu, tetapi jika ada yang mau
mengatasi masalah ini di masa mendatang, berikut beberapa informasi tambahan:

Untuk proyek saya, saya telah membuat file sederhanahttps : //github.com/crobi/ColladaAnimationCompress/blob/master/threejs-exports.jsdengan ekspor threejs yang cukup untuk dapat mengkompilasi proyek saya. Itu datang
dengan anotasi tipe yang cukup berguna karena memungkinkan penutupan
compiler untuk memeriksa semua jenis dan menemukan beberapa bug dalam kode saya. saya sudah
membuat file ini secara manual. Saya menggunakan kompiler penutupan terutama untuk bug
memeriksa, untuk minifikasi yang sebenarnya saya menggunakan yang kurang kuat tetapi aman
uglifyjs https://github.com/mishoo/UglifyJS.

Juga, untuk mencegah kompiler penutupan mengganti nama antarmuka publik saya
simbol, saya harus menambahkan beberapa baris kodehttps://github.com/crobi/ColladaAnimationCompress/blob/366344d3aa5dbbc0a53c47a2c1759b86bb1e0fcd/ColladaLoader2.coffee#L3376 (keempat fungsi itu adalah satu-satunya fungsi publik perpustakaan saya). Catatan
bahwa kompilator penutupan mengganti nama semua properti yang diakses melalui blah.xyz,
tetapi tidak menyentuh properti apa pun yang diakses melalui bla["xyz"].

Akhirnya, barishttps://github.com/crobi/ColladaAnimationCompress/blob/366344d3aa5dbbc0a53c47a2c1759b86bb1e0fcd/ColladaLoader2.coffee#L3383 window['ColladaLoader2']
= ColladaLoader2 (perhatikan lagi penggunaan string) diperlukan untuk memberi tahu
penutupan compiler bahwa kelas ini harus diekspor ke lingkup global.

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/mrdoob/three.js/issues/341#issuecomment -13426131.

Sejauh yang saya tahu, mode sederhana tidak melakukan validasi sama sekali. Ini mengganti nama variabel lokal, dan jika menemukan simbol yang tidak diketahui, ia membiarkannya tidak tersentuh, dengan asumsi itu adalah variabel global.

Mode lanjutan berperilaku seperti kompiler dalam bahasa yang diketik dengan kuat (dengan asumsi info jenis tersedia):

Sebagai contoh, mode sederhana mengubah kode berikut:

function fn() {
    var foo = {}; // local variable, safe to rename this
    foo.bar();    // undefined property, will crash here
}
fn();

tanpa peringatan apapun ke

function fn(){({}).bar()}fn();

yang jelas akan crash pada ({}).bar() . Mode lanjutan mengeluarkan kode berikut:

({}).a(); // fn() inlined, private member 'bar' renamed to 'a'

yang masih macet, tetapi kompiler juga memberikan peringatan

Property bar never defined on foo at line 3 character 0.

• Penutupan bug yang ditemukan adalah jenis bug di mana saya salah ketik dalam nama fungsi atau di mana saya meneruskan satu THREE.Vector3 ke Matrix4.makeTranslation alih-alih tiga angka terpisah untuk komponen x, y, dan z .
• Jika saya memiliki cakupan pengujian penuh (yang tidak), saya akan menemukan bug itu cepat atau lambat. Terkadang mereka sulit untuk di-debug, jika tidak segera terwujud.
• Jika threejs menyediakan file ekspor terbaru dengan setiap rilis baru (usaha besar untuk mempertahankan), kompiler penutupan akan menangkap semua masalah yang berasal dari API yang berubah (seperti halnya Matrix4.makeTranslation ).
• Menyiapkan kompiler penutupan terlalu banyak bekerja untuk saya, karena membutuhkan runtime Java. Semua alat lain yang diperlukan untuk membangun perpustakaan saya didasarkan pada node/javascript.

Saat ini saya sedang membangun file externs.js perpustakaan penutupan saya untuk mengintegrasikan aplikasi TIGA.js dengan Perpustakaan Penutupan. Pada dasarnya apa yang kami coba cari tahu adalah:
Apakah ada daftar di suatu tempat dari semua kelas THREE.js dan metode prototipe yang mereka terapkan? Daftarnya harus seperti ini:

TIGA. Tekstur
TIGA.Tekstur.konstruktor
TIGA.Tekstur.klon
TIGA.Tekstur.buang
TIGA.DataTexture.clone

(dan seterusnya...)

Ps- Three.js bagus, tetapi dengan jsDocs yang tepat, daftar ini dapat dengan mudah diekstraksi :)

Saya memiliki implementasi parsial dari ekspor three.js di sini (ditulis secara manual, jadi mungkin mengandung beberapa kesalahan).

@crobi : mengapa Anda memasukkan komentar dokumen ke dalamnya? Sepertinya itu agak memakan waktu dan saya tidak yakin itu perlu ...

@taoeffect : komentarnya sebagian besar untuk mode lanjutan kompiler penutupan. Saya suka kode yang diketik dengan kuat.

@crobi , oh komentar menghasilkan pengetikan yang dipaksakan? Itu agak keren, saya tidak tahu itu melakukan itu.

Hanya jika Anda menggunakan kompilator penutupan untuk memeriksa kesalahan tipe. Mirip dengan TypeScript . Kedua preprocess javascript beranotasi menjadi javascript biasa. Jadi ini hanya pemeriksaan waktu kompilasi.

Sebagian besar komentar tentang mode pengoptimalan lanjutan penutupan di sini tidak akurat.

Untuk mengatasi masalah utama, Anda dapat menggunakan alat berikut untuk secara otomatis menghasilkan eksternal penutupan untuk perpustakaan apa pun http://www.dotnetwise.com/Code/Externs/

Juga, jika Anda memutuskan untuk menggunakan three.js sebagai masukan ke kode Anda daripada hanya menggunakannya sebagai perpustakaan eksternal, Anda harus menambahkan tanda

--language_in=ECMASCRIPT5

Anda harus menulis posting blog tentang ini, mungkin mengambil pertunjukan
contoh kritis dan melihat apakah menjalankannya melalui Google Closure
compiler dengan optimasi yang baik membuat perbedaan.
-ben

Pada Senin, 13 Januari 2014 pukul 12:31, Rodrigo Formigone <
[email protected]> menulis:

Juga, jika Anda memutuskan untuk menggunakan three.js sebagai input ke kode Anda, bukan
cukup menggunakannya sebagai perpustakaan eksternal, Anda harus menambahkan bendera

--language_in=ECMASCRIPT5

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/mrdoob/three.js/issues/341#issuecomment -32191167
.

Salam,
Ben Houston
Suara: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom
http://Clara.io - Pembuatan Konten 3D Berbasis WebGL Kelas Profesional

Saya kira saya hanya bisa menulis posting seperti itu. Hanya untuk memperjelas, alasan seseorang ingin menjalankan Three.js melalui penutupan (dengan atau tanpa file eksternal) tidak harus hanya untuk optimasi kinerja. Penutupan terutama ditujukan untuk membantu Anda menulis kode yang dapat dipelihara dalam JavaScript (khususnya, basis kode yang sangat besar). Tujuannya adalah untuk membantu pengembang "menjinakkan" JavaScript (menulis JS asli), daripada "menghindarinya" (menggunakan GWT atau alat serupa lainnya). Jika Anda hanya mencoba mengkompilasi Three.js sebagai bagian dari proyek Penutupan, kompilator mungkin akan meneriaki Anda karena Three.js mungkin tidak sesuai dengan beberapa standarnya (mungkin tidak cukup dengan JSDoc?). Menggunakan flag compiler --language_in menyelesaikannya sampai sekarang, meskipun Anda akan mendapatkan beberapa peringatan. Jika Anda hanya ingin mengkompilasi kode JS Anda sendiri, tetapi mereferensikan Three.js sebagai perpustakaan eksternal (sehingga semua basis kode Three.js tidak tersentuh dan tidak dioptimalkan), Anda memerlukan file eksternal yang disebutkan di atas. Tanpa file eksternal, Penutupan akan memunculkan kesalahan kompilasi yang mengatakan bahwa THREE.* tidak dideklarasikan di mana pun, dll.

Meskipun saya tidak bisa menulis posting blog saya yang menjelaskan bagaimana dan mengapa seseorang mungkin ingin menggunakan Three.js pada proyek Penutupan, inilah presentasi pengantar terbaik tentang alat Penutupan Google yang pernah saya lihat: (Dari Google I/O 2011) https://www.youtube.com/watch?v=M3uWx-fhjUc (Saya tahu ini video yang panjang, tetapi benar-benar memperjelas apa tujuan dari kompiler, dan apa yang sebenarnya dilakukan oleh mode kompilasi yang berbeda. Ini juga menjelaskan mengapa Anda membutuhkan file eksternal).

Hai, Saya menantikan untuk mengembangkan aplikasi menggunakan three.js, dan karenanya menginginkan dukungan opsi ADVANCED_OPTIMIZATIONS.

Penghapusan kode mati sangat berhasil ketika aplikasi penyematan hanya menggunakan sebagian dari fungsi Three.js.

Saat ini, three.js membutuhkan setiap fungsi tunggal yang dikembangkan, karena penggunaan yang dimaksudkan terbatas pada "Hanya memerlukan three.min.js!". Pendekatan klasik ini mudah dimengerti, tetapi untuk kode yang ditulis oleh pendekatan ini, JavaScript minimizer dapat mengurangi kode ukuran hanya dengan mengecilkan nama variabel (tidak efektif untuk nama variabel pendek), menghapus spasi (hanya efektif untuk spasi indent, tab dan jeda baris) dan trik murah lainnya.

Dengan menggunakan opsi ADVANCED_OPTIMIZATIONS ke kode "Penutup gaya kompiler", itu dapat menghapus seluruh "kode yang tidak diperlukan", yang sebagian besar membebani perpustakaan besar. Perpustakaan seperti perpustakaan Penutupan telah menjadi besar, tetapi pengguna dan pengembang perpustakaan tidak mempedulikannya karena mereka tahu bahwa sebagian besar kode akan dihapus pada tahap kompilasi.

Karena three.js sudah ditulis dalam gaya berorientasi objek, saya pikir tidak (secara teknis) sulit untuk memperbarui seluruh kode ke kode "Closure compiler styled". Hal-hal yang saya khawatirkan ...

• Gaya kompiler penutupan memerlukan anotasi untuk setiap fungsi. Saat ini, tidak ada satupun dari mereka. Berapa lama waktu yang dibutuhkan untuk menambahkan anotasi ke semua fungsi yang pernah dikembangkan?
• Kompiler penutupan memerlukan definisi tipe yang ketat. Bahkan untuk null dan undefined, Anda harus bekerja dengan benar. Mungkin kerja keras untuk fungsi yang memiliki parameter "null-allowed", parameter "undefined-allowed", ...
• Anda harus menyiapkan file eksternal yang tepat, jika Anda ingin menyiapkan "perpustakaan versi lengkap" yang dikompilasi oleh ADVANCED_OPTIMIZATIONS.

Hai Jadwal Xor,

Ini adalah ide yang bagus untuk dilakukan. Bisakah Anda membagikan cuplikan kecil, tentang caranya
ini harus ditambahkan ke three.js?

Dengan hormat,

Ramsundhar Madhavan

Pada Selasa, 24 Jun 2014 jam 16:23, Jadwalkan Xor [email protected]
menulis:

Hai, Saya menantikan untuk mengembangkan aplikasi menggunakan three.js, dan
jadi menginginkan dukungan opsi ADVANCED_OPTIMIZATIONS.

Penghapusan kode mati sangat berfungsi ketika aplikasi penyematan hanya menggunakan
bagian dari fungsi Three.js.

Saat ini, three.js membutuhkan setiap fungsi yang dikembangkan, karena
penggunaan yang dimaksudkan terbatas pada "Hanya membutuhkan tiga.min.js!". Klasik ini
pendekatan ini mudah dimengerti, tetapi untuk kode yang ditulis oleh pendekatan ini,
Minimizer JavaScript dapat mengurangi ukuran kode hanya dengan mengecilkan nama variabel
(tidak efektif untuk nama variabel pendek), menghilangkan spasi (hanya efektif
untuk ruang indentasi, tab dan jeda baris) dan trik murah lainnya.

Dengan menggunakan opsi ADVANCED_OPTIMIZATIONS ke "Penutup gaya kompiler"
kode, itu dapat menghapus seluruh "kode yang tidak diperlukan", yang sebagian besar berbobot
perpustakaan besar. Perpustakaan seperti perpustakaan Penutup
https://developers.google.com/closure/library/ telah menjadi besar, tetapi
pengguna dan pengembang perpustakaan tidak mempedulikannya karena mereka tahu itu
sebagian besar kode akan dihapus pada tahap kompilasi.

Karena three.js sudah ditulis dalam gaya berorientasi objek, saya pikir itu
tidak (secara teknis) sulit untuk memperbarui seluruh kode ke "Penutup kompiler
styled". Hal-hal yang saya khawatirkan...

• Gaya kompiler penutupan memerlukan anotasi untuk setiap fungsi.
  Saat ini, tidak ada satupun dari mereka. Berapa lama waktu yang dibutuhkan untuk menambahkan anotasi
  untuk semua fungsi yang pernah dikembangkan?
• Kompiler penutupan memerlukan definisi tipe yang ketat. Bahkan untuk null dan
  undefined, Anda harus bekerja untuk mereka dengan benar. Ini mungkin kerja keras untuk
  fungsi yang memiliki parameter "null-allowed", "undefined-allowed"
  parameter, ...
• Anda harus menyiapkan file eksternal yang tepat, jika Anda menantikannya
  untuk mempersiapkan "perpustakaan versi lengkap" yang disusun oleh
  ADVANCED_OPTIMIZATIONS.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/mrdoob/three.js/issues/341#issuecomment -46957189.

@schedul-xor kami pasti membutuhkan bantuan dengan itu ... apakah penjelasan kode benar-benar diperlukan atau cukup dengan eksternal?

Hai,

Saya baru di komunitas ini, saya akan tertarik untuk berkontribusi ini
perubahan.

Dengan hormat,

Ramsundhar Madhavan

Pada Selasa, 24 Jun 2014 jam 19:23, Mr.doob [email protected] menulis:

@schedul-xor https://github.com/schedul-xor kami pasti membutuhkan bantuan
dengan itu ... apakah anotasi kode benar-benar diperlukan atau cukup dengan
eksternal?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/mrdoob/three.js/issues/341#issuecomment -46973166.

Ingatlah bahwa pengoptimalan lanjutan memerlukan gaya pengkodean tertentu atau mereka akan merusak kode Anda. Misalnya, three.js mencampur uniforms["diffuse"] dan uniforms.diffuse , yang tidak diizinkan dalam pengoptimalan lanjutan penutupan. Lihat juga #3222.

Menambahkan anotasi jenis yang ketat di mana-mana adalah pekerjaan yang sangat banyak, dan menambahkan banyak baris komentar (dalam proyek saya, itu meningkatkan jumlah baris dengan faktor 2).

Memiliki file eksternal untuk kerangka kerja/bahasa web lain itu bagus.

Menurut tutorial , externs digunakan untuk melindungi variabel yang tidak ingin Anda ganti namanya. Inilah yang Anda gunakan ketika Anda ingin melindungi (bergaya kompiler non-penutupan) perpustakaan pihak ketiga, menggunakan dalam proyek bergaya kompiler penutupan Anda, dari penggantian nama variabel yang agresif.

Saya tidak yakin apakah kompiler masih akan mencoba memotong kode mati bahkan ketika file eksternal adalah satu-satunya yang disediakan. Akan jauh lebih mudah jika Anda hanya menulis file eksternal, daripada menulis anotasi ke semua fungsi...

Padahal, menurut saya, menulis anotasi pada setiap fungsi lebih baik daripada menulis externs, karena setelahnya akan sulit untuk menyinkronkan file externs, jika jenis file definition dan source code berbeda. Anda mungkin membayangkan betapa menjengkelkannya jika setiap perbaikan fungsi memerlukan pembaruan file eksternal. Pilihan mana pun (eksternal atau /** */ mengomentari fungsi) memerlukan anotasi, dalam banyak kasus metode yang lebih mudah menang.

Karena three.js adalah proyek besar, saya bertanya-tanya di mana saya harus bekerja terlebih dahulu. Akan lebih baik untuk memulai dari apa yang dapat dengan mudah dilakukan.

Bagaimana dengan meletakkan header file, mengubah gaya definisi fungsi untuk setiap fungsi?

THREE.Material = function(){
  :
};
THREE.Material.prototype = {
    constructor: THREE.Material,
    setValues: function ( values1, value2 ) {}
    getValues: function () { return this.a; }
    :
};

↓

goog.provide('THREE.Material'); ← Write goog.provide('package.classname') at the first line

← three empty lines before <strong i="10">@constructor</strong>

/**
 * <strong i="11">@constructor</strong> ← Add <strong i="12">@constructor</strong> annotation to constructor
 */
THREE.Material = function(){
  :
};

← two empty lines before function definition
/**
 * <strong i="13">@param</strong> {!Array.<!string>} values1 Values1 explanation ← values1 is an array of strings. values1 can't be null, and elements inside values1 can't be null.
 * <strong i="14">@param</strong> {!number} value2 Value2 explanation ← value2 is a number.
 */
THREE.Material.prototype.setValue = function(values1, value2){
  goog.asserts.assertArray(values1);
  goog.asserts.assertNumber(value2);
  :
};


/**
 * <strong i="15">@return</strong> {!number} ← This function returns a non-null number.
 */
THREE.Material.prototype.getValue = function(){
  return this.a;
};

Akan lebih mudah untuk memperketat semua tipe parameter dan mengembalikan tipe nilai ke non-null. Ini akan membuatnya lebih mudah untuk melewati kesalahan kompilasi ADVANCED_OPTIMIZATIONS.

Hmmm, saya masih tidak terlalu senang dengan banyak komentar dalam kode. Terkadang saya bertanya-tanya apakah tidak lebih baik untuk mem -port semuanya ke sesuatu seperti sayang sekali yang dimiliki oleh Microsoft).

TypeScript terasa jauh lebih baik untuk javascript yang diketik dengan kuat daripada penutupan. Ini adalah pengalaman saya setelah menulis ulang colada loader berukuran sedang terlebih dahulu ke javascript yang sesuai dengan penutupan dan kemudian ke TypeScript. Kedua pendekatan membantu menemukan bug pada waktu kompilasi. Penutupan melakukan beberapa optimasi yang cukup bagus (inlining, penghapusan kode mati) dari kode saya, dan memiliki dukungan untuk tipe nullable. Di sisi lain, sejumlah besar komentar mengganggu dan dukungan IDE (untuk penyelesaian kode) tidak sebaik dengan TypeScript. Plus, menulis kelas dalam TypeScript jauh lebih mudah karena kata kunci class seperti ECMAScript6.

Tapi itu hanya pendapat pribadi. Lebih penting lagi, saya ingin menekankan lagi fakta bahwa Anda harus memastikan semua akses properti konsisten sebelum secara resmi mendukung penutupan dalam mode kompilasi lanjutan. Memiliki file eksternal tidak membantu, akses properti harus konsisten untuk objek internal yang tidak diekspor, karena Anda _ingin_ mereka diubah namanya/digarisbawahi/dihapus secara agresif. Anda akan mendapatkan akses properti yang tidak konsisten jika Anda memberi anotasi pada setiap kelas dan setiap variabel, tetapi melakukan ini untuk seluruh basis kode three.js membutuhkan waktu beberapa minggu (jika saya memperkirakan berapa lama waktu yang saya perlukan untuk membubuhi keterangan proyek saya).

Akhirnya, mem-porting proyek besar seperti three.js ke bahasa/kerangka/gaya pengkodean lain adalah sesuatu yang harus didiskusikan secara rinci.

Oke, saya setuju bahwa three.js sangat banyak, jadi menambahkan anotasi ke setiap fungsi mungkin memerlukan waktu beberapa minggu. Mungkin ada AltJS yang lebih baik daripada penutupan. Ini harus didiskusikan (jika Anda ingin memindahkannya ke hal lain) lebih dalam.

Maaf, saya tidak sabar. Saya akan memotong komit saat ini dan mulai porting.

Hai,

Apakah mungkin untuk menambahkan anotasi ini secara otomatis? Jika demikian, kami dapat menambahkannya
ke build.py dan tambahkan tepat sebelum kami mengaktifkan pengoptimalan penutupan lanjutan.

Dengan hormat,

Ramsundhar Madhavan

Pada hari Rabu, 25 Jun 2014 jam 06:05, Jadwalkan Xor [email protected]
menulis:

Oke, saya setuju bahwa three.js sangat banyak, jadi menambahkan anotasi ke masing-masing
fungsi dapat memakan waktu beberapa minggu. Mungkin ada AltJS yang lebih baik daripada
penutupan. Ini harus didiskusikan (jika Anda ingin memindahkannya ke
sesuatu yang lain) lebih dalam.

Maaf, saya tidak sabar. Saya akan memotong komit saat ini dan mulai porting.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/mrdoob/three.js/issues/341#issuecomment -47047966.

@ramsundhar20 , menurut saya, menambahkan anotasi (tidak akurat? lebih baik daripada tidak sama sekali. bukan masalah besar. dapat diperbarui) terlebih dahulu akan membuat otomatisasi jauh lebih mudah.

Three.js saat ini berisi 163 file javascript dengan 1354 fungsi yang ditentukan. Ya itu besar, tapi itu bukan tujuan yang terlalu jauh.

// Aku takut jika topik ini tidak pada tempatnya ...

@schedul-xor lagi, saya bukan penggemar komentar per fungsi :/

@mrdoob OK, saya mengerti.

Menghormati kebijakan Anda, saya ingin menambahkan komentar per fungsi hanya di garpu saya. Juga, saya tidak akan pernah membuat permintaan tarik. Sebagai gantinya, saya akan mem-porting modifikasi three.js asli ke garpu gaya penutupan saya. Pertimbangan menguntungkan Anda akan dihargai.

Kedengarannya bagus :)

Terima kasih! Saya akan mulai mengerjakannya.

Apakah setidaknya ada file base three.js externs untuk digunakan dengan kompiler penutupan? Itu tidak memerlukan kode sumber Three.js untuk memiliki anotasi gaya google tambahan, ini hanya untuk membuat penautan dari app.js eksternal yang menggunakan three.js cukup dapat dikompilasi/dikaburkan?

Saya juga sangat tertarik dengan kualitas, file eksternal lengkap untuk three.js. Ini satu, tapi tidak lengkap:

https://github.com/cljsjs/packages/blob/master/three/resources/cljsjs/three/common/three.ext.js

Saya kira salah satu cara untuk pergi adalah memulai dengan yang ini, dan secara manual menambahkan barang-barang yang Anda gunakan.

Ya, hitung suara saya. Idealnya untuk mode lanjutan yang dapat dikompilasi, 100% diketik threejs - atau setidaknya file eksternal.

Inferensi tipe menjadi lebih baik dan kekacauan yang diperlukan berkurang. Dengan cakupan dan alias yang ada, kode tidak harus dibaca secara verbose seperti library penutupan. Cukup banyak bermuara pada penulisan dokumen sebaris yang diketik dalam hal kode bersih. Apakah itu benar-benar cukup buruk untuk melebihi semua manfaatnya?

Pengaturan super-agresif, yaitu mode lanjutan + kompresi JS + pengoptimalan berbasis tipe, tidak hanya akan menghapus kode mati tetapi dapat melakukan semua hal keren yang dapat dilakukan oleh kompiler pengoptimalan:

Konstanta/enum bernama akan diganti dengan angka. Juga, kompiler dapat melacak constness, melakukan perhitungan dengan konstanta lain dan akhirnya memasukkan angka biasa di tempat yang diperlukan. Kontrol aliran dependen menjadi sasaran eliminasi kode mati, tentu saja. Fungsi yang hanya memiliki satu situs panggilan aktif dalam aplikasi yang dihasilkan dan yang bentuk terkompresinya akan menjadi lebih kecil dari definisinya akan disimpan menjadi inline. Ruang nama dihapus. Semua nama yang tidak dilindungi diciutkan seminimal mungkin.

Pencarian relatif mahal dalam JavaScript. Kombinasi penggantian nama, pelipatan konstan dan inlining akan menghapus banyak pencarian ditambah banyak panggilan fungsi. Selain itu, diberikan header yang sesuai (ada satu di perpustakaan penutupan), semua konstanta WebGL standar dapat dimasukkan ke dalam penyaji.

Hasilnya adalah perpustakaan yang lebih kecil, lebih cepat, didokumentasikan sendiri, dan dapat disesuaikan secara otomatis. Kompiler juga akan menangkap lebih banyak bug di bawah pengaturan yang lebih agresif - ini mungkin akan memudahkan peninjauan kode. Last but not least, ada efek kebingungan: Menyatukan kode klien dengan perpustakaan yang disesuaikan memberikan perlindungan yang jauh lebih baik terhadap pencurian kekayaan intelektual daripada kode dengan simbol pengungkapan yang diawetkan melalui file eksternal.

Saya tidak dapat menemukan cabang yang disebutkan di atas. Apakah ada yang masih mengerjakan versi yang diketik?

@mrdoob Ada harapan untuk perubahan hati mengenai jalur utama?

Saya akan dengan senang hati membantu.

@mrdoob Ada harapan untuk perubahan hati mengenai jalur utama?

Saat ini saya fokus pada refactoring WebGLRenderer

Dapat mengubah konstanta menjadi const daripada var memiliki dukungan yang baik untuk semua browser WebGL https://kangax.github.io/compat-table/es6/ (const->basic) dan js engine mulai dioptimalkan untuk const Mempercepat konstanta global menggunakan pengoptimalan bidang tetap

Menarik, karena hanya berfungsi sebagai pengganti var , hanya berlaku untuk sebagian kecil dari kasus yang saya bicarakan - bahkan ketika itu hanya tentang konstanta. Lebih lanjut, kompiler JIT terburu-buru menurut definisi sehingga mereka secara alami tidak dapat bersaing dengan pengoptimalan seluruh program yang dilakukan oleh alat offline. Setiap mesin JS harus menghormati struktur kode dan tidak dapat melakukan refactor secara sewenang-wenang seperti yang kita harapkan dapat misalnya membuka konsol dan menemukan program yang kita masukkan ke dalamnya, mengganti fungsi tertentu, dll.

Kembali ke dukungan kompiler penutupan: Saya melakukan beberapa pembacaan dan eksperimen. Inilah yang saya temukan:

• Tidak diperlukan anotasi untuk menjalankan mode lanjutan,
• anotasi dapat ditambahkan secara bertahap untuk meningkatkan tingkat pengoptimalan, dan
• loader membutuhkan perawatan agar tetap berfungsi, tetapi ini cukup mudah.

Pada dasarnya ada tiga kasus penggunaan yang berbeda:

1. Model dapat dikompresi bersama dengan aplikasi dan perpustakaan.
2. Aplikasi dan perpustakaan dikompresi. Model dimuat saat runtime.
3. Pustaka dikompilasi dalam mode dasar dan aplikasi mode lanjutan ingin menggunakannya.

Yang ketiga membutuhkan file eksternal untuk semua Three.js dan banyak pekerjaan untuk manfaat IMO yang terlalu sedikit. Jadi saya hanya akan membahas dua yang pertama - ini adalah yang lebih disukai:

Ketika kompiler melihat

anObject['aProperty']

itu tidak akan menyentuh nama properti (tidak ada string yang pernah diubah).

anObject.aProperty

di sisi lain memungkinkan kompiler untuk secara konsisten mengganti nama properti, kecuali ia mengetahui bahwa anObject berada di luar aplikasi yang sedang dikompilasi. Kompiler mengetahui hal ini dari _externs_ bawaan atau yang disediakan secara eksplisit.

Ini dia resepnya:

• Kami membuat loader secara konsisten mengakses properti menggunakan notasi titik.
• Kami mengetik input dan menulis file eksternal hanya untuk JSON .
• Mengkompilasi dengan file eksternal itu harus menjadi semua yang diperlukan agar use case 2 berfungsi.
• Untuk kasus penggunaan 1 kami tidak menggunakan file externs, melainkan menghapus tanda kutip dari kunci objek di JSON:

{
    "camera": {
        "object": {
    // ...

hanya akan menjadi

{
    camera: {
        object: {
    // ...

Cukup sederhana, bukan?

Kasus penggunaan 1 menjadi lebih menarik ketika format JSON memungkinkan data biner eksternal (mentah atau dikompresi melalui webgl-loader atau o3dgc) - secara teknis fitur lain yang sepenuhnya ortogonal untuk dukungan penutupan, tentu saja.

File eksternal juga dapat menggantikan halaman Wiki yang selalu ketinggalan zaman yang mendokumentasikan format file :-).

Saya tahu masalah ini telah ditutup untuk beberapa waktu. Namun saya baru-baru ini memiliki masalah yang sama menggunakan three.js dalam proyek kompiler penutupan dan mendarat di halaman ini. Saya menulis alat yang mengubah .d.ts (file deklarasi TypeScript) menjadi file kompilator penutupan. Menggunakan alat dan file deskriptor PastiTyped/threejs yang dijelaskan dengan baik berfungsi dengan sempurna.
Alat: https://github.com/eredo/tsd2cce atau instal melalui npm install -g tsd2cce

Semoga ini membantu...

@eredo yang benar-benar membantu saya. Semua generator lain yang saya coba tidak memiliki banyak definisi metode untuk pustaka three.js. Terima kasih!

@eredo @Corkle atau siapa pun, dapatkah Anda menunjukkan kepada kami cara menggunakan tsd2cce ? Argumen pertama jelas merupakan file definisi .d.ts, tetapi apa argumen kedua? Saya mendapatkan masalah ini. https://github.com/eredo/tsd2cce/issues/6

Sebenarnya saya menemukan bahwa menggunakan r73 d.ts dari Februari tidak berfungsi dengan baik dengan tsd2cce, r73 terlalu tua untuk saya.

Cara yang tepat untuk melakukan ini sekarang adalah dengan menggunakan tsickle untuk menghasilkan dari file d.ts.

Hai semua,

Untuk anak cucu dan keuntungan semua orang, saya memutuskan untuk melaporkan di sini atas upaya saya sendiri untuk mengecilkan perpustakaan lebih lanjut dengan ADVANCED_OPTIMIZATIONS dari Google Closure Compiler, dan beberapa penyesuaian lainnya.

Saya telah membuat extern.js yang memungkinkan Three.min.js dengan pengoptimalan lanjutan diaktifkan. Ini JAUH dari sempurna.

Untuk membuatnya, saya mulai dengan extern.js berdasarkan contoh sebelumnya di utas ini. Pustaka rusak saat dikompilasi dengan cara ini karena properti yang rusak tidak disertakan dalam file eksternal itu. Menggunakan opsi --property_renaming_report pada kompiler penutupan, saya mendapatkan daftar lengkap properti yang rusak. Setelah menambahkan SEMUA properti ini ke extern.js, properti tidak lagi rusak dan hasilnya sama dengan SIMPLE_OPTIMIZATIONS. Dari sana saya secara selektif/manual mulai mengomentari bagian extern.js dan mengonfirmasi bahwa perpustakaan masih berfungsi dalam bentuk yang diperkecil.

Saya akan SENANG untuk mengotomatiskan tebak-dan-periksa ini dan mendapatkan extern.js sempurna yang dengan aman menghancurkan sebanyak mungkin nama properti. Saya memiliki ide untuk menggunakan tes unit untuk THREE.JS dan secara terprogram menentukan propname mana yang rusak yang menghasilkan tes yang gagal, tetapi tampaknya tidak mungkin untuk menjalankan tes unit dari baris perintah saat ini, misalnya dengan phantomjs. (Mungkin karena WebGL)?

Either way ini adalah "kemajuan" menuju perpustakaan kecil yang lebih kecil, membantu saya menjaga ukuran javascript SPA saya secara keseluruhan tetap rendah.

externs.js

perintah package.json build-closure yang diperbarui

Saya juga menggunakan perintah ganti string untuk menghapus semua pesan console.warn dan console.error dari perpustakaan, seperti yang Anda lihat di perintah build-closure. Dengan ini, dan mengomentari bagian kode tertentu, sejauh ini saya telah mengecilkan lib yang diperkecil sekitar 20%, dan ada ruang untuk perbaikan.

@mrdoob Melakukan sesuatu seperti metode saya di sini, Anda akhirnya dapat menyediakan extern.js yang memungkinkan untuk ADVANCED_OPTIMIZATIONS tanpa mengacaukan kode dengan anotasi khusus untuk kompiler itu, yang tampaknya menjadi perhatian utama Anda.

@medmr1 Luar biasa! Sudahkah Anda mencoba mengkompilasi aplikasi Anda dengan pustaka three.js semuanya dalam satu? Ini akan mencegah kebutuhan akan file eksternal secara ideal.

Saya belum mencoba membangun semuanya dalam penutupan, tidak. Itu mungkin berfungsi dengan baik, tetapi saya curiga masih akan ada masalah sehubungan dengan merusak beberapa properti yang dirujuk secara terprogram? IE hal-hal seperti var thing = ShaderLib[ shaderType + "BumpMapFrag"] Tapi mungkin saya akan menyelamatkan diri dari banyak masalah?

Ya, sesuatu seperti var thing = ShaderLib[ shaderType + "BumpMapFrag"] akan rusak dengan pengoptimalan lanjutan. referensi properti perlu dianalisis secara statis. Anda dapat melakukan sesuatu seperti:

function(shaderType) {
  if (shaderType == "a") {
    return ShaderLib.aBumpMapFrag;
  }
  if (shaderType == "b") {
    return ShaderLib.bBumpMapFrag;
  }
...

Membangun file eksternal yang benar pasti lebih bermanfaat untuk proyek secara keseluruhan karena kebanyakan orang tidak akan mengkompilasi aplikasi mereka dengan Closure Compiler, hanya menggunakan versi minified yang diterbitkan.

Alih-alih eksternal, Anda juga dapat mencoba anotasi @export .
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#export -export-sometype