Pixi.js: Se busca ayuda: actualización de conversión de TypeScript

Mas consejos:

• Intente poner todos los import adicionales (en realidad, su tipo de importación) separados de las importaciones existentes. Agregaremos import type cuando se lance la nueva versión de TS. Sin embargo, linter evitará que use dos líneas de import del mismo módulo, está bien mezclarlas en ese caso.

• Puede usar las notaciones Array<X> y X[] , normalmente uso Array<X> para las estructuras que se insertan con frecuencia (también conocidas como Listas). X[] para cosas que tienen una longitud pequeña fija o si el tamaño se decide en el mismo lugar donde se construyen (matriz regular).

• Si el campo readonly se cambia solo en destroy() , puede usar la conversión any allí. Si se usa en otro lugar, elimine readonly . Podemos decidir si convertirlo en private field + readonly property más tarde.

Podría ganar @pixi-text este fin de semana a menos que alguien se me adelante.

nota: @pixi-tiling tendrá PIXI.TilingSprite.from qué noche no es posible hacer en TS. Podemos desaprobarlo.

Adelante, @qtiki. Estaré en línea el fin de semana en caso de que encuentres cosas raras.

Ok, @qtiki , tu elección se reservará después de enviar el borrador de relaciones públicas.
¡Gracias!

Acordado. Draft PR es la mejor manera de reclamar un paquete para convertir. Gracias por ayudar

Ok, @qtiki , tu elección se reservará después de enviar el borrador de relaciones públicas.
¡Gracias!

Abrí el borrador PR #6390. Acabo de cambiar el nombre de los archivos .js a .ts para tener algunos cambios y poder crear el PR. Intentaré hacer la conversión real este fin de semana.

Algunas cosas genéricas con las que me he encontrado al convertir el paquete de texto a TypeScript:

Así que me encontré con un problema fundamental con las propiedades de TypeScript. Parece que TypeScript no admite diferentes tipos para obtener y establecer propiedades: https://github.com/microsoft/TypeScript/issues/2521

Hay algunos lugares en las clases Text y TextStyle donde esto sería un gran beneficio. Por ejemplo fillStyle y stroke en TextStyle aceptan un número que luego se convierte en una cadena, por lo que el captador no debería devolver un tipo de unión con un número. Ahora que devuelve un tipo de unión con un número, tengo que convertirlo para poder pasarlo a CanvasRenderingContext2D fillStyle .

Además, la clase Text en sí misma acepta un objeto con el estilo de texto, que luego se pasa a new TextStyle , o una instancia de TextStyle directamente. De manera similar, aquí el getter siempre devolverá una instancia de TextStyle pero debe escribirse con el mismo tipo de unión que el setter. Por lo tanto, esto provocará algunas comprobaciones de tipo (o conversiones) innecesarias en el espacio del usuario para poder llamar a los métodos de TextStyle.

Realmente no sé cuál sería la mejor solución para esto a largo plazo, pero por ahora supongo que será suficiente.

Otra cosa que noté es que hay bastante código que reutiliza variables locales con diferentes tipos, lo que no funciona muy bien con TypeScript. No quería tocar demasiado el código existente, así que solo usé tipos de unión y algunos casting feos aquí y allá para compilarlo. Supongo que ese tipo de cosas se pueden mejorar con el tiempo con el principio de los boy scouts .

@qtiki
¿Por qué escribe problemas en este tema en lugar de su PR?

@qtiki
¿Por qué escribe problemas en este tema en lugar de su PR?

Creo que estos son problemas genéricos con los que las personas se encontrarán en otros lugares con la conversión de TypeScript y no solo problemas específicos del paquete de texto. El problema de la propiedad para uno es algo que es una cuestión de diseño fundamental para el futuro si se van a escribir correctamente.

He estado estudiando el problema con los setters y getters de TypeScript que no pueden usar diferentes tipos desde que me encontré con él. Parece que el problema es muy complejo y es posible que nunca se "solucione". Así que aquí está mi sugerencia de una guía general para convertir este tipo de propiedades a TypeScript:

Este es un ejemplo simplificado de lo que queremos: una propiedad que acepte string | number pero que se almacene internamente (y se devuelva) como string . Naturalmente, podríamos devolver la propiedad como string | number pero eso significaría que los usuarios de la API se enfrentarían a comprobaciones de tipos completamente innecesarias.

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

Así es como podemos solucionar esto:

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

De esta forma, el usuario obtiene el tipo correcto al leer la propiedad. Los usuarios de TypeScript que deseen asignar number a bar deberán llamar a la función de conversión setBar . Sin embargo, esto no sería un cambio importante para los usuarios de JavaScript existentes, ya que el definidor de propiedades llama a la función de conversión, lo que significa que el definidor de propiedades sin tipo acepta números.

¿Qué piensan ustedes, esto tiene sentido? No estoy seguro de con qué frecuencia se usa este tipo de patrón, pero al menos en el paquete de texto lo encontré más de una vez.

Odio hacer cambios en la API para acomodar las limitaciones de escritura, simplemente no me parece bien. Personalmente, prefiero usar cualquiera y luego crear un nuevo método. Tener una superficie API tan grande ya es una carga.

Nunca aprobaré hacks con el método set*, estoy de acuerdo con @bigtimebuddy en que el tipo any es más amigable que el método set* .

En el caso actual, es bastante aceptable el tipo return (string | number) para getter.

En realidad, a veces setBar es una buena idea debido a los problemas de herencia de set , pero necesita más símbolos en el prefijo, como _$setBar() :) Aunque no en este caso.

@qtiki gracias por resaltar el problema, lo encontré muchas veces cuando hice el tenedor pixijs ts para mis proyectos de trabajo.

Sí, Text es dolor. Sí, tenemos que pensarlo más.

Estoy de acuerdo en que setBar no es la solución más bonita. Para ser honesto, me sorprendió bastante que TypeScript no tenga soporte para este tipo de configuradores con coerción de tipos. Solo una palabra de advertencia sobre lo que significa usar una escritura más flexible o incluso any para estas propiedades con respecto al control de flujo de 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));

Creo que, a la larga, la opción más limpia sería ir con algo como esto:

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

Este tipo de set no carece de precedentes, ya que es exactamente cómo se implementa PIXI.Point . Básicamente, todas las API orientadas al usuario probablemente aceptarían la instancia Bar "tal cual" sin tener que llamar a get todas partes manualmente.

Naturalmente, este sería un cambio radical, por lo que no es algo para el futuro cercano, solo quería aportar mi granito de arena.

Y acabo de darme cuenta de que mi sugerencia anterior ya no sería una propiedad "real", por lo que cosas como Object.assign ya no funcionarían con el setter. Así que tal vez no sea la mejor idea después de todo.

Hola, soy usuario de PixiJS desde hace mucho tiempo y usuario de Typescript. Podría contribuir en esto: parece que la mayoría de los paquetes se han realizado en este punto. Aparte de los de lona. ¿Hay algo en lo que pueda ayudar?

@lloydevans sí!!! ¿Te apetece hacer preparar o mapa de bits de texto? Ambos son buenos, esperemos que no sean paquetes súper complicados.

@bigtimebuddy ¡Genial! Podría echar un vistazo a hacer text-bitmap.

¡Suena bien! Haga un borrador de PR una vez que comience para que podamos rastrearlo aquí.

OK lo haré. Echaré un vistazo a algunas de las conversiones y relaciones públicas existentes ahora y haré lo mismo.

Parece que los paquetes individuales en npm todavía no tienen tipos. ¿Supongo que eso es algo que se puede abordar después de que se solucione este problema? Sería genial poder usarlos para reducir los tamaños de construcción sin sacrificar la seguridad de tipo.

¡Llega a casa a todos! ¡Solo quedan un par de paquetes!

Muchas gracias a @Zyie , @ivanpopelyshev , @SerG-Y, @eXponenta y todos los demás colaboradores que ayudaron a hacer posible esta migración.