Pixi.js: ヘルプ募集：TypeScript変換アップデート

その他のヒント：

• すべての余分なimport （実際にはそのインポートタイプ）を既存のインポートとは別に配置してみてください。 新しいTSバージョンが公開されたら、 import typeを追加します。 ただし、linterを使用すると、同じモジュールから2行のimportを使用できなくなります。その場合は、それらを混在させることができます。

• Array<X>とX[]の両方の表記を使用できます。通常、プッシュポップされる構造（別名リスト）にはArray<X>を使用します。 X[]小さい長さが固定されているもの、またはサイズが同じ場所で決定されている場合（通常の配列）。

• readonlyフィールドがdestroy()でのみ変更された場合、そこでany変換を使用できます。 他の場所で使用されている場合は、 readonlyを削除します。 後でprivate field + readonly propertyにするかどうかを決めることができます。

誰かが私を殴らない限り、私は今週末に@pixi-textをすることができました。

注：@ pixi-tilingにはPIXI.TilingSprite.fromがありますが、この夜はTSでは実行できません。 非推奨にすることができます。

@qtiki、頑張ってください。 あなたが奇妙なものを見つけた場合に備えて、私は週末にオンラインになります。

わかりました、 @ qtiki 、ドラフトPRを送信した後、選択は予約されます。
ありがとう！

同意しました。 ドラフトPRは、変換するパッケージを要求するための最良の方法です。 助けてくれてありがとう

わかりました、 @ qtiki 、ドラフトPRを送信した後、選択は予約されます。
ありがとう！

ドラフトPR＃6390を開きました。 PRを作成できるようにいくつかの変更を加えるために、.jsファイルの名前を.tsに変更しました。 今週末、実際の変換を試してみます。

TextパッケージをTypeScriptに変換するときに遭遇したいくつかの一般的なこと：

そのため、TypeScriptプロパティで根本的な問題が発生しました。 TypeScriptはプロパティゲッターとセッターの異なるタイプをサポートしていないようです： https ：//github.com/microsoft/TypeScript/issues/2521

TextクラスとTextStyleクラスには、これが大きなメリットとなる場所がいくつかあります。 たとえば、TextStyleのfillStyleとstrokeは数値を受け入れ、それが文字列に変換されるため、ゲッターは数値を含む共用体型を返さないようにする必要があります。 数値のある共用​​体型が返されるので、CanvasRenderingContext2D fillStyleに渡すことができるようにキャストする必要があります。

また、Textクラス自体は、テキストスタイルのオブジェクトを受け入れます。このオブジェクトは、 new TextStyleまたはTextStyleのインスタンスに直接渡されます。 同様に、ここでは、getterは常にTextStyleインスタンスを返しますが、setterと同じ共用体型で入力する必要があります。 したがって、これにより、ユーザーランドで不要な型チェック（またはキャスト）が発生し、TextStyleのメソッドを呼び出すことができるようになります。

長期的にはこれが最善の解決策になるかどうかはわかりませんが、今のところはそれで十分だと思います。

私が気付いたもう1つのことは、異なるタイプのローカル変数を再利用するコードがかなりあることです。これは、TypeScriptではあまりうまく機能しません。 既存のコードにあまり触れたくなかったので、共用体型といくつかの醜いキャストをあちこちで使用してコンパイルしました。 ボーイスカウトの原則を使えば、そういうことは時間の経過とともに改善できると思います。

@qtiki
PRの代わりにこのトピックに問題を書くのはなぜですか？

@qtiki
PRの代わりにこのトピックに問題を書くのはなぜですか？

これらは、テキストパッケージ固有の問題だけでなく、TypeScript変換で他の場所で遭遇する一般的な問題だと思います。 1つのプロパティの問題は、正しく入力する必要がある場合の将来の基本的な設計上の問題です。

私はTypeScriptセッターとゲッターがそれに遭遇して以来、異なるタイプを使用できないという問題を研究してきました。 問題は非常に複雑で、「修正」されない可能性があるようです。 したがって、これらのタイプのプロパティをTypeScriptに変換する際の一般的なガイドラインについての私の提案は次のとおりです。

これは、必要なものの単純化された例です。 string | numberを受け入れるが、内部にstringとして格納される（そして返される）プロパティです。 当然、プロパティをstring | numberとして返すこともできますが、それはAPIのユーザーが完全に不要なタイプチェックに直面することを意味します。

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

これを回避する方法は次のとおりです。

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

このようにして、ユーザーはプロパティを読み取るときに正しいタイプを取得します。 numberをbarに割り当てたいTypeScriptユーザーは、 setBar変換関数を呼び出す必要があります。 ただし、プロパティセッターが変換関数を呼び出すため、これは既存のJavaScriptユーザーにとって大きな変更にはなりません。つまり、型指定されていないプロパティセッターは実際に数値を受け入れます。

皆さんはどう思いますか、これは理にかなっていますか？ このタイプのパターンがどのくらいの頻度で使用されているかはわかりませんが、少なくともテキストパッケージでは、何度もこのパターンに遭遇しました。

タイピングの制限に対応するためにAPIを変更するのは嫌いですが、私には正しく感じられません。 個人的には、いずれかを使用してから新しいメソッドを作成したいと思います。 このような大きなAPIサーフェスを持つことは、すでに負担になっています。

set *メソッドを使用したハッキン​​グを承認することは決してありませんanyタイプはset*メソッドよりも使いやすいという@bigtimebuddyに同意します。

現在の場合、getterに対して(string | number)タイプを返すことは非常に受け入れられます。

実際には、 setの継承の問題があるため、 setBarが良いアイデアである場合もありますが、 _$setBar()のようにprefxでより多くのシンボルが必要です:)この場合はそうではありません。

@qtikiは問題を強調してくれてありがとう、私が仕事のプロジェクトのためにpixijs tsforkを作ったときに何度も遭遇しました。

はい、 Textは苦痛です。 はい、もっと考えなければなりません。

setBarが最も美しい解決策ではないことに同意します。 正直なところ、TypeScriptが型強制を伴うこの種のセッターをサポートしていないことに非常に驚いていました。 TypeScriptのフロー制御に関して、これらのプロパティに緩いタイピングまたはanyを使用することの意味については、警告の言葉です。

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

長期的には、最もクリーンなオプションは次のようなものを使用することだと思います。

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());

このタイプのsetは、まさにPIXI.Pointの実装方法であるため、前例がないわけではありません。 基本的に、すべてのユーザー向けAPIは、 getを手動で呼び出すことなく、 Barインスタンスを「そのまま」受け入れる可能性があります。

当然、これは重大な変更になるので、近い将来には何も起こらないので、2セントを入れたかっただけです。

そして、以前の提案はもはや「実際の」プロパティではないため、 Object.assignのようなものはセッターでは機能しなくなることに気づきました。 結局のところ、おそらく最高のアイデアではありません。

こんにちは、私は長年のPixiJSユーザーであり、Typescriptのユーザーです。 私はこれに貢献することができるでしょう-ほとんどのパッケージがこの時点で完了しているように見えます。 キャンバスのものは別として。 手伝ってくれることはありますか？

@lloydevansはい!!! 準備やテキストビットマップをしたいですか？ どちらも、非常に複雑なパッケージではないことを願っています。

@bigtimebuddy素晴らしい！ 私はテキストビットマップを行うことを見ることができました。

いいですね！ ここで追跡できるように、開始したらドラフトPRを作成してください。

わかりました。 私は今、既存の変換とPRのいくつかを見て、それに続きます。

npmの個々のパッケージにはまだタイプがないようです。 この問題が解決した後、それは対処できるものだと思いますか？ それらを使用して、型の安全性を犠牲にすることなくビルドサイズを縮小できると便利です。

ホームストレッチみんな！ 残りわずか2、3のパッケージです！

@ Zyie 、@ ivanpopelyshev 、@ SerG-Y、@ eXponenta 、およびこの移行を可能にするのを助けてくれた他のすべての貢献者に心から感謝します。