Pixi.js: 도움을 구함: TypeScript 변환 업데이트

추가 팁:

• 기존 가져오기와 별도로 모든 추가 import (실제로는 가져오기 유형)를 넣으십시오. 새로운 TS 버전이 출시되면 import type 를 추가할 예정입니다. 그러나 linter는 동일한 모듈에서 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을 보낸 후 예약됩니다.
감사 해요!

동의. Draft PR은 변환할 패키지를 요청하는 가장 좋은 방법입니다. 도움을 주셔서 감사합니다

좋아, @qtiki , 당신의 선택은 초안 PR을 보낸 후 예약됩니다.
감사 해요!

PR #6390 초안을 열었습니다. PR을 생성할 수 있도록 일부 변경 사항을 적용하기 위해 .js 파일의 이름을 .ts로 변경했습니다. 이번 주말에 실제 변환을 시도해 보겠습니다.

Text 패키지를 TypeScript로 변환하는 동안 겪었던 몇 가지 일반적인 사항:

그래서 TypeScript 속성에 근본적인 문제가 발생했습니다. TypeScript는 속성 getter 및 setter에 대해 다른 유형을 지원하지 않는 것 같습니다: https://github.com/microsoft/TypeScript/issues/2521

Text 및 TextStyle 클래스에는 이것이 큰 이점이 될 부분이 있습니다. 예를 들어 TextStyle의 fillStyle 및 stroke 는 숫자를 받아들인 다음 문자열로 변환되므로 getter는 숫자가 있는 공용체 유형을 반환하지 않아야 합니다. 이제 숫자가 있는 공용체 유형을 반환하므로 CanvasRenderingContext2D fillStyle 에 전달할 수 있도록 변환해야 합니다.

또한 Text 클래스 자체는 new TextStyle 또는 TextStyle의 인스턴스에 직접 전달되는 텍스트 스타일의 개체를 허용합니다. 마찬가지로 여기에서 getter는 항상 TextStyle 인스턴스를 반환하지만 setter와 동일한 공용체 유형으로 입력해야 합니다. 따라서 사용자 영역에서 일부 불필요한 유형 검사(또는 캐스트)가 TextStyle의 메서드를 호출할 수 있게 됩니다.

장기적으로 이 문제에 대한 최선의 해결책이 무엇인지는 잘 모르겠지만 지금으로서는 그렇게 해야 할 것 같습니다.

다른 유형의 로컬 변수를 재사용하는 코드가 상당히 많다는 사실을 알게 되었고 TypeScript에서는 잘 작동하지 않습니다. 기존 코드를 너무 만지고 싶지 않았기 때문에 유니온 유형과 여기 저기에 추악한 캐스팅을 사용하여 컴파일하도록 했습니다. 그런 것들은 시간이 지나면서 보이스카우트 원칙 으로 개선될 수 있다고 생각합니다.

@qtiki
PR 대신 이 주제에 문제를 쓰는 이유는 무엇입니까?

@qtiki
PR 대신 이 주제에 문제를 쓰는 이유는 무엇입니까?

나는 이것이 사람들이 TypeScript 변환과 함께 텍스트 패키지 특정 문제뿐만 아니라 다른 곳에서 겪을 일반적인 문제라고 생각합니다. 속성 문제는 올바르게 입력해야 하는 경우 미래에 대한 근본적인 설계 문제입니다.

TypeScript setter 및 getter가 발생한 이후로 다른 유형을 사용할 수 없는 문제를 연구해 왔습니다. 문제는 매우 복잡한 문제이며 "수정"되지 않을 수도 있습니다. 따라서 이러한 유형의 속성을 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 변환 함수를 호출해야 합니다. 그러나 이것은 속성 setter가 변환 함수를 호출하기 때문에 기존 JavaScript 사용자에 대한 주요 변경 사항이 아닙니다. 이는 유형이 지정되지 않은 속성 setter가 실제로 숫자를 허용한다는 것을 의미합니다.

여러분은 어떻게 생각하세요? 이게 말이 되나요? 이 유형의 패턴이 얼마나 자주 사용되는지 잘 모르겠지만 적어도 텍스트 패키지에서 두 번 이상 만났습니다.

나는 타이핑 제한을 수용하기 위해 API를 변경하는 것을 싫어하지만 나에게 옳지 않다고 생각합니다. 개인적으로 나는 차라리 아무거나 사용하고 새로운 방법을 만들고 싶습니다. 이렇게 큰 API 표면을 갖는 것은 이미 부담입니다.

나는 set* 방법으로 해킹을 승인하지 않을 것이며 any 유형이 set* 방법보다 더 친숙하다는 @bigtimebuddy 의 의견에 동의합니다.

현재의 경우 getter에 대해 (string | number) 유형을 반환하는 것이 상당히 허용됩니다.

실제로 setBar 는 set 의 상속 문제 때문에 좋은 생각이지만 _$setBar() 와 같이 prefx에 더 많은 기호가 필요합니다. :) 하지만 이 경우에는 그렇지 않습니다.

@qtiki 문제를 강조해 주셔서 감사합니다. 제 작업 프로젝트를 위해 pixijs ts fork를 만들 때 여러 번 문제가 발생했습니다.

예, Text 는 고통입니다. 예, 우리는 그것에 대해 더 생각해야 합니다.

setBar 가 가장 좋은 솔루션이 아니라는 데 동의합니다. 솔직히 말해서 TypeScript가 type-coercion과 함께 이러한 종류의 setter를 지원하지 않는다는 사실에 상당히 놀랐습니다. 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 와 같은 것들이 더 이상 setter에서 작동하지 않는다는 것을 깨달았습니다. 그래서 결국 최고의 아이디어가 아닐 수도 있습니다.

안녕하세요, 저는 오랫동안 PixiJS 사용자이자 Typescript 사용자입니다. 나는 이것에 기여할 수 있을 것입니다 - 이 시점에서 대부분의 패키지가 완료된 것처럼 보입니다. 캔버스를 제외하고. 내가 도울 수 있는 것이 있습니까?

@lloydevans 네!!! 준비 또는 텍스트 비트맵을 하고 싶으십니까? 둘 다 매우 복잡한 패키지가 아니기를 바랍니다.

@bigtimebuddy 텍스트 비트맵 작업을 볼 수 있습니다.

좋은 소리! 시작하면 여기에서 추적할 수 있도록 PR 초안을 작성하십시오.

알았어 할게. 기존 전환 및 PR 중 일부를 지금 살펴보고 그에 따를 것입니다.

npm의 개별 패키지에는 여전히 유형이 없는 것 같습니다. 이 문제가 해결된 후에 해결할 수 있는 문제라고 생각합니다. 유형 안전성을 희생하지 않고 빌드 크기를 줄이는 데 사용할 수 있다면 좋을 것입니다.

모두 홈 스트레치! 패키지가 몇 개 남지 않았습니다!

@Zyie , @ivanpopelyshev , @SerG-Y, @eXponenta 및 이 마이그레이션을 가능하게 해준 다른 모든 기여자에게 큰 감사를 드립니다.