Language-tools: होवर दस्तावेज़ीकरण पर दिखाई देने वाले डॉकस्ट्रिंग वाले घटकों का दस्तावेज़ीकरण

चूंकि यह स्क्रिप्ट टैग के बिना घटकों के लिए भी मूल्यवान हो सकता है, इसलिए मैं इसके लिए HTML टिप्पणी का उपयोग करने का प्रस्ताव करता हूं। svelte2tsx फिर एक विशेष टैग (जैसे @doc ) से शुरू होने वाली HTML टिप्पणियों की तलाश करेगा और सामग्री को डिफ़ॉल्ट निर्यात के ऊपर एक jsdoc के रूप में रखेगा।

राय? अन्य विचार?

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

कुछ ऐसा जो दिमाग में आता है वह है:

/**
 * <strong i="6">@file</strong> Here is my documentation for this component
 */

फ़ाइल की शुरुआत में। लेकिन मुझे लगता है कि केवल HTML टिप्पणियां ही वहां काम करती हैं, है ना?

साथ ही, शायद इसे अन्य टैगों के समान बनाने के लिए, मुझे लगता है कि <svelte:documentation> टैग <svelte:head> समान अच्छा हो सकता है, लेकिन इसे कंपाइलर में लागू करने की आवश्यकता होगी।

शायद <svelte:options documentation="blabla" /> ?

इसके लिए कंपाइलर में कुछ काम और मुख्य रेपो के अनुमोदन की भी आवश्यकता होगी। विकल्पों को संकलक द्वारा सत्यापित किया गया।

मैंने मुख्य रेपो पर एक समान मुद्दा बनाया है, देखते हैं कि क्या हम किसी निष्कर्ष पर पहुंच सकते हैं: +1:

इसका आधा हिस्सा एक बार https://github.com/sveltejs/language-tools/pull/282 मर्ज हो जाने के बाद किया जाता है। एलएसपी होवर पर दस्तावेज़ीकरण स्ट्रिंग नहीं दिखा रहा था।

अब मुझे जो करना है वह @doc HTML टिप्पणी से एक डॉकस्ट्रिंग स्रोत है और इसे svelte2tsx में addComponentExport में जोड़ें।

@dummdidumm वर्तमान में डिफ़ॉल्ट निर्यात में

export default class {
    $$prop_def = __sveltets_partial(render().props)
    $$slot_def = render().slots
}

मुझे लगता है, चूंकि प्रत्येक फ़ाइल के मूल दायरे पर जाने वाली एकमात्र चीजें render और डिफ़ॉल्ट निर्यात हैं, तो इसे Component जैसा सामान्य नाम देना हानिरहित है? या शायद फ़ाइल के नाम से चुनें?

हाँ यह कोई समस्या नहीं होनी चाहिए।

क्या इनमें से कोई भी कोड कभी भी किसी एप्लिकेशन के रनटाइम का हिस्सा बनता है, या यह केवल टूलींग समर्थन के लिए है?

सिर्फ टूलींग के लिए।
उस डिफ़ॉल्ट निर्यात के बारे में: हमें यह जांचना होगा कि यह आयात स्वतः पूर्णता को कैसे प्रभावित करता है।

सही हम्म। मुझे समझ में नहीं आता कि यह वर्तमान में कैसे काम करता है। अगर मैं इसे टीएस-केवल वातावरण में अनुकरण करने का प्रयास करता हूं:

// Component.ts
export default class {}

मुझे अन्य फ़ाइलों पर Component लिए स्वत: पूर्णता नहीं मिलती है, लेकिन Svelte पर यह किसी भी तरह काम करता है। मुझे शायद एलएसपी में संबंधित कोड पढ़ना चाहिए।

वैसे भी, अगर मैं इसके बजाय ऐसा करता हूं:

// Component.ts
export default class Component {}

फिर मुझे डिफ़ॉल्ट निर्यात के लिए अन्य फाइलों पर Component रूप में स्वत: पूर्णता मिलती है। इसलिए मैं सुरक्षित शर्त का समर्थन करता हूं कि डिफ़ॉल्ट निर्यात को फ़ाइल के समान ही नाम दें, और फिर इसका लाइव परीक्षण करें।

ठीक है, इसलिए मैंने दो विकल्पों की कोशिश की है, लेकिन हमारे एलएसपी के साथ, घटक आयात के स्वत: पूर्णता के लिए काम करने वाली एकमात्र चीज है:

export default class {
  // etc
}

जिन चीजों की मैंने कोशिश की है:

• एक वर्ग घोषित करना और फिर इसे एक अलग पंक्ति में डिफ़ॉल्ट रूप से निर्यात करना।
• सीधे export default class Name लाइन में नाम जोड़ना।

~ इनमें से कोई भी काम नहीं करता है। अब मैं कंप्लीशन प्रदाता (https://github.com/sveltejs/language-tools/blob/master/packages/language-server/src/plugins/typescript/features/CompletionProvider.ts) में देख रहा हूं कि कहां अपराधी है, क्योंकि टीएस-केवल वातावरण में मुझे वर्ग के नाम के आधार पर नामित वर्गों के डिफ़ॉल्ट निर्यात के लिए पूर्णता मिलती है। ~

अद्यतन: एक वर्ग घोषित करना और फिर इसे एक अलग लाइन में डिफ़ॉल्ट रूप से निर्यात करना तब तक काम करता है जब तक कि निर्यात का नाम फ़ाइल नाम के समान हो। मैं इस विकल्प के लिए जा रहा हूँ।

हाँ, व्यापक घटकों के लिए आयात पूर्णता में कुछ अतिरिक्त कोड हैं, अनिवार्य रूप से आयात सुझाव का निर्माण। हो सकता है कि उस कोड को फेंक दिया जा सकता है यदि svelte2tsx में एक नामित डिफ़ॉल्ट निर्यात है जो फ़ाइल नाम के समान है।

https://github.com/sveltejs/language-tools/pull/285 . के माध्यम से फिक्स्ड