तो उनमें से कोई भी Svelte पार्सर का उपयोग नहीं कर रहा है?

svelte2tsx स्टाइल/स्क्रिप्ट टैग को हटा देता है और फिर htmlx भाग को पार्स करने के लिए svelte कंपाइलर का उपयोग करता है।
svelte-ts दूसरे चरण के रूप में svelte कंपाइलर का उपयोग करता है।
वर्तमान भाषा सर्वर पार्सिंग के लिए व्यापक संकलक का उपयोग नहीं करता है।
मैं प्रारंभिक पोस्ट अपडेट करूंगा।

मुझे यकीन नहीं था कि मुझे इसे साझा करना चाहिए, लेकिन इसका कुछ हिस्सा उपयोगी हो सकता है। पिछले साल (जुलाई/अगस्त 2019) मैंने टाइपचेकिंग स्वेल्ट के साथ खेलना शुरू कर दिया था, यह जानते हुए कि मैं सिर्फ सीखने के लिए फालतू काम कर रहा था। यह पूर्ण समाधान की कुछ अज्ञात राशि का समर्थन करता है, शायद 30%, और इसकी कुछ सीमाएँ हैं (बाद में उन पर अधिक)। कोई परीक्षण या बाहरी दस्तावेज नहीं हैं क्योंकि मैंने हमेशा इसे एक मृत अंत माना है।

एक गैर-टाइपचेकिंग टीएस प्रीप्रोसेसर के साथ आज के रूप में स्वेल्ट संकलन चला जाता है। यदि आप अपने HTMLx मार्कअप में टाइप करना चाहते हैं, न कि केवल अपने स्क्रिप्ट टैग में, तो आपको इसे संभालने के लिए एक प्रीप्रोसेसर की आवश्यकता होगी, या Svelte को TS को आंतरिक रूप से संभालने की आवश्यकता होगी।

टाइपचेकर एक अलग बिल्ड स्टेप है जो script ब्लॉक से अन-प्रीप्रोसेस्ड टाइपस्क्रिप्ट कोड का उपयोग करता है और svelte.compile से मार्कअप एएसटी का उपयोग केवल टाइपचेकिंग उद्देश्यों के लिए वर्चुअल फ़ाइल बनाता है और फिर उसे टाइपचेक करता है ) यह @हाफनेल्सन की रणनीति के समान है, लेकिन इसमें भिन्न है कि यह सामान्य TS उत्पन्न करता है, TSX नहीं, इसलिए मार्कअप में यह HTML टैग्स को टाइप करने की कोशिश नहीं करता है और विशेषताएँ, केवल मूंछें टैग और Svelte घटकों के अंदर का सामान। यह Svelte घटकों को कंस्ट्रक्टर में बदल देता है जो new एड अपने प्रॉप्स के साथ प्राप्त करते हैं। मुझे यह महसूस करने से पहले कि मैं अपने इरादे से कहीं अधिक दूर हो गया, मुझे बहुत सारे स्वेल्ट के निर्माणों का समर्थन करने के माध्यम से भाग मिला, और आगे की प्रगति सीरियस इंजीनियरिंग होनी चाहिए।

टाइपस्क्रिप्ट कंपाइलर एपीआई का उपयोग मेमोरी में एक प्रोग्राम बनाने और वर्चुअल Svelte TS को

वर्चुअल Svelte TS फ़ाइल एक सोर्समैप के साथ उत्पन्न होती है, जिसका उपयोग टाइपस्क्रिप्ट डायग्नोस्टिक्स को मूल Svelte स्रोत पर वापस मैप करने के लिए किया जाता है। यह देखने में बहुत अच्छा था कि टाइप एरर वापस Svelte स्रोत की ओर इशारा करते हैं लेकिन मुझे अपने दृष्टिकोण पर समग्र रूप से कोई भरोसा नहीं था।

एक समस्या जो मुझे याद है कि मैं समझ नहीं पाया वह निदान के साथ थी जो कुछ मामलों में पर्याप्त विशिष्ट नहीं थे। IIRC एक उदाहरण टाइपचेकिंग Svelte कंपोनेंट कंस्ट्रक्टर प्रॉप्स के साथ था - VSCode किसी तरह अलग-अलग प्रॉप एरर की ओर इशारा करेगा, लेकिन TS डायग्नोस्टिक्स जो मुझे मिल रहा था, वह केवल कंस्ट्रक्टर की ओर इशारा कर रहा था, प्रॉब्लम प्रॉपर्टी की नहीं।

यदि आप कोड को देखते हैं तो सावधान रहें कि भागों में गड़बड़ी है और कुछ टिप्पणियां पुरानी हो सकती हैं। मैंने मूल रूप से magic-string और कुछ बिंदु पर source-map बदल गया। और याद रखें कि यह शुरू से ही एक बर्बाद प्रयास था! ध्यान दें कि यह सब उस रेपो की ts शाखा पर है, न कि master ।

यहाँ ऊपर संदर्भित 4 फाइलें हैं:

• वर्चुअलSvelteTs.ts
• टाइपचेक.ts
• tsडायग्नोस्टिक्स.ts
• रोलअप-प्लगइन-svelte-typescript-checker.ts

मैंने वर्तमान व्यापक भाषा सर्वर के स्रोत कोड में कुछ खुदाई की है। यहाँ इसके टाइपप्रति भाग पर मेरे विचार हैं:

अवलोकन

मोटे तौर पर काम करने वाला भाषा सर्वर इसे पसंद करता है:

• DocumentManager खोले जाने वाले सभी दस्तावेज़ों को संभालता है।
• TypescriptPlugin भाषा सर्वर ईवेंट ("doHover" आदि) पर लागू होने के लिए DocumentManager पर रजिस्टर करता है। यह सीधे पंजीकृत नहीं होता है: यह wrapFragmentPlugin साथ लपेटा जाता है जो सुनिश्चित करता है कि TypescriptPlugin केवल script टैग के अंदर सामग्री प्राप्त करता है। स्थिति का मानचित्रण (माउस/पाठ कर्सर का) wrapFragmentPlugin जाता है ताकि यह सुनिश्चित किया जा सके कि जानकारी सही स्थिति में दिखाई दे रही है।
• TypescriptPlugin service का उपयोग करता है, जो एक टाइपस्क्रिप्ट भाषा सेवा आवरण है। यह मूल रूप से सभी घटनाओं को इस भाषा सर्वर को सौंपता है, कुछ मैपिंग के साथ विधि वापसी प्रकारों का पालन करने के लिए।
• service दस्तावेज़ को काम करने के साथ-साथ createDocument विधि से TypescriptPlugin । service दस्तावेजों का अपना नक्शा रखता है जो इस समय मूल रूप से केवल DocumentsManager के दस्तावेज़ का प्रतिनिधि है। हर बार service से TypescriptPlugin service का आह्वान किया जाता है, service दिए गए दस्तावेज़ के साथ अपने दस्तावेज़ मानचित्र को अपडेट करता है (इसे लपेटने के बाद)। createDocument को लागू किया जाएगा यदि भाषा सेवा एक दस्तावेज़ खोलती है जो अभी तक दस्तावेज़ मानचित्र का हिस्सा नहीं है - लेकिन ऐसा कभी नहीं होगा क्योंकि टाइपस्क्रिप्ट भाषा सेवा अन्य व्यापक मॉड्यूल नहीं ढूंढती है (अगला भाग देखें)।

सुधार के लिए वर्तमान कमियां और विचार

• चूंकि स्क्रिप्ट टैग को टाइपस्क्रिप्ट भाषा सेवा के रूप में दिया गया है, यह विशेष व्यापक वाक्यविन्यास ($) से निपट नहीं सकता है।
• टाइपप्रति भाषा सेवा अन्य फ़ाइलों को देखने का प्रयास करती है जो वर्तमान में खुली हुई फ़ाइल में संदर्भित हैं। .ts / .js फाइलों के लिए यह काम करता है, .svelte फाइलों के लिए यह काम नहीं करता है। कारण: टाइपस्क्रिप्ट भाषा सेवा .svelte समाप्त होने के बारे में नहीं जानती है, इसलिए यह मानती है कि यह एक सामान्य टाइपस्क्रिप्ट फ़ाइल है और ../Component.svelte.ts जैसी फ़ाइलों की खोज करती है, जो गलत है। इसे ठीक करने के लिए, हमें resolveModuleNames को LanguageServiceHost और सभी .svelte.ts फ़ाइल लुकअप को .svelte रूट करना होगा। तब भाषा सेवा सभी व्यापक फाइलों को चलाएगी। नोट: इसे लागू करने के लिए, हमें निम्नलिखित बग को भी ठीक करने की आवश्यकता है: चूंकि टाइपस्क्रिप्ट भाषा सेवा अब सभी फाइलों पर चलेगी, createDocument यह TypescriptPlugin आह्वान करेगी। लेकिन यह वर्तमान में पूरे दस्तावेज़ को लौटाता है, न कि केवल स्क्रिप्ट टैग के अंदर की सामग्री। यह अंदर एक बग है wrapFragmentPlugin लपेटकर नहीं openDocument ।
• अधिक उन्नत सुविधाओं को लागू करने के लिए जैसे "गो टू सॉल्वेट फाइल" पर क्लिक करके svelte कंपोनेंट इंपोर्ट नेम पर क्लिक करें, या टाइपस्क्रिप्ट को $ साइन्स ग्रोग करें, हमें एक प्रीप्रोसेसर जोड़ने की जरूरत है। यह प्रीप्रोसेसर किसी तरह टाइपस्क्रिप्ट के लिए लापता भागों को जोड़ देगा। आदर्श रूप से, सभी अतिरिक्त सामग्री को मौजूदा कोड के शीर्ष पर रखा जा सकता है, ताकि पदों को मैप करना ऑफसेट के साथ पदों को मैप करने जितना आसान हो। हालांकि यह एक और चुनौती है: अब हमारे पास दो स्थिति मानचित्रण होंगे: एक संपूर्ण फ़ाइल से स्क्रिप्ट टैग तक, और एक स्क्रिप्ट टैग से प्रीप्रोसेस्ड टाइपस्क्रिप्ट कोड तक। मुझे इस बिंदु पर यकीन नहीं है कि यह जाने का तरीका है या अगर हमें फिर से काम करना चाहिए कि TypescriptPlugin (और अन्य) को इसका दस्तावेज़ कैसे मिलता है - शायद स्क्रिप्ट टैग और प्रीप्रोसेसिंग दोनों को एक चरण में निकाला जाना चाहिए . इसका मतलब होगा wrapFragmentPlugin बदलना या पूरी तरह से बदलना। पुनर्विक्रय के लिए एक और तर्क यह है कि, "अप्रयुक्त फ़ंक्शन" जैसी चीज़ों को सही ढंग से निर्धारित करने के लिए, हमें HTML भाग को ध्यान में रखना होगा, इसलिए स्क्रिप्ट टैग पर्याप्त नहीं है।

विचार?

resolveModuleNames , यहां बताया गया है कि टाइपस्क्रिप्ट टीम के सदस्य ने Vetur के लिए इसे कैसे किया , और यहां एक समान संस्करण है जो मैंने Svelte के लिए किया था, जिसमें एक टिप्पणी शामिल है जिसमें एक वैकल्पिक रणनीति का उल्लेख है जो काम करती है, लेकिन Vetur की नकल करना बेहतर लग रहा था।

@dummdidumm क्या आपको टेक लीड के रूप में काम करने और इन चीजों को विशिष्ट मुद्दों पर तोड़ने का मन है? मुझे स्वेच्छा से देव समय देने में खुशी होगी, लेकिन मुझे यह बहुत भारी लगता है और मैं छोटे, परिभाषित मुद्दों में बेहतर काम करूंगा। जब तक कोई बड़ा वास्तु परिवर्तन नहीं किया जाता है जिसे करने की आवश्यकता होती है (ऐसा नहीं लगता है?)

मूल रूप से बस मुद्दों का एक समूह खोलें और लोगों को उन पर दावा करने दें और उन्हें इस पर हमारे अनौपचारिक तकनीकी नेतृत्व के रूप में प्रबंधित करें। मैं इसे करने की पेशकश करूंगा लेकिन ईमानदारी से अभी तक दर्द महसूस नहीं किया है

https://github.com/sveltejs/svelte/issues/4518 ब्राउज़ करने वाले अन्य लोगों के लिए ओर्टा की मूल एलएसपी पोस्ट से भी लिंक करना

निश्चित रूप से मुझे इस पर मदद करना अच्छा लगेगा, लेकिन अभी मैं सिर्फ एक यादृच्छिक दोस्त हूं जो भाषा सर्वर के बारे में बहुत उत्साहित है, कोड में खुदाई कर रहा है और कुछ सुझाव दे रहा है 😄 मुझे कोड से परिचित होने के लिए कुछ और समय चाहिए, इसकी वास्तुकला और सामान्य रूप से एलएसपी। लेकिन मैं निश्चित रूप से सामान को आगे बढ़ाने के लिए तैयार हूं। @orta चूंकि आप इस रेपो के अनुरक्षक हैं, आप इस बारे में क्या सोचते हैं?

हाँ, हम दोनों यादृच्छिक लोग हैं जो केवल परवाह करते हैं - मेरे पास "यह बेहतर होना चाहिए" खुजली को ट्रिगर करने के लिए कोई व्यापक कोडबेस भी नहीं है। इसलिए, मैं किसी भी आंदोलन को देखकर बहुत खुश हूं - @dummdidumm - दूर धकेलें और मैं आपका समर्थन करूंगा और यह सुनिश्चित करने का प्रयास करूंगा कि सब कुछ सुचारू रूप से चले

ठीक है अच्छा है! मैं आगे बढ़ूंगा और कुछ पीआर को कुछ कोड के पुनर्गठन और इसे तैयार करने के लिए तैयार करूंगा ताकि हम अलग-अलग वस्तुओं पर काम करना समानांतर कर सकें।

हो सकता है कि हम @ryanatkn , svelete-ts के दृष्टिकोण और eslint-plugin-svelte3 के चर दृष्टिकोण को

1. स्क्रिप्ट को जेएस में प्रीप्रोसेस करने के लिए
   यहां हम जितना संभव हो उतना कम परिवर्तन करने के लिए ES के नवीनतम या अगले संस्करण में बस ट्रैंपाइल कर सकते हैं।
2. पूर्वसंसाधित स्रोत को संकलित करने दें।
3. फिर हम परिणाम वर्र्स को इंजेक्ट कर सकते हैं जहां injected = true उदाहरण में ts स्रोत या ts AST और फिर टाइप चेक और ऑटो-पूर्णता प्रदान करने के लिए स्रोत मानचित्र के साथ इसका उपयोग करें।

स्क्रिप्ट में तीन टुकड़े हो सकते हैं: मॉड्यूल <script context="module"> , उदाहरण और मूंछें (टेम्पलेट)। मूंछों वाला हिस्सा अभी के लिए एक template.js में डंप किया जा सकता है। लेकिन लंबी अवधि के लिए हम टेम्पलेट को tsx या सादे ts जैसे ryanatkn के दृष्टिकोण में प्रतिबिंबित कर सकते हैं।

मॉड्यूल संस्करण, जहां module = true , को template.js और उदाहरण में इंजेक्ट किया जाएगा, लेकिन दूसरी तरफ नहीं।

इस तरह हमें टाइपस्क्रिप्ट एएसटी में प्रतिक्रियाशील चर $: a = 1 या $-prefixed स्टोर को खोजने के तरीके पर फिर से लागू करने की आवश्यकता नहीं है। सॉल्वेट कंपाइलर द्वारा इंजेक्ट किए गए ये वेरिएबल टॉप-लेवल स्टेटमेंट से प्राप्त होते हैं और हम इसे नवीनतम ES में ट्रांसपिल कर रहे हैं। तो इसका ज्यादातर नाम टाइपस्क्रिप्ट द्वारा नहीं बदला जाना चाहिए।

प्रतिक्रियाशील चर $: a इसे इस तरह लिखा जा सकता है:

$: a = 1

```ts
चलो एक: संख्या
$: ए = 1

```ts
$: a = someFunction(b) as Type

यह सब मान्य ts है जिसे ट्रांसपाइल से पहले बदलने की आवश्यकता नहीं है

और $-prefixed store हम एक सामान्य फंक्शन बना सकते हैं जैसे svelte/store get to Extract store type

/** injected */
let $store = getType(store)

1. स्क्रिप्ट को जेएस में प्रीप्रोसेस करने के लिए
   यहां हम जितना संभव हो उतना कम परिवर्तन करने के लिए ES के नवीनतम या अगले संस्करण में बस ट्रैंपाइल कर सकते हैं।
2. पूर्वसंसाधित स्रोत को संकलित करने दें।
3. फिर हम परिणाम वर्र्स को इंजेक्ट कर सकते हैं जहां injected = true उदाहरण में ts स्रोत या ts AST और फिर टाइप चेक और ऑटो-पूर्णता प्रदान करने के लिए स्रोत मानचित्र के साथ इसका उपयोग करें।

मुझे लगता है कि svelte-ts ऐसा ही कुछ करता है। यह अच्छा विचार प्रतीत होता है। injected = true : यह संपत्ति वास्तव में किस कोड में है?

स्क्रिप्ट में तीन टुकड़े हो सकते हैं: मॉड्यूल <script context="module"> , उदाहरण और मूंछें (टेम्पलेट)। मूंछों वाला हिस्सा अभी के लिए एक template.js में डंप किया जा सकता है। लेकिन लंबी अवधि के लिए हम टेम्पलेट को tsx या सादे ts जैसे ryanatkn के दृष्टिकोण में प्रतिबिंबित कर सकते हैं।

मॉड्यूल संस्करण, जहां module = true , को template.js और उदाहरण में इंजेक्ट किया जाएगा, लेकिन दूसरी तरफ नहीं।

इस तरह हमें टाइपस्क्रिप्ट एएसटी में प्रतिक्रियाशील चर $: a = 1 या $-prefixed store को खोजने के तरीके पर फिर से लागू करने की आवश्यकता नहीं है। सॉल्वेट कंपाइलर द्वारा इंजेक्ट किए गए ये वेरिएबल टॉप-लेवल स्टेटमेंट से प्राप्त होते हैं और हम इसे नवीनतम ES में ट्रांसपिल कर रहे हैं। तो इसका ज्यादातर नाम टाइपस्क्रिप्ट द्वारा नहीं बदला जाना चाहिए।

तो आप फ़ाइल को वर्चुअल .ts -file और .template -file में विभाजित करना चाहते हैं? .ts -फाइल के निचले हिस्से में मूंछें क्यों नहीं हैं? इस तरह हमें "अप्रयुक्त विधि" -चेतावनी से भी छुटकारा मिलेगा। एएसटी पर चलने पर: हां, मुझे लगता है कि हम यहां स्मार्ट हो सकते हैं और एएसटी को बहुत अधिक देखना छोड़ सकते हैं क्योंकि टेम्पलेट में संदर्भित हर चीज स्क्रिप्ट में शीर्ष स्तर की होनी चाहिए।

प्रतिक्रियाशील चर $: a इसे इस तरह लिखा जा सकता है:

$: a = 1

let a: number
$: a = 1

या

$: a = someFunction(b) as Type

यह सब मान्य ts है जिसे ट्रांसपाइल से पहले बदलने की आवश्यकता नहीं है

क्या प्रकार का अनुमान लगाना संभव है? हो सकता है कि यह कुछ ऐसा है जिसे हम छोड़ देते हैं और यदि उपयोगकर्ता टाइपस्क्रिप्ट का उपयोग करना चाहता है, तो उसे स्वयं let a: number परिभाषित करना होगा। एक विकल्प के रूप में, हम सम्मिलित कर सकते हैं let a; , लेकिन तब यह any ।

और $-prefixed store हम एक सामान्य फंक्शन बना सकते हैं जैसे svelte/store get to Extract store type

/** injected */
let $store = getType(store)

हाँ यह अच्छा लगता है। मेरे पास एक और विचार गेटर्स/सेटर्स बनाना था।

मुझे लगता है कि svelte-ts ऐसा ही कुछ करता है। यह अच्छा विचार प्रतीत होता है। injected = true : यह संपत्ति वास्तव में किस कोड में है?

संकलन परिणाम में एक संपत्ति vars है, जो ऑब्जेक्ट की एक सरणी है जिसमें निम्न गुण हैं:
नाम, निर्यात_नाम, इंजेक्शन, मॉड्यूल, उत्परिवर्तित, पुन: असाइन किया गया, संदर्भित_फ्रॉम_स्क्रिप्ट और लिखने योग्य
आप अधिक जानकारी के लिए व्यापक संकलन एपीआई देख सकते हैं

तो आप फ़ाइल को वर्चुअल .ts-file और .template-file में विभाजित करना चाहते हैं? .ts-file के नीचे मूंछें-भाग क्यों नहीं हैं? इस तरह हमें "अप्रयुक्त विधि" -चेतावनी से भी छुटकारा मिलेगा।

यह eslint-plugin-svelte3 का दृष्टिकोण है। इसके अलावा, मैंने सोचा कि क्या हम टेम्पलेट में ts का समर्थन करना चाहते हैं क्योंकि भाषा निर्दिष्ट करने के लिए कोई विशेषता नहीं है।

क्या प्रकार का अनुमान लगाना संभव है?

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

क्या प्रकार का अनुमान लगाना संभव है? हो सकता है कि यह कुछ ऐसा है जिसे हम छोड़ देते हैं और यदि उपयोगकर्ता टाइपस्क्रिप्ट का उपयोग करना चाहता है, तो उसे let a: number को स्वयं परिभाषित करना होगा। एक विकल्प के रूप में, हम let a; डाल सकते हैं, लेकिन तब यह कोई भी होगा।

ऐसा लगता है कि सामान्य अनुमान हमें वहां तक ​​नहीं ले जाता है। (क्या आपका मतलब संकलन-समय अनुमान था? सुनिश्चित नहीं है कि यह काम कर सकता है)

let a; // type is "any" initially
$: a = 5;
a; // type is now "number", good
const cb = () => a; // type is implicitly "any", noo

इसका कारण यह है कि रैखिक कोड प्रवाह में, टाइपस्क्रिप्ट देख सकता है कि a को पुन: असाइन नहीं किया गया था, लेकिन नेस्टेड फ़ंक्शन स्कोप में वह गारंटी नहीं होती है, और टाइपस्क्रिप्ट टाइप सुरक्षा के पक्ष में गलतियाँ करता है।

खेल का मैदान उदाहरण

बिल्कुल, यही मेरी चिंताएँ थीं। लेकिन जैसा कि @ jasonlyu123 ने बताया, हम केवल परिभाषा की प्रतिलिपि बना सकते हैं ( = बाद सब कुछ)।

पहले

$: a = true;

बाद में

let a = true;
$: a = true;

लेकिन मुझे नहीं पता कि यह सभी परिस्थितियों के लिए संभव है। विशेष रूप से बड़ी वस्तुओं के साथ जहां कोई इंटरफ़ेस लागू करता है, यह सब कुछ अनुमान नहीं लगाएगा जैसा कि उपयोगकर्ता उम्मीद कर सकता है। इसके अलावा, कॉपी-पास्ता बहुत बड़ा हो सकता है। तो मैं अभी भी "उपयोगकर्ता को इसे टाइप करने दें" के पक्ष में हूं।

स्पष्टीकरण के लिए धन्यवाद, मैंने गलत समझा कि @ jasonlyu123 ने क्या कहा। यह मेरे द्वारा उल्लिखित नेस्टेड फ़ंक्शन स्कोप समस्या को ठीक करता है।

क्या इसका कोई उदाहरण है जब यह अच्छा डिफ़ॉल्ट व्यवहार नहीं है? ऐसा लगता है कि यह ज्यादातर समय एर्गोनोमिक सही काम करता है, और अन्य मामलों को मैन्युअल रूप से ठीक किया जा सकता है। यहां कुछ उदाहरण दिए गए हैं।

एमएच मुझे लगता है कि तुम सही हो। यह सबसे एर्गोनोमिक चीज है। मुझे इस बात की चिंता है कि क्या अनुमानित प्रकार गलत है, उदाहरण के लिए संपत्ति string स्ट्रिंग्स के परिभाषित संघ के बजाय है ( 'a' | 'b' )। लेकिन जैसा कि आपने कहा, ये मामले इतने सामान्य नहीं हैं और फिर भी उपयोगकर्ता इसे मैन्युअल रूप से टाइप कर सकता है।

मेरा एक हिस्सा है जो इस तरह है: "महान, स्पष्ट वाक्य वाक्यविन्यास भयानक काम करता है" लेकिन यह बॉक्स के बाहर जेएस समर्थन के साथ काम नहीं करेगा

जाने देने के लिए बस पहले लेबल को बदलने के बारे में क्या:

$: a = 1
$: a = 2

में रूपांतरित हो जाओ

/** injected  */
let a = 1
$: a = 2

मैं थोड़ा पुनर्विचार करता हूं और " $: को let से बदलने पर "प्रतिलिपि परिभाषा" का लाभ नहीं ढूंढ सकता। क्या आप लोग $: को let से बदलने के किसी नुकसान के बारे में सोच सकते हैं?

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

इससे पहले

$: a = 'const1'

उपरांत

let a : AskUserForType
$: a = 'const1'

आपके द्वारा बताई गई बातों के लिए भी सोचता है, कुछ सीखा

हा, स्मार्ट विचार, $: को let माध्यम से पूरी तरह से प्रतिस्थापित करें। मैं ऐसी किसी भी स्थिति को भी नहीं जानता जहां यह बुरा होगा।
हम केवल पहले लेबल के लिए ही नहीं, हमेशा परिवर्तन करने के बारे में भी सोच सकते हैं। फिर एक "पुन: घोषित नहीं किया जा सकता" - त्रुटि जो उपयोगकर्ता को "वूप्स, मैंने इस चर को दो बार परिभाषित किया" पर संकेत दिया - या ऐसी स्थितियां हैं जहां यह व्यवहार्य होगा और गलती नहीं होगी?

अच्छा, मैं किसी भी कारण के बारे में नहीं सोच सकता कि लेबल को बदलना या तो विफल हो जाएगा। (चूंकि break $ कभी भी असाइनमेंट के अंदर काम नहीं करता है, है ना?)

समान प्रतिक्रियाशील चर को फिर से घोषित करने के लिए, ऐसा लगता है कि Svelte इसकी अनुमति देता है और यह आपकी अपेक्षा के अनुरूप काम करता है। ( यह उत्तर उदाहरण देखें ) मैं व्यक्तिगत रूप से खुद को जानबूझकर इस पैटर्न का उपयोग करते हुए नहीं देखता हूं और त्रुटि चाहता हूं, लेकिन यह स्वेल्टे के शब्दार्थ की व्याख्या करने के क्षेत्र में है, इसलिए इसके लिए मेरा शब्द न लें!

ठीक है तो इसे फिर से घोषित करना एक ऐसा पैटर्न है जो वास्तव में काम करता है। मैं कहूंगा कि हम इसे बेहतर अनुमति देते हैं - या "पुनः घोषित करने की अनुमति नहीं है" - बाद में फीचर ध्वज जो डिफ़ॉल्ट रूप से बंद है।

@halfnelson ने https://github.com/halfnelson/svelte-type-checker-vscode में अपने svelte2tsx दृष्टिकोण के आधार पर एक भाषा सर्वर बनाया है। मैं वास्तव में प्यार करता हूँ कि यह सब पहले से ही कितना अच्छा काम करता है, लेकिन मैं अभी भी tsx को एक मध्यवर्ती आउटपुट के रूप में उपयोग नहीं करना पसंद करूंगा क्योंकि मुझे डर है कि यह थोड़ा बहुत धीमा हो सकता है और इसकी कुछ सीमाएँ हो सकती हैं - लेकिन यह सिर्फ मेरी आंत की भावना है। फिर भी, हम svelte2tsx से बहुत कुछ ले सकते हैं: पार्सिंग-कंपाइलिंग-ट्रांसफॉर्मेशन का प्रवाह कैसे किया जाता है, और व्यापक परीक्षण सूट भी। कोड को tsx में बदलने के दृष्टिकोण को अन्य लोग कैसे देखते हैं?

मैं हालांकि इस बारे में कि अन्य परिवर्तन कैसे दिख सकते हैं। यहां कुछ उदाहरण दिए गए हैं। प्रतिक्रिया का स्वागत है।

एक घटक परिभाषा कैसी दिखती है

मूल:

<script>
    import { createEventDispatcher } from 'svelte';
    const dispatch = createEventDispatcher();

    export let todo: string;

    function doneChange() {
        dispatch('doneChange', true);
    }
</script>

परिवर्तित:

export default class Component {
   constructor(props: {todo: string; 'on:doneChange': (evt: CustomEvent<boolean>) => void}) {}
}

import { createEventDispatcher } from 'svelte';
const dispatch = createEventDispatcher();

export let todo: string;

function doneChange() {
    dispatch('doneChange', !todo.done);
}

व्याख्या:
किसी तरह सभी प्रॉप्स (आसान) और भेजे गए इवेंट (हार्ड) प्राप्त करें और उन्हें एक बड़े प्रॉप्स ऑब्जेक्ट में जोड़ें। on: -prefix के साथ ईवेंट जोड़ना टकराव को कम करना चाहिए और स्वत: पूर्ण सुझावों को लागू करना आसान बनाना चाहिए।

(निम्न उदाहरणों में, घटक-परिभाषा को संक्षिप्तता के लिए छोड़ दिया गया है)

टेम्पलेट में चर का प्रयोग करें

मूल:

<script>const bla = {bla: 'bla'};</script>
<p>{bla.bla}</p>

परिवर्तित:

const bla = 'bla';
const _bla = bla.bla;

व्याख्या:
चर के सही उपयोग की जांच करने के लिए और "अप्रयुक्त"-चेतावनी को दूर करने के लिए मनमाने ढंग से const तत्व जोड़ें, शायद कुछ अस्पष्ट यूनिकोड वर्ण के साथ उपसर्ग करें। हो सकता है कि फिर हमें इस बारे में सोचना पड़े कि अप्रयुक्त _bla -चेतावनी से कैसे छुटकारा पाया जाए ...

स्थानीय ईवेंट श्रोता का उपयोग करें

मूल:

<script>function bla() {return true;}</script>
<button on:click={bla}>bla</button>

परिवर्तित:

function bla() {return true;}
const btn = document.createElement('button');
btn.addEventListener('click', bla);

व्याख्या:
मूल ईवेंट श्रोताओं का उपयोग करते समय, संबंधित तत्व बनाएं और फिर ईवेंट श्रोता जोड़ें। इस तरह हम addEventListener -टाइपिंग का लाभ उठाते हैं, जिसमें हर श्रोता के लिए बहुत अधिक भार होता है: .addEventListener('click', ...); -> ईवेंट प्रकार का होता है MouseEvent । इस पैटर्न का उपयोग यह जांचने के बाद किया जाएगा कि क्या तत्व एक और व्यापक घटक है जिसमें घटना परिभाषित है (अगला उदाहरण भी देखें)। कमियां: क्या होगा यदि Svelte का उपयोग गैर-वेब-वातावरण (Nativescript) में किया जाता है?

अन्य घटक का प्रयोग करें

मूल:

<script>
import Bla from './bla.svelte';
function blub() {}
</script>
<Bla bla={1} on:blubb={blub} />

परिवर्तित:

import Bla from './bla.svelte';
function blub() {}
const bla = new Bla({bla: 1, 'on:blubb': blub});

व्याख्या:
प्रत्येक घटक को कक्षा परिभाषा मिलती है, इसलिए हम उस वर्ग को तुरंत चालू करते हैं।

प्रत्येक लूप

मूल:

{#each todos as todo,i (todo.id)}
    <p>{todo.text}</p>
{/each}

परिवर्तित:

todos.forEach((todo, i) => {
    const _todoText = todo.text;
});

व्याख्या:
forEach कनवर्ट करना सबसे आसान लगता है। अंदर, हम अन्य सभी सुविधाओं को पुनरावर्ती रूप से लागू कर सकते हैं।

अगर

मूल:

{#if x === 1}
    <p>if</p>
{else if x === 2}
    <p>elseif</p>
{else}
    <p>else</p>
{/if}

परिवर्तित:

if (x === 1) {

} else if (x === 2) {

} else {

}

व्याख्या:
काफी आत्म-व्याख्यात्मक।

गुम टुकड़े

• स्लॉट्स
• विशेष svelte:x घटक
• अन्य तत्व/घटक निर्देश जैसे use:action , transition , bind
• $-वाक्यविन्यास

तुम लोग क्या सोचते हो? क्या ये परिवर्तन व्यवहार्य और साध्य हैं? क्या मुझसे कुछ छूटा?

घटक वर्ग के बारे में मैं svelte के स्वयं के SvelteComponent वर्ग का विस्तार करना पसंद करूंगा, लेकिन मुझे नहीं पता कि इसे लागू करना आसान है या नहीं

import { SvelteComponent } from "svelte";

export default class Component extends SvelteComponent {
    constructor(options: ComponentOption<{ propA: string }>) {
        super(options)
    }

    $on(
        event: 'input',
        callback: (event: CustomEvent<string>) => void
    ): () => void
    $on(
        event: 'click',
        callback: (event: CustomEvent<number>) => void
    ): () => void 
    $on(
        event: string,
        callback: (event: CustomEvent<any>) => void
    ): () => void {
        return () => { }
    }
}

और इन इंटरफेस को आयात करें

interface ComponentOption<TProps, TSlot = undefined> {
    target: Element,
    props: TProps | SlotProp<TSlot>
}

type SlotOption<T> = [unknown, unknown, unknown]

interface SlotProp<TSlot> {
    $$slots: Record<string, SlotOption<TSlot>>
}

विख्यात $$slots शायद svelte की आंतरिक एपीआई है, मैं इसे संकलित कोड से खोदता हूं

इसका कारण यह है कि इसका उपयोग .d.ts उत्सर्जित करने के लिए किया जा सकता है जिसका उपयोग वेनिला टीएस/जेएस में टाइप करने के लिए किया जा सकता है।
इसके अलावा, हालांकि काफी अजीब है, यह वैध वाक्यविन्यास है:

<script>
onMount(() => {
    new Component({
        target: document.getElementById('foo')
    })
})
</script>

तत्व निर्देश

Transition , use:action और अन्य तत्व निर्देश जैसे बदल सकते हैं

fade(null as Element, {  } /* option in attribute*/)

का इंतजार

{#await promise}
    <p>...waiting</p>
{:then number}
    <p>The number is {number}</p>
{:catch error}
    <p style="color: red">{error.message}</p>
{/await}

प्रति

    promise.then(number => {  number })
    promise.catch(error => { error.message })

बाँध: यह

<script>
let a;
</script>
<div bind:this={a}><div>

प्रति

let a;
onMount(() => {
 a = document.createElement('div')
})

इसे कॉलबैक में लपेटने की आवश्यकता है क्योंकि यह तुरंत उपलब्ध नहीं है

संदर्भ = "मॉड्यूल"

यह थोड़ा मुश्किल है

<script context="module">
 let count = 1;
</script>

<script>
import _ from "lodash"
let b;
</script>

करने के लिए संकलित किया जाना चाहिए

import _ from "lodash"

let count = 1;

// any block is ok
{
    let b;
{

और यह भी कि क्या होगा यदि उपयोगकर्ता किसी भी तरह दो स्क्रिप्ट में अलग-अलग भाषा का उपयोग करता है, जैसे मॉड्यूल में जेएस और उदाहरण में टीएस?

अच्छा, अच्छा लग रहा है। "टेम्पलेट में वैरिएबल का उपयोग करें" के लिए const _bla = bla.bla; सिर्फ bla.bla; जिससे टाइपस्क्रिप्ट को "अप्रयुक्त var" डायग्नोस्टिक को फ़िल्टर करने की आवश्यकता के बिना इसकी जांच करने की अनुमति मिलती है। मैं किसी भी कोने के मामलों के बारे में नहीं सोच सकता जहां यह काम नहीं करता है।

Vue की कुछ टीम टाइपस्क्रिप्ट भाषा सर्वर प्लगइन की खोज कर रही है - https://github.com/znck/vue-developer-experience

यह एक दिलचस्प कोण है क्योंकि आज ये अनुभव टाइपस्क्रिप्ट के बाहर से जाते हैं और (जैसे वीटूर करता है, क्योंकि यह अपने स्वयं के tsserver-ish, साथ ही साथ html/css/आदि LSPs) चलाता है या क्या आप टाइपस्क्रिप्ट के अंदर से जाने और बाहर की ओर काम करने का प्रयास करते हैं ( उदाहरण के लिए यह प्रस्ताव) जहां आप प्रभावी ढंग से विश्वास करने के लिए TSServer में हेरफेर करते हैं कि .vue फाइलें गैर-टीएस कोड को मास्क करके वैध टाइपस्क्रिप्ट हैं।

हालांकि आज यह केवल टाइपस्क्रिप्ट के लिए पैच होने से ही काम कर सकता है

यह एक दिलचस्प तरीका है। लेकिन एचटीएमएल या सीएसएस के लिए स्वत: पूर्णता जैसी सुविधाएं कैसे काम करेंगी? क्या किसी को यह सब "हाथ से" लागू करना होगा और अब आउट-ऑफ-द-बॉक्स-भाषा-सर्वर पर भरोसा नहीं करना होगा, या क्या मुझे कुछ याद आ रहा है?

क्या आपको एक से अधिक ओवर करने का कोई लाभ दिखाई देता है?

जेएस/टीएस समर्थन के अलावा कुछ भी एक अलग बनाम कोड एलएसपी द्वारा नियंत्रित किया जाएगा। यह ऐसा होगा जैसे यदि यह एक्सटेंशन JS/TS के लिए सभी समर्थन को हटा देता है और केवल बाकी को संभालता है, तो टाइपस्क्रिप्ट प्लगइन बाकी को संभाल लेगा।

लाभ के लिहाज से आपको इस मामले में सभी टीएस टूलिंग "मुफ्त में" मिलती है, प्रतीक पर जाएं, फाइल मैपिंग आदि

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

अंतर्दृष्टि के लिए धन्यवाद। मैं कहूंगा कि हम वर्तमान दृष्टिकोण के साथ (बाहर-अंदर) हैं।

अगर हम ऊपर चर्चा की गई "एक वर्चुअल टीएस फाइल बनाएं"-दृष्टिकोण के साथ जाते हैं, तो हम इसे कैसे कार्यान्वित करेंगे और स्रोत मैपिंग रखेंगे?

आज, यह आसान है क्योंकि यह सिर्फ "स्क्रिप्ट की शुरुआत ढूंढें, स्क्रिप्ट का अंत ढूंढें", "स्क्रिप्ट भाग निकालें" और मैपिंग के लिए "स्थितियों में व्यापक फ़ाइल की ऑफसेट जोड़ें"।
यदि हम अभी स्क्रिप्ट का हिस्सा बदलते हैं, तो हमें अधिक परिष्कृत मानचित्रण की आवश्यकता है:

मूल

<script lang="typescript">
  let a = 1;
  $: b = a + 1;
</script>
<p>{b}</p>

मैप किया गया:

export default class Bla extends SvelteComponent { ... } // <- prepended, no mapping needed as far as I know
let a = 1; // <- untouched
let b = a + 1; // <- modified in place. How to map? Do we need to adjust all following code positions now to have a new offset/position?
b; // <- appended. Needs mapping from {b} inside svelte-mustache-tag to here. We can get the original position from the html ast which is part of the output of svelte.parse

कोई विचार? मैंने पहले कभी सोर्स मैपिंग स्टफ नहीं किया ..

Vue की कुछ टीम टाइपस्क्रिप्ट भाषा सर्वर प्लगइन की खोज कर रही है - https://github.com/znck/vue-developer-experience

यह एक दिलचस्प कोण है क्योंकि आज ये अनुभव टाइपस्क्रिप्ट के बाहर से जाते हैं और (जैसे वीटूर करता है, क्योंकि यह अपने स्वयं के tsserver-ish, साथ ही साथ html/css/आदि LSPs) चलाता है या क्या आप टाइपस्क्रिप्ट के अंदर से जाने और बाहर की ओर काम करने का प्रयास करते हैं ( उदाहरण के लिए यह प्रस्ताव) जहां आप प्रभावी ढंग से विश्वास करने के लिए TSServer में हेरफेर करते हैं कि .vue फाइलें गैर-टीएस कोड को मास्क करके वैध टाइपस्क्रिप्ट हैं।

हालांकि आज यह केवल टाइपस्क्रिप्ट के लिए पैच होने से ही काम कर सकता है

टाइपस्क्रिप्ट पैच पीआर को हटा दें विलय कर दिया गया है।
https://github.com/znck/vue-developer-experience/pull/7

तो ... @orta इसका मतलब है कि "अनौपचारिक" के बारे में नुकसान अब मामला नहीं है? या यह अभी भी अनौपचारिक है, सिर्फ एक पैच के माध्यम से नहीं बल्कि कुछ package.json कॉन्फ़िगरेशन के माध्यम से आपको पता होना चाहिए और किसी भी समय बदल सकता है?

एक अन्य विषय: इस समय मुझे लगता है कि हम अभी भी इस बात पर चर्चा कर रहे हैं कि इस सर्वोत्तम तरीके से कैसे संपर्क किया जाए, और यदि हम निर्णय लेते हैं, तो इसे लागू करने में कुछ समय लगने वाला है। आप लोग इस बीच svelte2tsx का उपयोग करने के बारे में क्या सोचते हैं? यह एक बहुत अच्छे शुरुआती बिंदु के रूप में काम कर सकता है, हम इसके चारों ओर कुछ परीक्षण प्राप्त कर सकते हैं और फिर हम या तो देखते हैं "ठीक है यह वास्तव में बहुत अच्छा काम करता है, चलो इसे नहीं बदलते" या धीरे-धीरे इससे दूर चले जाते हैं। विचार?

हां, टीएस के डिफ़ॉल्ट प्रवाह को संपादित करने के दो तरीके थे, यह अभी भी टाइपस्क्रिप्ट को पैच कर रहा है - लेकिन टीएस के कार्यों को बदलकर

अगर मैं इसकी सिफारिश करता हूं तो मैं एक खराब कोर टीम सदस्य बनूंगा;)

svelte2ts आज़माना अन्वेषण के लिए एक अच्छा अवसर लगता है!

आप देख सकते हैं कि यह बनाम कोड प्लगइन का उपयोग करके svelte2tsx के साथ कैसा होगा: https://marketplace.visualstudio.com/items?itemName=halfnelson.svelte-type-checker-vscode एक साथ Svelte बीटा (यदि आप svelte बीटा को अक्षम करते हैं तो सबसे अच्छा काम करता है) टाइपस्क्रिप्ट विकल्प ताकि आपको दोगुने संकेत न मिले :))

यहां तक ​​​​कि अगर svelte2tsx का उपयोग नहीं कर रहे हैं, तो मुझे चर्चा दिखाई देती है कि टाइपस्क्रिप्ट को खुश रखने के लिए svelte के JS कोड में कौन से परिवर्तन किए जाने की आवश्यकता है। svelte2tsx के लिए परीक्षण सूट न केवल टेम्प्लेट में किए जाने वाले आवश्यक परिवर्तनों को कवर करता है, बल्कि स्क्रिप्ट टैग भी है, जो कि यदि आप केवल स्क्रिप्ट टैग के लिए जा रहे हैं तो समाधान एक अच्छा प्रारंभिक बिंदु हो सकता है: https://github.com/halfnelson /svelte2tsx/पेड़/मास्टर/परीक्षण/svelte2tsx/नमूने

htmlx2jsx टेम्पलेट परिवर्तन परीक्षण (एचटीएमएलएक्स) फ़ोल्डर है, जबकि svelte2tsx नमूने जेएस सिंटैक्स के स्वेल्टे के विशेष दुरुपयोग के लिए आवश्यक व्यापक विशिष्ट परिवर्तन हैं :)

बस इस रेपो https://github.com/pivaszbs/svelte-autoimport की खोज की। शायद यह देखने लायक है कि क्या हम svelte2tsx स्वतंत्र आयात इंटेलिजेंस चाहते हैं।

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

लगता है किसी को आपत्ति नहीं है, इसलिए मैं इसे बंद करने जा रहा हूं। इस पर चर्चा करने के लिए सभी को धन्यवाद!