Pixi.js: مطلوب مساعدة: تحديث تحويل TypeScript

المزيد من النصائح:

• حاول وضع جميع import 's الإضافية (في الواقع نوع الاستيراد الخاص بها) منفصلة عن الواردات الحالية. سنضيف import type عند طرح إصدار TS الجديد. ومع ذلك ، سوف يمنعك 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 هو أفضل طريقة للمطالبة بتحويل الحزمة. شكرا على المساعدة

حسنًا ، qtiki ، سيتم حجز اختيارك بعد إرسال مسودة العلاقات العامة.
شكرا!

فتحت مسودة PR # 6390. لقد قمت للتو بإعادة تسمية ملفات .js إلى .ts لإجراء بعض التغييرات لتتمكن من إنشاء العلاقات العامة. سأحاول إجراء التحويل الفعلي في نهاية هذا الأسبوع.

بعض الأشياء العامة التي واجهتها أثناء تحويل حزمة النص إلى TypeScript:

لذلك واجهت مشكلة أساسية في خصائص TypeScript. يبدو أن TypeScript لا يدعم أنواعًا مختلفة من أداة getter و setter: https://github.com/microsoft/TypeScript/issues/2521

هناك بعض الأماكن في فئتي Text و TextStyle حيث سيكون هذا مفيدًا للغاية. على سبيل المثال ، يقبل fillStyle و stroke في TextStyle رقمًا يتم تحويله بعد ذلك إلى سلسلة ، لذلك لا يجب أن يُرجع المُحضر نوع توحيد برقم. الآن بعد أن أعاد نوع اتحاد برقم يجب أن ألقيه حتى أتمكن من تمريره إلى CanvasRenderingContext2D fillStyle .

كما تقبل فئة النص نفسها كائنًا بنمط النص ، والذي يتم تمريره بعد ذلك إلى new TextStyle - أو مثيل TextStyle مباشرة. وبالمثل هنا ، سيعيد getter دائمًا مثيل TextStyle ولكن يجب كتابته بنفس نوع الاتحاد مثل المُعيِّن. لذلك سيتسبب هذا في بعض عمليات التحقق غير الضرورية من النوع (أو القوالب) في userland لتتمكن من استدعاء طرق TextStyle.

لا أعرف حقًا ما هو الحل الأفضل لهذا على المدى الطويل ، لكن في الوقت الحالي أعتقد أن هذا سيحدث فقط.

هناك شيء آخر لاحظته وهو أن هناك قدرًا كبيرًا من التعليمات البرمجية التي تعيد استخدام المتغيرات المحلية بنوع مختلف ، والتي لا تعمل بشكل جيد مع TypeScript. لم أكن أرغب في لمس الكود الحالي كثيرًا ، لذا فقد استخدمت أنواع الاتحاد وبعض عمليات الصب القبيحة هنا وهناك لأجعلها مجمعة. أعتقد أن هذا النوع من الأشياء يمكن تحسينه بمرور الوقت مع مبدأ الكشافة .

qtiki
لماذا تكتب المشاكل في هذا الموضوع بدلا من العلاقات العامة الخاصة بك؟

qtiki
لماذا تكتب المشاكل في هذا الموضوع بدلا من العلاقات العامة الخاصة بك؟

أعتقد أن هذه مشكلات عامة سيواجهها الأشخاص في مكان آخر باستخدام تحويل TypeScript وليست مجرد مشكلات محددة في حزمة النص. إن مسألة الملكية بالنسبة للفرد هي مسألة أساسية تتعلق بالتصميم في المستقبل إذا كانت ستتم كتابتها بشكل صحيح.

لقد كنت أدرس المشكلة مع واضعي TypeScript وعدم تمكنهم من استخدام أنواع مختلفة منذ أن واجهت ذلك. يبدو أن المشكلة معقدة للغاية وقد لا يتم "حلها" أبدًا. إذن ، هذا اقتراحي للحصول على إرشادات عامة حول تحويل هذه الأنواع من الخصائص إلى TypeScript:

هذا مثال مبسط لما نريد: خاصية تقبل string | number لكن يتم تخزينها داخليًا (ويتم إرجاعها) كـ string . يمكننا بطبيعة الحال إرجاع الخاصية كـ string | number ولكن هذا يعني أن مستخدمي واجهة برمجة التطبيقات سيواجهون عمليات فحص غير ضرورية تمامًا.

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

بهذه الطريقة يحصل المستخدم على النوع الصحيح عند قراءة الخاصية. مستخدمو TypeScript الذين يريدون تعيين number إلى bar سيحتاجون إلى استدعاء وظيفة التحويل setBar . ومع ذلك ، لن يكون هذا تغييرًا جذريًا لمستخدمي JavaScript الحاليين لأن واضع الخصائص يستدعي وظيفة التحويل - مما يعني أن واضع الخاصية غير المكتوب يقبل بالفعل الأرقام.

ما رأيكم يا رفاق ، هل هذا منطقي؟ لست متأكدًا من عدد المرات التي يتم فيها استخدام هذا النوع من الأنماط ، ولكن على الأقل في الحزمة النصية واجهت ذلك أكثر من مرة.

أنا أكره إجراء تغييرات على واجهة برمجة التطبيقات (API) لتتوافق مع قيود الكتابة ، فقط لا أشعر أنني على حق. أنا شخصياً أفضل استخدام أي طريقة ثم إنشاء طريقة جديدة. إن وجود مثل هذا السطح الكبير لواجهة برمجة التطبيقات يمثل عبئًا بالفعل.

لن أوافق أبدًا على عمليات الاختراق باستخدام طريقة المجموعة * ، أتفق مع bigtimebuddy على أن النوع any أكثر ملاءمة من طريقة set* .

في الحالة الحالية ، من المقبول تمامًا إرجاع نوع (string | number) لـ getter.

في الواقع ، أحيانًا يكون setBar فكرة جيدة بسبب مشاكل الميراث set ، لكنها تحتاج إلى المزيد من الرموز في البادئة ، مثل _$setBar() :) ولكن ليس في هذه الحالة.

qtiki شكرًا لك على تسليط الضوء على المشكلة ، لقد واجهتها عدة مرات عندما صنعت pixijs ts fork لمشاريع وظيفتي.

نعم ، Text هو ألم. نعم ، علينا التفكير في الأمر أكثر.

أوافق على أن setBar ليس الحل الأجمل. لأكون صريحًا ، كنت مندهشًا تمامًا من أن TypeScript لا يدعم هذا النوع من المستوطنين الذين يعانون من الإكراه على الكتابة. مجرد كلمة تحذير على الرغم من معنى استخدام كتابة أكثر مرونة أو حتى any لهذه الخصائص فيما يتعلق بالتحكم في تدفق 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));

أعتقد أن الخيار الأنظف على المدى الطويل هو استخدام شيء مثل هذا:

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 . من المحتمل أن تقبل جميع واجهات برمجة التطبيقات التي تواجه المستخدم مثيل Bar "كما هي" دون الحاجة إلى استدعاء get في كل مكان يدويًا.

بطبيعة الحال ، سيكون هذا تغييرًا جذريًا ، لذا لن يكون شيئًا في المستقبل القريب ، أردت فقط أن أضع سنتي فيها.

وأدركت للتو أن اقتراحي السابق لم يعد ملكية "حقيقية" ، لذا فإن أشياء مثل Object.assign لن تعمل مع المُعد. لذلك ربما ليست أفضل فكرة بعد كل شيء.

مرحبًا ، أنا مستخدم PixiJS منذ فترة طويلة ومستخدم لـ Typescript. سأكون قادرًا على المساهمة في هذا - يبدو كما لو أن معظم الحزم قد تم إنجازها في هذه المرحلة. بصرف النظر عن اللوحات القماشية. هل هناك أي شيء يمكنني المساعدة فيه؟

تضمين التغريدة تخيل القيام بإعداد أو نص الصورة النقطية؟ كلاهما جيد وآمل ألا يكون حزم معقدة للغاية.

تضمين التغريدة يمكنني إلقاء نظرة على عمل صورة نقطية للنص.

يبدو ذلك جيدا! يرجى عمل مسودة علاقات عامة بمجرد أن تبدأ حتى نتمكن من تتبعها هنا.

حسنا سأفعل. سألقي نظرة على بعض التحويلات الحالية والعلاقات العامة الآن وسأحذو حذوها.

يبدو أن الحزم الفردية في npm ما زالت لا تحتوي على أنواع. أعتقد أن هذا شيء يمكن معالجته بعد الانتهاء من هذه المشكلة؟ سيكون من الرائع أن تكون قادرًا على استخدامها لتقليل أحجام البناء دون التضحية بسلامة النوع.

امتداد المنزل للجميع! فقط بضع حزم متبقية!

شكرًا جزيلاً لـ Zyie و ivanpopelyshev و @ SerG-Y و eXponenta وجميع المساهمين الآخرين الذين ساعدوا في جعل هذا الترحيل ممكنًا.