Pixi.js: Bantuan Dicari: Pembaruan Konversi TypeScript

Kiat lainnya:

• Coba pisahkan semua import ekstra (sebenarnya tipe impornya) dari impor yang ada. Kami akan menambahkan import type saat versi TS baru diluncurkan. Namun linter akan menghentikan Anda menggunakan dua baris import dari modul yang sama, tidak masalah untuk mencampurnya dalam kasus itu.

• Anda dapat menggunakan notasi Array<X> dan X[] , saya biasanya menggunakan Array<X> untuk struktur yang sering didorong (alias Daftar). X[] untuk hal-hal yang memiliki panjang tetap kecil atau jika ukuran ditentukan di tempat yang sama mereka dibangun (array biasa).

• Jika bidang readonly diubah hanya di destroy() - Anda dapat menggunakan konversi any di sana. Jika digunakan di tempat lain - hapus readonly . Kita dapat memutuskan apakah akan menjadikannya private field + readonly property nanti.

Saya bisa melakukan @pixi-text akhir pekan ini kecuali seseorang mengalahkan saya.

catatan: @pixi-tiling akan memiliki PIXI.TilingSprite.from yang malam tidak mungkin dilakukan di TS. Kita hanya bisa mencelanya.

Ayo, @qtiki. Saya akan online di akhir pekan jika Anda menemukan hal-hal aneh.

Ok, @qtiki , pilihan Anda akan dipesan setelah mengirim draft PR.
Terima kasih!

Sepakat. Draf PR adalah cara terbaik untuk mengklaim paket yang akan dikonversi. Terima kasih telah membantu

Ok, @qtiki , pilihan Anda akan dipesan setelah mengirim draft PR.
Terima kasih!

Saya membuka draft PR #6390. Saya baru saja mengganti nama file .js menjadi .ts untuk memiliki beberapa perubahan agar dapat membuat PR. Saya akan mencoba dan melakukan konversi yang sebenarnya akhir pekan ini.

Beberapa hal umum yang saya temui saat mengonversi paket Teks ke TypeScript:

Jadi saya mengalami masalah mendasar dengan properti TypeScript. Tampaknya TypeScript tidak mendukung berbagai jenis untuk pengambil dan penyetel properti: https://github.com/microsoft/TypeScript/issues/2521

Ada beberapa tempat di kelas Text dan TextStyle di mana ini akan menjadi keuntungan besar. Misalnya fillStyle dan stroke di TextStyle menerima angka yang kemudian diubah menjadi string, jadi pengambil tidak boleh mengembalikan tipe gabungan dengan angka. Sekarang setelah mengembalikan tipe gabungan dengan nomor, saya harus memberikannya agar dapat meneruskannya ke CanvasRenderingContext2D fillStyle .

Juga kelas Teks itu sendiri menerima objek dengan gaya teks, yang kemudian diteruskan ke new TextStyle - atau turunan dari TextStyle secara langsung. Demikian pula di sini pengambil akan selalu mengembalikan instance TextStyle tetapi harus diketik dengan tipe gabungan yang sama dengan penyetel. Jadi ini akan menyebabkan beberapa pemeriksaan tipe yang tidak perlu (atau gips) di userland untuk dapat memanggil metode TextStyle.

Saya tidak benar-benar tahu apa solusi terbaik untuk ini dalam jangka panjang, tetapi untuk saat ini saya kira itu hanya perlu dilakukan.

Satu hal lain yang saya perhatikan adalah ada cukup banyak kode yang menggunakan kembali variabel lokal dengan tipe berbeda, yang tidak cocok dengan TypeScript. Saya tidak ingin terlalu banyak menyentuh kode yang ada jadi saya hanya menggunakan tipe serikat pekerja dan beberapa casting jelek di sana-sini untuk membuatnya dikompilasi. Saya kira hal-hal semacam itu dapat ditingkatkan dari waktu ke waktu dengan prinsip pramuka .

@qtiki
Mengapa Anda menulis masalah dalam topik ini bukan PR Anda?

@qtiki
Mengapa Anda menulis masalah dalam topik ini, bukan PR Anda?

Saya percaya ini adalah masalah umum yang akan dihadapi orang di tempat lain dengan konversi TypeScript dan bukan hanya masalah khusus paket teks. Masalah properti untuk satu adalah sesuatu yang merupakan pertanyaan desain mendasar untuk masa depan jika mereka harus diketik dengan benar.

Saya telah mempelajari masalah dengan setter dan pengambil TypeScript yang tidak dapat menggunakan tipe yang berbeda sejak saya mengalaminya. Tampaknya masalahnya adalah masalah yang sangat kompleks dan mungkin tidak akan pernah "diperbaiki". Jadi, inilah saran saya untuk pedoman umum dalam mengonversi jenis properti ini ke TypeScript:

Ini adalah contoh sederhana dari apa yang kita inginkan: properti yang menerima string | number tetapi disimpan secara internal (dan dikembalikan) sebagai string . Secara alami kami dapat mengembalikan properti sebagai string | number tetapi itu berarti bahwa pengguna API akan dihadapkan dengan pemeriksaan ketik yang sama sekali tidak perlu.

class Foo {
    constructor() {
        this._bar = '';
    }

    // error: 'get' and 'set' accessor must have the same type.(2380)
    get bar(): string {
        return this._bar;
    }

    // error: 'get' and 'set' accessor must have the same type.(2380)
    set bar(value: string | number) {
        this._bar = value.toString();
    }

    private _bar: string;
}

Inilah cara kita dapat mengatasi hal ini:

class Foo {
    constructor() {
        this._bar = '';
    }

    // Return the strictest type possible in the getter.
    get bar(): string {
        return this._bar;
    }

    // Use the same strict type for the setter as the getter.
    set bar(value: string) {
        // Call the conversion function.
        this.setBar(value);
    }

    // Implement a separate conversion function that accepts all supported types.
    public setBar(value: number | string) {
        this._bar = value.toString();
    }

    private _bar: string;
}

Dengan cara ini pengguna mendapatkan tipe yang benar saat membaca properti. Pengguna TypeScript yang ingin menetapkan number ke bar perlu memanggil fungsi konversi setBar . Namun ini tidak akan menjadi perubahan besar bagi pengguna JavaScript yang ada karena penyetel properti memanggil fungsi konversi - yang berarti penyetel properti yang tidak diketik benar-benar menerima angka.

Bagaimana menurut kalian, apakah ini masuk akal? Saya tidak yakin seberapa sering jenis pola ini digunakan tetapi setidaknya dalam paket teks saya mengalaminya lebih dari sekali.

Saya benci membuat perubahan API untuk mengakomodasi batasan pengetikan, hanya saja saya merasa tidak benar. Secara pribadi, saya lebih suka menggunakan apa saja daripada membuat metode baru. Memiliki permukaan API yang begitu besar sudah menjadi beban.

Saya tidak akan pernah menyetujui peretasan dengan metode set*, setuju dengan @bigtimebuddy bahwa tipe any lebih ramah daripada metode set* .

Dalam kasus saat ini, tipe return (string | number) dapat diterima untuk pengambil.

Sebenarnya, terkadang setBar adalah ide yang bagus karena masalah pewarisan set , tetapi membutuhkan lebih banyak simbol dalam prefx, seperti _$setBar() :) Namun tidak dalam kasus ini.

@qtiki terima kasih telah menyoroti masalahnya, saya mengalaminya berkali-kali ketika saya membuat garpu pixijs ts untuk proyek pekerjaan saya.

Ya, Text menyakitkan. Ya, kita harus lebih memikirkannya.

Saya setuju bahwa setBar bukanlah solusi tercantik. Sejujurnya saya cukup terkejut bahwa TypeScript tidak memiliki dukungan untuk setter semacam ini dengan paksaan tipe. Hanya sebuah kata peringatan tentang apa artinya menggunakan pengetikan yang lebih longgar atau bahkan any untuk properti ini sehubungan dengan kontrol aliran TypeScript:

class Foo {
    constructor() {
        this._bar = '';
    }

    get bar(): string | number {
        return this._bar;
    }

    set bar(value: string | number) {
        this._bar = value.toString();
    }

    private _bar: string;
}

const foo = new Foo();

// TypeScript's flow control will assume from now on that `bar` is a `number`
foo.bar = 42;

function add(a: number, b: number) {
    return a + b;
}

// Call to `add` shouldn't be allowed since the value in `bar` is actually a string
// This will print `4242` instead of `84`
console.log(add(foo.bar, 42));

Saya pikir dalam jangka panjang opsi terbersih adalah menggunakan sesuatu seperti ini:

class Bar {
    constructor() {
        this._bar = '';
    }

    get(): string {
        return this._bar;
    }

    set(value: string | number) {
        this._bar = value.toString();
    }

    private _bar: string;
}

class Foo {
    constructor() {
        this.bar = new Bar();
    }

    public bar: Bar;
}

const foo = new Foo();
foo.bar.set(42);
console.log(foo.bar.get());

Jenis set ini bukan tanpa preseden karena persisnya bagaimana PIXI.Point diimplementasikan. Pada dasarnya semua api yang dihadapi pengguna mungkin akan menerima instance Bar "apa adanya" tanpa harus memanggil get di mana pun secara manual.

Tentu ini akan menjadi perubahan besar jadi bukan sesuatu untuk waktu dekat, saya hanya ingin memasukkan dua sen saya.

Dan saya baru menyadari bahwa saran saya sebelumnya tidak lagi menjadi properti "nyata" sehingga hal-hal seperti Object.assign tidak lagi berfungsi dengan setter. Jadi mungkin bukan ide terbaik.

Hai, saya adalah pengguna lama PixiJS dan pengguna TypeScript. Saya dapat berkontribusi dalam hal ini - Sepertinya sebagian besar paket telah selesai pada saat ini. Selain kanvas. Apakah ada yang bisa saya bantu?

@lloydevans ya!!! Ingin melakukan persiapan atau bitmap teks? Keduanya bagus semoga paketnya tidak super rumit.

@bigtimebuddy Hebat! Saya bisa melihat melakukan text-bitmap.

Kedengarannya bagus! Harap buat draf PR setelah Anda memulai sehingga kami dapat melacaknya di sini.

OK akan ku lakukan. Saya akan melihat beberapa konversi dan PR yang ada sekarang dan akan mengikutinya.

Tampaknya paket individu di npm masih belum memiliki tipe. Saya kira itu sesuatu yang bisa diatasi setelah masalah ini selesai? Akan sangat bagus untuk dapat menggunakannya untuk mengurangi ukuran bangunan tanpa mengorbankan keamanan tipe.

Rumah peregangan semua orang! Tinggal beberapa paket lagi!

Terima kasih banyak untuk @Zyie , @ivanpopelyshev , @SerG-Y, @eXponenta dan semua kontributor lain yang membantu memungkinkan migrasi ini.