Language-tools: टाइपिंग Svelte कंपोनेंट प्रॉप्स/इवेंट्स/स्लॉट्स

को निर्मित 11 अग॰ 2020 · 24टिप्पणियाँ · स्रोत: sveltejs/language-tools

इसके बारे में पहले से ही कई मुद्दे हैं (#424, #304, #273, #263), लेकिन मैं उन दृष्टिकोणों के बारे में चर्चा करने के लिए एक समेकित बनाना चाहता था जो हम ले सकते हैं।
संबंधित पीआर: #437

ध्यान दें कि यह समस्या d.ts फ़ाइल टाइप करने के बारे में नहीं है, यह बाद में एक अलग समस्या के रूप में आएगी।

क्या आपका फीचर अनुरोध किसी समस्या से संबंधित है?
फिलहाल कुछ परिस्थितियों में किसी घटक के इनपुट/आउटपुट को टाइप करना संभव नहीं है:

प्रॉप्स और इवेंट/स्लॉट (जेनेरिक) के बीच एक सामान्य संबंध को परिभाषित करना संभव नहीं है
घटनाओं और उनके प्रकारों को परिभाषित करना संभव नहीं है
स्लॉट और उनके प्रकारों को विशिष्ट तरीके से परिभाषित करना संभव नहीं है

आप जो समाधान चाहते हैं उसका वर्णन करें
प्रॉप्स/ईवेंट/स्लॉट्स को स्पष्ट रूप से टाइप करने का एक तरीका।

प्रस्ताव: एक नया आरक्षित इंटरफ़ेस ComponentDef जिसे परिभाषित होने पर कोड से चीजों का अनुमान लगाने के बजाय घटक के सार्वजनिक एपीआई के रूप में उपयोग किया जाता है।

उदाहरण (क्या संभव नहीं है इसके बारे में टिप्पणियों के साथ):

<script lang="ts"
   interface ComponentDef<T> { // <-- note that we can use generics as long as they are "defined" through props
      props: {  items: T[]  }
      events: {  itemClick: CustomEvent<T>  }
      slots: { default: { item: T } }
  }

   // generic type T is not usable here. Is that a good solution? Should it be possible?
   // Also: How do we make sure the types match the component definition?
  export items: any[];

   // ...

   // We cannot make sure that the dispatched event and its type are correct. Is that a problem?
   // Maybe enhance the type definitions in the core repo so createEventDispatcher accepts a record of eventname->type?
   dispatch('itemClick', item);
</script>
<!-- ... -->
<slot item={item}> <!-- again, we cannot make sure this actually matches the type definition -->

जब कोई अब घटक का उपयोग करता है, तो उसे प्रॉप्स/ईवेंट/स्लॉट से सही प्रकार मिलेंगे और कुछ गलत होने पर त्रुटि निदान भी होगा:

<Child
     items="{['a', 'string']}"
     on:itemClick="{event => event.detail === 1 /* ERROR, number not comparable to type string */}"
/>

यदि यह काम करता है और थोड़ा परीक्षण किया जाता है, तो हम इसे अन्य आरक्षित इंटरफेस जैसे ComponentEvents के साथ केवल एक चीज टाइप करने के लिए बढ़ा सकते हैं।

मैं इस पर अधिक से अधिक प्रतिक्रिया प्राप्त करना चाहता हूं क्योंकि यह एक बड़ा बदलाव है जिसका व्यापक रूप से उपयोग किया जा सकता है। साथ ही, मैं चाहता हूं कि कुछ कोर टीम के सदस्य इस पर एक नज़र डालें यदि यह उन्हें अच्छा लगता है या कुछ ऐसा पेश करता है जिससे वे सहमत नहीं हैं।

@jasonlyu123 @orta @Conduitry @antony @pngwn

enhancement

स्रोत

dummdidumm

👍6

सबसे उपयोगी टिप्पणी

शायद मैं यहाँ गलत शब्दों का प्रयोग कर रहा हूँ... या उम्मीद है कि मैंने अभी कुछ गलत किया है।

मैं जो चाहता हूं उसका उदाहरण मैं कर सकता हूं:

```एचटीएमएल

{option.myLabelProp}

{#प्रत्येक विकल्प विकल्प के रूप में} {/प्रत्येक}

NickClark 12 नव॰ 2020

👍7 🚀1

सभी 24 टिप्पणियाँ

उचित लगता है, रनटाइम पर स्लॉट इंजेक्ट करने में सक्षम होने के बारे में वास्तव में एक स्वेल्ट मुद्दा है। https://github.com/sveltejs/svelte/issues/2588 और एक पीआर जो इसे लागू करता है https://github.com/sveltejs/svelte/pull/4296 , ऐसा लगता है कि ओवरलैप हो सकता है, या कम से कम कुछ अवसर हो सकते हैं इंटरफेस को संरेखित करें (यदि कोई सहमति है, तो उपरोक्त पीआर के साथ अभी भी कुछ बकाया प्रश्न हैं)।

pngwn 11 अग॰ 2020

पीआर लिंक के लिए धन्यवाद, ऐसा लगता है कि यह केवल हमारे लिए एक तरह से संबंधित है कि हमें कन्स्ट्रक्टर को थोड़ा अलग टाइप करना होगा, लेकिन मुझे लगता है कि यह टेम्पलेट स्तर पर टाइप चेकिंग का इंडेंट है।

dummdidumm 11 अग॰ 2020

दिलचस्प।
मुझे आश्चर्य है कि क्या हम कुछ ऐसा कर सकते हैं

<script lang="ts" generic="T"> 
    type T = unknown
    export let items: T[]
    let item:T = items[0]
</script>
<slot b={item}></slot>

जो टाइपचेक के दौरान type T = unknown को अलग कर देगा और इसके बजाय इसे घटक के सामान्य तर्क के रूप में जोड़ देगा।

//...
render<T>() {
    export let items: T[]
    let item:T = items[0]
}

halfnelson 12 अग॰ 2020

👎5 👍1

इसे render फ़ंक्शन में जोड़ने के बारे में अच्छा विचार है!

मुझे लगता है कि हम समान परिणाम प्राप्त कर सकते हैं

<script lang="ts">
    interface ComponentDef<T> {
       ...
    } 
    type T = unknown
    export let items: T[]
    let item:T = items[0]
</script>
<slot b={item}></slot>

इंटरफ़ेस परिभाषा से T निकालकर।

यद्यपि आपके समाधान के साथ आपको "मैं सिर्फ अपने प्रोप और स्लॉट के बीच एक सामान्य संबंध चाहता हूं" के मामले में कम टाइप करना होगा, जो कि अच्छा है। एक तरफ मैं सोच रहा हूं "हाँ हम दोनों को जोड़ सकते हैं", दूसरी तरफ यह एपीआई सतह को बहुत अधिक विस्तारित करने जैसा लगता है (आप एक ही काम को अलग-अलग तरीकों से कर सकते हैं) - निश्चित नहीं।

dummdidumm 12 अग॰ 2020

मैं वास्तव में interface ComponentDef<T>{ props: {} } लिखना नहीं चाहता और इसे अपने प्रत्येक निर्यात के साथ पंक्तिबद्ध करना चाहता हूं। रिएक्ट की तुलना में टाइप किए गए वर्णों को कम करने में Svelte बहुत अच्छा करता है, और यह एक कदम पीछे की तरह लगता है। विशेष रूप से, इसके लिए हर निर्यात के प्रकारों को प्रॉप्स में डुप्लिकेट करने की आवश्यकता होती है, जो कि मज़ेदार नहीं है (और लगातार समस्याओं को जन्म देने के लिए बाध्य है)।

मुझे @halfnelson की सोच पसंद है। निर्यात को सहारा के रूप में पहचाना जाना चाहिए। मुझे नहीं पता कि मॉड्यूल एक बार कैसा दिखता है

shirakaba 12 अग॰ 2020

👍3

एक और त्वरित, जैसा कि मैंने इसे कुछ संबंधित मुद्दों में पढ़ा है: मुझे @template विकल्प सहित चीजों को टाइप करने के लिए JSDoc टिप्पणियों का उपयोग करने में कोई परेशानी नहीं हुई है।

जबकि हमें JSDoc (यहां तक कि HTML के भीतर JSDoc का उपयोग करते हुए) के लिए एक खुला दिमाग रखना चाहिए, मुझे चेतावनी देनी चाहिए कि, चाहे WebStorm या VS कोड के माध्यम से उपयोग किया जाए, यह टाइपस्क्रिप्ट के रूप में केवल अभिव्यंजक नहीं है। उदाहरण के लिए यह true प्रकार को लागू नहीं करता है; मुझे यकीन है कि यह इंडेक्स प्रकार नहीं करता है; और अगर मुझे याद है, तो आपके पास Record<keyof X, any> भी नहीं हो सकता। मैं इसके साथ दीवारों में भागता रहता हूं। @template ने काम किया, लेकिन बहुत सीमित भी था। और मुझे लगता है कि यह आईडीई के आधार पर भी अलग तरह से काम करता है।

shirakaba 12 अग॰ 2020

सामान्य प्रकार (jsx) तत्व को पास करना मेरे लिए नो-गो है क्योंकि यह मान्य svelte टेम्पलेट सिंटैक्स नहीं है। इसकी भी आवश्यकता नहीं होनी चाहिए क्योंकि जेनरिक गुणों से संचालित होते हैं, मैं केवल स्लॉट/घटनाओं के लिए एक सामान्य आश्रित को पेश करने के तरीके के बारे में नहीं सोच सकता। यदि वे इनपुट गुणों से संचालित होते हैं तो जेनिक्स तत्वों को जेनिक्स पास करने की आवश्यकता नहीं होती है क्योंकि हम svelte2tsx कोड इस तरह से उत्पन्न कर सकते हैं कि टीएस हमारे लिए इसका अनुमान लगाएगा।

टाइपिंग ओवरहेड के बारे में: यह सही है लेकिन केवल उन स्थितियों में इसकी आवश्यकता होगी जहां आप जेनरिक का उपयोग करना चाहते हैं और/या स्पष्ट रूप से ईवेंट/स्लॉट टाइप करना चाहते हैं। सिद्धांत रूप में, हम यह सब स्वयं अनुमान लगा सकते हैं, लेकिन इसे लागू करना बहुत कठिन लगता है। समस्याओं को लागू करने के लिए इस तरह के कठिन उदाहरण हैं #263 जैसे उन्नत स्लॉट परिदृश्यों के लिए समर्थन, और सभी संभावित घटक घटनाओं को एकत्र करना (जो आसान है यदि उपयोगकर्ता केवल createEventDispatcher का उपयोग करेगा, लेकिन वह एक फ़ंक्शन भी आयात कर सकता है जो createEventDispatcher सामान लपेटता है)।

आम तौर पर मुझे लगता है कि ऐसी कई स्थितियां हैं जहां लोग केवल उन चीजों में से एक को परिभाषित करना चाहते हैं, लेकिन दूसरों को नहीं, इसलिए शायद "प्रकार कम" रखने के लिए सभी अलग-अलग विकल्प प्रदान करना आवश्यक है - स्वेल्ट की भावना।

इसका मतलब होगा:

ComponentDef यह सब-में-एक-अगर-आप-की जरूरत है-यह है
ComponentEvents केवल ईवेंट लिखने के लिए है
ComponentSlots केवल टाइपिंग स्लॉट के लिए है
एक निर्माण जैसे <script generic="T"> यदि आपको केवल जेनरिक की आवश्यकता है
ComponentEvents/ComponentSlots/generic="T" . का संयोजन

dummdidumm 12 अग॰ 2020

@shirakaba JSDoc प्रकार के समर्थन को टाइपस्क्रिप्ट के रूप में सुविधा संपन्न होने की आवश्यकता नहीं है। मुझे संदेह है कि बहुत से लोग इसके साथ सामान्य घटक टाइप करेंगे। इसके अलावा क्योंकि हम टाइपस्क्रिप्ट की भाषा सेवा का उपयोग कर रहे हैं, बहुत से उन्नत प्रकार टाइपस्क्रिप्ट फ़ाइल से आसानी से आयात किए जा सकते हैं।

स्लॉट प्रॉप्स टाइप-चेक के बारे में, मेरे पास कुछ हैक है लेकिन यह नहीं पता कि इससे अच्छा डेवलपर अनुभव मिलेगा या नहीं। यदि उपयोगकर्ता इस तरह का घटक टाइप करता है:

interface ComponentDef {
      slots: { default: { item: string } }
  }

हम एक वर्ग उत्पन्न कर सकते हैं

class DefaultSlot extends Svelte2TsxComponent<ComponentDef['slots']['default']>{ }

और डिफ़ॉल्ट स्लॉट को . में बदलें

<DeafaultSlot />

jasonlyu123 12 अग॰ 2020

(केवल एक उपयोगकर्ता के रूप में चिल्लाना) मेरे लिए अतिरिक्त टाइपिंग कोई समस्या नहीं है क्योंकि टाइपस्क्रिप्ट के साथ काम करते समय मुझे इसे बहुत कुछ करना है।

इंटरफ़ेस बनाम generic प्रोप के लिए, चूंकि ऐसे मामले हैं जहां चर केवल उपभोक्ता के सामने आते हैं, प्रोप का समर्थन करने के लिए बेहतर डीएक्स होगा। लेकिन उस नोट पर, क्या generic="T" के बजाय generic="T" export type T का समर्थन करना संभव होगा?

joelmukuthu 25 अग॰ 2020

यह अमान्य TS सिंटैक्स है जो लोगों को भ्रमित कर सकता है। इसके अलावा, हमें एक अतिरिक्त परिवर्तन कदम करना होगा, जो कि यदि स्वेल्टे घटक एक गैर-संकलन योग्य स्थिति में है, तो ऐसा नहीं किया जाएगा। इस मामले में भाषा-उपकरण वापस वही आते हैं जो स्क्रिप्ट में है, जिसके बाद यह अमान्य सिंटैक्स होगा। इसलिए मैं इसके खिलाफ हूं।

dummdidumm 25 अग॰ 2020

मैं समझता हूं। रुकने के लिए नहीं, लेकिन क्या यह अमान्य वाक्यविन्यास या "अपरिभाषित/अज्ञात प्रकार" त्रुटि से अधिक है? मैं पूछ रहा हूं क्योंकि मुझे नहीं पता कि टाइपस्क्रिप्ट का कंपाइलर दो मामलों को कैसे संभालता है। मेरे पास script टैग में एक कस्टम विशेषता जोड़ने के खिलाफ आरक्षण है, विशेष रूप से "जेनेरिक" के रूप में सामान्य नाम के साथ :)

सब कुछ, मेरे लिए, यह एक अच्छा है और शायद घटक का उपयोग करते समय उपयोगकर्ता को निर्यात किए गए चर टाइप करने के लिए मजबूर करना एक अच्छी बात है (अधिक पठनीय कोड)।

joelmukuthu 25 अग॰ 2020

जब आप export type T; टाइप करते हैं, तो TS एक सिंटैक्स त्रुटि देगा। इसके अलावा, बाधाओं को कैसे तैयार किया जाए? export type T extends string; आप पर अधिक सिंटैक्स त्रुटियां फेंकेगा। मैं एक कस्टम विशेषता के खिलाफ आपके आरक्षण को पूरी तरह से समझता हूं, लेकिन मुझे लगता है कि यह कम से कम बाधित करने वाला तरीका है। अन्य तरीकों से आरक्षित प्रकार के नाम होंगे जैसे T1 या T2 लेकिन यह पर्याप्त लचीला नहीं है (बाधाओं को कैसे जोड़ा जाए?)।

विकल्प यह होगा कि पूरे घटक को ComponentDef के माध्यम से टाइप किया जाए, जहां आप स्वतंत्र रूप से जेनेरिक जोड़ सकते हैं, जैसे शुरुआती पोस्ट में उदाहरण में। लेकिन यह अधिक टाइपिंग की कीमत पर आता है।

मेरे लिए यह चर्चा से स्पष्ट हो जाता है कि लोगों की इस पर बहुत अलग राय है और अधिक विकल्प निर्धारित करने के लिए ( ComponentDef , विशेषताओं के रूप में जेनेरिक प्रॉप्स, केवल टाइप करना ComponentEvents ) इसके लिए सबसे लचीला है उनमें से अधिकांश को खुश करते हैं, हालांकि वे एक ही काम करने के विभिन्न तरीकों का परिचय देते हैं।

dummdidumm 25 अग॰ 2020

हो सकता है कि मैंने इसे याद किया हो लेकिन इसे एक विकल्प में विभाजित कर रहा हूं?

<script>
  import type { Foo } from './foo';
  export let items: Foo[];
  interface ComponentSlots<T> {}
  interface ComponentEvents<T> {}
</script>

क्या इससे ज्यादातर मामलों में टाइपिंग ओवरहेड कम हो जाएगा?

joelmukuthu 26 अग॰ 2020

हाँ यह संभव होगा।

dummdidumm 26 अग॰ 2020

👍1

@dummdidumm क्या इस दौरान interface ComponentSlots {} (जेनेरिक के समर्थन के साथ या बिना) के समर्थन पर काम करना संभव है? या इसका परिचय देना यहाँ चर्चा की गई बातों के विपरीत होगा?

joelmukuthu 18 सित॰ 2020

ऐसा नहीं होगा, लेकिन कार्यान्वयन जारी रखने से पहले मैं प्रस्तावित समाधान पर समुदाय और अन्य अनुरक्षकों से अधिक प्रतिक्रिया प्राप्त करने के लिए पहले एक आरएफसी लिखना चाहता हूं। एक बार समझौता हो जाने के बाद, हम उन चीजों को लागू करना शुरू कर देंगे।

dummdidumm 18 सित॰ 2020

👍1

@joelmukuthu btw आप इंटरफ़ेस का समर्थन क्यों करना चाहेंगे? हमने स्लॉट के लिए प्रकार के अनुमान को बढ़ाया है, क्या ऐसा कोई मामला है जहां यह अभी भी आपके लिए काम नहीं कर रहा है? यदि हां, तो मैं आपका मामला सुनने के लिए उत्सुक हूं।

dummdidumm 20 सित॰ 2020

मैंने अब इस विषय पर एक RFC बनाया है: https://github.com/sveltejs/rfcs/pull/38
वहां एपीआई पर चर्चा जारी रहनी चाहिए।

dummdidumm 20 सित॰ 2020

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

joelmukuthu 28 सित॰ 2020

यह बहुत बड़ा होगा! मैं वर्तमान में दुखी हूं कि स्लॉट गुणों का उपयोग करना हमेशा कोई भी होता है।

NickClark 12 नव॰ 2020

यह अजीब है, इस बिंदु पर टाइप किए गए स्लॉट का काफी अच्छी तरह से अनुमान लगाया जा सकता है, यदि आपके द्वारा उपयोग किया जाने वाला घटक आपके प्रोजेक्ट के भीतर है और टीएस का भी उपयोग करता है।

dummdidumm 12 नव॰ 2020

मैं जो चाहता हूं उसका उदाहरण मैं कर सकता हूं:

```एचटीएमएल

{option.myLabelProp}

{#प्रत्येक विकल्प विकल्प के रूप में} {/प्रत्येक}

NickClark 12 नव॰ 2020

👍7 🚀1

ठीक है, मैं समझता हूँ, हाँ अभी यह संभव नहीं है, इसलिए आपको any[] पर वापस आना होगा। यदि यह केवल string[] की अनुमति देता है, तो आपका स्लॉट string के रूप में टाइप किया जाएगा, जिसका अर्थ है "प्रकार का अनुमान लगाया जा सकता है"।

dummdidumm 13 नव॰ 2020

मार्क वोल्कमैन द्वारा "स्वेल्टे एंड सैपर इन एक्शन" में आने वाले चेकिंग घटकों को टाइप करने का एक अच्छा अस्थायी समाधान $$ प्रोप के साथ रिएक्ट प्रोप-टाइप लाइब्रेरी का उपयोग है।

उदाहरण के लिए यह एक टोडो आइटम के लिए कोड है:

import PropTypes from "prop-types/prop-types";

const propTypes = {
    text: PropTypes.string.isRequired,
    checked: PropTypes.bool,
};

// Interface for Todo items
export interface TodoInterface {
    id: number;
    text: string;
    checked: boolean;
}

PropTypes.checkPropTypes(propTypes, $$props, "prop", "Todo");

जबकि मैं टोडो के प्रोप को मान्य कर रहा हूं और कुछ बंद होने पर त्रुटियां प्राप्त कर रहा हूं, मैं भी टोडो आइटम के लिए एक इंटरफ़ेस रखना चाहता हूं, ताकि मैं वीएससीओडी के साथ-साथ स्वत: पूर्णता में स्थिर प्रकार की जांच कर सकूं। यह ऊपर परिभाषित इंटरफ़ेस का उपयोग करके हासिल किया गया है। इसका स्पष्ट और महत्वपूर्ण पहलू यह है कि मुझे यहां डुप्लिकेट कोड की आवश्यकता है। मैं propTypes ऑब्जेक्ट से इंटरफ़ेस को परिभाषित नहीं कर सकता, या इसके विपरीत।

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

मुझे लगता है कि टाइप चेकिंग किसी भी उत्पादक कोडबेस के लिए जरूरी है, रनटाइम पर स्थिर जांच और प्रोप टाइप चेकिंग दोनों।

(ध्यान दें कि इंटरफ़ेस को संदर्भ = 'मॉड्यूल' में परिभाषित किया जाएगा, इसलिए यह घटक डिफ़ॉल्ट निर्यात के साथ निर्यात योग्य है, लेकिन संक्षिप्तता के लिए उस हिस्से को छोड़ दिया गया है)

संपादित करें: प्रोप सत्यापन के अलावा किसी अन्य चीज़ के लिए यह कोशिश नहीं की है, मुझे बताएं कि क्या यह स्लॉट/घटनाओं के लिए भी काम करेगा!

RamiAwar 23 फ़र॰ 2021

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स