Pixi.js: BANTUAN DIPERLUKAN: Upaya Konversi ES6

Dibuat pada 14 Sep 2016  ·  43Komentar  ·  Sumber: pixijs/pixi.js

Halo pengembang pixi!

Berkat PR #2936 ini (berteriak ke @leonardo-silva!) kami telah memulai upaya untuk mengubah basis kode Pixi.js ke ES6. Tujuan pemutakhiran ini adalah untuk membuktikan masa depan serta membuat Pixi.js lebih mudah dipelihara. Sementara sumbernya adalah ES6, kami akan terus membangun JavaScript yang kompatibel dengan ES5 menggunakan Babel. Tapi mudah-mudahan di masa depan kami akan dapat menyediakan ES6+ build.

Biasanya jenis perubahan ini sangat menantang dan sulit dilakukan karena mengganggu PR dan pengembangan yang ada, jadi idealnya kami ingin mencapai stabilitas secepat mungkin. Jadi, kami membutuhkan bantuan Anda!

Ada beberapa hal yang akan sangat berguna jika Anda ingin membantu:

  • Kami telah menyiapkan cabang dev-es6 dan menyambut PR ke cabang itu bagi mereka yang mahir dengan ES6. Khususnya, mencari PR tambahan untuk menambahkan lebih banyak penggunaan const , fungsi panah gemuk, dan getter statis.
  • Kami membutuhkan bantuan untuk menguji kinerja Babel build untuk memastikan kami tidak mengkompromikan kecepatan Pixi yang luar biasa yang kami semua sukai.
  • Kami dapat menggunakan bantuan pengujian asap build terbaru di cabang ini (lihat di bawah untuk tautan build). Silakan tambahkan ini ke proyek v4 Anda dan posting jika Anda menemukan masalah.
  • Kami dapat menggunakan bantuan pengujian asap dokumentasi untuk memastikan jsdoc masih berfungsi dengan baik dengan ES6 (lihat tautan di bawah)

ES6 Build
http://s3-eu-west-1.amazonaws.com/pixi.js/dev-es6/pixi.js
http://s3-eu-west-1.amazonaws.com/pixi.js/dev-es6/pixi.min.js

Dokumentasi
http://s3-eu-west-1.amazonaws.com/pixi.js/dev-es6/docs/index.html

Komentar yang paling membantu

Saya akan menyarankan kepada kalian untuk mempertimbangkan menggunakan TypeScript sebagai bagian dari penulisan ulang/adaptasi utama ini. Hanya beberapa poin tentang TypeScript:

  • Menggunakan sistem tipe dalam JavaScript akan menjadi standar baru, hanya masalah waktu.
  • Ini adalah JavaScript. Tidak ada perbedaan sintaks selain sistem tipe.
  • Meningkatkan kualitas kode. Anda mungkin akan menemukan sejumlah besar kode yang perlu sedikit direstrukturisasi agar sesuai dengan jenis di tempat yang tepat.
  • Tingkatkan pemeriksaan kualitas permintaan tarik - jika ada beberapa masalah jenis, tambalan tidak dapat digabungkan.

Saya tahu ini bukan tugas yang mudah, tetapi saya yakin ini dapat membawa manfaat besar bagi basis kode dan komunitas.
Bersulang!

Semua 43 komentar

Rute mana yang ingin Anda lewati dengan let dan const? Default ke const, dan hanya gunakan let untuk properti yang referensinya harus diubah
Atau
Default untuk membiarkan, dan hanya menggunakan const sebagai petunjuk kepada pengembang bahwa mereka, saya serius, tidak mengubah ini.

Opsi sebelumnya. Default untuk menggunakan const. Saya mengonversi semua var internal untuk membiarkan dan memperbaiki masalah pelingkupan yang jelas dan melarang penggunaan var dengan jshint. Membutuhkan pass lain dengan const.

Hal-hal yang saya sarankan:

  • [x] Gunakan babel-preset-es2015-loose , saya memiliki kinerja yang buruk hanya dengan babel-preset-es2015 saja.
  • [x] Beralih ke eslint , ia memiliki dukungan ES6 yang lebih baik dan hanya lebih baik daripada jshint pada umumnya. Inilah titik awal yang baik untuk gaya pixi. Itu juga akan mengeluh tentang tempat-tempat yang dapat Anda gunakan const tetapi digunakan let . Memudahkan untuk menemukan semua tempat yang perlu Anda perbaiki untuk const.
  • [x] Gunakan master jsdoc terbaru, ia memiliki banyak perbaikan ES6 di sana yang belum dirilis.
  • Beralih ke paket web.

Terima kasih @englercj. Daftar yang bagus.

@englercj Babel -preset-es2015-loose memiliki peringatan penghentian, apakah Anda mencoba babel-preset-es2015 dengan opsi {"loose": true} seperti yang disarankan?

Saya juga lebih suka webpack daripada browserify, beberapa tautan berguna:
https://github.com/webpack/webpack/tree/master/examples/multi-part-library
http://krasimirtsonev.com/blog/article/javascript-library-starter-using-webpack-es6

Preferensi saya adalah menunggu di webpack dan tidak menumpuknya. Berpotensi untuk PR lain yang lebih kecil. Perubahan itu mewakili perubahan proses build tetapi belum tentu peningkatan ke ES6. Juga, perlu memastikan bahwa peta sumber, header, dll. berfungsi. Saya mengerti bagaimana ini lebih baik tetapi mari kita tunggu untuk saat ini.

Babel-preset-es2015-loose memiliki peringatan penghentian, apakah Anda mencoba babel-preset-es2015 dengan opsi {"loose": true} seperti yang disarankan?

Ha, itu _just_ ditambahkan 2 minggu yang lalu. Saya belum mencobanya karena tidak ada pada saat saya mulai menggunakannya.

Halo semuanya,

Hanya teriakan cepat untuk menggemakan pemikiran Chad tentang mode longgar, dan tambahkan dua sen saya di sini.
Seperti yang telah kita diskusikan dengan @GoodBoyDigital sebelumnya, kita harus benar- benar berhati-hati tentang kinerja, jadi saya pikir mode longgar adalah titik awal yang baik.

Juga, saya tidak yakin seberapa mutakhir tabel ini: https://kpdecker.github.io/six-speed/ apakah kalian tahu?

Jika masih maka kita harus berhati-hati untuk tidak menjadi gila ES2015 dan mengubah hal-hal yang tidak perlu, yaitu: jika for-of masih menurunkan kinerja seperti yang tertulis di atas meja, kita harus' t menggunakannya saat iterasi anak-anak grafik adegan.

Babel sekarang harus mengoptimalkan for-of untuk array (lihat: Optimization ), tes tersebut tampaknya sudah cukup lama .

Bagaimanapun, @alvinsight Anda benar, semuanya tidak harus ES2015.

Daftar yang bagus @englercj !

Juga setuju dengan @alvinsight. Kami sudah melihat banyak kode yang lebih bersih dengan sintaks es6 jadi menangkan semuanya :)

Setiap keputusan lain harus didasarkan pada kinerja - 'Apakah itu terlihat lebih baik tetapi berjalan lebih lambat - jangan lakukan itu'

Perulangan array adalah contoh yang baik - tidak perlu mengganti hal-hal yang sudah cepat dan mudah dibaca hanya karena kita bisa.

Juga ya untuk webpack! @bigtimebuddy benar, itu harus menjadi bagian kedua dari peralihan ini ke es6.

Sepakat!
Jauh lebih menyenangkan akhirnya bisa membaca dan menulis class Sprite extends Container !

Diperbarui

  • Mengganti jshint dengan eslint (dan memperbaiki kesalahan linting, eslint untuk menang!)
  • Menggunakan loose: true dengan babel-preset-es2015

Malam semua!

Pukul sedikit masalah dengan mixin kami..

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

Di atas saat ini tidak berfungsi di cabang ES6 sehingga hal-hal seperti interaksi rusak.

Apakah ada cara yang bagus untuk melakukan ini dengan kelas es6?

Tolong jawab di kartu pos!

Ok saya benar pertama kali - kode di atas tidak berfungsi saat ini .. (Dapatkah saya menyalahkan ini karena ini Jumat malam?)

Saya kira di sinilah komposisi bersinar!

Hmm, apa yang tidak berhasil? Ini berhasil untuk saya:

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

Salin tempel itu ke konsol chrome, dan sepertinya berfungsi dengan baik.

Menarik! Saat ini interaksi tidak berfungsi dan properti interaktif tampaknya tidak ada. Mungkin alasan lain? Akan terus menggali...

Ah! Menemukannya

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

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

Mungkin?

ya!

PR 1 di sini: https://github.com/pixijs/pixi.js/pull/2960

Ini memperbaiki beberapa bit seperti mixin dan teks.

Besok saya akan melihat filter ...

Terlihat sangat bagus meskipun bab!

Kerja bagus! Yah, menggunakan require() seperti itu akan mengembalikan objek dengan satu kunci default yang berisi semua yang Anda harapkan.

Filter terlihat bagus sekarang! Jalankan ini pada proyek saat ini yang sedang saya kerjakan yang cukup rumit - dan semuanya tampaknya berfungsi 100%!

Mungkin mengujinya di beberapa game lain tetapi seharusnya bagus untuk segera digabungkan!

@bigtimebuddy sudahkah Anda mencoba build ini dengan pixi-animate?

Membuang ini di luar sana .. traceur tampaknya lebih cepat dari babel?
Layak diselidiki?

https://kpdecker.github.io/six-speed/

Tes-tes itu sudah tua, dan tidak berjalan dengan babel longgar. Selain itu, Anda juga dapat berargumen bahwa dalam banyak kasus TypeScript lebih cepat dari keduanya :)

Saya akan menyarankan kepada kalian untuk mempertimbangkan menggunakan TypeScript sebagai bagian dari penulisan ulang/adaptasi utama ini. Hanya beberapa poin tentang TypeScript:

  • Menggunakan sistem tipe dalam JavaScript akan menjadi standar baru, hanya masalah waktu.
  • Ini adalah JavaScript. Tidak ada perbedaan sintaks selain sistem tipe.
  • Meningkatkan kualitas kode. Anda mungkin akan menemukan sejumlah besar kode yang perlu sedikit direstrukturisasi agar sesuai dengan jenis di tempat yang tepat.
  • Tingkatkan pemeriksaan kualitas permintaan tarik - jika ada beberapa masalah jenis, tambalan tidak dapat digabungkan.

Saya tahu ini bukan tugas yang mudah, tetapi saya yakin ini dapat membawa manfaat besar bagi basis kode dan komunitas.
Bersulang!

@endel Saya memindahkan pixi-spine ke TypeScript, akan ada demo plugin TS untuk pixi.

@endel hanya ingin tahu, tetapi apakah TS telah menyelesaikan masalah yang dimilikinya ketika saya terakhir melihatnya: bahwa ini adalah situasi semua atau tidak sama sekali dalam hal output, yaitu _semuanya_ ditranspilasikan kembali ke ES5, atau tidak sama sekali, berdasarkan target ?

Saya ingat itu tidak menggunakan polyfill sama sekali. Jadi, jika Anda ingin satu basis kode berjalan di berbagai browser, dari yang canggih hingga yang lawas, Anda masih harus menargetkan ES5, dan semua fitur baru yang bagus, yang sekarang didukung oleh browser modern secara native, abaikan saja karena itu downgrade ke ES5 sih? Atau apakah Anda masih perlu menggunakan ES6 polyfill di atas keluaran TS untuk mencakup semua basis?

bahwa ini adalah situasi semua atau tidak sama sekali dalam hal output, yaitu semuanya ditranspilasikan kembali ke ES5, atau tidak sama sekali, berdasarkan target?

Tidak yakin apa yang Anda maksud dengan ini. Jika Anda menargetkan ES5, itu mengubah sintaks ke ES5. Tapi begitu juga babel, tracuer, et al. Apakah ada sesuatu yang spesifik yang Anda maksud?

Saya ingat itu tidak menggunakan polyfill sama sekali.

Tidak, tetapi sekali lagi tidak babel, tracuer atau transpiler lainnya; jadi saya tidak yakin apa yang Anda kendarai? Kita harus menggunakan polyfill core-js dengan cara apa pun (babel atau TS).

Saya pikir pembahasannya adalah babel untuk mengubah ES6 -> ES5 atau TypeScript untuk mengubah TS -> ES5. Kita harus menggunakan ES5. TS dapat menargetkan ES6, dan kami dapat mengirimkan build ES6 jika kami menginginkannya, tetapi itu akan menjadi tambahan untuk build ES5.

@photonstorm Dengan TypeScript, sejauh pengetahuan saya, Anda tidak dapat memilih dan memilih fitur untuk ditranspile ke ES5 seperti yang Anda bisa dengan Babel.

Saya menggunakan TypeScript dan menurut saya itu luar biasa. Akan senang melihat Pixi akhirnya mengadopsi. Google sekarang mendorong pengembang untuk menggunakan TypeScript dengan Angular, yang merupakan pertanda baik dari adopsi yang meluas. Untuk basis kode yang kompleks adalah Pixi, akan dilayani dengan baik oleh pengetikan yang ketat.

Beberapa masalah yang perlu diatasi dengan TypeScript akan mencakup jsdocs (ada yang punya pengalaman dengan ini?) dan dependensi upstream yang mungkin menggunakan src ketika require('pixi.js') (adakah yang membutuhkan seperti ini?).

Sebagai langkah pertama, pindah ke ES6 masih merupakan pilihan yang baik, karena bagaimanapun kita harus mengonversinya ke kelas. Kami dapat mempertimbangkan TypeScript sebagai "lulus" lain untuk memodernisasi basis kode setelah kami yakin semua masalah dapat diatasi.

Dengan TypeScript, sejauh pengetahuan saya, Anda tidak dapat memilih dan memilih fitur untuk ditranspile ke ES5 seperti yang Anda bisa lakukan dengan Babel.

Saya tidak tahu Anda bisa melakukan itu dengan babel. Saya tidak yakin saya melihat manfaatnya bagi kami karena kami harus menargetkan ES5. Tapi itu rapi!

Beberapa masalah yang perlu ditangani dengan TypeScript akan mencakup jsdocs

https://github.com/TypeStrong/typedoc

dependensi hulu yang mungkin menggunakan src saat membutuhkan('pixi.js') (adakah yang membutuhkan seperti ini?).

Kami dapat mengarahkan "utama" ke apa pun yang kami inginkan, dan dengan TypeScript Anda mengarahkannya ke file yang dibuat (bukan _bundle_). Misalnya, file TS masuk ke src/ dan Anda mengubah setiap file menjadi js/ atau sesuatu, lalu arahkan main ke sana. Kemudian kami juga menggabungkan semuanya dan menempatkan bundel di dist/ atau w/e. Paket npm dikirimkan dengan file js/tsd tetapi bukan sumber TS biasanya (dapat diperdebatkan).

Sebagai langkah pertama, pindah ke ES6 masih merupakan pilihan yang baik, karena bagaimanapun kita harus mengonversinya ke kelas. Kami dapat mempertimbangkan TypeScript sebagai "lulus" lain untuk memodernisasi basis kode setelah kami yakin semua masalah dapat diatasi.

👍

Dengan TypeScript, sejauh pengetahuan saya, Anda tidak dapat memilih dan memilih fitur untuk ditranspile ke ES5 seperti yang Anda bisa lakukan dengan Babel.

Mereka menambahkan fitur ini pada TypeScript 2.0: https://github.com/Microsoft/TypeScript/wiki/What 's-new-in-TypeScript#termasuk-built-in-type-declarations-with---lib

Biasanya menggunakan ES5 sebagai target tetapi menyertakan ES6 sebagai perpustakaan, untuk memiliki definisi tipe untuk hal-hal seperti Symbol , Map , dll.

Memang, seperti yang dikatakan @englercj , Anda harus memasukkan shims setelah kode Anda dikompilasi, apa pun kompiler yang Anda gunakan. Babel tidak menyertakan polyfill Symbol untuk IE9 secara otomatis, misalnya.

Saya tidak tahu Anda bisa melakukan itu dengan babel. Saya tidak yakin saya melihat manfaatnya bagi kami karena kami harus menargetkan ES5. Tapi itu rapi!

Untuk Pixi, tidak terlalu berguna, tapi ya, Anda dapat memilih preset Babel untuk memilih hanya fitur tertentu yang akan diubah. Ini dapat berguna jika Anda ingin membangun ke ES6 tetapi hanya ingin mendukung fitur-fitur canggih V8 di Node 6, Electron 1, dll.

Sungguh paradoks yang menarik. Gunakan ES6 untuk membangun, karena bersih, dan indah, dan didukung dengan sangat baik / dioptimalkan secara internal oleh browser modern. Namun semua kerja keras itu dihancurkan dengan transpiling seperti tahun 1995 :) (dan dengan perubahan sintaksis bahasa Anda tidak dapat menghindarinya).

Saya menghargai masalahnya universal, tidak ada hubungannya dengan TS atau Pixi. Hanya sedikit situasi yang aneh untuk berada di dalamnya.

@photonstorm Sungguh ironi yang disayangkan semoga kita dapat memiliki build ES6 dan ES5 sehingga untuk aplikasi yang dikemas (seperti elektron) mereka dapat menggunakan build ES6.

Langsung saja ke diskusi di sini :) Saya pernah melihat orang mentranspile TS ke ES6 kemudian menggunakan Babel untuk mentranspilenya ke ES5, saya kira jika Anda ingin sesuatu seperti fitur tertentu ditranspilasikan, itu akan cukup bagus?

Juga, ada (lain lagi ...) modul bundler sekitar, namun saya pikir yang satu ini tampaknya menghasilkan beberapa kode yang cukup apik, dengan kemungkinan beberapa output.
http://rollupjs.org/ ini dibundel dari sintaks modul ES6/ES2015, yang menurut saya cukup bagus jika Anda ingin membuktikan kode di masa mendatang.

saya +1 untuk PIXI sedang ditulis dalam TypeScript. Dari pengalaman saya, type sangat membantu dengan struktur untuk proyek seperti ini. Andai saja bisa tetap perform :)

RollUp luar biasa, saya suka menggunakannya. Getaran pohonnya benar-benar cerdas. Digunakan dengan bubel (bukan babel) itu membuat alur kerja yang sangat, _sangat_ cepat.

Menarik untuk melihat begitu banyak cinta TS di sini. Tentu saja tidak setahun yang lalu :) Ada cara untuk mengetik cek ES2015 yang mungkin layak dipertimbangkan.

@photonstorm tidak menemukan bubel, tapi ada "buble"

Ya ya, salah ketik. http://buble.surge.sh/

BubleTape adalah alat uji yang bagus untuk itu https://github.com/snuggs/buble-tape

Apakah #2936 alasan mengapa Anggota meninggalkan dokumen? Ini memiliki satu anggota yang terbuka, di mana ini memiliki 25+.

Apakah @memberof perlu ditambahkan sekarang, atau adakah keajaiban yang bisa diterapkan?

@staff0rd Saya pikir kami masih membersihkan semuanya, setelah sedikit stabil, kami akan melihat untuk membersihkan dokumen. Kemungkinan besar itu hanya karena versi jsdoc yang kami gunakan memiliki bug ES6. Kita harus bisa segera membersihkannya.

ES6 telah digabungkan ke dev , terima kasih semua orang yang membantu. Ini sangat dihargai!

Menutup ini untuk saat ini.

Utas ini telah dikunci secara otomatis karena tidak ada aktivitas terbaru setelah ditutup. Silakan buka edisi baru untuk bug terkait.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat