Pixi.js: Hilfe gesucht: TypeScript-Konvertierungsaktualisierung

Mehr Tipps:

• Versuchen Sie, alle zusätzlichen import (eigentlich der Importtyp) von bestehenden Importen zu trennen. Wir werden import type hinzufügen, wenn die neue TS-Version eingeführt wird. Linter wird Sie jedoch davon abhalten, zwei Zeilen von import aus demselben Modul zu verwenden, es ist in diesem Fall in Ordnung, sie zu mischen.

• Sie können sowohl Array<X> als auch X[] Notationen verwenden, ich verwende normalerweise Array<X> für Strukturen, die oft gepusht werden (auch bekannt als Listen). X[] für Dinge, die eine feste kleine Länge haben oder wenn die Größe an derselben Stelle festgelegt wird, an der sie konstruiert werden (reguläres Array).

• Wenn das readonly -Feld nur in destroy() geändert wird, können Sie dort die any -Konvertierung verwenden. Wenn es woanders verwendet wird - entfernen Sie readonly . Wir können später entscheiden, ob wir daraus private field + readonly property machen.

Ich könnte dieses Wochenende @pixi-text machen, wenn mir nicht jemand zuvorkommt.

Hinweis: @pixi-tiling wird PIXI.TilingSprite.from haben, welche Nacht in TS nicht möglich ist. Wir können es einfach ablehnen.

Los, @qtiki. Ich werde am Wochenende online sein, falls Sie seltsame Dinge finden.

Ok, @qtiki , Ihre Auswahl wird nach dem Senden des PR-Entwurfs reserviert.
Danke!

Einverstanden. Draft-PR ist der beste Weg, um ein Paket zur Konvertierung zu beanspruchen. Danke fürs Helfen

Ok, @qtiki , Ihre Auswahl wird nach dem Senden des PR-Entwurfs reserviert.
Danke!

Ich habe den Entwurf PR #6390 geöffnet. Ich habe gerade die .js-Dateien in .ts umbenannt, um einige Änderungen vorzunehmen, um den PR erstellen zu können. Ich werde versuchen, die eigentliche Konvertierung dieses Wochenende durchzuführen.

Einige allgemeine Dinge, auf die ich beim Konvertieren des Textpakets in TypeScript gestoßen bin:

Ich bin also auf ein grundlegendes Problem mit den TypeScript-Eigenschaften gestoßen. Es scheint, dass TypeScript keine unterschiedlichen Typen für Property Getter und Setter unterstützt: https://github.com/microsoft/TypeScript/issues/2521

An einigen Stellen in den Text- und TextStyle-Klassen wäre dies ein großer Vorteil. Beispielsweise akzeptieren fillStyle und stroke in TextStyle eine Zahl, die dann in eine Zeichenfolge konvertiert wird, sodass der Getter keinen Union-Typ mit einer Zahl zurückgeben sollte. Jetzt, da es einen Union-Typ mit einer Zahl zurückgibt, muss ich ihn umwandeln, um ihn an CanvasRenderingContext2D fillStyle übergeben zu können.

Auch die Text-Klasse selbst akzeptiert ein Objekt mit dem Textstil, der dann an new TextStyle übergeben wird - oder direkt an eine Instanz von TextStyle. In ähnlicher Weise gibt der Getter hier immer eine TextStyle-Instanz zurück, muss aber mit demselben Union-Typ wie der Setter typisiert werden. Dies führt also zu einigen unnötigen Typprüfungen (oder Umwandlungen) im Userland, um Methoden von TextStyle aufrufen zu können.

Ich weiß nicht wirklich, was auf lange Sicht die beste Lösung dafür wäre, aber im Moment denke ich, dass das einfach reichen muss.

Eine andere Sache, die mir aufgefallen ist, ist, dass es ziemlich viel Code gibt, der lokale Variablen mit anderem Typ wiederverwendet, was mit TypeScript nicht wirklich gut funktioniert. Ich wollte den vorhandenen Code nicht zu sehr anfassen, also habe ich nur Union-Typen und ein paar hässliche Castings hier und da verwendet, um ihn zum Kompilieren zu bringen. Ich denke, solche Dinge können mit dem Pfadfinderprinzip im Laufe der Zeit verbessert werden .

@qtiki
Warum schreibst du in diesem Thema Probleme statt deine PR?

@qtiki
Warum schreibst du in diesem Thema Probleme statt deine PR?

Ich glaube, dass dies allgemeine Probleme sind, auf die Menschen an anderer Stelle bei der TypeScript-Konvertierung stoßen werden, und nicht nur spezifische Probleme mit Textpaketen. Das Eigenschaftsproblem für einen ist etwas, das eine grundlegende Entwurfsfrage für die Zukunft ist, wenn sie korrekt eingegeben werden sollen.

Ich habe das Problem untersucht, dass TypeScript-Setter und Getter nicht in der Lage sind, verschiedene Typen zu verwenden, seit ich darauf gestoßen bin. Es scheint, dass das Problem sehr komplex ist und möglicherweise nie "behoben" wird. Hier ist mein Vorschlag für eine allgemeine Richtlinie zum Konvertieren dieser Arten von Eigenschaften in TypeScript:

Dies ist ein vereinfachtes Beispiel für das, was wir wollen: eine Eigenschaft, die string | number akzeptiert, aber intern als string gespeichert (und zurückgegeben) wird. Natürlich könnten wir die Eigenschaft als string | number zurückgeben, aber das würde bedeuten, dass die Benutzer der API mit völlig unnötigen Typprüfungen konfrontiert würden.

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

So können wir das umgehen:

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

Auf diese Weise erhält der Benutzer beim Lesen der Eigenschaft den richtigen Typ. TypeScript-Benutzer, die number bar zuweisen möchten, müssen die Umwandlungsfunktion setBar aufrufen. Dies wäre jedoch keine bahnbrechende Änderung für vorhandene JavaScript-Benutzer, da der Property-Setter die Konvertierungsfunktion aufruft – was bedeutet, dass der nicht typisierte Property-Setter tatsächlich Zahlen akzeptiert.

Was meint ihr, macht das Sinn? Ich bin mir nicht sicher, wie oft diese Art von Muster verwendet wird, aber zumindest im Textpaket bin ich mehr als einmal darauf gestoßen.

Ich hasse es, API-Änderungen vorzunehmen, um Tippbeschränkungen auszugleichen, fühlt sich für mich einfach nicht richtig an. Persönlich würde ich lieber eine beliebige verwenden, als eine neue Methode zu erstellen. Eine so große API-Oberfläche zu haben, ist schon eine Belastung.

Ich werde niemals Hacks mit der set*-Methode genehmigen, stimme @bigtimebuddy zu, dass der any -Typ freundlicher ist als die set* -Methode.

Im aktuellen Fall ist es durchaus akzeptabel, den Typ (string | number) für Getter zurückzugeben.

Eigentlich ist setBar wegen Vererbungsproblemen von set manchmal eine gute Idee, benötigt aber mehr Symbole im Präfix, wie _$setBar() :) Nicht in diesem Fall.

@qtiki danke, dass du das Problem hervorgehoben hast, ich bin oft darauf gestoßen, als ich pixijs ts fork für meine Jobprojekte gemacht habe.

Ja, Text ist Schmerz. Ja, darüber müssen wir mehr nachdenken.

Ich stimme zu, dass das setBar nicht die schönste Lösung ist. Um ehrlich zu sein, war ich ziemlich überrascht, dass TypeScript diese Art von Settern mit Type-Conercion nicht unterstützt. Nur ein Wort der Warnung, was es bedeutet, lockerere Eingaben oder sogar any für diese Eigenschaften in Bezug auf die Flusssteuerung von TypeScript zu verwenden:

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

Ich denke, auf lange Sicht wäre es die sauberste Option, so etwas zu wählen:

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

Diese Art von set ist nicht ohne Präzedenzfall, da PIXI.Point genau so implementiert wird. Grundsätzlich würden wahrscheinlich alle benutzerorientierten APIs die Bar -Instanz "wie sie ist" akzeptieren, ohne die get überall manuell aufrufen zu müssen.

Natürlich wäre dies eine bahnbrechende Änderung, also nichts für die nahe Zukunft, ich wollte nur meinen Senf dazu geben.

Und mir wurde gerade klar, dass mein vorheriger Vorschlag keine "echte" Eigenschaft mehr sein würde, sodass Dinge wie Object.assign mit dem Setter nicht mehr funktionieren würden. Also vielleicht doch nicht die beste Idee.

Hallo, ich bin ein langjähriger PixiJS-Benutzer und Benutzer von Typescript. Ich könnte dazu beitragen - Es sieht so aus, als ob die meisten Pakete zu diesem Zeitpunkt fertig sind. Abgesehen von den Leinen. Gibt es irgendwelche, bei denen ich helfen kann?

@lloydevans ja!!! Lust auf Prepare oder Text-Bitmap? Beide sind gute, hoffentlich nicht super komplizierte Pakete.

@bigtimebuddy Großartig! Ich könnte einen Blick auf Text-Bitmap werfen.

Hört sich gut an! Bitte erstellen Sie einen PR-Entwurf, sobald Sie beginnen, damit wir ihn hier verfolgen können.

OK mach ich. Ich werde mir jetzt einige der bestehenden Konvertierungen und PRs ansehen und nachziehen.

Es scheint, dass die einzelnen Pakete in npm immer noch keine Typen haben. Ich vermute, das ist etwas, das behoben werden kann, nachdem dieses Problem erledigt ist? Es wäre großartig, sie verwenden zu können, um Baugrößen zu reduzieren, ohne die Typsicherheit zu beeinträchtigen.

Heimstrecke alle! Nur noch wenige Pakete übrig!

Ein großes Dankeschön an @Zyie , @ivanpopelyshev , @SerG-Y, @eXponenta und alle anderen Mitwirkenden, die dazu beigetragen haben, diese Migration zu ermöglichen.