Pixi.js: मदद चाहिए: टाइपस्क्रिप्ट रूपांतरण अपडेट

अधिक सुझाव:

• सभी अतिरिक्त import (वास्तव में इसके आयात प्रकार) को मौजूदा आयातों से अलग रखने का प्रयास करें। जब नया TS संस्करण शुरू होगा तो हम import type जोड़ देंगे। हालाँकि लिटर आपको एक ही मॉड्यूल से import की दो पंक्तियों का उपयोग करने से रोकेगा, उस स्थिति में उन्हें मिलाना ठीक है।

• आप Array<X> और X[] नोटेशन दोनों का उपयोग कर सकते हैं, मैं आमतौर पर संरचनाओं के लिए Array<X> का उपयोग करता हूं जिन्हें अक्सर धक्का दिया जाता है (उर्फ सूचियां)। X[] उन चीजों के लिए जिनकी लंबाई छोटी होती है या यदि आकार उसी स्थान पर तय किया जाता है जहां उनका निर्माण किया जाता है (नियमित सरणी)।

• यदि readonly फ़ील्ड को केवल destroy() में बदला जाता है - तो आप वहां any रूपांतरण का उपयोग कर सकते हैं। यदि इसका उपयोग कहीं और किया जाता है - readonly हटा दें। हम तय कर सकते हैं कि इसे बाद में private field + readonly property बनाना है या नहीं।

मैं इस सप्ताह के अंत में @pixi-text कर सकता था जब तक कि कोई मुझे इसके लिए नहीं मारता।

नोट: @ पिक्सी-टाइलिंग में PIXI.TilingSprite.from होगा जो टीएस में रात में करना संभव नहीं है। हम इसे सिर्फ बहिष्कृत कर सकते हैं।

इसके लिए जाओ, @qtiki। अगर आपको अजीब चीजें मिलती हैं तो मैं सप्ताहांत में ऑनलाइन रहूंगा।

ठीक है, @qtiki , ड्राफ्ट पीआर भेजने के बाद आपकी पसंद सुरक्षित रहेगी।
धन्यवाद!

माना। ड्राफ्ट पीआर एक पैकेज को बदलने का दावा करने का सबसे अच्छा तरीका है। मदद के लिए धन्यवाद

ठीक है, @qtiki , ड्राफ्ट पीआर भेजने के बाद आपकी पसंद सुरक्षित रहेगी।
धन्यवाद!

मैंने ड्राफ्ट पीआर #6390 खोला। मैंने पीआर बनाने में सक्षम होने के लिए कुछ बदलाव करने के लिए .js फ़ाइलों का नाम बदलकर .ts कर दिया। मैं इस सप्ताह के अंत में वास्तविक रूपांतरण करने की कोशिश करूँगा।

टेक्स्ट पैकेज को टाइपस्क्रिप्ट में कनवर्ट करते समय मैंने कुछ सामान्य चीजें चलाई हैं:

तो मैं टाइपस्क्रिप्ट गुणों के साथ एक मौलिक समस्या में भाग गया। ऐसा लगता है कि टाइपस्क्रिप्ट संपत्ति पाने वाले और सेटर के लिए विभिन्न प्रकारों का समर्थन नहीं करता है: https://github.com/microsoft/TypeScript/issues/2521

टेक्स्ट और टेक्स्ट स्टाइल कक्षाओं में कुछ स्थान हैं जहां यह एक बड़ा लाभ होगा। उदाहरण के लिए टेक्स्ट स्टाइल में fillStyle और stroke एक संख्या स्वीकार करते हैं जिसे बाद में एक स्ट्रिंग में परिवर्तित कर दिया जाता है, इसलिए गेटर को एक संख्या के साथ एक संघ प्रकार वापस नहीं करना चाहिए। अब जब यह एक संख्या के साथ एक संघ प्रकार लौटाता है तो मुझे इसे CanvasRenderingContext2D fillStyle पर पास करने में सक्षम होने के लिए डालना होगा।

साथ ही टेक्स्ट क्लास स्वयं टेक्स्ट स्टाइल के साथ एक ऑब्जेक्ट स्वीकार करता है, जिसे बाद में new TextStyle - या टेक्स्ट स्टाइल का एक उदाहरण सीधे पास कर दिया जाता है। इसी प्रकार यहां गेटर हमेशा टेक्स्ट स्टाइल इंस्टेंस लौटाएगा लेकिन उसी यूनियन प्रकार के साथ सेटर के रूप में टाइप किया जाना चाहिए। तो यह टेक्स्ट स्टाइल के तरीकों को कॉल करने में सक्षम होने के लिए उपयोगकर्तालैंड में कुछ अनावश्यक प्रकार की जांच (या कास्ट) का कारण बन जाएगा।

मैं वास्तव में नहीं जानता कि लंबी अवधि में इसके लिए सबसे अच्छा समाधान क्या होगा, लेकिन अभी के लिए मुझे लगता है कि बस यही करना होगा।

एक और बात जो मैंने देखी, वह यह है कि काफी कोड है जो विभिन्न प्रकार के स्थानीय चर का पुन: उपयोग करता है, जो टाइपस्क्रिप्ट के साथ वास्तव में अच्छा नहीं खेलता है। मैं मौजूदा कोड को बहुत अधिक स्पर्श नहीं करना चाहता था इसलिए मैंने इसे संकलित करने के लिए यहां और वहां यूनियन प्रकारों और कुछ बदसूरत कास्टिंग का उपयोग किया। मुझे लगता है कि बॉय स्काउट सिद्धांत के साथ समय के साथ इस तरह की चीजों में सुधार किया जा सकता है।

@qtiki
आप अपने पीआर के बजाय इस विषय में समस्याएं क्यों लिखते हैं?

@qtiki
आप अपने पीआर के बजाय इस विषय में समस्याएं क्यों लिखते हैं?

मेरा मानना ​​​​है कि ये सामान्य मुद्दे हैं जिन्हें लोग टाइपस्क्रिप्ट रूपांतरण के साथ कहीं और चलाएंगे, न कि केवल टेक्स्ट पैकेज विशिष्ट समस्याओं के साथ। एक के लिए संपत्ति का मुद्दा कुछ ऐसा है जो भविष्य के लिए एक मौलिक डिजाइन प्रश्न है यदि उन्हें सही ढंग से टाइप किया जाना है।

मैं टाइपस्क्रिप्ट सेटर्स और गेटर्स के साथ समस्या का अध्ययन कर रहा हूं, जब से मैंने इसमें भाग लिया है, तब से विभिन्न प्रकारों का उपयोग करने में सक्षम नहीं है। ऐसा लगता है कि समस्या बहुत जटिल है और इसे कभी भी "ठीक" नहीं किया जा सकता है। तो यहाँ इस प्रकार की संपत्तियों को टाइपस्क्रिप्ट में बदलने के लिए एक सामान्य दिशानिर्देश के लिए मेरा सुझाव है:

यह हम जो चाहते हैं उसका एक सरल उदाहरण है: एक संपत्ति जो 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;
}

इस तरह उपयोगकर्ता को संपत्ति पढ़ते समय सही प्रकार मिलता है। टाइपस्क्रिप्ट उपयोगकर्ता जो number से bar असाइन करना चाहते हैं, उन्हें setBar रूपांतरण फ़ंक्शन को कॉल करने की आवश्यकता होगी। हालांकि यह मौजूदा जावास्क्रिप्ट उपयोगकर्ताओं के लिए एक ब्रेकिंग परिवर्तन नहीं होगा क्योंकि संपत्ति सेटर रूपांतरण फ़ंक्शन को कॉल करता है - जिसका अर्थ है कि अप्रकाशित संपत्ति सेटर वास्तव में संख्या स्वीकार करता है।

आप लोग क्या सोचते हैं, क्या इसका कोई मतलब है? मुझे यकीन नहीं है कि इस प्रकार के पैटर्न का कितनी बार उपयोग किया जाता है लेकिन कम से कम टेक्स्ट पैकेज में मैं इसमें एक से अधिक बार भाग गया।

मुझे टाइपिंग सीमाओं को समायोजित करने के लिए एपीआई परिवर्तन करने से नफरत है, बस मुझे यह सही नहीं लगता। व्यक्तिगत रूप से, मैं किसी का उपयोग करना चाहूंगा और फिर एक नई विधि बनाऊंगा। इतनी बड़ी एपीआई सतह का होना पहले से ही एक बोझ है।

मैं सेट* पद्धति के साथ हैक्स को कभी भी स्वीकृति नहीं दूंगा, @bigtimebuddy से सहमत हूं कि any प्रकार set* पद्धति से अधिक अनुकूल है।

वर्तमान मामले में, गेटटर के लिए यह काफी स्वीकार्य वापसी (string | number) प्रकार है।

वास्तव में, कभी-कभी setBar विरासत के मुद्दों के कारण set एक अच्छा विचार है, लेकिन प्रीफ़ैक्स में अधिक प्रतीकों की आवश्यकता है, जैसे _$setBar() :) हालांकि इस मामले में नहीं।

@qtiki समस्या को उजागर करने के लिए धन्यवाद, मैंने कई बार इसका सामना किया जब मैंने अपनी नौकरी परियोजनाओं के लिए पिक्सीज टीएस कांटा बनाया।

हाँ, Text दर्द है। हां, हमें इसके बारे में और सोचना होगा।

मैं सहमत हूं कि setBar सबसे सुंदर समाधान नहीं है। सच कहूं तो मैं काफी हैरान था कि टाइपस्क्रिप्ट के पास इस तरह के बसने वालों के लिए टाइप-जबरदस्ती का समर्थन नहीं है। चेतावनी का एक शब्द हालांकि टाइपस्क्रिप्ट के प्रवाह नियंत्रण के संबंध में इन गुणों के लिए शिथिल टाइपिंग या यहां तक ​​कि 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 को लागू किया जाता है। मूल रूप से सभी उपयोगकर्ता-सामना करने वाले एपीआई Bar उदाहरण "जैसा है" को हर जगह मैन्युअल रूप से get कॉल किए बिना स्वीकार करेंगे।

स्वाभाविक रूप से यह एक ब्रेकिंग बदलाव होगा, इसलिए निकट भविष्य के लिए कुछ नहीं, मैं सिर्फ अपने दो सेंट लगाना चाहता था।

और मुझे अभी एहसास हुआ कि मेरा पिछला सुझाव अब "वास्तविक" संपत्ति नहीं होगा, Object.assign जैसी चीजें अब सेटर के साथ काम नहीं करेंगी। तो शायद सबसे बड़ा विचार नहीं है।

अरे वहाँ, मैं एक लंबे समय से PixiJS उपयोगकर्ता और टाइपस्क्रिप्ट का उपयोगकर्ता हूं। मैं इसमें योगदान करने में सक्षम हूं - ऐसा लगता है कि इस बिंदु पर अधिकांश पैकेज किए गए हैं। कैनवास के अलावा। क्या कोई है जिस पर मैं मदद कर सकता हूँ?

@lloydevans हाँ !!! फैंसी तैयारी या टेक्स्ट-बिटमैप कर रहे हैं? दोनों अच्छे हैं उम्मीद है कि सुपर जटिल पैकेज नहीं हैं।

@bigtimebuddy बढ़िया! मैं टेक्स्ट-बिटमैप करने पर एक नज़र डाल सकता था।

सुनने में तो अच्छा लगता है! एक बार आरंभ करने के बाद कृपया एक मसौदा पीआर बनाएं ताकि हम इसे यहां ट्रैक कर सकें।

ठीक है कर दूंगा। मैं अभी कुछ मौजूदा रूपांतरणों और पीआर पर एक नज़र डालूंगा और उनका पालन करूंगा।

ऐसा लगता है कि npm में अलग-अलग पैकेजों में अभी भी प्रकार नहीं हैं। मैं अनुमान लगा रहा हूं कि यह कुछ ऐसा है जिसे इस मुद्दे के पूरा होने के बाद संबोधित किया जा सकता है? प्रकार की सुरक्षा का त्याग किए बिना बिल्ड आकार को कम करने के लिए उनका उपयोग करने में सक्षम होना बहुत अच्छा होगा।

घर सभी को फैलाओ! बस कुछ पैकेज बचे हैं!

@Zyie , @ivanpopelyshev , @SerG-Y, @eXponenta और अन्य सभी योगदानकर्ताओं को बहुत-बहुत धन्यवाद जिन्होंने इस प्रवास को संभव बनाने में मदद की।