Flutter: JSX-जैसे रिएक्ट नेटिव पर विचार करें

यह लंबे समय से पूछा गया है:
https://github.com/flutter/flutter/issues/11609
कार्यात्मक प्रोटोटाइप विकसित:
https://spark-heroku-dsx.herokuapp.com/index.html
यह विकल्प और कुछ लाभ दिखाता है ...

DSX के साथ वर्तमान समस्या फ़्लटर टूल के साथ उचित एकीकरण के बारे में है ताकि .dsx फ़ाइलों पर काम करने वाले डीबगर, ऑटो-पूर्ण, आदि के साथ एक महान डेवलपर अनुभव प्रदान किया जा सके।

उपयोगकर्ताओं को यह बताना कि वे DSX का उपयोग कर सकते हैं, लेकिन डीबगर का उपयोग नहीं कर सकते या स्वतः पूर्ण का आनंद नहीं ले सकते, मेरे लिए एक गैर स्टार्टर है। अगर कोई मदद करना चाहता है, तो मुझे डार्ट टूल्स और वीएस कोड डार्ट प्लग इन में पूर्ण प्रीप्रोसेसिंग समर्थन (स्रोत मानचित्र के साथ) जोड़ने का एक तरीका पता लगाना है। एक बार उपकरण उस डीएसएक्स या किसी अन्य ट्रांसपिलिंग भाषा का समर्थन करते हैं (कोई भी भाषा जो डार्ट का सुपरसेट है लेकिन डार्ट को सब कुछ संकलित करता है) बस काम करेगा।

अगर आप मदद कर सकते हैं और करना चाहते हैं तो मुझे बताएं।

मैं सहमत नहीं हो सकता। विशेष रूप से डार्ट कोड जैसे आईडीई का उपयोग करके आपको वर्चुअल क्लोजिंग टैग मिलते हैं जो पढ़ने के तरीके को आसान बनाता है। डार्ट2 के साथ जहां आप new को छोड़ सकते हैं, यह और भी बेहतर हो जाएगा।

इसके अलावा, मुझे लगता है कि यह आपको बहुत बड़े विजेट पेड़ बनाने के लिए हतोत्साहित करता है, बिना विजेट कक्षाओं को बनाए रखने के लिए इसे छोटे आसान में बदल देता है।

मैं एंड्रॉइड स्टूडियो का उपयोग करता हूं। मुझे वर्चुअल क्लोजिंग टैग भी नहीं दिख रहा है। भले ही हमारे पास वर्चुअल क्लोजिंग टैग है, लेकिन यह HTML से अधिक जटिल है जिससे हर कोई नफरत करता है। डार्ट सिर्फ एक प्रोग्रामिंग भाषा है। Google में लोग सरलीकरण के महत्व को नहीं समझते हैं।

मुझे नहीं लगता कि मुझे JSX जैसा सिंटैक्स चाहिए, लेकिन हाँ, मैं IntelliJ का उपयोग करता हूं और टूलिंग के साथ कुछ करने की आवश्यकता है ताकि UI कोड को समझना आसान हो।

इसके अलावा, मुझे लगता है कि यह आपको बहुत बड़े विजेट पेड़ बनाने के लिए हतोत्साहित करता है, बिना विजेट कक्षाओं को बनाए रखने के लिए इसे छोटे आसान में बदल देता है।

मैं नहीं देखता कि यह JSX से कैसे अलग है ... जैसे-जैसे पेड़ बड़ा होता जाता है आप दोनों के साथ छोटे उप-पेड़ों में टूट सकते हैं।

मुझे नहीं लगता कि मुझे JSX जैसा सिंटैक्स चाहिए, लेकिन हाँ, मैं IntelliJ का उपयोग करता हूं और टूलिंग के साथ कुछ करने की आवश्यकता है ताकि UI कोड को समझना आसान हो।

और इसे केवल Intellij ही नहीं, बल्कि सभी प्लेटफॉर्म पर पढ़ना आसान होना चाहिए; मेरा मतलब है कि कोड की समीक्षा करते समय बिटबकेट पर पढ़ना आसान होना चाहिए; और यह किसी भी संपादक का उपयोग करते समय भी मान्य होना चाहिए; मेरा मतलब है कि इन 'टिप्पणी एनोटेशन' के साथ क्या होता है यदि कोई 'vi' का उपयोग करके वहां एक अलग टिप्पणी टाइप करता है?

यह लॉक डाउन #11609 . का एक ढोंग है
@सेथलाड ?

क्षमा करें, आपको IntelliJ और Android Studio में "वर्चुअल क्लोजिंग टैग" दिखाई देने चाहिए।

cc @devoncarew यह सत्यापित करने के लिए कि किस संस्करण ने उसे चालू किया, या यदि उपयोगकर्ता को ऑप्ट-इन करने की आवश्यकता है?

आपकी टिप्पणियों के लिए हम आपको धन्यवाद देते हैं: JSX जैसा वाक्य-विन्यास। हमारा मानना ​​है कि यूआई कोड को संपादित करना आसान बनाने के लिए भाषा, हमारे टूल और प्लगइन्स में अवसर है।

यह डुप्ली #11609 है, लेकिन यदि संभव हो तो मैं "वर्चुअल क्लोजिंग टैग्स" को चालू करने के तरीके के बारे में एक नोट जोड़ने के लिए @devoncarew या @ mit-mit के लिए चाहूंगा।

धन्यवाद!

@JonathanSum , दुर्भाग्य से Android Studio 3.0 में समापन लेबल उपलब्ध नहीं हैं। आपको कम से कम IntelliJ 2017.3 या Android Studio 3.1 की आवश्यकता होगी। एंड्रॉइड स्टूडियो 3.1 वर्तमान में रिलीज उम्मीदवार चरण में है, और हम कल इसके लिए समर्थन के साथ एक स्पंदन प्लगइन जारी करने की योजना बना रहे हैं।

JSX जैसे सिंटैक्स के आसपास की बातचीत के बावजूद, हम IntelliJ / Android Studio और VS कोड दोनों में, डार्ट में UI कोड लिखना आसान बनाने की दिशा में काम करना चाहते हैं। यह शुरू में क्लोजिंग लेबल का काम है, लेकिन हाल ही में फ़्लटर आउटलाइन व्यू भी है। यह आपके बिल्ड () पद्धति की संरचना को एक रूपरेखा दृश्य में दिखाता है, और आपको विजेट्स को नेविगेट करने और उनके माता-पिता/बाल संबंधों को अधिक आसानी से देखने की अनुमति देता है। यह वर्तमान में IntelliJ में उपलब्ध है - हम इसे VS कोड में भी लाने में सक्षम होने की उम्मीद करते हैं।

@zoechi - यह एक डुप्ली हो सकता है; लेकिन दूसरा धागा गर्म होकर बंद हो गया। तो उनका उस बातचीत में योगदान करने का कोई तरीका नहीं है। मुझे नहीं लगता कि आपको इस धागे को एक डुप्ली के रूप में बंद करना चाहिए क्योंकि आप लोगों को एक सुविधा के लिए पूछना पसंद नहीं करते हैं। जेएसएक्स समर्थन (या समान कार्यक्षमता) आने और अनुरोध करने वाले नए लोगों के लिए प्रतिक्रियाओं के लिए यह शायद नया धागा होना चाहिए।

@sethladd - कृपया इस धागे को बंद न करें; मुझे लगता है कि वैकल्पिक लेआउट विधियों पर समुदाय के पेशेवरों और विपक्षों पर चर्चा करना उपयोगी है। मैंने #11609 में भाग लिया होता अगर इसे लॉक नहीं किया गया होता।

मैं एक नेटिवस्क्रिप्ट बैकग्राउंड से आता हूं। मेरा कहना है कि यह एक ऐसा क्षेत्र है जहां मुझे लगता है कि फ़्लटर की तुलना में नेटिवस्क्रिप्ट का उपयोग करना काफी आसान है। मैं 5 मिनट से भी कम समय में काम करने वाली काफी जटिल स्क्रीन प्राप्त कर सकता हूं और आसानी से डिजाइन को जल्दी से पुनरावृत्त कर सकता हूं। फिर स्क्रीन चलाने वाला कोड जोड़ें।

नेटिवस्क्रिप्ट में हमारे पास वास्तव में निम्नलिखित फाइलें हैं:

• screen.js / screen.ts (यदि आप टाइपप्रति पसंद करते हैं तो .ts को .js में बदल दिया जाता है)। यह स्क्रीन के लिए मुख्य तर्क है जिसे आप प्रदर्शित कर रहे हैं।
• screen.css (या screen.android.css और/या screen.ios.css ) जो सीएसएस का बहुत अधिक सीमित संस्करण है लेकिन ऊंचाई, चौड़ाई, रंग, पृष्ठभूमि आदि जैसी चीजों का समर्थन करता है। ज्यादातर समय केवल एक सीएसएस फ़ाइल की जरूरत है, लेकिन कभी-कभी अगर आप कुछ अजीब कर रहे हैं तो आप एंड्रॉइड और आईओएस के लिए अपने सीएसएस को अलग कर सकते हैं। इसमें कक्षाओं, तत्वों और आईडी के लिए पूर्ण समर्थन है, इसलिए मैं TextArea.Login #Password कर सकता हूं और यह वास्तव में केवल उस विशिष्ट तत्व श्रृंखला तक ही सीमित रहेगा।
• screen.xml (फिर से या screen.android.xml और/या screen.ios.xml ) - यह स्क्रीन लेआउट है। यदि आप चाहें तो JS में लेआउट को कोड कर सकते हैं (मूल रूप से स्पंदन की तरह); लेकिन एक्सएमएल इतना आसान है। उदाहरण:

<Page onLoad="loadme">
    <ActionBar title="Blah"><NavigationButton click="back" title="Back"/></ActionBar>
    <StackLayout>
      <Label text="Hi" id="Hi" style="color: red"/>
     <Label text="{{name}}" class="name"></Label>
     <Button text="Click Me" tap="clicker"/>
    </StackLayout></Page>

दिलचस्प बात यह है कि एक्शनबार एक विशिष्ट पृष्ठ केवल घटक है (यानी यह केवल पृष्ठ के लिए विशिष्ट है); तो मूल रूप से क्या होता है XML पार्सर देखें का पृष्ठ; एक नया पृष्ठ तत्व बनाता है; फिर एक एक्शनबार घटक बनाता है जो फिर पेज घटक पर एक बिल्डर चाइल्ड फ़ंक्शन चलाता है; पृष्ठ घटक डिफ़ॉल्ट बिल्डर चाइल्ड को ओवरराइड करता है और यह देखने के लिए देखता है कि क्या बच्चा एक एक्शनबार है; अगर यह होता है; तो यह आंतरिक रूप से इसे उचित चर के लिए असाइन करता है; अन्यथा बाकी को माता-पिता/सुपर के माध्यम से पारित किया जाता है जो इसे "बच्चे" या "बच्चों" घटकों को स्वचालित रूप से असाइन करता है। बिल्ड सिस्टम अविश्वसनीय रूप से बहुमुखी है जिसमें प्रत्येक घटक माता-पिता के बिल्डरचाइल्ड फ़ंक्शन का उपयोग कर सकता है या इसे अतिरिक्त आइटम करने के लिए ओवरराइड कर सकता है जैसे समर्थन <Label>Hi</Label> और इसे टेक्स्ट मान को स्वचालित रूप से असाइन करें। यह लेआउट को बिना किसी कोड के उठने और चलने में अविश्वसनीय रूप से आसान बनाता है।

चूंकि अधिकांश संपादकों में एक्सएमएल संपादन क्षमता अच्छी होती है, इसलिए यह स्वचालित रूप से रंगीन हो जाती है और उचित xsd परिभाषा के साथ इंटेलिज (& बनाम कोड) स्वचालित जांच और सीमित संदर्भ समर्थन करता है।

अब तकनीकी रूप से सब कुछ वास्तव में एक जावास्क्रिप्ट घटक है; तो आप यह सब मैन्युअल रूप से कर सकते हैं (जैसे स्पंदन क्या करता है); लेकिन मुझे लगता है कि नेटिवस्क्रिप्ट में स्क्रीन बिछाने में आसान है। और जब आप पहली बार शुरू करते हैं तो आपको JS या CSS की आवश्यकता नहीं होती है; तो आप सीएसएस जोड़ सकते हैं (आमतौर पर आप सीएसएस आधारित गुणों के लेआउट में हार्ड कोड नहीं रखते हैं, लेकिन यदि आप चाहें तो आप कर सकते हैं)।

इसके बारे में अच्छी बात है; क्या यह वेब डेवलपर्स को बहुत कम (यदि कोई हो) पुनर्प्रशिक्षण के साथ सही तरीके से कूदने की अनुमति देता है। वास्तव में; अपने लचीले रेंडरर और जेएस आधारित होने के कारण - नेटिवस्क्रिप्ट वास्तव में एंगुलर और वीयू का समर्थन करता है - ताकि यदि आप एंगुलर या वीयू का उपयोग करते हैं तो आप वास्तव में वेब और अपने मोबाइल ऐप के बीच लगभग 95% कोड बेस साझा कर सकते हैं। चूंकि यह मूल निवासी ओएस घटकों का उपयोग करता है जैसे प्रतिक्रिया देशी (कॉर्डोवा की तरह एक वेबव्यू नहीं); यह वास्तव में एक अच्छा क्रॉस-प्लेटफ़ॉर्म सिस्टम है (जो कि रिएक्ट नेटिव से बेहतर इम्हो है)। हालाँकि, मैं देख सकता हूँ कि फ़्लटर में कुछ ताकतें कहाँ हैं जो इसे कुछ मोबाइल विकास के लिए एक अच्छा मानार्थ उपकरण बनाती हैं क्योंकि उनके कुछ ऐप हैं जिनमें नेटिवस्क्रिप्ट बदतर है और कुछ यह अभी भी मेरे लिए प्रतिक्रियाओं के आधार पर बहुत बेहतर है इयान से मुद्दे; उन क्षेत्रों के लिए काफी बेहतर उपकरण रहेगा।

उस लॉक किए गए धागे को खोलना और इन टिप्पणियों को वहां कॉपी करना बेहतर है ताकि हमारे पास पूरी चर्चा का इतिहास हो।

@JonathanSum यह इस बारे में नहीं है कि कोई इस सुविधा को चाहता है या नहीं चाहता है,
यह है कि क्या यह इसके बारे में गरमागरम चर्चा करने का स्थान है। मुझे लगता है कि reddit या इसी तरह के बेहतर स्थान हैं।

@cbazza - मैं असहमत नहीं हूँ; लेकिन आपको भविष्य में बहुत सावधान रहना होगा कि आप लोगों के बारे में बातें न करें। यह सिर्फ चर्चा को भड़काता है, चाहे आप कितना भी बेवकूफ क्यों न हों, आप मानते हैं कि वे हैं।

@zoechi - असल में मेरा मानना ​​​​है कि किसी नई सुविधा के बारे में कोई भी चर्चा यहां होनी चाहिए। इतिहास को बनाए रखा जाना चाहिए ताकि जब जॉन डो अब से एक महीने बाद आए और एक्सवाईजेड फीचर के बारे में खोजे तो वह: +1: एक मौजूदा फीचर और/या इसमें योगदान दे सके।

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

थ्रेड लॉक है क्योंकि फ़्लटर टीम को ऐसा करने में कोई दिलचस्पी नहीं है और बस चाहते हैं कि लोग इसके बारे में बात करना बंद कर दें।

आइए कृपया इस मुद्दे पर चर्चा को JSX जैसी सुविधा के लिए उपयोग के मामलों और उदाहरणों पर केंद्रित रखें।

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

JSX कोड में डिजाइन कर रहा है !!!

@सेथलाड

आइए कृपया इस मुद्दे पर चर्चा को JSX जैसी सुविधा के लिए उपयोग के मामलों और उदाहरणों पर केंद्रित रखें।

ठीक है, मेरे DSX डिज़ाइन के बारे में बात करते हैं जिसे यहाँ देखा जा सकता है:
https://spark-heroku-dsx.herokuapp.com/index.html

यह विजेट्स के निर्माण के वर्तमान तरीके के लिए एक सीधा मानचित्रण प्रदान करता है और फिर भी एक JSX जैसा स्वाद प्रदान करता है जो कि बहुत हल्का है और रिएक्ट डेवलपर्स के लिए परिचित है। क्या इस डिज़ाइन में कुछ कमी है? क्या यह डिज़ाइन जंगली में सभी संभावित विजेट उत्पन्न कर सकता है?

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

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

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

आपके DSX बनाम जेनरेट किए गए डार्ट स्निपेट से कुछ टिप्पणियां:

1. विषयपरक: मुझे कोई महान पठनीयता लाभ नहीं दिख रहा है। वर्बोसिटी समान है - यदि अधिक समय तक नहीं। डार्ट आईडीई प्लगइन ऑटो क्लोजिंग टैग प्रदान करता है, जो डिक्लेरेटिव मार्कअप क्लोजिंग टैग को मिरर करता है। यदि JSX कोड में डिज़ाइन किया गया है, तो मैं नहीं देखता कि डार्ट में विजेट कैसे नहीं हैं।

2. <vars> . में एकाधिक गुण

@<vars>
var textStyle = {
    "textDirection": "TextDirection.ltr",
    "textAlign": "TextAlign.center",
    "overflow": "TextOverflow.ellipsis",
    "style": "new TextStyle(fontWeight: FontWeight.bold)"
};
</vars>@

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

Text के लिए ऐसा लगता है कि मुझे जो कुछ भी पुन: उपयोग करने की आवश्यकता है उसे कई गुणों के मिश्रण के बजाय TextStyle में परिभाषित किया गया है। हो सकता है कि आपको Text के अलावा कोई और उदाहरण मिल जाए, जहां ऐसा नहीं है।

TextStyle को देखते हुए, मुझे वर्तमान अपरिवर्तनीय + कॉपी() डार्ट में पुन: उपयोग और रचना के लिए बहुत अच्छा लगता है:

class Style {
  static const TextStyle avenirNextMedium =
      const TextStyle(
         fontFamily: 'Avenir Next', 
         fontWeight: FontWeight.w500,
      );

  static TextStyle title =
      avenirNextMedium.copyWith(
        color: ColorKit.blue, 
        fontSize: 45.0,
      );
}

new Text(
  'Hello',
  style: Style.title,
),

new Text(
  'Hello2',
  style: Style.title.copyWith(
    color: ColorKit.red,
  ),
),

पुन: प्रयोज्य Container समान शैली साझा करने के लिए, मुझे लगता है कि एक कस्टम स्टेटलेस विजेट बनाना बाहरी परिभाषित <vars> से बेहतर काम करता है। ज्यादातर समय, मुझे एक पैडिंग, एक स्याही, एक इशारा श्रोता या एक छाया भी चाहिए।

उन मामलों में से किसी के लिए, मुझे किसी अन्य विजेट के साथ Container की रचना करने की आवश्यकता होगी: Material , Padding , Center आदि। तो अगर मुझे एक बनाना है कस्टम पुन: प्रयोज्य "कंटेनर" विजेट वैसे भी, मुझे बाहरी <vars> शैली के लिए बहुत अधिक लाभ नहीं दिखता है जो मेरे पुन: प्रयोज्य विजेट पदानुक्रम में केवल एक विजेट के गुणों को परिभाषित करेगा।

मुझे स्पंदन का "सब कुछ एक विजेट है" "एकाधिक गुण" शैलियों के साथ अच्छी तरह से काम नहीं करता है।

1. आपके वर्तमान DSX उदाहरणों में हाइलाइट नहीं किया गया है: आप डायनामिक विजेट्स के साथ एक इंटरफ़ेस को कैसे कोडित करेंगे? अर्थ: किसी शर्त के आधार पर कुछ विजेट कैसे दिखाना है या नहीं दिखाना है।

डार्ट में डिज़ाइन करते समय किसी विशेष विजेट को children में जोड़ना या न जोड़ना आसान और सुविधाजनक होता है।
एक विजेट को दूसरे के साथ गतिशील रूप से लपेटना भी बहुत सुविधाजनक है। यह बिल्ड () फ़ंक्शन को धाराप्रवाह और समझने में आसान बनाता है।

    var children = <Widget>[];
    if(a) {
      children.add(wa);
    }

    var wb = Text();
    if(b) {
      wb = Padding(child: wb);
    }

    children.add(wb);

@SirComputer1 DSX प्रस्ताव एक अतिरिक्त है, वर्तमान तरीका नहीं बदलता है इसलिए यदि आपको यह पसंद नहीं है, तो इसका उपयोग न करें, जैसे आप आज हैं वैसे ही जारी रखें।

<var> चीज़ केवल डेमो के लिए की गई थी क्योंकि मैं पूर्ण डार्ट को पार्स नहीं करना चाहता था। अंतिम समाधान में <var> शामिल नहीं होगा, लेकिन किसी भी डार्ट चर का उपयोग करेगा। इसके अलावा '@' केवल डेमो के लिए पार्सिंग को आसान बनाने के लिए किया गया था। अंतिम समाधान में इसे शामिल नहीं किया जाएगा।

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

    var children = <Widget>[];
    if(a) {
      children.add(wa);
    }

    // You can mix and match both
    var wb = <Text/>;
    if(b) {
      wb = Padding(child: wb);
    }

    // or
    var wb = Text();
    if(b) {
      wb = <Padding> {wb} </Padding>;
    }

    children.add(wb);

    children.add(
      <Center>
          {sayHello == true ?
             <Text ['Hello, world!']/>
          :
             <Text ['Good bye']/>
          }
      </Center>
    );

आइए डीएसएक्स की मौजूदा तरीके से तुलना करना बंद करें, एक दूसरे के साथ प्रतिस्पर्धा नहीं कर रहा है। कुछ लोग JSX को पसंद करेंगे और यह धागा उनके लिए है। मैं जो जानना चाहता हूं वह यह है कि मैं उन चीजों को संभालने के लिए डीएसएक्स को कैसे सुधार सकता हूं जिनके लिए यह काम नहीं करेगा।

@escamoteur - मैं एक स्क्रू ड्राइवर के रूप में एक हथौड़ा का उपयोग नहीं करता हूं। मैं विभिन्न तकनीकों का मूल्यांकन करता हूं और उचित उपयोग के मामले में उचित उपयोग करता हूं। इसका मतलब यह नहीं है कि प्रत्येक प्लेटफॉर्म में चीजों को बेहतर के लिए बदला जा सकता है। :मुस्कुराना:

उदाहरण के लिए; तृतीय पक्ष प्लगइन्स एकीकरण। नेटिवस्क्रिप्ट वास्तव में हर एक क्रॉस प्लेटफॉर्म पर राजा है। कुछ भी दूर से भी नेटिवस्क्रिप्ट के करीब नहीं आता है; और तृतीय पक्ष एकीकरण। मेरे पास एक क्लाइंट है जो https://github.com/vipulasri/Timeline-View का उपयोग करने के बारे में पूछ रहा है। लगभग असंभव स्पंदन; नेटिवस्क्रिप्ट मुझे कुछ घंटे देता है और यह किसी भी अन्य एनएस नियंत्रण की तरह ही काम करेगा, यहां तक ​​​​कि पूरी तरह से काम कर रहे डेटा बाइंडिंग के साथ भी। दूसरी तरफ स्पंदन में कुछ गंभीर ताकत होती है जहां एनएस झंडे ...

नौकरी के लिए उचित उपकरण का प्रयोग करें। :मुस्कुराना:

मुझे एक्सएमएल आधारित स्क्रीन लेआउट पसंद है; लेकिन मुझे समझ में आता है कि लोग क्यों नहीं। एक्सएमएल आधारित भवन के लिए क्षमता जोड़ने का मतलब मौजूदा पद्धति को खत्म करना नहीं है; यह सिर्फ पूरक है; पसंद। आप में से जिन लोगों ने पढ़ने की जहमत नहीं उठाई, उनके लिए मैं एनएस में कॉल की वही श्रृंखला कर सकता हूं जो हम स्पंदन में करते हैं; लेकिन एक्सएमएल का उपयोग करना मेरे लिए बहुत कम टाइपिंग और पढ़ने में आसान है। सबकी अपनी पसंद होती है...

मैंने वास्तव में एक एक्सएमएल आधारित रेंडरर को पीओसी के रूप में स्पंदन में जोड़ने के बारे में सोचा है; लेकिन मेरे पास खाली समय नहीं है। मैं सिर्फ बातचीत में योगदान देना चाहता था और कहता था कि मैं इस कदम को आगे बढ़ते हुए देखना चाहता हूं; लेकिन मैं वास्तव में कोर टीम से इस पर काम करने की उम्मीद नहीं करता। मुझे लगता है कि एनएस एक्सएमएल प्रारूप सामुदायिक परियोजनाओं के रूप में किया जा सकता है जहां हममें से जो परवाह करते हैं (यानी शायद मुझे: मुस्कुराते हुए :) उन पर काम करने के इच्छुक होंगे। हालाँकि, मेरी सबसे बड़ी चिंता @sethladd -- है कि क्या मैं एक पैच पर बहुत समय बिताता हूँ; क्या इसे खारिज कर दिया जाएगा क्योंकि कोर टीम में कोई इस क्षमता का बिल्कुल विरोध करता है। इससे पहले कि मैं इस पर कोई समय बिताऊं, मैं सबसे पहले यही कहना चाहूंगा ...

@NathanaelA शानदार परिप्रेक्ष्य!!!!!!! और देखो मैंने बहुत सारे विस्मयादिबोधक चिह्नों का उपयोग किया है ;-) आपने सचमुच इसे सिर पर लगाया है।

हां, मैं DSX कर सकता हूं, लेकिन मुझे इसे वर्तमान स्पंदन बिल्ड सिस्टम में एकीकृत करने के लिए एक तरीके की आवश्यकता है, इसलिए आगे बढ़ने से पहले मुझे वर्तमान फ़्लटर टीम से प्रतिबद्धता की आवश्यकता है। वीएस कोड पर आईडीई एकीकरण वस्तुतः तुच्छ है लेकिन इंटेलिज के साथ इतना नहीं है (जब तक कि Google के पास इंटेलिज जेएसएक्स समर्थन तक पहुंच न हो)।

@zoech , नहीं! मुझे लगता है कि यह एक मुद्दा है। मुझे मूल जावा और एक्सएमएल के साथ एक एंड्रॉइड ऐप विकसित करना याद है। हम अभी भी UI भाषा भाग के लिए XML का उपयोग करते हैं। मुझे लगता है कि तर्क और यूआई के लिए डार्ट का उपयोग करना अजीब है, और यह समस्या स्पष्ट है। इसके अलावा, मुझे उम्मीद है कि Google रिएक्ट के UI विचार को स्पंदन में जोड़ने जा रहा है। रिएक्ट का UI भाग बहुत शक्तिशाली और संक्षिप्त है।

@JonathanSum मैंने इस बारे में कई टिप्पणियाँ देखी हैं।
मेरे लिए यह अभी भी ऐसा लगता है जैसे लोग कुछ चाहते हैं क्योंकि वे अपनी आदतों को बदलने के लिए अनिच्छुक हैं, इसलिए नहीं कि यह मंच के लिए एक लाभ है।

कुछ लोगों को jsx पसंद है, कुछ लोगों को नहीं। UI को लागू करने के दो तरीकों का समर्थन क्यों न करें। आप जेएसएक्स-जैसे वाक्यविन्यास लिख सकते हैं, और अंत में इसे मूल वाक्यविन्यास को फहराने के लिए लागू किया जाएगा, समर्थन क्यों नहीं?

@ yuu2lee4 https://github.com/flutter/flutter/issues/11609#issuecomment -364811331

@zoechi

मेरे लिए यह अभी भी ऐसा लगता है जैसे लोग कुछ चाहते हैं क्योंकि वे अपनी आदतों को बदलने के लिए अनिच्छुक हैं

यह एक उचित अवलोकन है, लेकिन क्या फ़्लटर के लिए एक एनबलर होना और फ़्लटर को अपनाने के लिए लोगों (Google के बाहर) के लिए जितना संभव हो उतना घर्षण दूर करना बेहतर नहीं होगा? गेट-कीपिंग का यह व्यवहार डेवलपर्स का दिल और दिमाग नहीं जीत रहा है।

@yuu2lee4

कुछ लोगों को jsx पसंद है, कुछ लोगों को नहीं। UI को लागू करने के दो तरीकों का समर्थन क्यों न करें। आप जेएसएक्स-जैसे वाक्यविन्यास लिख सकते हैं, और अंत में इसे मूल वाक्यविन्यास को फहराने के लिए लागू किया जाएगा, समर्थन क्यों नहीं?

बेहतरीन सवाल। यह देखते हुए कि मैं DSX पर सभी काम कर रहा हूं, जो JSX की तरह है, और @Hixie ने व्यक्तिगत रूप से मुझे प्रगति के बारे में उत्साहित ईमेल भेजा है, मुझे नहीं पता कि इसका समर्थन क्यों नहीं किया जाता है, मुझे नहीं लगता कि क्यों न हाथ बढ़ाया जाए और कहा जाए 'मैं आपके लिए क्या कर सकता हूँ? आपको ऐसा करने से क्या रोक रहा है?'

ईमानदारी से, मैं इस शीर्षक को पिछले एक के समान दिशा में सोचना शुरू कर रहा हूं ... जो मदद नहीं करेगा ...

@cbazza

@ हिक्सी ने मुझे व्यक्तिगत रूप से प्रगति के बारे में उत्साहित ईमेल भेजा ..

तो आप क्यों नहीं जारी रखते हैं और जो लोग मदद कर सकते हैं उन्हें भी बोर्ड पर आना चाहिए और मदद करनी चाहिए? अगर हम नहीं चाहते कि यह दूसरे धागे की तरह हो... मुझे लगता है कि हमें इस बात पर चर्चा करनी चाहिए कि ब्लॉक क्या हैं, हम इसके बारे में कैसे जाते हैं और हम इसे कैसे काम करते हैं और इसे वहां कैसे डालते हैं ... और मुझे यह भी लगता है कि स्पंदन और डार्ट टीम ने यूआई लिखने की क्रियात्मक प्रकृति को कम करने पर कुछ काम शुरू कर दिया है ...
हो सकता है कि टीम अभी इसमें शामिल न हो पाए, लेकिन मेरा मानना ​​है कि अगर इसके योग्य कारण जो मुझे लगता है कि यह मेरे लिए ठीक है, जो भी दृष्टिकोण हो ... वे किसी बिंदु पर पकड़ लेंगे ... आप कर रहे हैं और इसे बाहर निकालो ... जैसे इस आदमी ने शुरुआती दिनों में http://mutisya.com/ किया था, हालांकि मुझे इसकी स्थिति का पता नहीं है ... मुझे यह भी पता है कि @NathanaelA मदद कर सकता है क्योंकि उसने कुछ योगदान दिया है नेटिवस्क्रिप्ट के लिए वास्तव में अद्भुत सामग्री और उपकरण ... और अधिक देवों को अधिक विकल्प देने के लिए इसे बाहर निकालें ...

@MichaelSowah
इस पर अधिक समय न लगाने का कारण @NathanaelA ने कहा:

हालाँकि, मेरी सबसे बड़ी चिंता @sethladd -- है कि क्या मैं एक पैच पर बहुत समय बिताता हूँ; क्या इसे खारिज कर दिया जाएगा क्योंकि कोर टीम में कोई इस क्षमता का बिल्कुल विरोध करता है। इससे पहले कि मैं इस पर कोई समय बिताऊं, मैं सबसे पहले यही कहना चाहूंगा ...

ठीक है, यहाँ मेरे पास है:
(ए) एक प्री-प्रोसेसर जो *.dsx फाइलों को अंदर लेता है और *.dart फाइलों को आउटपुट करता है।

यहाँ मुझे क्या चाहिए:
(1) किसी को 'वीएस कोड' एकीकरण का ध्यान रखना। मेरी जांच से यह आसान लगता है।
(2) किसी को यह पता लगाने के लिए कि फ़्लटर बिल्ड सिस्टम में प्री-प्रोसेसर क्षमता को कैसे जोड़ा जाए ताकि डिबगिंग ठीक से काम करे। मेरा मतलब है कि कोड स्टेपिंग *.dsx फाइलों पर सोर्समैप, आदि जैसी किसी चीज़ के माध्यम से होगी।

एक बार उपरोक्त 2 आइटम हो जाने के बाद हमारे पास गेंद को लुढ़कने के लिए एक प्रारंभिक एंड-टू-एंड सिस्टम है। कोई लेने वाला?

तो जैसा कि आप ऊपर देख सकते हैं, (1) और (2) को फ़्लटर कोड में बदलाव की आवश्यकता है जिसे फ़्लटर टीम अस्वीकार कर सकती है इसलिए बिना समर्थन/प्रतिबद्धता के यह सुविधा अटक गई है।

@cbazza बहुत अच्छा है तो चलिए यहां स्पंदन टीम के सदस्यों में से एक को यह बताने के लिए मिलता है कि क्या वे एक और दो में लेने की इच्छा रखते हैं ...

(2) के लिए मुझे लगता है कि सबसे अच्छा दांव डार्ट टीम से संपर्क करना है, शायद [email protected] या उनके इश्यू ट्रैकर के माध्यम से? मेरा मानना ​​​​है कि डार्ट 2 का एक लक्ष्य भाषा के साथ अधिक प्रयोग के लिए एक बुनियादी ढांचा तैयार करना और समुदाय को डीएसएक्स जैसे प्रयोग बनाने देना था। हो सकता है कि @ एंडर्स-सैंडहोम @ मिट-मिट या @ मरालेफ आपको सही दिशा में इंगित कर सकें।

@sethladd त्वरित प्रतिक्रिया के लिए धन्यवाद और क्या आप संसाधन व्यक्तियों और संभवतः कॉपी भी कर सकते हैं
इस सूत्र पर भी टीम को डार्ट करें
@cbazza सूचीबद्ध संसाधन व्यक्ति के साथ इस प्रवचन को प्राप्त करने के लिए आप कूद सकते हैं।
'वीएस कोड' एकीकरण के संबंध में मुझे यकीन है कि एक बार जब हम 2 रास्ते से बाहर हो जाते हैं तो शायद @DanTup मदद करने में दिलचस्पी ले सकता है

बस कुछ विचार

ठीक है, यहाँ मेरे पास है:
(ए) एक प्री-प्रोसेसर जो *.dsx फाइलों को अंदर लेता है और *.dart फाइलों को आउटपुट करता है।

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

1. Vscode और Intellij एकीकरण के लिए, यह स्पंदन निर्माण प्रणाली नहीं है, यह डार्ट विश्लेषक है जो आप चाहते हैं। मुझे लगता है कि आप इसके लिए एक प्लगइन बना सकते हैं जो डीएक्स का उपभोग करेगा, इसे डार्ट में ट्रांसपाइल करेगा, फिर परिणामों को मूल फ़ाइल पर वापस मैप करेगा। इस प्रकार कोणीय विश्लेषक प्लगइन एचटीएमएल फाइलों को स्वत: पूर्ण जैसी चीजें प्रदान करने के लिए काम करता है।

2. आप रनर बनाना चाहते हैं, यह a करने के लिए एक अधिक परिष्कृत पैकेज है।

@MichaelSowah
बहुत बढ़िया तो मुझे लगता है कि आप (1) और (2) ले रहे हैं ताकि मैं ट्रांसपिलर पर ध्यान केंद्रित कर सकूं?

@jonahwilliams
मुझे पता है, पूर्ण डार्ट पार्सिंग जटिल होगी और अभी वास्तव में जरूरी नहीं है क्योंकि मैं हमेशा पहली रिलीज के लिए अपने मार्करों का उपयोग कर सकता हूं (https://spark-heroku-dsx.herokuapp.com/index.html)

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

पुन: आईडीई और डीबगर, संभवतः डार्ट 2 इंफ्रास्ट्रक्चर और "कॉमन फ्रंट एंड" के अंदर इस सुविधा को लागू करके, आप डीएसएक्स के बारे में जागरूक होने के लिए स्टैक के उच्च स्तर को सक्षम करने में सक्षम होना चाहिए। मैं डार्ट टीम के साथ काम करने और कॉमन फ्रंट एंड और उसके एपीआई के विभिन्न हिस्सों का पता लगाने का तरीका सीखने की सलाह देता हूं।

@MichaelSowah मैंने https://github.com/flutter/flutter/issues/15922#issuecomment -376960770 में डार्ट के लोगों को सीसी किया

@NathanaelA क्या आप (1) और (2) में शामिल होने में रुचि रखते हैं क्योंकि अब हमें स्पष्ट रूप से टीम का समर्थन प्राप्त है

पक्का नहीं; इस समय -- मैं कई क्लाइंट प्रोजेक्ट्स से भरा हुआ हूँ। लेकिन मैं यह देखने के लिए तैयार हूं कि संकलन पाइपलाइन में कैसे लगाया जाए और संभावित रूप से स्रोत मानचित्र कैसे बनाए जाएं। (अर्थात 2) लेकिन मुझे ऐसा करने में कुछ हफ़्ते लग सकते हैं।

@NathanaelA कोई जल्दी या कुछ भी नहीं है इसलिए आप अच्छे हैं :-)

यदि DSX केवल Dart + Virtual closing tag है तो कोई वास्तविक लाभ नहीं है। डार्ट के साथ एक लाभ यह है कि हम विजेट का हिस्सा बनाने और पठनीयता बढ़ाने के लिए फ़ंक्शन और चर का उपयोग कर सकते हैं।

साथ ही DSX और प्री-प्रोसेसर के साथ, हम सब-सेकंड हॉट रीलोड क्षमता खो देंगे, ठीक है @cbazza ?

नहीं, DSX JSX की तरह है और 'डार्ट + वर्चुअल क्लोजिंग टैग' से पूरी तरह से अलग है जो कि आज आप अपने डार्ट केवल विजेट ट्री और आईडीई के साथ कर सकते हैं।

DSX यहाँ वर्णित है:
https://spark-heroku-dsx.herokuapp.com/index.html

DSX डार्ट है इसलिए डार्ट के सभी लाभ जैसा कि आप वर्णन कर रहे हैं। JSX से परिचित लोग इसे तुरंत प्राप्त करेंगे और इसे पसंद करेंगे।

नहीं, आप कुछ भी नहीं खोएंगे, आपके द्वारा बनाई गई सामान्य *.dart फ़ाइल के लिए कुछ भी नहीं बदलता है, आपके पास अभी भी सब-सेकंड हॉट रीलोडिंग है।
अब यदि आपके पास एक *.dsx फ़ाइल है, तो इसे पहले *.dart में स्थानांतरित किया जाएगा और यह प्रक्रिया मेरे पलक झपकने से भी तेज़ है !!! तो यह DSX उपयोगकर्ताओं के लिए ध्यान देने योग्य नहीं होगा।

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

@JonathanSum क्या आपने एंड्रॉइड स्टूडियो (3.1) के अंतिम संस्करण को क्लोजिंग लेबल के साथ आज़माया था?

@ 14n हां, मैं उन वर्चुअल क्लोजिंग टैग और टिप्पणियों को देखता हूं।

एक बड़ा एक्सएमएल जैसा विजेट ट्री किसी भी अन्य बड़ी चीज की तरह पढ़ने में मुश्किल हो सकता है, चाहे वह डार्ट, जेएसओएन, वाईएएमएल या जेएसएक्स हो। ऐसा नहीं लगता कि JSX ही पठनीयता की समस्या को हल करता है।

मुझे वर्तमान सिंटैक्स के साथ समझदार आकार के विजेट ट्री पढ़ने में कोई समस्या नहीं हुई है। प्लस स्पंदन रचना को बढ़ावा देता है इसलिए एक बार कुछ विजेट बहुत बड़े हो जाने पर इसे कई छोटे विजेट्स में विभाजित करना तुच्छ है।

प्रस्तावित DSX प्रारूप पर व्यक्तिपरक राय:

1. नेत्रहीन कोई वास्तविक लाभ नहीं और फिर से - बड़े एक्सएमएल-पेड़ को पढ़ना उतना ही दर्दनाक हो सकता है, इसलिए ऐसा नहीं लगता कि यह समस्या हल करता है। उदाहरण के लिए, स्वच्छ कोड प्रथाओं को बढ़ावा देना वास्तव में पठनीयता संबंधी चिंताओं को दूर करेगा, लेकिन इन प्रथाओं को (लगभग) किसी भी वाक्यविन्यास पर लागू किया जा सकता है।
2. एक और डीएसएल/वाक्यविन्यास सीखने की आवश्यकता है। मैं वास्तव में-वास्तव में वास्तव में पसंद करता हूं कि मुझे केवल एक वाक्यविन्यास जानने की जरूरत है - डार्ट - सब कुछ करने के लिए - लेआउट, शैलियों, एनिमेशन, तर्क। यह html/js/jsx/ts/coffee/css/sass/scss के साथ वेब पर जो हुआ उसकी तुलना में नए लोगों और अनुभवी डेवलपर्स दोनों के लिए बहुत अधिक अनुकूल है। वास्तव में, मैं इसे अन्य प्लेटफार्मों पर स्पंदन का एक प्रमुख लाभ भी मानता हूं।

उस ने कहा, मेरा मानना ​​​​है कि UI का वर्णन करने के लिए उपयोग किए जाने पर डार्ट के लिए और अधिक अभिव्यंजक होने के लिए सुधार के लिए जगह है, हालांकि मैं इसे मौजूदा डार्ट सिंटैक्स के बजाय पूरी तरह से नए डीएसएल के विस्तार के रूप में पसंद करूंगा।

कृपया फ़्लटर को "हॉट न्यू चीज़" जैसा बनाने की कोशिश करना बंद करें। यह अपने आप में सबसे नई चीज़ है, इसे नए प्रतिमानों का पता लगाने दें।

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

इस दर्पण पर मेरे विचार @pulyaevskiy ने https://github.com/flutter/flutter/issues/15922#issuecomment -377666972 में क्या कहा। मैंने देखा है कि सभी उदाहरण जो पठनीय नहीं हैं, उन्हें आम तौर पर मौजूदा कोड में साफ किया जा सकता है और मुझे लगता है कि डार्ट में और मामूली बदलाव हो सकते हैं (नए/कॉन्स्ट को हटाने के समान) जो इसे और बेहतर बना सकता है . एक पूरे अन्य सिंटैक्स के साथ फाइलों का एक पूरा सेट बनाए रखना और टूलिंग कोड का एक नया सेट अपेक्षाकृत कम लाभ के लिए एक उच्च लागत की तरह लगता है (एफडब्ल्यूआईडब्ल्यू, मैं जेएसएक्स के बिना भी प्रतिक्रिया पसंद करता हूं)।

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

एक काम करने वाले ट्रांसपिलर के बजाय, मुझे पढ़ने में मुश्किल माने जाने वाले कुछ कोड के बीच तीन-तरफ़ा तुलना देखने में अधिक दिलचस्पी होगी, यह इस प्रस्तावित सिंटैक्स में कैसा दिखेगा, और यह कैसा दिखेगा यदि आप इसमें कोई बदलाव कर सकते हैं सभी कोष्ठकों को बदले बिना मौजूदा डार्ट सिंटैक्स। उदाहरण के लिए, रिएक्ट में जो कुछ मुझे पसंद है वह यह है कि बच्चों को अंतिम पैरामीटर के रूप में varargs के रूप में पारित किया गया है - मुझे लगता है कि child और children स्पंदन में बहुत अधिक शोर जोड़ते हैं - शायद वहां सुधार की गुंजाइश है . इस बारे में भी कुछ चर्चाएं हैं कि क्या फ़ॉर्मेटिंग बदलने या विजेट वर्ग के नामों को हाइलाइट करने से मदद मिल सकती है। ऐसा लगता है कि एक्स्ट्रेक्ट विजेट रिफैक्टर बड़ी बिल्ड विधियों को आसानी से तोड़ने की राह पर है। और निश्चित रूप से, IntelliJ में स्पंदन रूपरेखा दृश्य है जो आपको एक पेड़ में कोड देखने देता है और चयन संपादक में कर्सर की स्थिति के साथ तालमेल रखता है (और मैं वास्तव में वीएस कोड में कुछ ऐसा ही प्राप्त करने की उम्मीद कर रहा हूं, हालांकि यह अवरुद्ध है इस तरह की कुछ वीएस कोड सुविधाओं द्वारा इसे करने के लिए स्वतंत्र महसूस करें!)।

@pulyaevskiy
मैं समझता हूं कि आप क्या कह रहे हैं लेकिन प्रयोग अच्छा है, यह विकास का मार्ग है। भले ही डीएसएक्स के साथ मेरा प्रयोग विफल हो जाता है, मुझे उम्मीद है कि अन्य लोग कई अन्य चीजों के साथ प्रयोग करेंगे और अद्भुत तकनीक बनाने के लिए सर्वोत्तम विचारों को एक साथ लाएंगे।

@सेथलाड
लीड्स के लिए धन्यवाद।
@anders-sandholm @mit-mit या @mraleph on . से वापस सुनना पसंद करेंगे
डार्ट 2 इंफ्रास्ट्रक्चर और 'कॉमन फ्रंट एंड' के साथ कैसे काम करें।
मैं @NathanelA के साथ उस पर गौर करूंगा।

@DanTup

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

हाँ आप सही हैं। मेरी 'तुच्छ, सरल पाई के रूप में लागू करने के लिए' टिप्पणी केवल संपादक को .dsx सिंटैक्स को पहचानने के लिए लागू करने के लिए लागू होती है। मैंने इंटेलिज में देखा और इसके लिए उन्हें एक पूर्ण भाषा पार्सर की आवश्यकता है (इसलिए यह जटिल है), जबकि वीएस कोड सिंटैक्स फाइलों के साथ बहुत आसान था और मैंने यह भी देखा कि टाइपस्क्रिप्ट/जावास्क्रिप्ट सिंटैक्स फाइलों में पहले से ही जेएसएक्स (और डीएसएक्स के लिए समर्थन था) JSX से मामूली बदलाव)।

हमारे प्रयोग को आगे बढ़ाने के लिए हम निश्चित रूप से आपकी सहायता/दिशा के लिए आपसे आग्रह करेंगे।

संक्षेप में, मेरे पास है:
(ए) एक प्री-प्रोसेसर जो *.dsx फाइलों को अंदर लेता है और *.dart फाइलों को आउटपुट करता है।
https://spark-heroku-dsx.herokuapp.com/index.html

मुझे इसमें मदद चाहिए:
(1) किसी को 'वीएस कोड' एकीकरण का ध्यान रखना।
(2) किसी को यह पता लगाने के लिए कि फ़्लटर बिल्ड सिस्टम में प्री-प्रोसेसर क्षमता को कैसे जोड़ा जाए ताकि डिबगिंग ठीक से काम करे। मेरा मतलब है कि कोड स्टेपिंग *.dsx फाइलों पर सोर्समैप, आदि जैसी किसी चीज़ के माध्यम से होगी।

@NathanaelA (2) के साथ मदद करेगा।

इसलिए मैं अब भी ऐसे लोगों की तलाश कर रहा हूँ जिनके साथ मदद की जा सके (1)
कोई लेने वाला? @birkir @yuriy-manifold @tehfailsafe @alexkrolick @sanketsahusoft

@DanTup - मैं JSX का समर्थक नहीं हूं, लेकिन मैं नेटिवस्क्रिप्ट XML प्रारूप की ओर बात कर सकता हूं। मैं कर सकता हूं:

कोई भी संपत्ति जिसे StackLayout वर्ग समर्थन करता है, उसे XML में जोड़ा जा सकता है। तो यह एक-से-एक संबंध है; जो एक टन अतिरिक्त क्रॉफ्ट को समाप्त करता है: तो आइए स्पंदन डेमो को देखें:
https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/gallery/home.dart#L39 -L63

<AnimationBuilder animation="{{animation}}">
   <Stack>
      <BackgroundLayer top="{{-layer.parallaxTween.evaluate(animation)}}" left=0.0 right=0.0 bottom=0.0>
          <Image src="{{layer.assetName}}" package="{{layer.assetPackage}} fit="cover" height="{{maxHeight}"}/>
      </BackgroundLayer>
   </Stack>
</AnimationBuilder>

अगर मैंने इसे सही तरीके से परिवर्तित किया तो मुझे इसे पढ़ना और समझना आसान लगता है। :मुस्कुराना:

@NathanaelA क्या होता है यदि आपको कुछ और गतिशील करने की ज़रूरत है, जैसे map पर कॉल करना? यहाँ उसी फ़ाइल से कुछ कोड है:

  Widget build(BuildContext context) {
    return new AnimatedBuilder(
      animation: animation,
      builder: (BuildContext context, Widget child) {
        return new Stack(
          children: _kBackgroundLayers.map((_BackgroundLayer layer) {
            return new Positioned(
              top: -layer.parallaxTween.evaluate(animation),
              left: 0.0,
              right: 0.0,
              bottom: 0.0,
              child: new Image.asset(
                layer.assetName,
                package: layer.assetPackage,
                fit: BoxFit.cover,
                height: _kFlexibleSpaceMaxHeight
              )
            );
          }).toList()
        );
      }
    );
  }

इस सिंटैक्स में children: _kBackgroundLayers.map(...) कैसा दिखेगा?

JSX/DSX केवल टैग रूपांतरण को इस प्रकार निर्दिष्ट करता है:

में:
<A property="a"/>
बाहर:
new A(property: a)

में:

<A property="a">
  <B/>
  <C/>
</A>

बाहर:

new A(property: a, 
children: <Widget>[
   new B(), 
   new C()
])

और आप किसी भी वैध डार्ट कोड को डालने के लिए {} का उपयोग कर सकते हैं, जैसे चर मूल्यांकन और अनाम कार्य, आदि। {} को 3 स्थानों पर रखा जा सकता है। नीचे दिया गया उदाहरण {} को 2 स्थानों (टैग विशेषताएँ और बच्चों के रूप में) में उपयोग करता है, जिसमें तीसरा स्प्रेड ऑपरेटर के साथ है।

  Widget build(BuildContext context) {
    return <AnimatedBuilder
      animation={animation}
      builder={(BuildContext context, Widget child) {
        return <Stack> {
          _kBackgroundLayers.map((_BackgroundLayer layer) {
            return <Positioned
              top={-layer.parallaxTween.evaluate(animation)}
              left={0.0}
              right={0.0}
              bottom={0.0}>
              <Image.asset [layer.assetName]
                package={layer.assetPackage}
                fit={BoxFit.cover}
                height={_kFlexibleSpaceMaxHeight}
              />
            </Positioned>;
          }).toList()
        } </Stack>;
      }}
    />;
  }

उपरोक्त कोड को जावास्क्रिप्ट फ़ाइल में रखें और इसे वीएस कोड/इंटेलिज के साथ देखें। +/- (लाइन के बाईं ओर) पर ध्यान दें, जिसका उपयोग आप एक्सएमएल नोड्स को खोलने और संक्षिप्त करने के लिए पेड़ को छोटा/बड़ा करने के लिए कर सकते हैं।

हम सिर्फ इस मुद्दे को स्वीकार क्यों नहीं कर सकते हैं और रिएक्ट नेटिव तरीका अपना सकते हैं? क्या हम ऐसा करने जा रहे हैं या नहीं?

@JonathanSum यहाँ निर्देशित होने पर क्षमा करें, लेकिन आपको क्या लगता है कि आप कौन हैं? कोई सामान्य समस्या नहीं है बस कुछ ऐसा है जो आपको पसंद नहीं है।
क्या आपने फ़्लटर के साथ एक भी ऐप लिखा है?
डार्ट को एक्सएमएल के साथ मिलाने के ऊपर के उदाहरण सिर्फ डार्ट से भी बदतर दिखते हैं। यहां हासिल करने के लिए कुछ भी नहीं है।
मैं Xamarin प्रपत्रों से आया हूं जो xaml का उपयोग करता है और मुझे वास्तव में यह पसंद आया। लेकिन शिकायत करने के बजाय कि फ़्लटर Xaml का समर्थन क्यों नहीं करता है, मैंने इसमें सही तरीके से काम किया और अनुकूलन और सीखना शुरू कर दिया।
इसका सामना करें यदि आप रिएक्ट की तरह काम करना चाहते हैं तो यहां सभी को परेशान करने के बजाय रिएक्टिव का उपयोग करें।

यहां उपरोक्त जैसा ही कोड ब्लॉक है, लेकिन शुद्ध डार्ट में और गहरे घोंसले से बचने के लिए दोबारा प्रतिक्रिया दी गई है।
जिज्ञासु नीचे दिए गए स्निपेट के किन हिस्सों को पढ़ना और/या समझना मुश्किल है?

Widget build(BuildContext context) =>
    AnimatedBuilder(animation: animation, builder: _buildChild);

_buildChild(BuildContext context, Widget child) {
  return Stack(
    children: _kBackgroundLayers.map((_BackgroundLayer layer) {
      final image = Image.asset(layer.assetName,
          package: layer.assetPackage,
          fit: BoxFit.cover,
          height: _kFlexibleSpaceMaxHeight);
      return Positioned(
          top: -layer.parallaxTween.evaluate(animation),
          left: 0.0,
          right: 0.0,
          bottom: 0.0,
          child: image);
    }).toList(),
  );
}

वास्तव में, व्यक्तिगत रूप से मैं इसे कुछ इस तरह के करीब देखूंगा:

Widget build(BuildContext context) => AnimatedBuilder(
      animation: animation,
      builder: _buildChild,
    );

_buildChild(BuildContext context, Widget child) {
  return Stack(
    children: _kBackgroundLayers.map(_imageForLayer).toList(),
  );
}

_imageForLayer(_BackgroundLayer layer) {
  final top = -layer.parallaxTween.evaluate(animation);
  final image = Image.asset(
    layer.assetName,
    package: layer.assetPackage,
    fit: BoxFit.cover,
    height: _kFlexibleSpaceMaxHeight,
  );
  return PositionedImage(top: top, image: image);
}

class PositionedImage extends StatelessWidget {
  PositionedImage({this.top, this.image});
  final double top;
  final Image image;

  <strong i="10">@override</strong>
  Widget build(BuildContext context) =>
      Positioned(top: top, left: 0.0, right: 0.0, bottom: 0.0, child: image);
}

फिर, ऐसा लगता है कि हम यहां दो अलग-अलग समस्याओं को मिला रहे हैं:

1. डार्ट सिंटैक्स को नापसंद करते हैं और XML/JSX जैसे सिंटैक्स की आवश्यकता होती है
2. स्पंदन कोड की पठनीयता।

क्या यहां ऐसे लोग हैं जो मानते हैं कि JSX को लागू करने से पठनीयता हल हो जाएगी? कोड में गहरे घोंसले वाले पेड़ बनाना अभी भी संभव होगा और डेवलपर्स को अभी भी उन्हीं चरणों से गुजरना होगा जो मैंने अभी-अभी डार्ट संस्करण के साथ किए हैं ताकि चीजों को पठनीय बनाया जा सके।

लेकिन यह निश्चित रूप से जो जोड़ देगा वह स्रोत मानचित्रों और सह के साथ एक अतिरिक्त निर्माण/पारदर्शी कदम है, और आईडीई और डार्ट एसडीके (विश्लेषक, डीबगर, आदि) में इस बुनियादी ढांचे का समर्थन करने के लिए बहुत सारे काम हैं।

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

कुल मिलाकर, मुझे ऐसा लगता है कि DSX को जोड़ने से फ़्लटर पारिस्थितिकी तंत्र अपने शुरुआती चरणों में खंडित हो जाएगा, दोनों सिंटैक्स को सुविधा-पूर्ण रखने के लिए बहुत काम किया जा रहा है, वास्तव में ज्यादातर मामलों में पठनीयता में महत्वपूर्ण रूप से मदद नहीं करता है, और उन डेवलपर्स को आकर्षित करता है जो एक समान वाक्य रचना और/या एक गर्म नई चीज़ के प्रतिमान के लिए विशुद्ध रूप से परियोजनाओं के लिए आकर्षित होते हैं।

@Hixie क्षमा करें कि मैंने अपना आपा खो दिया है, लेकिन मुझे लगता है कि फ़्लटर एक अच्छे रास्ते पर है और फ़्लटर देवों के पास इस तरह की मांगों के बिना करने के लिए पर्याप्त है

@escmoteur - मुझे लगता है कि यही कारण है कि मैंने विशेष रूप से "समुदाय" प्रयास कहा। मुझे नहीं लगता कि इसके लिए स्पंदन कोर टीम को शामिल करने की जरूरत है, जो पैच स्वीकार करने के लिए तैयार हैं ... ऐसा लगता है कि सेठ ने कहा है कि हम आगे बढ़ने में सक्षम हैं। यदि आप इस सुविधा में रुचि नहीं रखते हैं; तो इसका उपयोग न करें... :मुस्कुराते हुए:

@escamoteur , मैंने जो कहा उसके लिए मुझे खेद है।
मैंने ट्यूटोरियल्स से कुछ स्पंदन ऐप्स बनाए हैं। स्पंदन के बारे में मुझे लगता है कि सब कुछ एक विजेट के बजाय एक वस्तु है। यह जटिल ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग कोड के एक विशाल टुकड़े की तरह है जो अव्यवस्थित रूप से एक साथ फंस गया है।

मुझे लगता है कि सबसे महत्वपूर्ण बात एक ऐसा ढांचा बनाना है जो पढ़ने और प्रबंधित करने में आसान हो, और इसे नरक के रूप में जटिल नहीं होना चाहिए। सबसे महत्वपूर्ण बात, मुझे लगता है कि जिस तरह से रिएक्ट-नेटिव का निर्माण होता है, वह इस प्रकार है कि मनुष्य स्वाभाविक रूप से सामान बनाते हैं। दूसरी ओर, स्पंदन को स्टेटफुल विजेट को स्टेटलेस में जोड़ने की आवश्यकता होती है और ... इसके अलावा, इन वर्षों में उपयोग किए जाने वाले अधिकांश UI फ्रेमवर्क मानक के रूप में इस रिएक्ट तरीके पर ध्यान केंद्रित करते हैं, और मुझे लगता है कि स्पंदन को इस पर अधिक ध्यान देना चाहिए। हॉट रीलोड के बजाय (जब मैं कुछ नई कक्षाएं जोड़ने की कोशिश करता हूं, तो कंसोल मुझे हॉट रीलोड करने के बजाय सब कुछ पुनरारंभ करने के लिए कहता है)। मुझे सच में लगता है कि यह एक मुद्दा है, टिप्पणी या मांग नहीं।
नैवेइगुई ने कहा:

कृपया फ़्लटर को "हॉट न्यू चीज़" जैसा बनाने की कोशिश करना बंद करें। यह अपने आप में सबसे नई चीज़ है, इसे नए प्रतिमानों का पता लगाने दें।

आप उन्हें देखने जा सकते हैं।
https://facebook.github.io/react-native/
प्रतिक्रिया में सोच:
https://reactjs.org/docs/design-principles.html
स्पंदन:
https://flutter.io/tutorials/animation/

रिएक्ट-नेटिव को देखें, यह राज्य प्रबंधन को ऊपर और UI भागों को नीचे रखता है। यह मनुष्य की एक कला और स्वाभाविक व्यवहार है। यही कारण है कि सीखने की अवस्था और प्रबंधन का समय कम होता है। इस प्रकार, कृपया XML या Xamarin की तुलना रिएक्ट नेटिव से न करें। इसके अलावा, बकवास सिर्फ एक अराजकता और अव्यवस्था की तरह है। स्टेटलेस स्टेटफुल से कनेक्ट होता है, और क्रिएट-स्टेट स्टेटलेस में सब कुछ जोड़ता है। रिएक्ट-नेटिव के साथ, आप एक पेंसिल के साथ एक सुंदर चित्र बना रहे हैं। स्पंदन के साथ, यह एक कागज पर पानी गिराने और पानी को अलग-अलग हिस्सों में अलग करने जैसा है। लेकिन मुझे लगता है कि हम अभी भी फड़फड़ाने के शुरुआती दिनों में हैं। रिएक्ट-नेटिव का अपना दर्शन और लक्ष्य है, और स्पंदन सिर्फ एक गंभीर परियोजना है, या हर कोई मुझसे असहमत है।

@JonathanSum

मैंने ट्यूटोरियल्स से कुछ स्पंदन ऐप्स बनाए हैं। स्पंदन के बारे में मुझे लगता है कि सब कुछ एक विजेट के बजाय एक वस्तु है। यह जटिल ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग कोड के एक विशाल टुकड़े की तरह है जो अव्यवस्थित रूप से एक साथ फंस गया है।

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

मुझे लगता है कि सबसे महत्वपूर्ण बात एक ऐसा ढांचा बनाना है जो पढ़ने और प्रबंधित करने में आसान हो, और इसे नरक के रूप में जटिल नहीं होना चाहिए।

यह एक तनातनी है। जाहिर तौर पर हर कोई यही चाहता है, लेकिन लोगों के पास इस समस्या से निपटने के अलग-अलग तरीके हैं। स्पंदन का प्रतिमान उनमें से एक है।

सबसे महत्वपूर्ण बात, मुझे लगता है कि जिस तरह से रिएक्ट-नेटिव का निर्माण होता है, वह इस प्रकार है कि मनुष्य स्वाभाविक रूप से सामान बनाते हैं।

मुझे नहीं लगता कि यूआई के निर्माण के लिए सिंटैक्स जितना मामूली है, यह प्रभावित करता है कि एक फ्रेमवर्क का उपयोग कितना आसान है।

दूसरी ओर, स्पंदन को स्टेटफुल विजेट को स्टेटलेस में जोड़ने की जरूरत है और ...

ऐसा लगता है कि आप मूल रूप से इस बात से असहमत हैं कि फ़्लटर ऐप्स तक कैसे पहुंचता है। आप इसका उपयोग क्यों कर रहे हैं? इसके अलावा, यह वास्तव में एक मान्य बिंदु नहीं है। आप कुछ ऐसा व्यक्त नहीं कर रहे हैं जो आपको लगता है कि गलत है, आप बस कह रहे हैं "मुझे लगता है कि स्टेटलेस और स्टेटफुल विजेट्स के बीच संबंध कुछ अस्पष्ट तरीके से गलत और जटिल हैं जिन्हें मैं समझाने के लिए आगे नहीं बढ़ूंगा।"

इसके अलावा, अधिकांश UI फ्रेमवर्क जिनका हम इन वर्षों में उपयोग करते हैं, एक मानक के रूप में इस रिएक्ट तरीके पर ध्यान केंद्रित करते हैं,

तर्क विज्ञापन पॉपुलम।

और मुझे लगता है कि स्पंदन को हॉट रीलोड के बजाय इस पर अधिक ध्यान देना चाहिए (जब मैं कुछ नई कक्षाएं जोड़ने की कोशिश करता हूं, तो कंसोल मुझे हॉट रीलोड करने के बजाय सब कुछ पुनरारंभ करने के लिए कहता है)

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

हालाँकि, बकवास सिर्फ अराजकता और अव्यवस्था की तरह है।

यहां आपने यह स्पष्ट कर दिया है कि आपको फ़्लटर का दृष्टिकोण पसंद नहीं है। तब इसका इस्तेमाल न करें। और अगर आपको लगता है कि किसी तरह, जादुई रूप से, UI सिंटैक्स को बदलने से फ़्लटर "अराजकता और अव्यवस्था" नहीं बन जाएगा, तो आपको उसी प्रकार की सेटिंग्स और बाधाओं में काम करने का स्पष्ट प्रमाण देना होगा, जिसके साथ फ़्लटर काम कर रहा है।

इसलिए सीखने की अवस्था और इसे प्रबंधित करने का समय कम है। कृपया XML या Xamarin की तुलना रिएक्ट नेटिव से न करें।

काफी उचित - तब रिएक्ट नेटिव का उपयोग करें। वहां के डेवलपर्स अपने प्रतिमान के साथ बहुत अच्छा काम कर रहे हैं।

स्टेटलेस स्टेटफुल से कनेक्ट और स्टेटलेस में क्रिएट-स्टेट

क्या? नहीं, यह बिल्कुल गलत है - यहाँ आपका क्या मतलब है?

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

सच कहूं तो यह सादृश्य मेरे लिए बहुत कम मायने रखता है। मैं आसानी से उल्टा राय बता सकता था और हम ठीक वहीं होंगे जहां हमने यहां शुरुआत की थी।

आप इस तरह से अभिनय कर रहे हैं जो स्पष्ट रूप से स्पष्ट है ("चलो इसका सामना करते हैं") और हम यहां केवल यह कहने के लिए दिखावा और/या असहनीय हैं कि फ़्लटर टीम को इससे निपटना नहीं चाहिए। यदि आप चाहते हैं कि अन्य लोग आपको गंभीरता से लें तो इसे अपनाना अच्छा रवैया नहीं है।

अतिरिक्त बिंदु: कृपया यह दिखावा न करें कि यह ऐसा कुछ है जो तृतीय-पक्ष डेवलपर्स बिना किसी भागीदारी के कर सकते हैं या फ़्लटर कोर टीम की ओर से काम कर सकते हैं। Flutter टीम को IDE और संपादक प्लगइन्स, और इंजीलवाद के साथ बहुत सारे अतिरिक्त काम करने होंगे, और GitHub मुद्दों से निपटने के लिए, यदि इस तरह की सुविधा को Flutter के सामंजस्यपूर्ण भाग के रूप में संतोषजनक ढंग से लागू किया जाना है।

@naiveaiguy
ठीक है, मुझे लगता है कि तुम सही हो। मैं सिर्फ एक यादृच्छिक व्यक्ति हूं जो यहां सभी की तुलना कर रहा है और एक व्यक्ति जो प्रतिक्रिया पसंद करता है। स्पंदन का अपना तरीका होता है, और रिएक्ट का भी। मुझे अपने रवैये के लिए खेद है, और मैं अच्छा नहीं था।

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

मैं यह जानना चाहता हूं कि आप स्पंदन में बिल्कुल रुचि क्यों रखते हैं? मेरे लिए रिएक्ट जेएस की वजह से नहीं जाना है

टिप्पणी करने के लिए इतना, इतना कम समय, शायद मुझे ध्यान देना चाहिए...

@escamoteur वास्तव में आपका क्या मतलब है:

मेरे लिए रिएक्ट जेएस की वजह से नहीं जाना है

ES6/7 या टाइपस्क्रिप्ट डार्ट/कोटलिन/स्विफ्ट के इतने करीब हैं कि मैं इनमें से किसी भी महिला के साथ खुशी से नृत्य करूंगा :)

जो चीज मुझे स्पंदन की ओर आकर्षित करती है वह है ग्राफिक्स और एनिमेशन सपोर्ट। 60 एफपीएस पर सुपर फास्ट यूएक्स के लिए ओपनजीएल के शीर्ष पर बनाया गया डायरेक्ट स्कीया वेक्टर ग्राफिक्स आसानी से चीजों को लागू करने के लिए जो आप देखते हैं:
https://uimovement.com/
मैं कस्टम यूएक्स में हूं और स्पंदन इसे सक्षम बनाता है। मैंने दशकों से यूएक्स सामग्री को लागू किया है और मुझे वास्तव में घोषणात्मक/प्रतिक्रियाशील तकनीकों का उपयोग करके इसे बनाने में सक्षम होना पसंद है, और स्पंदन इसका समर्थन करता है।

@pulyaevskiy

फिर, ऐसा लगता है कि हम यहां दो अलग-अलग समस्याओं को मिला रहे हैं:

• डार्ट सिंटैक्स को नापसंद करते हैं और XML/JSX जैसे सिंटैक्स की आवश्यकता होती है
• स्पंदन कोड की पठनीयता।

सही है, यह टिकट यहाँ (और पिछला वाला) केवल JSX जैसी क्षमताओं को चाहता है। मौजूदा UI बिल्डिंग कोड की वर्बोसिटी को कम करने के लिए डार्ट भाषा में सुधार के लिए अन्य टिकट हैं।

क्या यहां ऐसे लोग हैं जो मानते हैं कि JSX को लागू करने से पठनीयता हल हो जाएगी?

यह उनके लिए हो सकता है, प्रत्येक के लिए उनका अपना।

हां, आपके द्वारा प्रदान किया गया उदाहरण पेड़ को छोटा बनाता है लेकिन इसे टुकड़ों में तोड़कर और टुकड़ों को कहीं और ले जाकर, यह पूरी संरचना को कोड में देखना भी कठिन बना देता है। मैं इसके बजाय पूरी संरचना को एक स्थान पर रखूंगा और पेड़ से कुछ संबंधित गुण (नामित पैरामीटर) निकालूंगा और उन्हें लाने के लिए डीएसएक्स के स्प्रेड ऑपरेटर का उपयोग करूंगा। बस मेरी प्राथमिकता।

लेकिन यह निश्चित रूप से जो जोड़ देगा वह स्रोत मानचित्रों और सह के साथ एक अतिरिक्त निर्माण/पारदर्शी कदम है, और आईडीई और डार्ट एसडीके (विश्लेषक, डीबगर, आदि) में इस बुनियादी ढांचे का समर्थन करने के लिए बहुत सारे काम हैं।

हम इसे संभाल रहे हैं और @sethladd ने कहा है कि I believe one of the goals of Dart 2 was to create an infrastructure for more experimentation with the language and let the community create experiments like DSX.

@naiveaiguy

मैं तर्क दूंगा कि 30-40% कोड परिवर्तनों में भी फ़्लटर ने जो विकास चक्र हासिल करने में कामयाबी हासिल की है, वह वास्तव में प्रभावशाली है, और केवल ट्रांसपिलिंग की परतों से धीमा हो जाएगा।

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

अतिरिक्त बिंदु: कृपया यह दिखावा न करें कि यह ऐसा कुछ है जो तृतीय-पक्ष डेवलपर्स बिना किसी भागीदारी के कर सकते हैं या फ़्लटर कोर टीम की ओर से काम कर सकते हैं। Flutter टीम को IDE और संपादक प्लगइन्स, और इंजीलवाद के साथ बहुत सारे अतिरिक्त काम करने होंगे, और GitHub मुद्दों से निपटने के लिए, यदि इस तरह की सुविधा को Flutter के सामंजस्यपूर्ण भाग के रूप में संतोषजनक ढंग से लागू किया जाना है।

ज़रुरी नहीं। हम ऐसा कर रहे हैं और केवल ब्लॉक न करने के लिए कह रहे हैं। हम हमें सही दिशा में इंगित करने के लिए मार्गदर्शन मांग रहे हैं। मैं यह सब अपने आप नहीं करूंगा, इसलिए अब हम में से 2 हैं (धन्यवाद @NathanaelA) और हम और लोगों की तलाश कर रहे हैं (कम से कम 1 और) अगर वे मदद करना चाहते हैं।

हर किसी को अभिवादन! सबसे पहले, मैं यह बताना चाहूंगा कि इस मुद्दे पर आगे और पीछे की चर्चा जारी रखने का कोई मतलब नहीं है - रैखिक संरचना के कारण इसका पालन करना बड़ा और कठिन होगा। आपके तर्क खो जाएंगे और बार-बार दोहराए जाएंगे। आइए इसे शुद्ध संख्या में कम करें:

• यदि आप इस सुविधा के लिए हैं - इस मुद्दे पर सबसे पहले टिप्पणी करें।
• यदि आप इस सुविधा के खिलाफ हैं - तो इस मुद्दे पर सबसे पहले टिप्पणी करने से बचें।

इसके बाद, मैं @sethladd के कथन को स्पष्ट करना चाहूंगा, इसे पढ़ना चाहिए _"डार्ट 2 के लक्ष्यों में से एक डार्ट टीम के लिए भाषा के साथ अधिक प्रयोग के लिए एक बुनियादी ढांचा तैयार करना था"_।

यहां तक ​​कि डार्ट 2 में भी हम कोई एपीआई प्रदान नहीं करते हैं जो आपको डार्ट एसडीके (या स्पंदन इंजन कलाकृतियों) के पुनर्निर्माण के बिना, डार्ट भाषा के सिंटैक्स को आसानी से बदलने की अनुमति देता है। डार्ट 2 जो प्रदान करता है वह एक _कॉमन फ्रंट-एंड_ (सीएफई) इंफ्रास्ट्रक्चर (डार्ट एसडीके स्रोतों में pkg/front_end में स्थित) है - जो डार्ट में लिखी गई डार्ट भाषा के लिए एक पार्सर है। डीएसएक्स जैसे विशुद्ध रूप से वाक्यात्मक चीनी भाषा परिवर्तन के लिए आपको सीएफई कोड को संपादित करने में सक्षम होना चाहिए, डार्ट एसडीके (या स्पंदन इंजन) का निर्माण करना चाहिए और सभी उपकरण हैं (संबंधित आईडीई प्लगइन्स में निर्मित सिंटैक्स हाइलाइटिंग कोड को छोड़कर) अपना नया सिंटैक्स एक्सटेंशन चुनें। ध्यान दें कि वर्तमान में केवल VM और dart2js वास्तव में CFE का उपयोग करते हैं, विश्लेषक अगले संक्रमण के लिए निर्धारित है। जैसा कि आप देख सकते हैं कि यहां प्रवेश के लिए कुछ अवरोध हैं।

यहां एक महत्वपूर्ण बात यह है कि डार्ट सिंटैक्स का विस्तार करने के लिए कोई एपीआई नहीं है, इसलिए आपको भाषा को विस्तारित करने के लिए डार्ट भाषा टीम के साथ काम करना होगा। वर्तमान में इसके लिए कोई औपचारिक प्रक्रिया नहीं है, हालांकि DSX जैसी सुविधा के लिए इसे डार्ट में शामिल करने के लिए बहुत सारे सबूत और प्रेरणा की आवश्यकता होगी। (/ fyi @leafpetersen @lrhn - अगर मैं गलत हूं तो कृपया मुझे सुधारें)

डीएसएक्स जैसे समाधान के समर्थकों के लिए मेरी सिफारिशें यहां दी गई हैं:

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

  • यदि आप अपना प्रस्ताव Google दस्तावेज़ में डालते हैं, तो लोग आपके प्रस्ताव के विभिन्न घटकों पर चर्चा करने के लिए अंतर्निहित टिप्पणियों का उपयोग कर सकते हैं;
  • वैकल्पिक रूप से आप अपने प्रस्ताव के मार्कडाउन विवरण के साथ एक गिटहब रेपो बना सकते हैं, और अपने प्रस्ताव को परिष्कृत और चर्चा करने के लिए गिटहब मुद्दे और पीआरएस का उपयोग कर सकते हैं।

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



• अगला यदि आप कर सकते हैं तो आपको कार्यान्वयन करने का प्रयास करना चाहिए। सीएफई अवसंरचना के साथ भी यहां अवरोध अधिक है - लेकिन पहले की तुलना में बहुत कम।

@mraleph मुझे लगता है कि डार्ट में एकीकरण के बारे में तर्क कोड पीढ़ी या समान को लागू करने के लिए हुक के बारे में अधिक थे, भाषा को बदलने के लिए नहीं।
मुझे नहीं पता कि ऐसा कुछ जरूरी है।
मुझे लगता है कि इसे ज्यादातर अपने एनालाइज़र प्लगइन के साथ एंगुलर की तरह लागू किया जा सकता है, HTML के बजाय सिर्फ DSX

@mraleph

स्पष्टीकरण के लिए बहुत-बहुत धन्यवाद।
हम वास्तव में डार्ट भाषा को संशोधित नहीं करना चाहते हैं, हमें अपने प्रायोगिक डीएसएक्स को डार्ट में बदलने के लिए पूर्व-प्रसंस्करण क्षमता की आवश्यकता है।
वैसे आप इसे यहां ऑनलाइन आजमा सकते हैं:
https://spark-heroku-dsx.herokuapp.com/index.html

बात यह है कि जब डार्ट पहली बार बाहर आया तो यह जावास्क्रिप्ट को ट्रांसपाइल करने में सक्षम था और स्रोत मानचित्रों का उपयोग करके यह सिर्फ जावास्क्रिप्ट पारिस्थितिकी तंत्र में प्लग करने में सक्षम था (कई अन्य भाषाओं ने ऐसा ही किया: कॉफ़ीस्क्रिप्ट, टाइपस्क्रिप्ट, आदि)। हम जो खोज रहे हैं वह डार्ट/स्पंदन के लिए कुछ ऐसा ही है। हम जेनेरिक प्री-प्रोसेसिंग क्षमता की तलाश कर रहे हैं जो डार्ट/स्पंदन के शीर्ष पर किसी अन्य ट्रांसपिलिंग भाषा को बनाने में सक्षम हो।

मतदान के संबंध में, पिछले टिकट में कुछ संख्याएँ होती हैं:
https://github.com/flutter/flutter/issues/11609

@cbazza

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

मैं इस दृष्टिकोण से बात कर रहा था कि *.dsx फाइलें वास्तव में डार्ट फाइलें हैं जिनमें आप कुछ अतिरिक्त सिंटैक्स का उपयोग कर सकते हैं। और जैसा कि मैंने कहा कि वर्तमान में कोई एपीआई या विस्तार बिंदु नहीं हैं जो इस तरह के सिंटैक्स एक्सटेंशन के निर्माण की सुविधा प्रदान करते हैं जो इन सिंटैक्स एक्सटेंशन को डार्ट पारिस्थितिकी तंत्र में सभी उपकरणों के साथ पारदर्शी रूप से इंटरऑपरेट करने की अनुमति देता है। इसके अलावा, मुझे नहीं लगता कि ऐसे एपीआई या विस्तार बिंदुओं को डिजाइन और प्रदान करने की कोई तत्काल योजना है - इसलिए आज की आपकी सबसे अच्छी शर्त डार्ट एसडीके को फोर्क करना और सीएफई में डीएसएक्स समर्थन का निर्माण करना है।

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

@mraleph एक बार फिर धन्यवाद।

हम निश्चित रूप से DSX उपयोगकर्ताओं के लिए एक शानदार उपयोगकर्ता अनुभव प्रदान करने का लक्ष्य बना रहे हैं जो निश्चित रूप से है।

कुछ लोग एक्सएमएल-जैसे सिंटैक्स पसंद करते हैं, कुछ लोग इससे नफरत करते हैं। शायद जेएसएक्स-जैसे सिंटैक्स जोड़ना बहुत अधिक है। स्पंदन के बारे में मेरी मुख्य चिंता पठनीयता है। आईएमएचओ, डार्ट और स्पंदन के वर्तमान वाक्यविन्यास में सुधार करने के लिए अभी भी जगह है (मेरे लिए यह है मुख्य रूप से गहरे घोंसले के शिकार कोष्ठक के बारे में, child , children , अर्धविराम शोर, आदि।)
कुछ उदाहरण कोड को दोबारा पोस्ट करना [1] यहां,

// Comparing Flutter to what it might look like in Kotlin
class TutorialHome : StatelessWidget {
    override
    fun build(context: BuildContext) = scaffold {
        appBar = appBar {
            leading = iconButton {
                iconImage = Icon(Icons.menu)
                tooltip = "Navigation menu"
                onPressed = null
            } 
            titleText = "Example title"
            actions = [ // based on https://twitter.com/abreslav/status/867714627060322305
              iconButton { 
                iconImage = Icon(Icons.search)
                tooltip = "Search"
                onPressed = null  
              }
            ]
        }
        body = center {
            // Remember: This is a fully functional programming environment. You can execute any 
           //  code you can think of.
            child = Text("Hello ${MyApp.users.me.fullName.split(" ").first}!")
        }
        floatingActionButton = fab {
            tooltip = "Add"
            childImage = Icon(Icons.add)
            onPressed = null
        }
    }
}

new और अर्धविराम वैकल्पिक के साथ डार्ट 2 संस्करण(@sethladd से कोड)[2],

class TutorialHome extends StatelessWidget {
  <strong i="13">@override</strong>
  Widget build(BuildContext context) => Scaffold(// implicit new!, also matching your Kotlin here
      appBar: AppBar(
        leading: IconButton(
          icon: Icon(Icons.menu)
          tooltip: 'Navigation menu'
          onPressed: null
        )
        title: Text('Example title')
        actions: [ // Dart + strong mode will infer the contents of the list
          IconButton(
            icon: Icon(Icons.search)
            tooltip: 'Search'
            onPressed: null
          )
        ]
      )
      // body is the majority of the screen.
      body: Center(
        child: Text('Hello, world!')
      )
      floatingActionButton: FloatingActionButton(
        tooltip: 'Add' // used by assistive technologies
        child: Icon(Icons.add)
        onPressed: null
      )
   )
}

आईएमओ, कोटलिन संस्करण साफ है और बेहतर दिखता है। डार्ट 2 संस्करण बहुत करीब है और अभी भी सुधार के लिए जगह है (यदि डार्ट विस्तार विधियों का समर्थन करता है?)। इसलिए मुझे लगता है कि वर्बोसिटी को कम करने के लिए डार्ट सिंटैक्स में सुधार करना सही दिशा है।

[1] https://gist.github.com/asarazan/b3c23bef49cf9a61f5a1a19de746f1b0
[2] https://gist.github.com/sethladd/7397a067deb43b6052032195fcb26d94

एक और कोण, मुझे JSX की रचना क्षमता पसंद है।

घटकों (विजेट) के साथ काम करना बहुत आसान और सुलभ है, उन्हें एक संपादक में पेड़ के ऊपर और नीचे ले जाना केवल एक कीबोर्ड शॉर्टकट (Alt+UP / Alt+DOWN) की बात है। यह विशेष रूप से तब सच होता है जब सामान को कंटेनर, रो, कॉलम आदि से अंदर और बाहर ले जाया जाता है।

लेकिन यह ऐसा कुछ नहीं है जिसे DSX अपने आप हल कर लेगा। उन्हें स्वयं विजेट्स की आवश्यकता होगी
काम करने के लिए संपत्ति के नामकरण के साथ अधिक प्रतिबंधित। रिएक्ट में, यह children नामक एक संपत्ति है और JSX में एक मुख्य प्रिंसिपल है। स्पंदन बच्चों के नामकरण (बच्चों, बच्चों, शरीर, आदि) में लचीलेपन की अनुमति देता है।

यहां पेशेवरों और विपक्षों की एक बड़ी चर्चा है: https://github.com/jsforum/jsforum/issues/1

तीव्र गति	डीएसएक्स

स्रोत: https://github.com/flutter/flutter/blob/master/examples/platform_view/lib/main.dart

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

@birkir DSX कई/गैर- children चाइल्ड स्लॉट के लिए रेंडर प्रॉप्स पैटर्न जैसी किसी चीज़ का समर्थन करने में सक्षम होना चाहिए। यदि यह कार्यों या वर्ग संदर्भों को सहारा के रूप में ले सकता है (जो शायद यह स्वचालित रूप से होगा) तो यह बॉक्स से बाहर काम करेगा।

जहां तक ​​टूलींग कार्यान्वयन की बात है, जावास्क्रिप्ट टूलिंग ने लंबे समय तक गैर-मानक सिंटैक्स और भाषा विस्तार (फ्लोटाइप/टाइपस्क्रिप्ट/बेबेल) का समर्थन किया है, इसलिए JSX के लिए बहुत सारे टूल मौजूदा ट्रांसपिलर का लाभ उठाते हैं। अफैक डार्ट ने उस स्तर के विखंडन का अनुभव नहीं किया है, इसलिए टूलींग अभी तक मौजूद नहीं है। लेकिन अब इसका निर्माण शुरू करने का अच्छा समय है

आईएमएचओ, जेसन-जैसी वाक्यविन्यास ~ एक्सएमएल-जैसी ~ वाक्यविन्यास से काफी बेहतर है!

container {
  padding: EdgeInsets.symmetric { vertical: 16.0  }
}

@jaychang0917
मुझे नहीं लगता कि जेएसएक्स की तुलना एक्सएमएल से की जा सकती है। मुझे लगता है कि JSX और XML सुपरसोनिक एयरक्राफ्ट वर्स प्रोपेलर एयरक्राफ्ट के रूप में दो अलग-अलग चीजें हैं।

JSX के साथ, आप निम्न कार्य कर सकते हैं:

<supersonicAircarft 
          aircarft={{"F-22"}} 
          speed={{"mach2"}} 
          style={{"you can style it whatever you want as simple as css"}}
/>

या

<Image
          source={{uri: 'https://i.chzbgr.com/full/7345954048/h7E2C65F9/'}}
          style={{width: 320, height:180}}
        />

JSX के साथ, हम ऊपर दिए गए अनुसार सब कुछ टुकड़े-टुकड़े भी कर सकते हैं, या आप UI के एक बड़े हिस्से को एक <> टैग में समूहित कर सकते हैं ताकि UI के इस बड़े हिस्से को आप कहीं भी रख सकें।

यही कारण है कि रिएक्ट एचटीएमएल और एक्सएमएल की जगह लेता है और जेएसएक्स को आईफोन ऐप या वेब ऐप बनाने के लिए अपनाता है, या लोग कहते हैं कि जेएसएक्स एचटीएमएल का सिर्फ एक कूलर संस्करण है।

• मुझे एक्सएमएल और एचटीएमएल दोनों पसंद नहीं हैं और जेएसएक्स से प्यार है।

• मुझे लगता है कि सबसे महत्वपूर्ण बात आईफोन बनाम डेस्कटॉप के रूप में प्रदर्शन के बारे में नहीं है।

• सबसे महत्वपूर्ण बात iPhone बनाम डेस्कटॉप के रूप में उपयोग करना आसान है।

उदाहरण के लिए:

import React, { Component } from 'react';
import { Image, ScrollView, Text } from 'react-native';

class AwkwardScrollingImageWithText extends Component {
  render() {
    return (
      <ScrollView>
        <Image
          source={{uri: 'https://i.chzbgr.com/full/7345954048/h7E2C65F9/'}}
          style={{width: 320, height:180}}
        />
        <Text>
                        JSX is the philosophy, everything is a component. Simple is Complicate because you can 
                        form everything to your own perfect shape. 
        </Text>
      </ScrollView>
    );
  }
}

या लिखो

< AwkwardScrollingImage/>

लिखने के लिए-एक बार-रन-हर जगह

import { AwkwardScrollingImage } from './your-native-code';
class SomethingFast extends Component {
  render() {
    return (
      <View>
          <AwkwardScrollingImage/>
        <Text>
            JSX is the philosophy, everything is a component. Simple is Complicate because you can form everything to your own perfect shape. Everything is a widget or component.
        </Text>
      </View>
    );
  }
}

~ फ़्लटर UI बनाने के लिए प्रोग्रामिंग भाषा का उपयोग कर रहा है। ~

संदर्भ:

स्पंदन:
https://flutter.io/tutorials/layout/
रिएक्ट नेटिव जो एंड्रॉइड, आईफोन और यहां तक ​​​​कि डेस्कटॉप का निर्माण करता है:
https://facebook.github.io/react-native/

@birkir
ओह, यह बहुत अच्छा लग रहा है !!! सिर्फ मांस और कोई हड्डी नहीं :)
इसके साथ https://builderx.io/ का उपयोग करने की कल्पना करें (दूसरी एनिमेटेड छवि पर एक नज़र डालें - 2 तरह से यूआई बिल्डिंग जैसे फ्लेक्स उपयोग करने के लिए :)

@escamoteur
इनलाइन बिल्डरों के साथ यह मौजूदा तरीके की तरह ही गन्दा लगेगा; नमूने ऊपर प्रदान किए गए थे:
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

वैसे भी, मुझे लगता है कि वर्तमान तरीका स्पष्ट और सुसंगत है। डार्ट फ़ाइल में कुछ डार्ट कोड और < टैग मिलाने से मुझे लगता है कि कोड अजीब और अस्पष्ट है। एंड्रॉइड डेवलपर के दृष्टिकोण से, यह लेआउट xml फ़ाइल में जावा/कोटलिन कोड लिखने जैसा दिखता है :)

बस मेरे दो सेंट

@JonathanSum उम ...

तो JSX का उपयोग करने के कौन से फायदे वर्तमान स्पंदन तरीके से नहीं कर सकते हैं? मुझे आपके द्वारा कहा गया कोई भी तर्क मजबूत नहीं लगता।

JSX XML जैसा नहीं है। JSX उस XML से सरल और शक्तिशाली है।

बीटीडब्ल्यू, जेएसएक्स एक्सएमएल जैसा है , अगर फेसबुक टीम मुझसे झूठ नहीं बोलती है :)

@jaychang0917
जेएसएक्स एक्सएमएल नहीं है क्योंकि जेएसएक्स उस एक्सएमएल की तुलना में सरल और अधिक शक्तिशाली है। (मैं कहता हूं कि जेएसएक्स एक्सएमएल जैसा नहीं है)

यदि आप कहते हैं कि कोई मजबूत तर्क नहीं हैं, तो मैं आपसे एक प्रश्न पूछता हूं।
मैं अपनी बात यहीं समाप्त करता हूं। अगर लोग JSX या DSX कुछ भी चाहते हैं, तो भविष्य में भी ऐसा ही होगा।

• संदर्भ:
  https://facebook.github.io/jsx/
  This specification does not attempt to comply with any XML or HTML specification. JSX is designed as an ECMAScript feature and the similarity to XML is only for familiarity.

हालांकि मुझे एक्सएमएल से असली समापन टैग याद आते हैं :)
आइडिया: ऑटो जेनरेटेड क्लोजिंग टैग

कोटलिन ने इसे भी हल किया होगा। जरा देखिए कि कोटलिन-रिएक्शन और अंको कितने शानदार हैं

कोटलिन-प्रतिक्रिया इतनी भयानक नहीं है, केएसएक्स बेहतर होता :)

import React from 'react';

export function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

package hello

import react.*
import react.dom.*

fun RBuilder.hello(name: String) {
    h1 {
        +"Hello, $name"
    }
}

package hello

import react.*
import react.dom.*

fun RBuilder.hello(name: String) {
   <h1>Hello, {name}</h1>
}

टैग जस्ट डॉन|टी वहां के नहीं हैं :)

जेएसएक्स/डीएसएक्स/केएसएक्स शिविर में होने के नाते, मुझे निश्चित रूप से विश्वास है कि टैग कोड के अंदर हैं :)

@ सैयद89
क्या आप HTML की तरह ही किसी अन्य तत्व के अंदर किसी तत्व को नेस्ट करने के लिए टैग का उपयोग करना चाहते हैं? या आप "बच्चों", "बच्चे" या [] शब्द टाइप करना चाहते हैं? इसके अलावा, JSX केवल एक टैग टाइप करके सैकड़ों UI कोड का पुन: उपयोग करने जैसी चीज़ें प्रदान करता है।

शायद एक अन्य पहलू डिफ़ॉल्ट स्वरूपण है जो dart format करता है। आईएमएचओ विशेष रूप से अग्रणी बच्चे के साथ पढ़ना मुश्किल है:/बच्चों।

मैं वास्तव में कुछ स्वरूपण पसंद करूंगा जो वृक्ष संरचना पर कुछ इस तरह जोर देता है:

 Widget build(BuildContext context) {
    return new Scaffold(
      appBar: new AppBar(title: new Text("WeatherDemo")),
      resizeToAvoidBottomPadding: false,
      body: 
        new Column(children: <Widget>
        [
          new Padding(
            padding: const EdgeInsets.all(16.0),
            child: 
            new TextField(
                    key: AppKeys.textField,
                    autocorrect: false,
                    controller: _controller,
                    decoration: new InputDecoration(hintText: "Filter cities",),
                    style:  TextStyle(fontSize: 20.0,),
                    onChanged: ModelProvider.of(context).textChangedCommand,
                    ),
          ),
          new Expanded(
                child: 
                new RxLoader<List<WeatherEntry>>(
                        key: AppKeys.loadingSpinner,
                        radius: 25.0,
                        commandResults: ModelProvider.of(context).updateWeatherCommand,
                        dataBuilder: (context, data) => new WeatherListView(data ,key: AppKeys.weatherList),
                        ),
          ),
          new Padding(
            padding: const EdgeInsets.all(8.0),
            child: 
            new Row(children: <Widget>
            [
                new Expanded(
                    child: 
                    // This might be solved with a Streambuilder to but it should show `WidgetSelector`
                    new WidgetSelector(
                            buildEvents: ModelProvider.of(context).updateWeatherCommand.canExecute,   //We access our ViewModel through the inherited Widget
                            onTrue:  new RaisedButton(    
                                            key: AppKeys.updateButtonEnabled,                           
                                            child: new Text("Update"), 
                                            onPressed: ModelProvider.of(context).updateWeatherCommand,
                                            ),
                            onFalse:  new RaisedButton(                               
                                            key: AppKeys.updateButtonDisabled,                           
                                            child: new Text("Please Wait"), 
                                            onPressed: null,
                                            ),

                        ),
                ),
                new StateFullSwitch(
                        state: true,
                        onChanged: ModelProvider.of(context).switchChangedCommand,
                   )
              ],
            ),
          ),
        ],
      ),
    );
  }

यह आदर्श समाधान नहीं हो सकता है लेकिन इसे दिशा दिखानी चाहिए।
@sethladd उस दिशा में कुछ करने का कोई मौका?

सबसे पहले, मुझे खुशी है कि यह उतना गर्म नहीं हो रहा है जितना कि इसकी बहन का मुद्दा था: मुस्कान:।

अगर मुझे 2 सिंटैक्स में से कोई भी चुनने के लिए कहा जाता, तो मैं डार्ट की तरफ झुक जाता। यह कई तथ्यों पर आधारित है:

• मैं यथासंभव कुछ संदर्भों के बीच स्विच करना पसंद करता हूं। यह पसंद है या नहीं, सिंटैक्स के बीच कूदना ऐसा करने का एक तरीका है। टूलींग समर्थन के साथ इसकी मदद की जा सकती है लेकिन यह नीचे दिए गए बिंदु की ओर जाता है।
• मैं पसंद करता हूं कि विकास दल अन्य मुद्दों के लिए समय समर्पित करता है जो हमें कुछ विशेषताओं को कोड करने से रोकता है और/या लोगों को फ़्लटर में कूदने से रोकता है। मुझे लगता है कि JSX जैसा सिंटैक्स नहीं होने का कारण कंपनी/डेवलपर/फ्लटर को खारिज करने का कारण नहीं होना चाहिए।
• हमें हर डार्ट अपडेट से फायदा होगा। यह डार्ट के लिए विशेष रूप से सच है क्योंकि फ़्लटर इसके मुख्य ग्राहकों में से एक है और यह एक यूआई फ्रेमवर्क है। उदाहरण के लिए new/const परिवर्तन देखें।
• मैं टाइप-सेफ्टी को बहुत महत्व देता हूं। यह नहीं कहना कि JSX जैसा सिंटैक्स सुरक्षित नहीं हो सकता है, मुझे विश्वास नहीं है कि इसे पूरा करने का प्रयास इसके राजस्व के लायक है।

इसके अलावा, मैं वास्तव में कोटलिन-जैसे सिंटैक्स का पक्ष लेता हूं। विशेष रूप से अगर कहा गया वाक्यविन्यास कुछ कोटलिन सुविधाओं को डार्ट पर लाता है: मासूम:।

@emalamela ,

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

मुझे लगता है कि JSX जैसा सिंटैक्स नहीं होने का कारण कंपनी/डेवलपर/फ्लटर को खारिज करने का कारण नहीं होना चाहिए।

लेकिन दुर्भाग्य से यह बहुत सारे रिएक्ट डेवलपर्स के लिए होगा।

हमें हर डार्ट अपडेट से फायदा होगा।

मैं नहीं देखता कि कैसे DSX को डार्ट अपडेट से भी लाभ नहीं होता है क्योंकि यह डार्ट का सुपरसेट है।

मैं टाइप-सेफ्टी को बहुत महत्व देता हूं। यह नहीं कहना कि JSX जैसा सिंटैक्स सुरक्षित नहीं हो सकता है, मुझे विश्वास नहीं है कि इसे पूरा करने का प्रयास इसके राजस्व के लायक है।

DSX में टाइप सेफनेस को पूरा करने का प्रयास शून्य है क्योंकि DSX डार्ट के ऊपर सिर्फ एक छोटी सी सिंटेटिक शुगर लेयर है, इसलिए यह डार्ट टाइप सिस्टम का उपयोग करता है जैसे यह डार्ट कंट्रोल स्टेटमेंट आदि का उपयोग करता है।
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

आपके इनपुट के लिए धन्यवाद @cbazza !

यहाँ बात है, कोई संदर्भ स्विच नहीं है जैसा कि आप इसे कहते हैं, बस किसी भी अनुभवी रिएक्ट डेवलपर से पूछें।

मैं कोई अनुभवी रिएक्ट डेवलपर नहीं हूं इसलिए मेरे लिए यह एक संदर्भ स्विच है। जैसे एंड्रॉइड में आपको जावा/कोटलिन से एक्सएमएल में कूदना पड़ता है, हालांकि वहां छलांग बड़ी होती है। एक भाषा, वही टूलींग, कम ओवरहेड।

साथ ही यह वाक्य रचना पृथक्करण वास्तव में एक महान विशेषता है क्योंकि जब आप कोड को देखते हैं तो आप आसानी से देख सकते हैं कि क्या घोषणात्मक है और क्या अनिवार्य है।

जिस तरह से अब यह मेरी राय में काफी घोषणात्मक है।

मैं नहीं देखता कि कैसे DSX को डार्ट अपडेट से भी लाभ नहीं होता है क्योंकि यह डार्ट का सुपरसेट है।
DSX में टाइप सेफनेस को पूरा करने का प्रयास शून्य है क्योंकि DSX डार्ट के ऊपर सिर्फ एक छोटी सी सिंटेटिक शुगर लेयर है, इसलिए यह डार्ट टाइप सिस्टम का उपयोग करता है जैसे यह डार्ट कंट्रोल स्टेटमेंट आदि का उपयोग करता है।

उचित अंक। लेकिन DSX को अभी भी बनाए रखा जाना और सुधारना बाकी है, जो अभी भी प्रयास का तात्पर्य है कि मैं पारिस्थितिकी तंत्र के अन्य अधिक महत्वपूर्ण / अभाव वाले पहलुओं पर ध्यान केंद्रित करना चाहता हूं।

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

जहाँ तक मेरा सवाल है, अगर किसी डेवलपर ने DSX/JSX समर्थित नहीं होने के कारण फ़्लटर में विकास नहीं करना चुना, तो वह व्यक्ति फ़्लटर में बिल्कुल भी शामिल नहीं होना चाहता था।

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

क्योंकि रिएक्ट में अंतराल है जिसे फ़्लटर भर सकता है और फिर आप कुछ ऐसा बनाते हैं जो रिएक्ट से बेहतर होता है क्योंकि यह रिएक्ट के सबसे अच्छे हिस्सों के साथ-साथ परिचित होने के साथ-साथ डार्ट के प्रदर्शन और जीपीयू त्वरित ग्राफिक्स के साथ रिएक्ट के नुकसान को ठीक करता है।

जहाँ तक मेरा सवाल है, अगर किसी डेवलपर ने DSX/JSX समर्थित नहीं होने के कारण फ़्लटर में विकास नहीं करना चुना, तो वह व्यक्ति फ़्लटर में बिल्कुल भी शामिल नहीं होना चाहता था।

इससे कोई फर्क नहीं पड़ता, अंतिम परिणाम यह है कि यदि मोबाइल डेवलपर्स जो क्रॉस प्लेटफॉर्म टूल का उपयोग कर रहे हैं, वे फ़्लटर में शामिल नहीं होते हैं, तो फ़्लटर बाज़ार में विफल हो जाएगा। इसलिए स्पंदन को अपने अस्तित्व के लिए रिएक्ट नेटिव डेवलपर्स को आकर्षित करने की आवश्यकता है।

विकास की बात करें तो यह 'सर्वाइवल ऑफ द फिटेस्ट' नहीं है, यह 'सर्वाइवल ऑफ द मोस्ट एडैप्टेबल' है। अनुकूलन करें या आप नष्ट हो जाएं।

@cbazza

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

क्या? इसकी आवश्यकता क्यों होगी? स्पंदन बीटा में रहते हुए अपना खुद का स्थान बना सकता है (जैसा कि इसने बहुत सफलतापूर्वक किया है), और फिर सतही रूप से समान विशेषताओं वाले पतंगों को आकर्षित करने की आवश्यकता के बिना व्यवस्थित रूप से विकसित होता है। इसके अलावा आपका क्या मतलब है "असफल"? स्पंदन को सफल होने के लिए लोकप्रिय होने की आवश्यकता नहीं है।

@naiveaiguy
देखिए, मुझे पता है कि आपने cbazza के उत्तरों को कम कर दिया है।
लेकिन क्या आप मेरे जवाब को कम करने से पहले इसे देखने के लिए 15 सेकंड खर्च कर सकते हैं?

इससे पहले कि आप DSX के बारे में सोचें।
जरा नीचे देखें, यह सिर्फ एक JSX है।

एक नेविगेशन बार और एक बॉडी बनाने के बाद, आप बस अपने नेवी बार कोड से एनएवी बार कोड आयात कर सकते हैं।

import XXXXX, { Component } from 'XXXXX';
import { Text, View } from 'XXXXX-native';
import navbar from "your code1"
import body from "your code2"

class SomethingFast extends Component {
  render() {
    return (
      <View>
        <navbar
            style={{width: 360, height:90}}
         />
        <Image
          source={{uri: 'https://google.com/dsx.jpg/'}}
          style={{width: 320, height:180}}
        />
        <body/>
        <Text>
          Look at <strong i="11">@escamoteur</strong> s code from above.
           Can you export part of UI code to another place,
           separate it into different modules, and read everything in few seconds or less?
        </Text>
      </View>
    );
  }
}

       I think cbazza is right.
       If flutter uses DSX or whatever that is JSX,
       it is a perfect UI framework.

       So, could we have something
       similar or better in the future?
       Or do you really think that the
       current is fine?

हो सकता है कि किसी को JSX से नफरत हो क्योंकि यह फेसबुक से है, लेकिन वास्तव में, यह एक छोटी जापानी गेम कंपनी से है।

रिएक्ट नेटिव और स्पंदन के साथ ऐप करने के बाद, मुझे लगता है कि वर्तमान स्थिति में शुद्ध नेस्टेड डार्ट कक्षाओं की तुलना में JSX को पढ़ना और समायोजित करना आसान है।
हालाँकि, जैसा कि पहले उल्लेख किया गया है, फेसबुक के पास JSX का उपयोग करने का एक कारण था कि जावास्क्रिप्ट कैसे लिखा जाता है (उदाहरण के लिए कोई नामित कंस्ट्रक्टर पैरामीटर नहीं) जो कि डार्ट के मामले में नहीं है। इसके अलावा जोड़ा गया डार्ट प्रकार-सुरक्षा वास्तव में अच्छी है!
इसलिए यदि स्पंदन अंत में शुद्ध डार्ट सिंटैक्स से चिपक जाता है, तो मुझे सिंटैक्स हाइलाइटर और ऑटो फॉर्मेटर के साथ सुधार देखने की उम्मीद है। नई क्लोजिंग टैग टिप्पणियाँ पहले से ही एक बड़ा सुधार हैं लेकिन JSX उत्पादकता तक पहुँचने के लिए पर्याप्त नहीं हैं।

@JonathanSum आप पुन: प्रयोज्य घटकों के विचार की व्याख्या कर रहे हैं। पुन: प्रयोज्य घटकों को करने के लिए आपको JSX की आवश्यकता नहीं है। मुझे लगता है कि डार्ट के सिंटैक्स को परिष्कृत करके कुछ बेहतर हो सकता था, लेकिन डीएसएक्स इसके बारे में जाने का एक अच्छा तरीका नहीं है।

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

आईएमएचओ ने new/const का उपयोग करने की आवश्यकता को हटाकर पहले ही बहुत मदद की है। जिस तरह से डार्ट प्रारूप पेड़ों को प्रारूपित करता है, उसमें मुझे वास्तविक कठिनाइयाँ होती हैं। यह पेड़ संरचना IMHO की तुलना में पर्याप्त जोर नहीं देता है:

    return Scaffold(
      appBar: AppBar(title: Text("WeatherDemo")),
      resizeToAvoidBottomPadding: false,
      body: 
        Column(children: <Widget>
        [
          Padding(
            padding: const EdgeInsets.all(16.0),
            child: 
            TextField(
                    key: AppKeys.textField,
                    autocorrect: false,
                    controller: _controller,
                    decoration: InputDecoration(hintText: "Filter cities",),
                    style:  TextStyle(fontSize: 20.0,),
                    onChanged: ModelProvider.of(context).textChangedCommand,
                    ),
          ),

https://reactjs.org/docs/introducing-jsx.html

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

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

@woodstream जिस तरह के लोग JSX का उपयोग करने के लिए उत्सुक हैं, वे पहले से ही रिएक्ट फैनबॉय के प्रशंसक हैं। वे पहले से ही रिएक्ट नेटिव का उपयोग कर रहे हैं। स्पंदन एक बहुत ही अलग प्रकार के डेवलपर की पूर्ति कर रहा है।

संपादित करें : मैं मानता हूं कि मेरे फैनबॉय का उपयोग यहां गलत था।

@naiveaiguy , @Hixie

जिस तरह के लोग JSX का उपयोग करने के लिए उत्सुक हैं, वे पहले से ही रिएक्ट फैनबॉय हैं। वे पहले से ही रिएक्ट नेटिव का उपयोग कर रहे हैं। स्पंदन एक बहुत ही अलग प्रकार के डेवलपर की पूर्ति कर रहा है।

आप गलत हैं और आपका नाम विभाजनकारी टिप्पणी करना ('प्रतिक्रिया फैनबॉय' और 'विभिन्न प्रकार के डेवलपर') अवांछित हैं। JSX/DSX में तकनीकी योग्यता है और अन्य इसे पसंद करते हैं। यह थ्रेड इस बात पर चर्चा करने के लिए है कि, यदि आपको यह पसंद नहीं है, तो इसे अनसब्सक्राइब करें। मेरी हर एक टिप्पणी को डाउन-वोट करना भी बंद कर दें, यह आपके लिए अच्छा नहीं है।

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

@ एंडर्स-सैंडहोम मैं विजेट ट्री की दृश्यता बढ़ाने की आवश्यकता के बारे में @escamoteur से सहमत हूं। मैंने उसका उदाहरण निम्नलिखित की तरह किया होगा:

return
      Scaffold(
          appBar: AppBar(title: Text("WeatherDemo")),
          resizeToAvoidBottomPadding: false,
          body:
        Column(children: <Widget> [
          Padding(
              padding: const EdgeInsets.all(16.0),
              child:
            TextField(
                key: AppKeys.textField,
                autocorrect: false,
                controller: _controller,
                decoration: InputDecoration(hintText: "Filter cities",),
                style:  TextStyle(fontSize: 20.0,),
                onChanged: ModelProvider.of(context).textChangedCommand,
            ),
          ),
        ])
      );

इसके अलावा मैं एक अलग रंग, फ़ॉन्ट शैली या वजन के साथ विजेट वर्ग के नामों को हाइलाइट करने की कल्पना कर सकता हूं ताकि यह तुरंत और भी पहचानने योग्य हो।

@cbazza

नाम पुकारना? मेरा मतलब यह नहीं था कि ये लोग नकारात्मक थे, केवल यह कि वे अलग थे। मुझे यह धागा पसंद है लेकिन मुझ पर बुरे विश्वास में बहस करने का आरोप लगाना थोड़ा विडंबनापूर्ण है।

शब्द "फैनबॉय" को आम तौर पर अपमानजनक माना जाता है, और इस संदर्भ में भी इसे लिया गया था। मैं यहां चर्चाओं में इस तरह के शब्दों से बचने की सलाह देता हूं।

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

@hartmannj

बस कुछ मामूली स्पष्टीकरण ...

हालाँकि, जैसा कि पहले उल्लेख किया गया है, फेसबुक के पास JSX का उपयोग करने का एक कारण था कि जावास्क्रिप्ट कैसे लिखा जाता है (उदाहरण के लिए कोई नामित कंस्ट्रक्टर पैरामीटर नहीं) जो कि डार्ट के मामले में नहीं है।

दरअसल ES2015/ES6 के बाद से, JS ने पैरामीटर्स को नाम दिया है; आप इसके लिए बस 'डी-स्ट्रक्चरिंग' का उपयोग कर सकते हैं :)
यहाँ एक उदाहरण है:

// function declaration
function findUsersByRole ({
  role,
  withContactInfo, 
  includeInactive
}) {
  if (role === 'admin' && withContactInfo) {
  ...
  }
...
}


// usage
findUsersByRole({
  role: 'admin', 
  withContactInfo: true, 
  includeInactive: true
})

https://medium.freecodecamp.org/elegant-patterns-in-modern-javascript-roro-be01e7669cbd

इसके अलावा जोड़ा गया डार्ट प्रकार-सुरक्षा वास्तव में अच्छी है!

आपको DSX के साथ समान प्रकार की सुरक्षा मिलती है, जो वास्तव में अच्छा है।

चूंकि यह पहले से रिपोर्ट किए गए https://github.com/flutter/flutter/issues/11609 का डुप्लिकेट है, इसलिए मैं इसे उसके पक्ष में बंद करने जा रहा हूं।

मैं वास्तव में यह नहीं समझता कि लोग इसके खिलाफ कैसे मतदान कर सकते हैं- कुछ ऐसा जो इंटरनेट युग में घोषणात्मक कोड लिखे जाने के तरीके से दूसरी प्रकृति है।

<like><this /></like>

स्पंदन को उड़ने का मौका देने के लिए कृपया पर्याप्त लचीला बनें!

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

हमें इसे करने की ज़रूरत नहीं है जैसे प्रतिक्रिया देशी या एचटीएमएल, बस साधारण एक्सएमएल का उपयोग करें

और शायद... एक्सएमएल डार्ट में एम्बेडेड! ;पी

मंगलवार, 28 अगस्त 2018 को 21:29 बजे, Touseef [email protected] ने लिखा:

हमें इसे करने की ज़रूरत नहीं है जैसे प्रतिक्रिया देशी या एचटीएमएल, बस साधारण एक्सएमएल का उपयोग करें

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/flutter/flutter/issues/15922#issuecomment-416550338 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AC8aNdVb_NV8c8JH4t36OS1OOvX6kY58ks5uVSmjgaJpZM4S6HPa
.

--
टोनी पोलिनेलि

मेरे लिए JSX जैसी कार्यक्षमता भविष्य है और यह रिएक्ट, वू और स्पंदन जैसे घोषणात्मक ढांचे के लिए एक मानक निर्माण बन जाएगा।

हमें डार्ट में एक्सएमएल एम्बेड करने की आवश्यकता नहीं है अगर हमारे पास यूआई और तर्क के लिए सिर्फ 2 अलग-अलग फाइलें हो सकती हैं तो हम आसानी से एमवीवीएम, एमवीसी या किसी अन्य वांछित पैटर्न का पालन कर सकते हैं।

मैंने इसे दूसरे सूत्र में कहा है लेकिन:

यदि आप वास्तव में JSX चाहते हैं, तो एक अच्छा स्टार्टर कोड जनरेशन का उपयोग कर रहा है। .html या .xml फ़ाइल के साथ जाएं और इनसे विजेट बनाएं।

जाहिर है, यह एक पूर्ण JSX नहीं है, लेकिन यह एक शुरुआत है। यह देखने के लिए पर्याप्त है कि समुदाय इस पर क्या प्रतिक्रिया देगा।
यदि वह सिंटैक्स कर्षण प्राप्त करता है, तो शायद फ़्लटर टीम विषय पर पुनर्विचार करेगी।

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

यदि स्पंदन परिचय देता है और एक्सएमएल/जेएसएक्स/इसे कॉल करता है जो आप यूआई बनाने का तरीका चाहते हैं तो मैं इसे दिल की धड़कन में उत्पादन स्तर के ऐप्स के लिए उपयोग करना शुरू कर दूंगा!

मैं सहमत हूं @leossmith tht ही उत्पादन स्तर के ऐप्स के लिए एक बाधा है।

मैं व्यक्तिगत रूप से _not_ JSX या बाहरी मार्कअप भाषा जोड़ना पसंद करूंगा। मैं सब कुछ एक ही प्रकार की जाँच की गई भाषा में रखना पसंद करता हूँ। मुझे लगता है कि एक बेहतर तरीका यह है कि डीप नेस्टेड डिक्लेरेटिव यूआई ट्री को कोड करने के उद्देश्य से डार्ट भाषा में सुधार जारी रखा जाए। उन्होंने पहले ही इस क्षेत्र में कुछ अच्छी सुविधाएं जोड़ दी हैं:

• new और const कीवर्ड को वैकल्पिक बनाने से मदद मिलती है।
• IDE में वर्चुअल क्लोजिंग टैग
• dartfmt भी मदद करता है

मैं सब कुछ एक ही प्रकार की जाँच की गई भाषा में रखना पसंद करता हूँ

ठीक यही DSX/JSX करता है, भाषा DSX के लिए डार्ट है, JSX के लिए जावास्क्रिप्ट !!!

मुझे लगता है कि एक बेहतर तरीका यह है कि डीप नेस्टेड डिक्लेरेटिव यूआई ट्री को कोड करने के उद्देश्य से डार्ट भाषा में सुधार जारी रखा जाए।

DSX, डीप नेस्टेड डिक्लेरेटिव ट्री का बेहतर समर्थन करने के लिए डार्ट भाषा में सुधार है। जैसे JSX जावास्क्रिप्ट के लिए है।

https://facebook.github.io/jsx/

इस विनिर्देश का उद्देश्य विशेषताओं के साथ वृक्ष संरचनाओं को परिभाषित करने के लिए एक संक्षिप्त और परिचित वाक्यविन्यास को परिभाषित करना है।

@cbazza आप एक अच्छी बात उठाते हैं। JSX जावास्क्रिप्ट में न्यायसंगत और सुधार है।

तो आइए पहले दो चीजों को स्पष्ट रूप से अलग करें:

1. UI को परिभाषित करने के लिए बाहरी DSL। मैं इसके खिलाफ 100% हूं। मेरा हमेशा से मानना ​​रहा है कि इससे हल होने से ज्यादा समस्याएं पैदा होती हैं। मैंने इस बिंदु पर बहस करते हुए एक ब्लॉग पोस्ट लिखा था। इसे 58 हजार बार देखा गया और आश्चर्यजनक रूप से, लगभग कोई असहमतिपूर्ण राय नहीं: मेरी 80% कोडिंग यह कर रही है (या टेम्प्लेट मर क्यों रहे हैं)
2. भाषा सुधार। गहराई से नेस्टेड UI ट्री संरचनाओं का निर्माण और कल्पना करना आसान बनाने के लिए। इस पर हम दोनों सहमत हैं कि इसमें सुधार की गुंजाइश है।

लेकिन हम दृष्टिकोण पर थोड़ा भिन्न हैं। JSX के रिएक्ट के लिए अधिक समझ में आने के दो कारण हैं:

1. डेटा संरचना: वेब पर, JSX उत्पन्न होने वाली चीज़ (HTML DOM नोड्स) से बिल्कुल मेल खाता है। स्पंदन में, हम विजेट उदाहरण उत्पन्न कर रहे हैं।
2. परिचित: लोग html कोड देखने के आदी हैं। लेकिन DSX प्रस्ताव JSX/XML से इस बिंदु को अमान्य करने के लिए पर्याप्त है।

नीचे दो चीजें हैं (मुझे विश्वास है) जो यूआई पेड़ बनाने के लिए एक्सएमएल को अच्छा (और पठनीय) बनाती हैं। सवाल यह है कि क्या एक्सएमएल को भाषा में पेश किए बिना इन्हें हासिल किया जा सकता है:

1. एक्सएमएल में एंड टैग हैं। यह xml-ish सिंटैक्स के साथ या उसके बिना संभव है। विजुअल बेसिक में यह 90 के दशक में था (थिंक एंड इफ)। और अन्य भाषाओं के पास है। आईडीई "वर्चुअल एंड टैग" प्रदान करता है लेकिन यह एक प्रकार का स्केच है। मैं भाषा समर्थन पसंद करूंगा।
2. एक्सएमएल में बच्चों के साथ विशेष व्यवहार किया जाता है। गुण बच्चों से भिन्न होते हैं। लेकिन मैं तर्क दूंगा कि यह एक दोधारी तलवार है। ऐसे कुछ मामले हैं जहां इस संबंध में डार्ट वास्तव में एक्सएमएल की तुलना में अधिक स्पष्ट और अभिव्यंजक है। उदाहरण के लिए, अलग-अलग चाइल्ड सामग्री मॉडल वाले कंटेनर विजेट:

MyWidgetA(children: [ w1, w2 ])
MyWidgetB(child: w1)
MyWidgetC(top: w1, bottom: w2)

एंड टैग समस्या के लिए डेव प्रस्ताव

ButtonsView(
        onDeal: onDeal,
        onHit: onHit,
        onStay: onStay,
)ButtonsView

यह मनुष्यों द्वारा पढ़ना आसान होगा। और एक पार्सर सिर्फ )ButtonsView को ) से बदल देगा। साथ ही, आईडीई इस योजना के साथ बेहतर जाँच और सहायता प्रदान कर सकता है। मैं किसी भी समय खुले और करीबी माता-पिता एक ही लाइन पर नहीं होने पर इसे आवश्यक बनाउंगा।

नेस्टेड बच्चों की समस्या के लिए डेव प्रस्ताव

कुछ भाषाएं (जैसे कोटलिन) लैम्ब्डा प्रकार के आर्ग के लिए विशेष उपचार की अनुमति देती हैं। वे आपको लैम्ब्डा तर्क को माता-पिता के बाहर रखने की अनुमति देते हैं। लैम्ब्डा को अंतिम पैरामीटर में पास करना देखें।

मैं डार्ट के लिए कुछ इसी तरह का प्रस्ताव करता हूं, लेकिन प्रकार की सूची के तर्क के रूप में, लैम्ब्डा के लिए नहीं। मैं "बच्चों" नामक प्रकार की सूची के तर्क को पारित करने के लिए विशेष वाक्यविन्यास का प्रस्ताव करता हूं:

```
//इसके अलावा:
फू (ए: 1, बी: 10, सी: 44, बच्चे: [...])

// हम यह करते हैं:
फू (ए: 1, बी: 10, सी: 44) [

]

एक कंस्ट्रक्टर/कार्यों के लिए जो एक एकल बच्चे या 2 बच्चे (जैसे ऊपर और नीचे) लेते हैं, इसे वैसे ही छोड़ दें, कोई बदलाव नहीं।

मैं सब कुछ एक ही प्रकार की जाँच की गई भाषा में रखना पसंद करता हूँ

ठीक यही DSX/JSX करता है, भाषा DSX के लिए डार्ट है, JSX के लिए जावास्क्रिप्ट !!!

मुझे लगता है कि एक बेहतर तरीका यह है कि डीप नेस्टेड डिक्लेरेटिव यूआई ट्री को कोड करने के उद्देश्य से डार्ट भाषा में सुधार जारी रखा जाए।

DSX, डीप नेस्टेड डिक्लेरेटिव ट्री का बेहतर समर्थन करने के लिए डार्ट भाषा में सुधार है। जैसे JSX जावास्क्रिप्ट के लिए है।

https://facebook.github.io/jsx/

इस विनिर्देश का उद्देश्य विशेषताओं के साथ वृक्ष संरचनाओं को परिभाषित करने के लिए एक संक्षिप्त और परिचित वाक्यविन्यास को परिभाषित करना है।

@StokeMasterJack - अंत टैग समस्या के लिए आपका प्रस्ताव कुछ समय पहले मेरे प्रस्ताव जैसा ही लगता है।
आइडिया: ऑटो जेनरेटेड क्लोजिंग टैग

मुझे लगता है कि स्पंदन को कुछ इस तरह की जरूरत है। मैं ज्यादातर दिनों एक गहरे घोंसले के अंदर नए विजेट डालने के लिए संघर्ष करता हूं। मैं केवल अंत टैग नोटेशन प्राप्त करने के लिए एक जेएसएक्स-जैसी वाक्यविन्यास का उपयोग करूंगा।

मैं क्लोजिंग टैग नहीं लिखना चाहता। यह जेएसएक्स/एचटीएमएल/एक्सएमएल में दर्द है। खासकर जब मैं रिफैक्टर करना चाहता हूं।
मुझे लगता है कि वर्चुअल क्लोजिंग टैग बहुत साफ हैं। ऐसा लगता है कि दोनों दुनिया के बीच एक अच्छा समझौता है।

अगर हमें वास्तव में यहां कुछ सुधारों की आवश्यकता है तो मुझे लगता है कि हम आईडीई पक्ष पर खोज जारी रख सकते हैं। उदाहरण के लिए, vscode निम्नलिखित पैनल प्रदान करता है:

(निश्चित रूप से एंड्रॉइड स्टूडियो में समान है)

फोकस्ड मेथड पर रुकने के बजाय, हम कंस्ट्रक्टर्स नेस्टिंग भी जोड़ सकते हैं।
ताकि किसी विशिष्ट वर्ग को मँडराते समय हमें निम्नलिखित UI प्राप्त हो:

lib > main.dart > Foo > build > Container > Center > Text 

यदि यह नेत्रहीन विजेट को अन्य प्रकार की सामग्री से अलग करने के बारे में है, तो आईडीई इसे फिर से कर सकता है।

हमारे पास विजेट्स के लिए एक अलग सिंटैक्स हाइलाइटिंग हो सकती है। कक्षाओं के लिए उपयोग किए जाने वाले सामान्य रंग के बजाय, हमारे पास विजेट उपवर्ग के लिए एक विशिष्ट रंग हो सकता है

यदि यह संपादन क्षमता के बारे में है, तो फ़्लटर पहले से ही आपके लिए आवश्यक सभी टूलिंग प्रदान करता है।

काफी कुछ रिफैक्टरिंग विकल्प हैं, जिनमें शामिल हैं:

• नए विजेट में लपेटें
• विजेट हटाएं
• बच्चे के साथ विजेट स्वैप करें
• माता-पिता के साथ विजेट स्वैप करें

इन्हें ध्यान में रखते हुए, आपको अब कोष्ठकों से निपटने की आवश्यकता नहीं है।

पूरी ईमानदारी से, मैंने महीनों तक फ़्लटर के आसपास खेलने के लिए दैनिक आधार पर घंटों बिताए। और मुझे नेस्टेड विगेट्स लिखने में पठनीयता या किसी भी असुविधा में कोई कमी महसूस नहीं हुई है।
तुलना करते हुए, मैंने रिएक्ट का उपयोग उतना ही किया है और वहाँ _are_ कुछ चीजें हैं जो मुझे निराश करती हैं।

@rrousselGit - वे रिफैक्टरिंग विकल्प जो आपके लिए उपयोगी हैं। मैं उन्हें एंड्रॉइड स्टूडियो 3.2 पर नहीं देखता हूं।
मैंने सोचा था कि एंड्रॉइड स्टूडियो स्पंदन विकास के लिए सबसे अच्छी सुविधाएं प्रदान करेगा।

@ रॉकवोल

यहाँ Android स्टूडियो से एक स्क्रीनशॉट है:

एक त्वरित सुधार Option+Enter (macOS) के रूप में सक्रिय।
मैं हर समय इनका उपयोग करता हूं, सुपर मददगार।

विषय पर: ऐसा लगता है कि फ़्लटर टीम "यूआई कोड के रूप में" के लिए विकल्प तलाश रही है और हमें इस मोर्चे पर जल्द या बाद में और सुधार मिल सकते हैं। हालांकि @StokeMasterJack के विचार दिलचस्प लगते हैं।

@Rockvole महान दिमाग एक जैसे सोचते हैं!

@StokeMasterJack

अच्छा जवाब !!!

JSX के रिएक्ट के लिए अधिक समझ में आने के दो कारण हैं:

1. डेटा संरचना: वेब पर, JSX उत्पन्न होने वाली चीज़ (HTML DOM नोड्स) से बिल्कुल मेल खाता है। स्पंदन में, हम विजेट उदाहरण उत्पन्न कर रहे हैं।

JSX की शक्ति HTML/DOM नोड्स उत्पन्न करने पर नहीं है, यह घटक पदानुक्रमों के प्रबंधन में है; प्रतिक्रिया मूल निवासी के पास HTML/DOM नोड्स सही नहीं हैं?

1. परिचित: लोग html कोड देखने के आदी हैं। लेकिन DSX प्रस्ताव JSX/XML से इस बिंदु को अमान्य करने के लिए पर्याप्त है।

ऊपर की तरह, यह HTML कोड के बारे में नहीं है, यह एक सिंटैक्स के बारे में है जो स्पष्ट रूप से मेजबान भाषा के अनिवार्य निर्माणों से अलग हो जाता है और ट्री पदानुक्रम के निर्माण के लिए घोषणात्मक मार्कअप चिल्लाता है ।

मैं आपके प्रस्ताव या कोटलिन का प्रशंसक नहीं हूं क्योंकि यह एक उचित डिजाइन करने से बचने के लिए किया गया हैक जैसा दिखता है। एक अलग दिखने वाले डीएसएल को डिजाइन करने के बजाय, अब मुझे कोड को देखना होगा और यह पता लगाने की कोशिश करनी होगी कि यह क्या करता है; वाक्यविन्यास अस्पष्ट दिखता है। अनिवार्य और घोषणात्मक निर्माणों को अलग करने के लाभ हैं; उदाहरण के लिए, तृतीय पक्ष टूल कोड के अंदर XML मार्कअप का आसानी से पता लगा सकते हैं।

@ रॉकवोल

मैं केवल एंड टैग नोटेशन प्राप्त करने के लिए JSX-जैसे सिंटैक्स का उपयोग करूंगा

जानकर अच्छा लगा ;)

@rrousselGit

मैं क्लोजिंग टैग नहीं लिखना चाहता।

आपको नहीं करना है; वेबस्टॉर्म उदाहरण के लिए ऑटो क्लोजिंग टैग जेनरेट करता है और जब आप दूसरे को एडिट करते हैं तो यह ओपन या क्लोजिंग टैग का नाम भी बदल देता है। वास्तव में महान संपादक कार्यक्षमता जिसका दूसरों को पालन करना चाहिए (आपको 'वीएस कोड' देखकर)।

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

मुझे आशा है कि आप इस बात की सराहना कर सकते हैं कि आपका अनुभव हर किसी के अनुभव को नहीं दर्शाता है। टूलींग के साथ, कोड को पढ़ने के रूप में लिखना उतना दर्दनाक नहीं है। अन्य लोगों के कोड को पढ़ने के लिए जीथब पर जाएं और आप देखेंगे कि पढ़ना एक दर्द है, कोड बहुत क्रियात्मक है और नेस्टेड संरचनाओं के साथ लंबा है। ऐसा लगता है कि जब एसिंक/प्रतीक्षा से पहले वादा-श्रृंखला का उपयोग बेहतर तरीका दिखाया गया था। साथ ही ऐसा लगता है कि घोषणात्मक तकनीक अनिवार्य लोगों की तुलना में कम महत्वपूर्ण हैं; मेरा मतलब है कि घोषणात्मक वेक्टर ग्राफिक्स संरचनाएं क्यों नहीं हैं? इसके बजाय मुझे उदाहरण के लिए वेक्टर ग्राफिक्स ड्राइंग के लिए स्कीया को अनिवार्य कॉल का उपयोग करना होगा।

आपको नहीं करना है; वेबस्टॉर्म उदाहरण के लिए स्वतः उत्पन्न होता है

Vscode वह भी करता है। लेकिन यह अभी भी सही नहीं है। विशेष रूप से चीजों को घुमाते समय रिफैक्टरिंग चरण में।
मुझे लगता है कि वर्चुअल टैग यहां बहुत आसान अनुभव प्रदान करते हैं।

मुझे आशा है कि आप इस बात की सराहना कर सकते हैं कि आपका अनुभव हर किसी के अनुभव को नहीं दर्शाता है

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

अन्य लोगों के कोड को पढ़ने के लिए जीथब पर जाएं और आप देखेंगे कि पढ़ना एक दर्द है, [...]

मैं यह नहीं देखता कि यहाँ आपके तर्क विषय से कैसे संबंधित हैं।
आपके द्वारा सूचीबद्ध समस्या खराब प्रथाओं से आती है, खराब वाक्यविन्यास से नहीं। अगर लोग 500 लंबा विजेट ट्री बनाना चाहते हैं तो यह फ़्लटर की गलती नहीं है।

@pulyaevskiy - उपयोगी टिप के लिए धन्यवाद, लिनक्स पर त्वरित सुधार Alt-Enter है। खोजने के लिए बहुत आसान सुविधा नहीं है, मैंने शीर्ष मेनू विकल्पों को परिमार्जन किया है, लेकिन ऐसा लगता है कि यह जादुई कीप्रेस के अलावा कहीं नहीं है :)

मुझे लगता है कि वर्चुअल टैग यहां बहुत आसान अनुभव प्रदान करते हैं।

क्या ये वर्चुअल टैग उदाहरण के लिए जीथब में स्रोत फ़ाइल पर दिखाई देते हैं?

मैं यह नहीं देखता कि यहाँ आपके तर्क विषय से कैसे संबंधित हैं।

मूल रूप से भाषा चीजों को कम क्रियात्मक बनाने के लिए निर्माण प्रदान कर सकती है जैसा कि मैंने वादों बनाम async/प्रतीक्षा उदाहरण में उल्लेख किया है। स्पंदन विजेट में कंस्ट्रक्टर बहुत बड़े होते हैं और कई बार वे बहुत सारे पैरामीटर लेते हैं; DSX के साथ आप स्प्रेड ऑपरेटर का उपयोग कर सकते हैं उदाहरण के लिए 10 लाइन कंस्ट्रक्टर को 1 लाइन कंस्ट्रक्टर में संपीड़ित करने के लिए और इसलिए आप अभी भी इसके चारों ओर कम शोर के साथ पूर्ण ट्री पदानुक्रम दिखाई दे सकते हैं। यह कोड को पढ़ना आसान बनाता है और उदाहरण के लिए पेड़ की संरचना से शैली को अलग करने की अनुमति देता है। मैं यह नहीं कह रहा हूं कि यह आपके डार्ट कोड को फिर से संरचित करके नहीं किया जा सकता है, लेकिन यह बिना किसी प्रयास या चीजों को फिर से संरचित किए बिना किया जा सकता है। आपको भाषा की सीमाओं में फिट होने की आवश्यकता नहीं है, भाषा आपके लिए उपयुक्त है।

आपके द्वारा सूचीबद्ध समस्या खराब प्रथाओं से आती है, खराब वाक्यविन्यास से नहीं।

एसिंक्स/प्रतीक्षा से पहले, हर जगह क्रेजी इवेंट कॉलबैक के बजाय वादों का उपयोग करने के लिए सर्वोत्तम अभ्यास थे। वादों का उपयोग करने से पठनीयता की समस्याएं होती हैं जिन्हें async/प्रतीक्षा द्वारा संबोधित किया गया था। यह मूल रूप से सिंटैक्टिक चीनी जैसा ही है लेकिन किसी और के कोड को पढ़ने पर एसिंक/प्रतीक्षा स्पष्ट है।

यह एक भयानक उदाहरण है @ वुडस्ट्रीम

अपडेट : सिर्फ अपनी बात रखने के लिए और बिना किसी तर्क के सिर्फ शब्दों को कोसने के लिए नहीं। DSX समतुल्य उतना ही लंबा है... इसका लाइन काउंट या HTML से कोई लेना-देना नहीं है।

class MusicImage extends StatelessWidget {

  TextStyle titleTextStyle = TextStyle(
    fontWeight: FontWeight.w800,
    letterSpacing: 0.5,
    fontSize: 20.0
  );

  Container titleText = (
    <Container height={116.0} padding={EdgeInsets.all(10.0)}>
      <Text style={titleTextStyle}>title</Text>
    </Container>
  );

  TextStyle authorTextStyle = TextStyle(
    fontWeight: FontWeight.w800,
    letterSpacing: 0.5,
    fontSize: 10.0,
  );

  Container music = (
    <Container
      height={40.0}
      decoration={BoxDecoration(
        color: Colors.white,
        borderRadius: BorderRadius.all(Radius.circular(8.0))
      )}
      padding={EdgeInsets.fromLTRB(0.0, 5.0, 5.0, 0.0)}
      margin={EdgeInsets.fromLTRB(8.0, 0.0, 8.0, 0.0)}
    >
      <Stack>
        <Row>
          <Container
            height={30.0}
            width={30.0}
            decoration={BoxDecoration(
              borderRadius: BorderRadius.all(Radius.circular(8.0))
            )}
            margin={EdgeInsets.fromLTRB(5.0, 0.0, 5.0, 0.0)}
          >
            {Image.asset('images/bg2.jpg')}
          </Container>
          <Column>
            <Text>music</Text>
            <Text style={authorTextStyle}>author</Text>
          </Column>
        </Row> 
        <Align alignment={FractionalOffset.centerRight}>
          <Icon icon={Icons.play_arrow} />
        </Align>
      </Stack>
    </Container>
  )

  <strong i="9">@override</strong>
  Widget build(BuildContext context) {
    return (
      <Container
        height={168.0}
        margin={EdgeInsets.fromLTRB(16.0, 8.0, 16.0, 8.0)}
        decoration={BoxDecoration(
          borderRadius: BorderRadius.all(Radius.circular(8.0)),
          image: DecorationImage(
            image: new AssetImage('images/bg.jpg'),
            fit: BoxFit.cover,
          ),
        )}
      >
        {titleText}
        {music}
      </Container>
    );
  }
}

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

मुझे लगता है कि लोगों द्वारा इसके खिलाफ जोर देने का एक मुख्य कारण यह है कि वे इसका उपयोग करने की कल्पना नहीं कर सकते। सच्चाई यह है कि, आपको वास्तव में ऐसा करने की ज़रूरत नहीं है, जैसे लोग उपयोग करते हैं (प्रतिक्रिया की तुलना में) React.createElement(Component, {}, null) के विपरीत <Component /> यदि इसे लागू किया जाता है, तो यह लोगों को पहले फ़्लटर का उपयोग करने के लिए आकर्षित करेगा जगह, और यही हम वास्तव में चाहते हैं। एक दूसरे के समर्थन के साथ स्पंदन को समर्पित एक बड़ा समुदाय। यदि यह उस तरह का सिंटैक्स नहीं है जिसका आप उपयोग करेंगे, ओह ठीक है। लेकिन टन वर्तमान पद्धति के विपरीत JSX जैसे संकेतन को प्राथमिकता देंगे।

व्यक्तिगत रूप से मुझे लगता है कि एसजीएमएल और इसके डेरिवेटिव सिर्फ सादे बदसूरत हैं। अगर हम एक डीएसएल कर रहे हैं, तो क्यूएमएल-जैसे सिंटैक्स वाला क्यों नहीं?

मुझे यह भी लगता है कि कुछ प्रो-डीएसएक्स बिंदु जावास्क्रिप्ट की एक भाषा के रूप में सुविधाओं को भ्रमित कर रहे हैं (जो कि एक भाषा के रूप में डार्ट नहीं है) और जेएसएक्स की विशेषताएं एक डीएसएल के रूप में हैं। उदाहरण के लिए,

मूल रूप से भाषा चीजों को कम क्रियात्मक बनाने के लिए निर्माण प्रदान कर सकती है जैसा कि मैंने वादों बनाम async/प्रतीक्षा उदाहरण में उल्लेख किया है। स्पंदन विजेट में कंस्ट्रक्टर बहुत बड़े होते हैं और कई बार वे बहुत सारे पैरामीटर लेते हैं; DSX के साथ आप स्प्रेड ऑपरेटर का उपयोग कर सकते हैं उदाहरण के लिए 10 लाइन कंस्ट्रक्टर को 1 लाइन कंस्ट्रक्टर में संपीड़ित करने के लिए और इसलिए आप अभी भी इसके चारों ओर कम शोर के साथ पूर्ण ट्री पदानुक्रम दिखाई दे सकते हैं।

यह एक विशेषता नहीं है DSX जादुई रूप से अनुदान देगा, यह एक विशेषता JSX है क्योंकि जावास्क्रिप्ट में यह है। एक भाषा के रूप में डार्ट स्प्रेड ऑपरेटर (बल्कि असंभव आईएमओ) प्राप्त कर सकता है, इस मामले में आप चीजों के शीर्ष पर एक विशेष डीएसएल की आवश्यकता के बिना इसे कन्स्ट्रक्टर और अन्य फ़ंक्शन कॉल के साथ उपयोग करने में सक्षम होंगे। यह एक ऐसी विशेषता भी है जो बड़े पैमाने पर काम करती है क्योंकि जावास्क्रिप्ट की वस्तुएं, हैशमैप और सरणियाँ सभी अनिवार्य रूप से एक ही चीज़ हैं, जो निश्चित रूप से डार्ट के मामले में नहीं है और लगभग निश्चित रूप से कभी भी बदलने वाली नहीं है।

और मुझे लगता है कि समस्या यह है कि प्रस्ताव के खिलाफ बहुत से लोगों ने भले ही इसे मुखर नहीं किया है - यह अनिवार्य रूप से जावास्क्रिप्ट की तरह डार्ट व्यवहार (या व्यवहार करने का नाटक) करने का अनुरोध है, और कुछ पेशेवर होने पर तथ्य यह है कि वे बस अलग-अलग भाषाएं हैं जो डार्ट 1 के शुरुआती दिनों से अधिक से अधिक भिन्न हो रही हैं।

संपादित करें: यह कहना नहीं है कि यूआई के लिए मार्कअप/मॉडलिंग डीएसएल पूरी तरह से एक बुरा विचार है। यह ईमानदारी से नहीं है, लेकिन मुझे लगता है कि इसके लिए प्रेरणा उन भाषाओं/ढांचे से आनी चाहिए जो डार्ट/स्पंदन के समान हैं (टाइपिंग प्रतिमान के साथ-साथ अन्य अर्थपूर्ण विवरण - मैं सादे वाक्यविन्यास के बारे में बात नहीं कर रहा हूं) जावास्क्रिप्ट की तुलना में है।

एक भाषा के रूप में डार्ट स्प्रेड ऑपरेटर प्राप्त कर सकता है (बल्कि असंभव आईएमओ)

वास्तव में संग्रह के लिए प्रसार पहले से ही निर्दिष्ट है और कार्यान्वयन के लिए तैयार है, आगामी डार्ट भाषा सुविधाओं के बारे में अधिक जानकारी के लिए स्प्रेड संग्रह और संपूर्ण "भाषा फ़नल" देखें ।

@mraleph मैं विशेष रूप से फ़ंक्शन/कन्स्ट्रक्टर कॉल और ऑब्जेक्ट्स के साथ स्प्रेड ऑपरेटर के बारे में बात कर रहा था, न केवल सूचियों या मानचित्रों के साथ - यही मुझे लगता है कि असंभव है। क्षमा करें यदि यह स्पष्ट नहीं था!

(मैं उस प्रस्ताव के बारे में अस्पष्ट रूप से अवगत हूं, लेकिन आखिरी बार मैंने इसे चेक किया था, आप सिर्फ एक डार्ट Size(10, 10) नहीं फैला सकते हैं जिस तरह से आप जावास्क्रिप्ट Size { width: 10, height: 10 } को फैला/नष्ट कर सकते हैं, या एक सूची फैला सकते हैं / एक सामान्य फ़ंक्शन कॉल में तर्कों का नक्शा ( Function.apply का उपयोग नहीं कर रहा है, जो प्रकार की सुरक्षा का त्याग करेगा))

@filluchaos

व्यक्तिगत रूप से मुझे लगता है कि एसजीएमएल और इसके डेरिवेटिव सिर्फ सादे बदसूरत हैं। अगर हम एक डीएसएल कर रहे हैं, तो क्यूएमएल-जैसे सिंटैक्स वाला क्यों नहीं?

क्योंकि बहुत से लोग, आपके विपरीत, यह नहीं सोचते कि यह बदसूरत है, बल्कि इसे पसंद करते हैं। सभी उत्साही रिएक्ट डेवलपर्स को वहाँ देखने के लिए आपके पास बहुत अधिक दृष्टि होने की आवश्यकता नहीं है।

JSX/DSX होस्ट भाषा Javascript/डार्ट में मार्कअप को इस तरह से लाता है जो होस्ट भाषा को बढ़ाता है और मार्कअप पर सभी प्रोग्रामेटिक भाषा के निर्माण को सक्षम बनाता है। बहुत ही सरल और शक्तिशाली सामान।

यह एक विशेषता नहीं है DSX जादुई रूप से अनुदान देगा, यह एक विशेषता JSX है क्योंकि जावास्क्रिप्ट में यह है।

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

मेरा प्रोटोटाइप ऑनलाइन DSX ट्रांसपिलर प्रक्रिया ऑपरेटर को ठीक से फैलाता है, इसे देखें:
https://spark-heroku-dsx.herokuapp.com/index.html

और मुझे लगता है कि समस्या यह है कि प्रस्ताव के खिलाफ बहुत से लोगों ने भले ही इसे मुखर नहीं किया है - यह अनिवार्य रूप से जावास्क्रिप्ट की तरह डार्ट व्यवहार (या व्यवहार करने का नाटक) करने का अनुरोध है, और कुछ पेशेवर होने पर तथ्य यह है कि वे बस अलग-अलग भाषाएं हैं जो डार्ट 1 के शुरुआती दिनों से अधिक से अधिक भिन्न हो रही हैं।

वर्तमान डार्ट क्या है, इसके बारे में सोचना बंद करें और अन्य सभी भाषाओं के सर्वोत्तम विचारों को लेकर इस पर ध्यान केंद्रित करें कि यह क्या हो सकता है।

मुझे लगता है कि इसके लिए प्रेरणा उन भाषाओं/ढांचे से आनी चाहिए जो डार्ट/स्पंदन के समान हैं (टाइपिंग प्रतिमान के साथ-साथ अन्य अर्थपूर्ण विवरण - मैं सादे वाक्यविन्यास के बारे में बात नहीं कर रहा हूं) जावास्क्रिप्ट की तुलना में है।

टाइपप्रति टाइप किया गया है और JSX का समर्थन करता है। फ़्लटर का सबसे नज़दीकी UI फ्रेमवर्क रिएक्ट है, और अनुमान लगाएं कि JSX के कारण रिएक्ट ने क्या किया। कृपया JSX/DSX से बेहतर कुछ लेकर आएं और यदि आप ऐसा करते हैं, तो लोग JSX/DSX के लिए पूछना बंद कर देंगे, लेकिन मैंने ऐसा कुछ भी नहीं देखा है जिसे मैं बेहतर समझता हूं इसलिए अभी JSX अत्याधुनिक है .

हालांकि यह देखना अच्छा है कि डार्ट भाषा के लोग पाइथन (सूची और शब्दकोश समझ) जैसी अन्य भाषाओं से सर्वोत्तम विचार ले रहे हैं।

@cbazza

क्योंकि बहुत से लोग, आपके विपरीत, यह नहीं सोचते कि यह बदसूरत है, बल्कि इसे पसंद करते हैं।

और इसके विपरीत। यह एक वाक्य रचना क्यों है और कोई अन्य नहीं, खासकर जब इसका वास्तव में भाषा के साथ मजबूत संबंध नहीं है? (एंड्रॉइड एसडीके के साथ, जावा और एक्सएमएल का संबंध वर्षों से था। जावास्क्रिप्ट और एचटीएमएल के साथ डिट्टो, जो जेएसएक्स से काफी मिलता-जुलता है। जैसा कि प्रस्तावित है, डीएसएक्स अन्य भाषाओं के लिए समझ में आने के आधार पर एसजीएमएल सिंटैक्स लाएगा, लेकिन जरूरी नहीं कि _Dart_ के लिए)।

JSX/DSX होस्ट भाषा Javascript/डार्ट में मार्कअप को इस तरह से लाता है जो होस्ट भाषा को बढ़ाता है और मार्कअप पर सभी प्रोग्रामेटिक भाषा के निर्माण को सक्षम बनाता है। बहुत ही सरल और शक्तिशाली सामान।

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

इन दोनों कथनों को एक-दूसरे से जोड़कर देखना दिलचस्प है, क्योंकि ये सिर्फ मेरी बात को साबित करने के लिए जाते हैं। JSX बहुत अच्छा है (जावास्क्रिप्ट के लिए) विशेष रूप से इसकी सादगी के कारण - यह केवल चीनी है जो पहले से ही JS भाषा निर्माण कर रहा है, यह वास्तव में किसी विशेष शब्दार्थ को लागू नहीं करता है। आप उस सादगी की सही प्रशंसा करते हैं, फिर कहते हैं कि डीएसएक्स को स्पष्ट रूप से पहचानने के बिना लक्ष्य भाषा से स्वतंत्र रूप से अर्थशास्त्र को लागू करना चाहिए 1) कितना अधिक काम मांगना है, और 2) यह पूरी तरह से एक होने के बिंदु को कैसे हरा देता है सरल लेकिन शक्तिशाली डीएसएल।

मेरा प्रोटोटाइप ऑनलाइन DSX ट्रांसपिलर प्रक्रिया ऑपरेटर को ठीक से फैलाता है, इसे देखें:
https://spark-heroku-dsx.herokuapp.com/index.html

मैंने आपके ट्रांसपिलर को पहले देखा है, और जबकि यह प्रभावशाली काम है, यह किसी भी तरह से स्प्रेड ऑपरेटर को संसाधित करने के करीब नहीं आता है जिस तरह से जावास्क्रिप्ट एक भाषा के रूप में (और इस प्रकार JSX) डिफ़ॉल्ट रूप से करता है। जैसा कि उल्लेख किया गया है, प्रसार (और अंततः विनाशकारी) संग्रह डार्ट के साथ बहुत अधिक नहीं है, और वास्तव में इसे लागू करने के लिए पाइपलाइन में है। किसी भी वस्तु को फैलाना और नष्ट करना (जो, जेएस के विपरीत, मैप्स के समान नहीं हैं), और आपका ट्रांसपिलर इसे संभालने के लिए प्रकट नहीं होता है (और वास्तव में मैप्स के अंदर तर्क डालने की आवश्यकता होती है, जो कि एकतरफा है और अनुपयोगी डार्ट (उदाहरण के लिए, शालीनता से टाइप-सुरक्षित तरीके से बातचीत नहीं की जा सकती))।

वर्तमान डार्ट क्या है, इसके बारे में सोचना बंद करें और अन्य सभी भाषाओं के सर्वोत्तम विचारों को लेकर इस पर ध्यान केंद्रित करें कि यह क्या हो सकता है।

ज़रूर। लेकिन डार्ट के लिए वहां से उठने वाली भाषाओं में, व्यक्तिगत रूप से जेएस सूची में बहुत अधिक नहीं है - मैं ईमानदारी से सोचता हूं कि जेएस (इंटरऑपरेबिलिटी के लिए) की तरह बहुत ज्यादा बनने की कोशिश ने डार्ट को अपने शुरुआती दिनों में अपंग कर दिया।

मुझे निश्चित रूप से एक यूआई डीएसएल पसंद आएगा। लेकिन वह DSL _Dart_ के लिए मुहावरेदार होना चाहिए, न कि केवल लोकप्रियता के कारण शब्दार्थ रूप से भिन्न भाषा से थोक उठाया।

और मैं यह भी चाहूंगा कि लोग यह समझना बंद करें कि जावास्क्रिप्ट JSX DSL के साथ क्या करता है, क्योंकि उल्लिखित कुछ लाभ वास्तव में भेस में भाषा-स्तरीय सुविधा अनुरोध हैं। स्प्रेड ऑपरेटर के साथ जारी रखने के लिए, यदि डार्ट एक भाषा के रूप में वास्तव में ऑपरेटर की पूरी श्रृंखला का समर्थन करता है क्योंकि यह जेएस में है तो मुझे नहीं लगता कि return <SomeWidget {...someArgs, arg: newValue } />; पढ़ने के लिए return SomeWidget(...someArgs, arg: newValue); से बेहतर कैसे है या QML-जैसे return SomeWidget { ...someArgs, arg: newValue }; जब तक कि किसी को SGML से कुछ लगाव न हो।

@filluchaos

यह एक वाक्य रचना क्यों है और कोई अन्य नहीं, खासकर जब इसका वास्तव में भाषा के साथ मजबूत संबंध नहीं है? (एंड्रॉइड एसडीके के साथ, जावा और एक्सएमएल का संबंध वर्षों से था। जावास्क्रिप्ट और एचटीएमएल के साथ डिट्टो, जो जेएसएक्स से काफी मिलता-जुलता है। जैसा कि प्रस्तावित है, डीएसएक्स अन्य भाषाओं के लिए समझ में आने के आधार पर एसजीएमएल सिंटैक्स लाएगा, लेकिन जरूरी नहीं कि डार्ट के लिए)।

उन चीजों को जोड़ना बंद करें जो आपको लगता है कि एक साथ चलते हैं (और एक रिश्ता है) और सर्वोत्तम विचारों को चुनने पर ध्यान केंद्रित करें, चाहे वे कहीं से भी आए हों। जब आप की कोई आवश्यकता नहीं होती है तो आप चीजों को कृत्रिम रूप से अलग कर रहे होते हैं।

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

इन दोनों कथनों को एक-दूसरे से जोड़कर देखना दिलचस्प है, क्योंकि ये सिर्फ मेरी बात को साबित करने के लिए जाते हैं। JSX बहुत अच्छा है (जावास्क्रिप्ट के लिए) विशेष रूप से इसकी सादगी के कारण - यह केवल चीनी है जो पहले से ही JS भाषा निर्माण कर रहा है, यह वास्तव में किसी विशेष शब्दार्थ को लागू नहीं करता है। आप उस सादगी की सही प्रशंसा करते हैं, फिर कहते हैं कि डीएसएक्स को स्पष्ट रूप से पहचानने के बिना लक्ष्य भाषा से स्वतंत्र रूप से अर्थशास्त्र को लागू करना चाहिए 1) कितना अधिक काम मांगना है, और 2) यह पूरी तरह से एक होने के बिंदु को कैसे हरा देता है सरल लेकिन शक्तिशाली डीएसएल।

यह नए शब्दार्थ को लागू करता है या नहीं, यह अप्रासंगिक है। इसके प्रयोग से सरलता आती है। यदि उपयोगकर्ताओं/डेवलपर्स के लिए उपयोग करना आसान है, तो वे इसका उपयोग करेंगे। उपयोगकर्ता/डेवलपर इस बात की परवाह नहीं करते हैं कि आंतरिक रूप से कुछ कितना जटिल है (या कितना काम करना था), वे बस परवाह करते हैं कि यह उनके जीवन को कितना आसान बनाता है और उनके कोड को बेहतर बनाता है।

मैंने आपके ट्रांसपिलर को पहले देखा है, और जबकि यह प्रभावशाली काम है, यह किसी भी तरह से स्प्रेड ऑपरेटर को संसाधित करने के करीब नहीं आता है जिस तरह से जावास्क्रिप्ट एक भाषा के रूप में (और इस प्रकार JSX) डिफ़ॉल्ट रूप से करता है।

डीएसएक्स पर प्रसार के साथ मेरा इरादा सिर्फ विशेषताओं को फैलाना था, न कि प्रसार का पूर्ण जेएस कार्यान्वयन। यह जो है उसके लिए ठीक काम करता है और इसमें कोई प्रकार की सुरक्षित समस्या नहीं है। टाइप चेकिंग/शुद्धता तब होती है जब डार्ट संकलित करता है कि डीएसएक्स क्या उत्पन्न करता है।

अपने शुरुआती दिनों में अपंग डार्ट।

शुरुआती दिनों में डार्ट ने जो अपंग किया वह सरल जेएस इंटरऑपरेबिलिटी प्रदान नहीं कर रहा था, इसलिए वर्तमान जेएस पुस्तकालयों को डार्ट कोड (और इसके विपरीत) के साथ आसानी से उपयोग किया जा सकता था। यही कारण है कि डार्ट विफल होने पर टाइपस्क्रिप्ट सफल होने का ठीक यही कारण है।

मुझे निश्चित रूप से एक यूआई डीएसएल पसंद आएगा। लेकिन वह डीएसएल डार्ट के लिए मुहावरेदार होना चाहिए, न कि केवल लोकप्रियता के कारण शब्दार्थ रूप से भिन्न भाषा से थोक उठाया।

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

और मैं यह भी चाहूंगा कि लोग यह समझना बंद करें कि जावास्क्रिप्ट JSX DSL के साथ क्या करता है, क्योंकि उल्लिखित कुछ लाभ वास्तव में भेस में भाषा-स्तरीय सुविधा अनुरोध हैं।

फिर यह प्रासंगिक नहीं है।

हमें वास्तव में Google (डार्ट/स्पंदन) लोगों से स्रोत मानचित्रों के माध्यम से सामान्य ट्रांसपिलिंग समर्थन की आवश्यकता है ताकि किसी भी उच्च स्तरीय भाषा को विकसित किया जा सके जो डार्ट/स्पंदन को लक्षित करता है और यह वर्तमान टूल (आईडीई, डीबगर, आदि) के साथ ठीक काम करेगा। . खेल के मैदान को समतल करें और आप गारंटी देते हैं कि दूसरों से सबसे अच्छे विचार मंच पर आएंगे।

@cbazza

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

यह बल्कि विभाजनकारी लगता है और मेरे लिए काफी हद तक हकदार है। स्पंदन को विशेष रूप से रिएक्ट सिंटैक्स के लिए प्रथम श्रेणी का समर्थन क्यों होना चाहिए? Vue घटक फ़ाइलें, या Xamarin.Forms सिंटैक्स क्यों नहीं? स्पंदन के लिए (संभवतः आधिकारिक) यूआई डीएसएल इस बात पर आधारित क्यों होना चाहिए कि एक अलग भाषा में एक अलग ढांचे का उपयोग करने वाले लोगों का एक विशेष समूह क्या उम्मीद करता है और चाहता है? यदि आप विशेष रूप से रिएक्ट/जेएस डेवलपर्स के लिए एक सामुदायिक उपकरण चाहते हैं, तो यह एक बात होगी। लेकिन ढांचे के लिए पूछना पूरी तरह से आप सभी को पूरा करने के लिए इसे शामिल करने के लिए थोड़ा अधिक आईएमओ है।

यह नए शब्दार्थ को लागू करता है या नहीं, यह अप्रासंगिक है। इसके प्रयोग से सरलता आती है। यदि उपयोगकर्ताओं/डेवलपर्स के लिए उपयोग करना आसान है, तो वे इसका उपयोग करेंगे। उपयोगकर्ता/डेवलपर इस बात की परवाह नहीं करते हैं कि आंतरिक रूप से कुछ कितना जटिल है (या कितना काम करना था), वे बस परवाह करते हैं कि यह उनके जीवन को कितना आसान बनाता है और उनके कोड को बेहतर बनाता है।

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

डीएसएक्स पर प्रसार के साथ मेरा इरादा सिर्फ विशेषताओं को फैलाना था, न कि प्रसार का पूर्ण जेएस कार्यान्वयन। यह जो है उसके लिए ठीक काम करता है और इसमें कोई प्रकार की सुरक्षित समस्या नहीं है। टाइप चेकिंग/शुद्धता तब होती है जब डार्ट संकलित करता है कि डीएसएक्स क्या उत्पन्न करता है।

यदि आप इसके बारे में बिल्कुल नहीं सोचते हैं तो इसमें केवल "कोई टाइप-सुरक्षित समस्या नहीं है"। मैंने जो कहा वह यह था कि तर्कों के मानचित्र डार्ट कोडबेस के बाकी हिस्सों के साथ पूरी तरह से सुरक्षित तरीके से _usable_ नहीं हैं, जहां संभवतः आप उन तर्कों के साथ बातचीत करना चाहेंगे जिस तरह से आप प्रोप के साथ और जावास्क्रिप्ट में कर सकते हैं - उन्हें दूसरे से नीचे पास करें विजेट, उन्हें किसी अन्य मॉड्यूल से आयात करें, आदि - और न केवल उन्हें एक ही स्थान पर घोषित करें, इस मामले में सामान्य कन्स्ट्रक्टर कॉल पर क्या बात है?

मेरा क्या मतलब है, इसका वर्णन करने के लिए, आप इसे JS में कर सकते हैं:

class MyCustomSize {
  constructor(length, width, height) {
    this.length = length;
    this.width = width;
    this.height = height;
    this.calculateVolume.bind(this);
  }

  calculateVolume() {
    return this.length * this.width * this.height;
  }
}

const Cuboid = ({ length, width, height }) => { // blah blah }

const literalSize = { 'length': 30, 'width': 20, 'height': 10 };
const size = new MyCustomSize(30, 20, 10);

size.length = 100; // Can interact with the object as normal, no compromises
console.log(size.getVolume()); // and even call methods
size.foo = 50 // If you're using TypeScript, you get a nice error
literalSize.height = 15 // can interact with the hashmap as though it were an object

const SomeComponent = () => (
  <div>
    <Cuboid {...literalSize} />{/* valid */}
    <Cuboid {...size} />{/* also valid even though size is an object */}
  </div>
)

लेकिन डार्ट और आपके ट्रांसपिलर के साथ तर्कों के हैशमैप की आवश्यकता होती है:

class MyCustomSize {
  int length, width, height;

  MyCustomSize(this.length, this.width, this.height);

  calculateVolume() {
    return length * width * height;
  }
}

class Cuboid extends StatelessWidget {
  final int length, width, height;

  Cuboid(this.length, this.width, this.height);

  <strong i="9">@override</strong>
  Widget build(BuildContext context) { // blah }
}

Map literalSize = { 'length': 30, 'width': 20, 'height': 10 };
Map invalidSize = { 'length': 300, 'width': 200, 'height': 100 };
final size = MyCustomSize(30, 20, 10);

literalSize.height = 15; // Invalid, you must use square bracket notation which is honestly ugly to do a lot of the time
invalidSize['foo'] = 50; // No indication of anything wrong here

class SomeWidget extends StatelessWidget {
  <strong i="10">@override</strong>
  Widget build(BuildContext context) {
    return (
      <Column>
        <Cuboid {...literalSize} />{/* Yes, works */}
        <Cuboid {...invalidSize} />{/* Sure the transpiled code errors as there is no parameter named foo. But this is now a completely opaque error. What if the `foo:50` key-value pair was added in some other section of your codebase? In a third party library even? How do you debug that*/}
        <Cuboid {...size} />{/* How do you plan on handling this as a plain transpilation step? */}
      </Column>
    )
  }
}

शुरुआती दिनों में डार्ट ने जो अपंग किया वह सरल जेएस इंटरऑपरेबिलिटी प्रदान नहीं कर रहा था, इसलिए वर्तमान जेएस पुस्तकालयों को डार्ट कोड (और इसके विपरीत) के साथ आसानी से उपयोग किया जा सकता था। यही कारण है कि डार्ट विफल होने पर टाइपस्क्रिप्ट सफल होने का ठीक यही कारण है।

जेएस के साथ डार्ट का इंटरऑप कभी भी जटिल नहीं रहा है, जब तक (और यह एक ऐसा बिंदु है जिस पर मैं जोर देता रहता हूं) आप बस अभी भी जावास्क्रिप्ट लिखना चाहते हैं और कुछ और सीखने के खिलाफ हैं। टाइपस्क्रिप्ट एक सुपरसेट होने के कारण जेएस के साथ संचालन क्षमता नहीं है क्योंकि यह केवल जेएस है , जानबूझकर जेएस को पूरा करने के लिए एक अस्वस्थ टाइप सिस्टम होने के बिंदु पर (साथ ही वास्तव में इसकी अभिव्यक्तिपूर्ण प्रकार प्रणाली को लागू करने के लिए कोई रनटाइम नहीं है, जो एक है धिक्कार है यह कई वर्षों पर)। लेकिन अपनी बात पर वापस, मुझे व्यक्तिगत रूप से लगता है कि डार्ट ने जेएस की खातिर कुछ खराब डिजाइन निर्णय लिए और डार्ट 2 को वास्तव में भाषा का पहला पुनरावृत्ति होना चाहिए था।

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

"सर्वश्रेष्ठ", या यों कहें कि अच्छे विचार अच्छे विचार हैं क्योंकि उनमें योग्यता है। कभी-कभी वे लोकप्रिय हो जाते हैं, कभी-कभी नहीं। कभी-कभी बुरे विचार लोकप्रिय हो जाते हैं, कभी-कभी नहीं। यह सुझाव देना कि लोकप्रियता योग्यता का प्रत्यक्ष संकेतक है, स्पष्ट रूप से बेतुका है और यह एक ऐसा रवैया है जिसे मैं व्यक्तिगत रूप से डार्ट समुदाय में नहीं फैलाऊंगा, जो कि छोटा है।

हमें वास्तव में Google (डार्ट/स्पंदन) लोगों से स्रोत मानचित्रों के माध्यम से सामान्य ट्रांसपिलिंग समर्थन की आवश्यकता है ताकि किसी भी उच्च स्तरीय भाषा को विकसित किया जा सके जो डार्ट/स्पंदन को लक्षित करता है और यह वर्तमान टूल (आईडीई, डीबगर, आदि) के साथ ठीक काम करेगा। . खेल के मैदान को समतल करें और आप गारंटी देते हैं कि दूसरों से सबसे अच्छे विचार मंच पर आएंगे।

... मुझे नहीं लगता था कि आप पहले की तुलना में और भी अधिक हकदार थे, और फिर भी हम यहां हैं। यह एक UI SDK क्यों है जिसे विश्व की प्रत्येक उच्च-स्तरीय भाषा द्वारा लक्षित किया जाना चाहिए? एक बार फिर प्रस्ताव दृढ़ता से, " मेरी भाषा/ढांचे में डार्ट/स्पंदन बनाओ" के रूप में दृढ़ता से सामने आता है - आप अभी भी बाहर आ सकते हैं और कह सकते हैं कि आप जावास्क्रिप्ट के साथ स्पंदन ऐप्स बनाना चाहते हैं। और हाँ, आपकी कोहनी पर अधिक तेल और मैं इस तरह की एक सामुदायिक परियोजना में योगदान देने के लिए तैयार हूँ, लेकिन यदि आप इसके लिए आधिकारिक समर्थन का अनुरोध करते हैं तो सकारात्मक उत्तर की अपेक्षा करना स्पष्ट रूप से हास्यास्पद है।

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

फिर भी एक और संपादन: डीएसएल का अनुरोध करना एक बात होगी, जेएसएक्स को संभावित वाक्यविन्यास/वाक्यविन्यास प्रेरणा के रूप में सुझाएं, और अन्य सुझावों के लिए खुले रहें। यह डीएसएक्स पर आग्रह है जो मुझे परेशान करता है (और मुझे कई लोगों पर संदेह है जिन्होंने टिप्पणी की है) गलत।

@filluchaos

आप उल्लसित रूप से भ्रमित हैं और मेरे पास अभी तक बर्बाद करने के लिए ज्यादा समय नहीं है।

मैं डार्ट/स्पंदन टीम से केवल वही पूछ रहा हूं जो मैंने पहले कहा था:

What we really need from Google (Dart/Flutter) people is generic transpiling support via source maps so that any higher level language can be developed that targets Dart/Flutter and it would work just fine with the current tools (IDE, debugger, etc). Level the playing field and you guarantee the best ideas will come to the platform from others.

यह DSX, Vue घटक फ़ाइलों, Xamarin.Forms, NativeScript, QML, आदि को लागू करने के लिए आवश्यक सब कुछ प्रदान करता है और इसलिए समुदाय को अपनी इच्छानुसार कुछ भी लाने में सक्षम बनाता है और किसी को भी मेरा DSX 'लेना' नहीं पड़ता है। DSX पसंद नहीं है, आप सादे डार्ट का उपयोग कर सकते हैं या आसानी से अपनी खुद की चीज़ बना सकते हैं।

मैं कहूंगा कि आप https://github.com/dart-lang/build और dartanalyzer जैसी चीज़ों की तलाश में हैं।
आप शायद एक या दो टुकड़े याद करेंगे (जैसे विश्लेषक प्लगइन्स को पब निर्भरता के रूप में बनाने की क्षमता), लेकिन मुझे पूरा यकीन है कि डार्ट टीम इसके साथ मदद करने में ठीक है।

किसी भी मामले में, मुझे नहीं लगता कि लगातार एक-दूसरे के प्रति कठोर रहने से किसी भी तरह से ढांचे की प्रगति में मदद मिलेगी।
हम इससे जितना अधिक प्राप्त करेंगे, वह एक और स्थायी रूप से बंद मुद्दा है क्योंकि यह "बहुत गर्म" हो गया है।

@filluchaos

आपके 'फू' उदाहरण के संबंध में, डीएसएक्स स्प्रेड एक संकलन समय की बात है इसलिए मानचित्र को const के रूप में परिभाषित करने की आवश्यकता होगी या मैं कुछ और भी लेकर आ सकता हूं जो मैं संकलन समय पर करना चाहता था (उदाहरण के लिए एक बनाएं नया DSX कीवर्ड या इसके लिए एनोटेशन और उसके बाद कॉन्स्टेबल मैप)। इसे रन टाइम के बजाय कंपाइल टाइम पर होना चाहिए, क्योंकि डार्ट रन टाइम पर डायनेमिक कंस्ट्रक्टर पैरामीटर इंसर्शन का समर्थन नहीं करता है। कोई समस्या नहीं है क्योंकि यह उस समस्या को हल करता है जिसे मैं हल करना चाहता था, यानी रचनाकारों पर गुण फैलाना।

@cbazza मुद्दा यह है कि जेएस/जेएसएक्स में स्प्रेड ऑपरेटर को इतना आसान बनाने का वह हिस्सा यह है कि आपको "आप केवल हैशपैप का उपयोग कर सकते हैं" या "आपके सभी तर्क संकलन समय पर ज्ञात होने चाहिए" जैसे प्रतिबंध लगाने की आवश्यकता नहीं है। या "आप उन तर्कों/प्रॉप्स के साथ बातचीत नहीं कर सकते हैं जिन्हें आप एक विजेट में पास करना चाहते हैं, उसी तरह आप बाकी सब कुछ के साथ बातचीत कर सकते हैं" (ध्यान दें कि आपने उस मामले को संभालने के लिए कुछ भी सुझाव नहीं दिया है जहां आप गुणों के साथ बात करते हैं आवश्यकता वास्तव में एक वस्तु है, नक्शा शाब्दिक नहीं) -0 यह सब ठीक है और अच्छा है जब यह एक साधारण उदाहरण है, लेकिन उस तरह की चीज किसी भी मध्यम आकार की परियोजना में बेहद निराशाजनक _fast_ हो जाएगी। मेरा मतलब है, किस बिंदु पर वर्कअराउंड और समझौता और एनोटेशन पर ढेर करना बंद कर देता है, एक कदम पीछे हटता है और सोचता है कि क्या एक्सटेंशन वास्तव में भाषा के लिए उपयुक्त है क्योंकि यह मौजूद है?

JSX इतनी सफल रही है (अधिकांश टेम्प्लेट की तुलना में) क्योंकि यह आपको एक निश्चित तरीके से प्रोग्राम करने के लिए बाध्य नहीं करता है (या इसके बजाय, आपको किसी भी तरह से जावास्क्रिप्ट में किसी भी तरह से कोड लिखने के लिए मजबूर नहीं करता है)। यह _any_ जावास्क्रिप्ट के साथ उपयोग करने के लिए काफी दर्द रहित है; एक डीएसएल बनाकर मेरा यही मतलब है जो वास्तव में भाषा में फिट बैठता है। Redux के साथ भी ऐसा ही है। JS कोडबेस में Redux सुंदरता की चीज है (जब इसे ठीक से उपयोग किया जाता है); दूसरी ओर सभी स्पंदन उदाहरण मैंने Redux का बड़े पैमाने पर ईमानदारी से उपयोग करते हुए देखा है, केवल स्ट्रीम/बीएलओसी पैटर्न का उपयोग करने की तुलना में दर्दनाक दिखता है। यह कहना नहीं है कि ऐसी चीजें नहीं हैं जो बड़ी सफलता के साथ ओवरलैप होती हैं: रिएक्ट का Context और फ़्लटर का InheritedWidget एक सामान्य अवधारणा को लागू करता है जो दोनों की ताकत को अविश्वसनीय रूप से अच्छी तरह से पूरा करता है। मैं अभी आश्वस्त नहीं हूं कि JSX वर्तमान में उन चीजों में से एक है - कई भाषा-स्तर के परिवर्तनों को छोड़कर, यह ईमानदारी से दिखता है कि DSX को विकसित करने के लिए दर्द होगा और तुच्छ उदाहरणों से अधिक किसी भी चीज़ के लिए उपयोग करने के लिए दर्द होगा, जबकि कोई शायद लिख सकता है एक आलसी सप्ताहांत में खरोंच से एक सुविधा-पूर्ण JSX ट्रांसफार्मर क्योंकि JS को मैप करना कितना सरल है।

इसके अलावा मैं पहले थोड़ा आक्रामक था और मैं माफी मांगता हूं।

@filluchaos

मैं पूरी तरह से जेनेरिक स्प्रेड ऑपरेटर बनाने की कोशिश नहीं कर रहा हूं जो हर जगह और हर चीज के लिए काम करता है, यहां तक ​​​​कि भविष्य के लिए नियोजित डार्ट भी जेएस के समान सामान्य नहीं है। जो मैं DSX के संदर्भ में फैलाने के लिए फैलाना चाहता हूं वह ठीक है। उदाहरण के लिए DSX को वस्तुओं को फैलाने की कोई आवश्यकता नहीं है।

संग्रह फैलाएं
https://github.com/dart-lang/language/issues/47

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

@cbazaa मैं मूल्यांकन कर रहा हूं कि प्रतिक्रिया मूल या स्पंदन का उपयोग करना है या नहीं। स्पंदन की ओर झुकाव क्योंकि सब कुछ सिर्फ डार्ट है ताकि संकलक मेरे यूआई टाइपो की जांच कर सके। यह भी देखें: https://medium.com/flutter-io/out-of-depth-with-flutter-f683c29305a8

क्या JSX मेरे टाइपो को भी खोजता है? मैं टाइपस्क्रिप्ट का उपयोग करता हूं।

मुझे एचटीएमएल/अलग मार्कअप से नफरत है। उदाहरण के लिए, कोणीय में, यदि मैंने HTML में कुछ / चर गलत टाइप किया है, तो मुझे पृष्ठ को प्रस्तुत करने के बाद ही मेरी त्रुटियां मिलती हैं।

@ शिवबुद्ध

क्या JSX मेरे टाइपो को भी खोजता है? मैं टाइपस्क्रिप्ट का उपयोग करता हूं।

हां, JS/ES6 का उपयोग करते समय कुछ JSX टाइपो संकलन समय (उदाहरण के लिए घटक नाम) पर पकड़े जाते हैं, लेकिन प्रोप नाम नहीं (जो रन टाइम पर पकड़े जाएंगे); लेकिन चूंकि आप टाइपस्क्रिप्ट का उपयोग कर रहे हैं, इसलिए टाइप सिस्टम संकलन समय पर सभी JSX टाइपो को पकड़ लेता है:
https://www.typescriptlang.org/docs/handbook/jsx.html

@cbazza dsx खुला स्रोत है?

@pushqrdx
अभी नहीं, मैंने इसका सोर्स कोड जारी नहीं किया है।

रिएक्ट + टाइपस्क्रिप्ट और स्पंदन के उपभोक्ता के रूप में मैं खुद को एक परीक्षक के रूप में पेश कर सकता हूं। चियर्स

क्या हमारे पास डीएसएक्स स्रोत होगा? यह बहुत बढ़िया होगा!

मैं cbazza के प्रयासों की सराहना करता हूं लेकिन मैं Flutter में DSX का उपयोग नहीं करूंगा। हालांकि इसका परीक्षण करने में खुशी हुई।

मुद्दा #27141 बिल्ड सिस्टम में कोड जनरेशन सपोर्ट को जोड़ने को ट्रैक करता है। यह https://github.com/dart-lang/build के माध्यम से Builder के साथ किया जाएगा। सिद्धांत रूप में यह सुविधा तैयार होने पर डीएसएक्स कंपाइलर/ट्रांसपिलर को तार करने के लिए काफी सरल होना चाहिए।

दो मुद्दों के बाद, मैं पहली बार इतनी जिद्दी टीम से मिला।

यह JSX की चर्चा नहीं है, बल्कि नेस्टेड नर्क की चर्चा है

यदि आप JSX समाधान नहीं दे सकते हैं, तो भी आपको नेस्टिंग कम और कोड को अधिक पठनीय बनाना चाहिए

मुझे लगता है कि JSX का लाभ स्पष्ट है, लेकिन स्पंदन टीम इसे अनदेखा करने की कोशिश कर रही है।

JSX नेस्टिंग समस्या का समाधान नहीं करता है। प्रतिक्रिया एक ही समस्या का सामना करती है

यदि आप उस घोंसले को नापसंद करते हैं, तो आप हुक पर एक नज़र डालना चाहते हैं, जो कि रिएक्ट हुक का एक बंदरगाह है, जो स्वयं घोंसले के शिकार नरक को हल करने का एक प्रयास है।

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

JSX अस्तित्व में आया क्योंकि रिएक्ट, इसके मूल में, जावास्क्रिप्ट और HTML का सम्मिश्रण है। जावास्क्रिप्ट इंटरपोलेशन/इंजेक्शन के साथ एक्सएमएल सिंटैक्स स्वाभाविक रूप से जेएसएक्स बनाता है।

स्पंदन जावास्क्रिप्ट और एचटीएमएल से पूरी तरह से अलग है, इसलिए यह जेएसएक्स में अच्छी तरह से अनुवाद नहीं करता है। मैं मानता हूं कि स्पंदन परियोजनाएं अक्सर बहुत नेस्टेड होती हैं और यह एक वास्तविक दर्द हो सकता है, खासकर जब dartfmt इन भारी नेस्टेड लाइनों को तोड़ देता है। भयंकर।

मैं यह भी नोट करूंगा कि जब मैं रिएक्ट से आया था, तब मुझे लगा कि फ़्लटर बुरी तरह से संरचित था, लेकिन जब आप प्रारंभिक सीखने की अवस्था को पार कर लेते हैं, तो फ़्लटर के साथ काम करना बहुत आसान हो जाता है। स्पंदन के लिए सीखने की अवस्था अद्वितीय नहीं है, यह नए ढांचे को सीखते समय आम है। स्पंदन विशेष रूप से कठिन है क्योंकि इसमें HTML सिंटैक्स की तरह कार्य करने का कोई कारण नहीं है जिससे बहुत से लोग परिचित हैं।

मुझे लगता है कि घोंसले के शिकार के मुद्दे को सुधारने के तरीके हैं, और जेएसएक्स जवाब नहीं है।

कुछ विचार:

1. एक आंतरिक स्टाइल गाइड विकसित करें जिसके लिए लोगों को बड़े पैमाने पर स्पंदन वाले पेड़ों को छोटे घटकों में तोड़ने की आवश्यकता होती है।

2. औपचारिक रूप से यह पहचानने के लिए dartfmt प्राप्त करें कि फ़्लटर में डार्ट पैकेज की तुलना में स्वरूपण आवश्यकताओं का एक अनूठा सेट है और उचित समाधान के साथ आने के लिए फ़्लटर/डार्ट टीम के साथ काम करें। @ उदार

3. डेवलपर्स के लिए नंबर 1 करना आसान बनाने के लिए @rrousselGit के @stateless पैकेज जैसे कोड जनरेशन का उपयोग करें

निष्पक्ष होने के लिए, घोंसले के शिकार की समस्या ज्यादातर तब उत्पन्न होती है जब हम अपने कोड को रिफ्रैक्टर नहीं करना चाहते हैं।

विजेट्स को कई छोटे टुकड़ों में तोड़ने के लिए बनाया जाता है।
extract widget रिफैक्टरिंग टूल का उपयोग और दुरुपयोग।

यह दोनों कोड को और अधिक पठनीय बनाता है, अतिरेक को कम करता है, और संभावित रूप से बग को भी ठीक करता है/परफ बढ़ाता है।

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

JSX अस्तित्व में आया क्योंकि रिएक्ट, इसके मूल में, जावास्क्रिप्ट और HTML का सम्मिश्रण है। जावास्क्रिप्ट इंटरपोलेशन/इंजेक्शन के साथ एक्सएमएल सिंटैक्स स्वाभाविक रूप से जेएसएक्स बनाता है।

आप इस तथ्य की व्याख्या कैसे करते हैं कि रिएक्ट नेटिव JSX का उपयोग करता है और इसका HTML से कोई लेना-देना नहीं है?

आप इस तथ्य की व्याख्या कैसे करते हैं कि रिएक्ट नेटिव JSX का उपयोग करता है और इसका HTML से कोई लेना-देना नहीं है?

क्योंकि यह रिएक्ट का उपयोग करता है। वे शायद वाक्य रचना का पुन: आविष्कार नहीं करना चाहते थे

क्योंकि यह रिएक्ट का उपयोग करता है। वे शायद वाक्य रचना का पुन: आविष्कार नहीं करना चाहते थे

तो JSX वास्तव में जावास्क्रिप्ट और HTML का सम्मिश्रण नहीं है जैसा कि @lukepighetti बताता है, बल्कि यह एक XML-like syntax extension to ECMAScript without any defined semantics... who's purpose is to define a concise and familiar syntax for defining tree structures with attributes. है
यह सब कल्पना में लिखा गया है: https://facebook.github.io/jsx/

जैसा कि मैं इसे समझता हूं, रिएक्ट को पहले react + react-dom के रूप में jsx कंपाइलर के साथ जारी किया गया था, इसलिए HTML + जावास्क्रिप्ट मिश्रण स्वाभाविक था। उसके बाद, react का उपयोग अन्य रेंडरर्स जैसे react-native , react-vr , react-pdf , आदि आदि को चलाने के लिए किया गया था। इसलिए मैं अभी भी अपने मूल कथन के साथ खड़ा हूं प्रतिक्रिया के इतिहास और वंशावली के प्रति उचित और संवेदनशील। 2019 की कल्पना 2019 की कल्पना है और यह प्रतिक्रिया के इतिहास को संबोधित नहीं करती है।

मैं सहमत हूं

लेकिन मेरे लिए इससे भी बड़ा मसला है। उस पहलू में Vue और React समान रूप से काम करते हैं।
रिएक्ट में createElement है और Vue में h फ़ंक्शन है।

हम कभी भी रिएक्ट और वीयू दोनों में घटकों को मैन्युअल रूप से इंस्टेंट नहीं कर रहे हैं। यह ढांचा है जो इसका ख्याल रखता है।

स्पंदन अलग व्यवहार करता है। हम विजेट के उदाहरण में सीधे हेरफेर कर रहे हैं।

जैसे कि स्पंदन की दुनिया में, <Foo /> का अर्थ है new Foo()

लेकिन उस स्थिति में, JSX विजेट्स से पूरी तरह से असंबंधित है। हम सिर्फ डार्ट में कक्षाओं को इंस्टेंट करने के तरीके के सिंटैक्स को बदल रहे हैं।

मेरे लिए ऐसा लगता है जैसे हम विजेट बनाने का अर्थ खो रहे हैं।

@lukepighetti
react-pdf एक और प्रतिक्रिया रेंडरर नहीं है, आप react-canvas के बारे में सोच रहे होंगे।
तो react != react-dom != react-native । react पैकेज JSX की सहायता से घटक पदानुक्रमों के प्रबंधन के लिए ज़िम्मेदार है, इसलिए react को परवाह नहीं है कि यह react-dom , react-native उत्पन्न कर रहा है या नहीं react-canvas , इसलिए react वास्तव में HTML के बारे में नहीं है।

2019 की कल्पना 2019 की कल्पना है और यह प्रतिक्रिया के इतिहास को संबोधित नहीं करती है।

JSX के 2019 स्पेक जैसी कोई चीज नहीं है। JSX का केवल एक संस्करण है और यह मेरे द्वारा प्रदान किए गए लिंक (https://facebook.github.io/jsx/) से 2014 में प्रकाशित मूल संस्करण है।

@rrousselGit

हम सिर्फ डार्ट में कक्षाओं को इंस्टेंट करने के तरीके के सिंटैक्स को बदल रहे हैं।

स्पंदन के साथ डीएसएक्स के मामले में ट्रांसपिलर ठीक यही कर रहा है।

मेरे लिए ऐसा लगता है जैसे हम विजेट बनाने का अर्थ खो रहे हैं।

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

नमस्ते, मुझे विश्वास है कि आपको मेरे संदेश के बारे में गलतफहमी हो सकती है। react अन्य प्रतिक्रिया रेंडरर्स को ड्राइव करता है जैसे react-dom , react-native , react-pdf , react-vr , आदि। अफैक, react और react-dom एक साथ जारी किए गए थे इसलिए jsx की विरासत, मेरी राय में, बिल्कुल स्पष्ट है। मुझे आशा है कि आप मेरे संदेश में खुदाई नहीं कर रहे हैं क्योंकि स्पंदन के संदर्भ में JSX के मूल्य पर हमारी अलग-अलग राय है। शायद इसे विषय पर रखना और बालों को विभाजित न करना सबसे अच्छा होगा।

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

मुझे अब भी उम्मीद है कि Google JSX की सुंदरता को समझ सकता है, और जैसा कि हमारे पास कई लोग थे जो इसका समर्थन कर रहे थे। Google टीम एक दिन रिएक्ट प्रेरित ढांचे के लिए DSX या JSX के बारे में सोच सकती है, स्पंदन।

हाय लुकेपिघेटी, क्या आपने एक से दो महीने के लिए JSX के साथ रिएक्ट नेटिव का उपयोग किया है? यदि हां, तो आपको यह समझना चाहिए कि JSX और रिएक्ट नेटिव (या रिएक्ट, मुझे पता है कि वे अलग हैं) के साथ एक ऐप बनाना सरल और अच्छी संरचना है।

मैं lukepighetti के लिए बात नहीं कर सकता, लेकिन मैं दो साल के लिए पेशेवर रूप से React के साथ काम कर रहा हूं, अब कुछ Vue कर रहा हूं। इसलिए जब JSX की बात आती है तो मैं काफी अच्छी तरह से वाकिफ हूं।

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

• JSX हाथ से लिखना भयानक है। इसे सहने योग्य बनाने के लिए बहुत सारे टूलिंग की आवश्यकता होती है, जिसमें ऑटो-क्लोजिंग टैग, ऑटो रीनेमिंग टैग और एम्मेट शामिल हैं। और फिर भी यह फ़्लटर के सिंटैक्स जितना सरल कहीं नहीं है।

उदाहरण के लिए, Foo() से Foo(child: Bar()) तक रीफैक्टरिंग करना आसान है।
लेकिन <Foo /> से <Foo><Bar /></Foo> तक रिफैक्टरिंग नहीं है।

• स्पंदन बहुत सारे रिफैक्टरिंग विकल्प प्रदान करता है जो कोष्ठक में हेरफेर करना और भी आसान बनाता है

• फ़्लटर द्वारा ऑफ़र किए जाने वाले वर्चुअल क्लोजिंग टैग्स एंडिंग टैग्स की कमी को पूरा करते हैं।
  _लेकिन वे कोड-समीक्षाओं में दिखाई नहीं देते!_
  वे वास्तव में करते हैं! आप अपने आईडीई से अपनी कोड-समीक्षा कर सकते हैं। देखें https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests

  • JSX स्पंदन मॉडल के लिए अच्छी तरह से अनुवाद नहीं करता है।

क्या होगा यदि कोई विजेट child और children दोनों लेता है? क्या हमें मिलता है:

<Foo
  child={<Bar />}
>
  <Bar />
</Foo>

?

उस स्थिति में, इसका मतलब है कि निरंतरता के उद्देश्य के लिए child को हमेशा children स्लॉट का उपयोग करने के बजाय एक नामित तर्क के रूप में माना जाना चाहिए।

बात यह है कि, बहुत कम विजेट children लेते हैं। विशाल बहुमत या तो एक child , या कस्टम नामित पैरामीटर (जैसे Scaffold ) का संयोजन है।

जिसका अर्थ है कि JSX का उपयोग करने वाले अधिकांश विजेट इस तरह दिखेंगे:

<Container
  child={<Bar />}
/>

जो _बदतर_ तब है:

Container(
  child: Bar(),
)

सब संक्षेप में, मुझे लगता है कि स्पंदन ठीक है। और भले ही JSX उपलब्ध हो, मुझे संदेह है कि यह वास्तव में चीजों में सुधार करेगा।

जैसा कि मैंने अपथ्रेड कहा था, मुझे लगता है कि वास्तव में जेएस/ईसीएमएस्क्रिप्ट/सामान्य वेब फीचर्स (ऑब्जेक्ट स्प्रेडिंग, डिस्ट्रक्टिंग, ऑब्जेक्ट्स/हैशमैप्स की अदला-बदली, सभी डीओएम * नोड्स में एक समान समान इंटरफ़ेस, एचटीएमएल की लचीलापन के बीच बहुत अधिक टकराव है। सामान्य, आदि) JSX सुविधाएँ क्या हैं। पूर्व IMO वही हैं जो JSX को लिखने में सुखद बनाते हैं। उनके बिना, आप सिर्फ एक्सएमएल लिख रहे हैं, और ज्यादातर लोग जिन्हें मैं जानता हूं, जिनके पास वास्तव में एक विकल्प है, वे एक्सएमएल लिखना पसंद नहीं करते हैं।

* ध्यान देने योग्य बात यह है कि यह सब से ऊपर है, फ़्लटर को एक्सएमएल में वापस लाने की कोशिश करने का मेरा प्रमुख विरोध है। मुझे नहीं लगता कि इस बात से इनकार करने का कोई वास्तविक बिंदु है कि JSX/React की वेब में गहरी जड़ें हैं, और DOM तत्वों में _attributes_ और _children_ वाले प्रत्येक नोड का एक पुराना मानक है। दूसरी ओर फ़्लटर अन्य विजेट children या यहां तक ​​कि child के लिए कस्टम विजेट के स्लॉट का नाम देने के लिए देवों को बाध्य नहीं करता है और मुझे शून्य कारण दिखाई देता है कि इसे ऐसा क्यों करना चाहिए।

मैं देख सकता हूं कि अन्य जेएसएक्स थ्रेड क्यों बंद कर दिया गया था। मुझे यह समझाने के लिए GitHub टिप्पणियों में अपने कौशल/अनुभव का बचाव नहीं करना चाहिए कि मुझे क्यों लगता है कि JSX स्पंदन को लाभ नहीं पहुंचाता है। मैं आसानी से कह सकता हूं "आपके पास फ़्लटर के बारे में कोई राय रखने के लिए फ़्लटर के साथ पर्याप्त अनुभव नहीं है।" अच्छा नहीं लगता, करता है। आप सभी अपने कीबोर्ड योद्धा जनजाति का आनंद लें।

क्या होगा यदि कोई विजेट child और children दोनों लेता है? क्या हमें मिलता है:

विजेट को child और children दोनों की आवश्यकता क्यों है? यह या तो यह है या वह。
एक अन्य विषय: स्पंदन के कुछ विजेट children का उपयोग करते हैं, और अन्य child का उपयोग करते हैं, कोई नहीं सोचता कि यह जटिल और भ्रमित करने में आसान है？ children में child शामिल है, इसलिए नहीं कोई फर्क नहीं पड़ता कि आपके पास कितने child हैं (एक या एक से अधिक तो एक) काम पूरा करने के लिए बस children का उपयोग करें।

@rrousselGit

JSX हाथ से लिखना भयानक है। इसे सहने योग्य बनाने के लिए बहुत सारे टूलिंग की आवश्यकता होती है,

न केवल पूरी प्रतिक्रिया दुनिया आपसे असहमत है बल्कि पूरी HTML दुनिया और एक्सएमएल दुनिया भी असहमत है।

स्पंदन बहुत सारे रिफैक्टरिंग विकल्प प्रदान करता है जो कोष्ठक में हेरफेर करना और भी आसान बनाता है

तो आप कह रहे हैं कि फ़्लटर को 'बहुत सारे टूलिंग की भी आवश्यकता है' लेकिन चूंकि आप पक्षपाती हैं, इसलिए आपको दूसरी तरफ कचरा करने की आवश्यकता महसूस होती है। एफवाईआई: करने के लिए सबसे अच्छी बात यह स्वीकार करना है कि कुछ करने के एक से अधिक तरीके हैं और कुछ लोग इसे करने के दूसरे तरीके को पसंद करेंगे।

वे वास्तव में करते हैं! आप अपने आईडीई से अपनी कोड-समीक्षा कर सकते हैं।

यह टीमों द्वारा उपयोग किए जाने वाले अन्य सभी ऑनलाइन कोड समीक्षा टूल की समस्या का समाधान नहीं करता है। ये उपकरण स्रोत कोड में हेरफेर करते हैं और यदि यह स्रोत कोड में नहीं है, तो यह मौजूद नहीं है।

JSX स्पंदन मॉडल के लिए अच्छी तरह से अनुवाद नहीं करता है।

यह सिर्फ आपकी बुरी राय है, कोई भी देख सकता है कि DSX JSX में एन्हांसमेंट जोड़ता है जो स्पंदन के साथ पूरी तरह से फिट बैठता है।
https://spark-heroku-dsx.herokuapp.com/index.html

तो आप कह रहे हैं कि स्पंदन 'बहुत सारे टूलिंग की आवश्यकता है'

नहीं, मैंने कहा "और भी आसान" "सहने योग्य" नहीं।

मैं अक्सर StackOverflow/Slack का जवाब देता हूं, और कभी-कभी अपने फोन से भी।
और html से संबंधित प्रश्न का उत्तर देते समय मेरे पास स्पष्ट रूप से एक बुरा समय है - लेकिन स्पंदन ठीक है।

सबसे अच्छी बात यह है कि यह स्वीकार करना है कि कुछ करने के एक से अधिक तरीके हैं और कुछ लोग इसे करने के दूसरे तरीके को पसंद करेंगे।

यह दूसरी तरह से काम करता है। आपको यह स्पष्ट रूप से देखना चाहिए कि समुदाय JSX का 100% प्रशंसक नहीं है। इस मुद्दे और पिछले दोनों पर डाउनवोट की संख्या इसे साबित करती है।

यह सिर्फ आपकी बुरी राय है, कोई भी देख सकता है कि DSX JSX में एन्हांसमेंट जोड़ता है जो स्पंदन के साथ पूरी तरह से फिट बैठता है।

मैं असहमत हूं। सिंटैक्स में बहुत से जटिल वर्ण होते हैं, जिन्हें कई कीबोर्ड लेआउट पर एक्सेस करना कठिन होता है।
इसमें दोहराव के टन भी शामिल हैं।

किसी भी मामले में, मुझे समझ में नहीं आता कि आप स्थायी रूप से इतने आक्रामक क्यों हैं। हम सभी Flutter को बेहतर बनाने की कोशिश कर रहे हैं।
कठोर होने और इस चर्चा को फिर से बंद करने का कोई मतलब नहीं है।

यदि JSX स्पंदन में अच्छी तरह से काम नहीं करता है, तो मैं JSX में शामिल नहीं होना स्वीकार कर सकता हूं, लेकिन हमें नेस्टेड हेल पर विचार करना चाहिए।

एक अन्य पक्ष कहानी डार्ट भाषा का अर्धविराम है। यह वास्तव में कष्टप्रद है।

एक अन्य पक्ष कहानी डार्ट भाषा का अर्धविराम है। यह वास्तव में कष्टप्रद है।

इसके लिए डार्ट-लैंग/भाषा पर एक अनुरोध है: https://github.com/dart-lang/language/issues/69
जाओ इसे एक

यह लंबी चर्चा इसका उपयोग करने में सक्षम होने के बारे में है:

<A property="a">
  <B/>
  <C/>
</A>

इसके अलावा:

A(property: a, children: [
   B(), 
   C()
])

यहां तक ​​​​कि अगर कोई पूर्व सिंटैक्स से बेहतर होने के लिए सहमत है, तो कुछ मैं व्यक्तिगत रूप से नहीं करता, यह चल रहे रखरखाव लागत, उच्च जटिलता और नए संभावित त्रुटि स्रोतों के साथ आता है, न केवल भाषा/ढांचे में बल्कि आसपास के टूलिंग जैसे आईडीई, डिबगर, लिंटर, आदि। यह निर्माण के समय को भी बढ़ाता है। और यह समझने के लिए कि कब और कैसे इंस्टेंस बनाए जा रहे हैं, यह समझने के लिए डेवलपर्स को एक नया सिंटैक्स सीखने और ट्रांसपिलर के आंतरिक भाग पर कब्जा करने की आवश्यकता है। यह सब काफी हद तक रिएक्ट एंड कंपनी के एकमात्र लक्ष्य के साथ है। Developers को घर जैसा महसूस हो रहा है.

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

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

https://twitter.com/mattly/status/1109464147782074373
https://twitter.com/orta/status/1109467814862172160

अरे मैं-शूएट्ज़।
एक उत्तर खंड है।

मैं इस लंबी पोस्ट में यही कह रहा हूं। JSX ने "HTML और XML की स्पेगेटी समस्या" (अपठनीय और जटिल UI कोड) को ठीक किया। स्पंदन का उपयोग करने के बाद मेरी व्यक्तिगत राय में, यह JSX या सबसे खराब से अधिक जटिल है।

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

मुझे यकीन नहीं है कि मैं अनुसरण करता हूं। आपके द्वारा हाइलाइट किए गए टेक्स्ट में, उपयोगकर्ता कह रहा है कि उसे JSX सीखना आसान लगा क्योंकि वह HTML से परिचित था और इसका सिंटैक्स समान है। मैं नहीं देखता कि यह कैसे JSX के अस्तित्व को सही ठहराता है और किसी भी तरह से स्पंदन की नकल को भी कम करता है।

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

@JonathanSum JSX की तुलना में स्पंदन अधिक जटिल है, या स्पंदन _React_ से अलग है और यह आपके लिए घर्षण पैदा कर रहा है? यह कुछ मामलों में अधिक वर्बोज़ है, हाँ, और एक आईडीई में वर्चुअल क्लोजिंग टैग के बिना काफी कम पठनीय है, लेकिन मुझे पूरा यकीन नहीं है कि एक्सएमएल-जैसे डीएसएल लिखने की तुलना में कंस्ट्रक्टर्स का उपयोग करना अधिक _complicated_ है और मुझे अभी भी पूरा यकीन नहीं है ऐसा क्यों लगता है कि इतने सारे लोग सोचते हैं कि एक्सएमएल जैसा डीएसएल एक चांदी की गोली होगी जो स्पंदन का उपयोग _समझने के लिए आसान बना देगी। विशेष रूप से यह देखते हुए कि फ़्लटर का उन समस्याओं के साथ कोई पूर्व इतिहास नहीं है जिन्हें हल करने के लिए रिएक्ट/जेएसएक्स बनाया गया था - रिएक्ट डोम हेरफेर को आसान और क्लीनर बनाता है, और यह अच्छा है, लेकिन वास्तव में इसका फ़्लटर के साथ क्या करना है?

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

इस धारणा को छुए बिना कि रिएक्ट में हर चीज के कुछ "सच्चे" विचार हैं जो फ़्लटर नहीं हैं, फ़्लटर/डार्ट के डिज़ाइन के कुछ फायदे भी हैं जिन्हें रिएक्ट/जेएस कैप्चर नहीं कर सकता है। और आप सबसे सभ्य यूआई एसडीके/ढांचे/पुस्तकालयों के लिए वही (और इसके विपरीत) कह सकते हैं। अविश्वसनीय रूप से, विभिन्न परियोजनाएं वास्तव में भिन्न हैं; शायद एक परियोजना में आने वाले लोगों को बेहतर सेवा दी जा सकती है यदि वे इसे [अतीत में उपयोग की गई परियोजना डालें] होने की उम्मीद करना शुरू नहीं करते हैं। मैं

वहाँ कुछ दिलचस्प विचार हैं https://github.com/munificent/ui-as-code

यह संभवतः काफी ब्रेकिंग परिवर्तन होगा, लेकिन पैरामीटर स्वतंत्रता प्रस्ताव ने मुझे यह सोचने पर मजबूर कर दिया कि यदि डार्ट के पास क्रिस्टल की विधि तर्क कल्पना थी तो और अधिक संक्षिप्त निर्माण विधियां कैसे हो सकती हैं।

बेशक, क्रिस्टल का कंपाइलर स्लग और कछुआ के खिलाफ दौड़ में आखिरी बार आएगा, इसलिए वह है

अब मैं JSX को नहीं जोड़ने और स्पंदन पर अतिरिक्त दबाव नहीं डालने के लिए सहमत हूं।

लेकिन जहां तक ​​डार्ट का सवाल है, यह जेएस या टीएस की तुलना में बहुत कम सुरुचिपूर्ण है। मुझे असहाय महसूस हो रहा है

उदाहरण के लिए, Microsoft UI तकनीक का विकास मार्ग WinForm से WPF तक है，और अब Flutter में，WPF को छोड़ दें और इसके बजाय WinForm का उपयोग करें。डेवलपर की शिकायतों के जवाब में, Flutter टीम ने WinForm की विज़ुअल विंडो और प्रॉपर्टी एडिटर को लागू करने के लिए कड़ी मेहनत की

स्पंदन में एक नवागंतुक के रूप में मुझे कहना होगा कि यह रोडमैप में होना चाहिए। यदि जेएसएक्स नहीं है, तो विजेट डालने का एक और मानवीय पठनीय तरीका।

मैं इस समय एक प्रतिक्रिया वर्ग रेंडर फ़ंक्शन और रेंडर किए गए वर्ग और सहयोगी की छवि देख सकता हूं।

मैं एक डार्ट फ़ाइल और प्रस्तुत सामग्री देख सकता हूं और मुझे यह पता लगाने में 5-6 मिनट लगेंगे कि यह कैसे काम करता है ...

मैं एक सादे पाठ संपादक में 5 मिनट में एक अर्ध-जटिल प्रतिक्रिया वर्ग बना सकता हूं, क्योंकि यह सहज है

मैं स्पंदन में ऐसा नहीं कर सकता। स्वत: पूर्णता के बिना मैं एक डेवलपर के रूप में कर रहा हूँ। मैं कुछ विकसित करने के लिए विस्तार पर निर्भर रहना पसंद नहीं करता -.-

हालांकि। यह दिलचस्प होगा कि डार्ट डेवलपर्स इस "समस्या" से कैसे निपटते हैं। डार्ट 2 में उन्होंने इसे और अधिक पठनीय बना दिया। मुझे नहीं पता कि वे dart 3 -4 -5 में पठनीयता में सुधार कैसे करेंगे। लेकिन मुझे लगता है कि घटकों के निर्माण समारोह की एक रिफैक्टरिंग जल्द या बाद में आवश्यक होगी।

संपादित करें:
कोई बात नहीं, बस फिर से रिएक्ट नेटिव की कोशिश की, और मुझे jsx, प्रॉप्स सिस्टम से नफरत थी, यह तथ्य कि सब कुछ गतिशील था, वास्तव में फिर से डरावनी अवधारणा थी, मुझे लगता है कि यह सिर्फ एक व्यक्तिगत राय है। जैसे है वैसे ही फड़फड़ाना छोड़ दो ....

उन्होंने DSX का अनुरोध किया, केवल इसलिए नहीं कि वे JSX से प्यार करते हैं। वे स्पंदन चाहते हैं।

बेहतर कोड पठनीयता और समर्थन के लिए UI घोषणा को कोड में नेत्रहीन रूप से अलग किया जाना चाहिए। विशेष रूप से बड़ी टीमों में जिसमें बहुत सारे जूनियर/मिडल होते हैं। Adobe Flex से मैं कह सकता हूँ कि Flutter की UI घोषणाओं को पढ़ने से उत्पादकता बुरी तरह कम हो जाती है।
यदि डीएसएक्स नहीं (जो कि भयानक आईएमओ होगा) लेकिन कम से कम आईडीई स्तर पर वर्तमान स्थिति के साथ कुछ किया जाना चाहिए।
सभी पूर्व UI विकास ढांचे में यह सुविधा थी और हमारे पास भी होनी चाहिए।

बेहतर कोड पठनीयता और समर्थन के लिए UI घोषणा को कोड में नेत्रहीन रूप से अलग किया जाना चाहिए।

और उदाहरण के लिए 'गुई बिल्डर्स' जैसे अन्य उपकरणों के साथ बेहतर एकीकरण के लिए।

Adobe Flex से मैं कह सकता हूँ कि Flutter की UI घोषणाओं को पढ़ने से उत्पादकता बुरी तरह कम हो जाती है।

फ़्लटर पावर के साथ एमएक्सएमएल जैसे यूआई घोषणा की कल्पना करें! मैं केवल सपना देख सकता हूँ!

अब जब हमारे पास कोडजेन सपोर्ट है, तो उत्पाद में ऐसा कुछ लाने का सबसे अच्छा तरीका एक ऐसा पैकेज बनाना है जो इसे सक्षम बनाता है और यह दिखाता है कि यह बेहद लोकप्रिय है।

@Hixie कोडजेन के लिए डॉक्टर के लिए कोई सूचक है?

अब जब हमारे पास कोडजेन सपोर्ट है, तो उत्पाद में ऐसा कुछ लाने का सबसे अच्छा तरीका एक ऐसा पैकेज बनाना है जो इसे सक्षम बनाता है और यह दिखाता है कि यह बेहद लोकप्रिय है।

यह मुझे ऐसा लगता है जैसे codegen सिर्फ .dart -> .dart के लिए है, इनपुट फ़ाइल मान्य .dart फ़ाइल होनी चाहिए। यह .dsx फ़ाइलों के लिए बहुत उपयोगी नहीं है क्योंकि यह डार्ट का सुपरसेट है। मुझे अभी भी स्रोत मानचित्रों जैसे डिबगिंग के लिए सुविधाओं आदि के साथ .dart में क्रॉस-कंपाइलिंग के लिए समर्थन की आवश्यकता है।

कृपया स्विफ्टयूआई दें, जो कल जारी किया गया था, एक नज़र। ऐसा लगता है कि रिएक्ट-जैसे मार्कअप के बजाय फ़्लटर का लक्ष्य क्या होना चाहिए।

अकेले स्विफ्ट के निहित सदस्य भाव इतने अद्भुत होंगे

मैं स्विफ्टयूआई सिंटैक्स के बारे में मिश्रित हूं। यह निश्चित रूप से हल्का है, लेकिन कुछ पहलू जादुई लगते हैं।

लेकिन हम तकनीकी रूप से पहले से ही अपेक्षाकृत समान हो सकते हैं:

Column(mainAxisSize: MainAxisSize.min)([
  if (foo) Text('foo'),
  Text('bar'),
]);

यह वैध डार्ट कोड है, जहां Column _still_ एक वर्ग है।

इसे प्रदर्शित करने वाला एक स्टेटलेस विजेट यहां दिया गया है:

class Foo extends StatelessWidget {
  const Foo({Key key}) : this._(key: key);
  const Foo._({Key key, this.children}) : super(key: key);

  final List<Widget> children;

  <strong i="12">@override</strong>
  Widget build(BuildContext context) {
    return Column(children: children);
  }

  Foo call(List<Widget> children) {
    return Foo._(key: key, children: children);
  }
}

यह बॉयलरप्लेट-ईश है, लेकिन एक कोड-जनरेटर मदद कर सकता है - विशेष रूप से आगामी एक्सटेंशन सदस्यों के साथ।

इस दृष्टिकोण के बारे में एकमात्र मुद्दा यह है कि हम दोनों कॉन्स कंस्ट्रक्टर खो रहे हैं (क्योंकि यह बच्चों को निर्दिष्ट करने के लिए एक फ़ंक्शन का उपयोग करता है) और विजेट क्लास _twice_ को तुरंत चालू करता है।

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

@rrousselGit मैं उत्सुक हूं कि स्विफ्टयूआई के कौन से पहलू आपको जादुई लगते हैं - यह मेरे लिए स्विफ्ट सिंटैक्स का बहुत सीधा विस्तार जैसा लगता है।

यहां से उनके कोड उदाहरण पर:

• Content परिवर्तनशील है? क्या इसका मतलब है कि उनके पास एक अंतर्निहित Mobx / Vue स्टोर है?
• वह @State क्या है?
• body एक चर क्यों है? क्या यह गेटर है? यदि हां, तो गेटर को दोबारा कब बुलाया जाता है?
• body एक इंटरफ़ेस का हिस्सा है, या कई समान चर Content के अंदर हैं?
• वह item in _बिल्कुल_ क्या करता है? in का सही ऑपरेंड कुछ चलने योग्य क्यों नहीं है, बल्कि इसके बजाय "परिणाम" है?
• जब कोई HStack नहीं है तो Image को शीर्षक/उपशीर्षक के बाईं ओर संरेखित क्यों किया जाता है?

मुझे निश्चित रूप से याद नहीं है, लेकिन मुझे पूरा यकीन है कि फ़्लटर को उठाते समय मेरे पास ऐसे प्रश्न नहीं थे।

@rrousselGit यह आपकी पृष्ठभूमि के कारण हो सकता है, इसलिए नहीं कि फ़्लटर सिंटैक्स या शब्दार्थ स्वाभाविक रूप से स्पष्ट है (मैं बहुत से ऐसे लोगों से मिला हूँ जो इससे काफी प्रभावित थे)। और आपके द्वारा उठाए गए बिंदु दोषों के लिए 14-पंक्ति कोड स्निपेट के अति-विश्लेषण का एक अजीब जंक्शन प्रतीत होता है, जबकि वास्तव में उस भाषा को नहीं जानते हैं जिसमें यह लिखा गया है।

• यह वास्तव में परिवर्तनशील नहीं है (डार्ट या जेएस अर्थ में) हालांकि? यह एक संरचना है। इसके अलावा MobX/Vue- शैली के स्टोर (यानी बहुत सीमित भाषा समर्थन पर पेपरिंग) परिवर्तनशीलता को संभालने का एकमात्र तरीका नहीं है

• @State एक विशेषता है, अन्यथा कुछ भाषाओं में एनोटेशन के रूप में जाना जाता है (जैसे डार्ट), अन्यथा स्विफ्ट कोड में एक बहुत ही सामान्य चीज़ के रूप में जाना जाता है। यदि आपका मतलब है कि यह क्या करता है, यहां तक ​​​​कि दस्तावेज़ों को देखे बिना भी यह एक संपत्ति को राज्य के रूप में चिह्नित करता है जो समय के साथ बदल जाएगा।

• body एक गणना की गई संपत्ति है, जो स्विफ्ट डेवलपर्स के लिए आसानी से स्पष्ट है। जब इसकी पुनर्गणना की जाती है, तो क्या Widget build(BuildContext context) भी स्वाभाविक रूप से आपको बताता है कि इसे फिर से कब कहा जाता है?

• Content (स्विफ्ट डेवलपर्स के लिए फिर से स्पष्ट रूप से) View विस्तार/कार्यान्वयन करता है, जहां आप अपने प्रश्न के उत्तर की तलाश करेंगे (इसमें वास्तव में एक बहुत अच्छा एपीआई संदर्भ पृष्ठ है)।

• यह बहुत अधिक है "इस भाषा में कीवर्ड मेरे द्वारा उपयोग की जाने वाली भाषा में कीवर्ड के समान क्यों नहीं है", विशेष रूप से "जादुई" कुछ भी नहीं। यहां in कीवर्ड for...in निर्माण के समान नहीं है - यह इंगित करता है कि बंद होने का शरीर शुरू होने वाला है। { item in ... } एक फ़ंक्शन ब्लॉक है जो List कंस्ट्रक्टर को दिया गया है; एक ListView के itemBuilder , यदि आप करेंगे।

• क्या आप वैध रूप से पूछ रहे हैं कि किसी दृश्य के अपने स्वयं के इनकैप्सुलेटेड लेआउट नियम क्यों हैं?

स्विफ्टयूआई पर:

1-व्यू में घोषित राज्य को देखकर अच्छा लगा और साइड एपेंडेज के रूप में नहीं।

2-कंस्ट्रक्टर पर सब कुछ पास करने के बजाय चीजों को सेट करने के लिए अलग-अलग तरीके (तरीके केवल डेटा पास किए जाने के बजाय क्रियाओं को प्रभावी बनाने में सक्षम होते हैं)।

3- घोषणात्मक वेक्टर ग्राफिक्स को अन्य सभी चीजों के साथ मिलाकर देखना बहुत अच्छा है जो कि घोषणात्मक है (जैसा कि मैंने अतीत में घोषणात्मक एसवीजी जैसे विगेट्स के साथ सुझाव दिया था) !!!
https://developer.apple.com/tutorials/swiftui/drawing-paths-and-shapes

4-बहुत ही सरल एनीमेशन और संक्रमण निर्माण
https://developer.apple.com/tutorials/swiftui/animating-views-and-transitions

5-कोड संपादक के साथ सिंक में डिज़ाइन टूल को दोनों तरीकों से खींचें और छोड़ें।

हर चीज की तरह मस्से भी होते हैं लेकिन मैं इस पर ध्यान केंद्रित करता हूं कि उन्होंने बहुत अच्छा क्या किया।

ये "प्रश्न" केवल संभावित रूप से भ्रमित करने वाले बिंदुओं को प्रदर्शित करने के लिए मौजूद हैं। ये _वास्तविक प्रश्न_ नहीं हैं।

यह आपकी पृष्ठभूमि के कारण हो सकता है

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

जब इसकी पुनर्गणना की जाती है, तो क्या विजेट बिल्ड (बिल्डकॉन्टेक्स्ट संदर्भ) भी स्वाभाविक रूप से आपको बताता है कि इसे फिर से कब कहा जाता है?

यहां मेरा कहना है कि State और body के पुनर्गणना के कार्य के बीच संबंध की कमी है।
प्रतिक्रिया और स्पंदन उस मामले पर बहुत स्पष्ट हैं: setState.
Vue/Mobx समान @State सुविधा का उपयोग करते हुए "जादुई" हैं।

यह वास्तव में ठीक है, लेकिन यह एक अलग पैटर्न है।

क्या आप वैध रूप से पूछ रहे हैं कि किसी दृश्य के अपने स्वयं के इनकैप्सुलेटेड लेआउट नियम क्यों हैं?

नहीं, यह "स्पष्ट" बनाम "अंतर्निहित" से अधिक है।
ऐसा लगता है कि उन्होंने वास्तव में "जितना संभव हो उतना कम कोड में जितना संभव हो सके" पर ध्यान केंद्रित किया, भले ही यह कुछ तर्क छुपाता हो (उस मामले में, ltr बनाम rtl तर्क)

स्पंदन आपको Row का उपयोग करने के लिए कहेगा।

स्पंदन बहुत सारे "फैंसी भाषा सुविधाओं" का उपयोग करता है और उन पर निर्भर करता है (पढ़ें: भाषा की विशेषताएं जो कि स्पीकर का उपयोग नहीं किया जाता है और/या इससे सहमत नहीं है)। मेरे सिर के ऊपर से, निरंतर रचनाकार (और सामान्य रूप से निर्माणकर्ताओं के नामकरण की डार्ट की शैली), ऑपरेटर ओवरलोडिंग, कक्षाएं निहित इंटरफेस हैं, @covariant , और मिश्रण ऐसी विशेषताएं हैं जो भ्रम से प्रतिक्रियाओं को एकमुश्त लेबलिंग के रूप में आकर्षित करती हैं एक डेवलपर की पृष्ठभूमि के आधार पर एक कोड गंध। मैं शायद एक घंटे के विचार को देखते हुए एक लंबी सूची के साथ आ सकता हूं। और यह फ़्लटर का अभियोग नहीं है, यह स्विफ्टयूआई का एक अभियोग है - मुझे नहीं लगता कि कोई यह क्यों सोचेगा कि किसी विशेष भाषा में सॉफ़्टवेयर लिखना एक गुण है ताकि इसे किसी भी भाषा में उसी तरह लिखा जा सके - क्या है अलग-अलग भाषाओं के बिंदु अगर हम दिखावा करने वाले हैं जैसे कि उनके बीच मतभेद मौजूद नहीं हैं?

इसके अलावा, मैं पूरी तरह से असहमत हूं कि setState या @State में से कोई भी एक दृश्य के पुनर्निर्माण के कार्य के साथ अपने संबंधों के बारे में स्पष्ट है। दोनों ही मामलों में आपको बस इतना बताया जाता है कि यदि आप कुछ ऐसा बदलते हैं जिसे राज्य के रूप में चिह्नित किया गया है तो ढांचा यह तय करेगा कि क्या बनाना है। दोनों ही मामलों में देव का अभी भी इस बात पर कोई स्पष्ट नियंत्रण नहीं है कि क्या हो रहा है या वास्तव में कब। आप फ़ंक्शन कॉल को अधिक परिचित पाते हैं, जो लोग कुछ अन्य भाषाओं में काम करते हैं, वे डेकोरेटर को अधिक परिचित पाते हैं। लेकिन किसी फ़ंक्शन को कॉल करने से चीज़ें जादू नहीं हो जातीं।

स्पंदन आपको Row . का उपयोग करने के लिए कहेगा

मुझे लगता है कि आपने कभी भी ListTile उपयोग नहीं किया है, जिसमें वही व्यवहार दिखाया गया है लेकिन नामित पैरामीटर के साथ? क्या हमें यह भी पूछना चाहिए कि एक Scaffold "जादुई रूप से" आपके ऐपबार के बाईं ओर एक मेनू बटन क्यों डालता है जब आपने इसे नहीं पूछा था?

अंतर यह है कि डार्ट की वर्तमान स्थिति में अधिकांश मुख्यधारा की भाषाओं के समान है।

वह महत्वपूर्ण है।
प्रश्न "क्या मुझे डार्ट सीखने की ज़रूरत है, या क्या मैं फ़्लटर सीखना शुरू कर सकता हूँ?" बहुत बार आता है।
फिलहाल, इसका उत्तर है "सिर्फ स्पंदन सीखें। आप एक दिन के बाद प्रभावी डार्ट लिख सकते हैं"।
यह हमेशा के लिए इस तरह रहने की गारंटी नहीं है, लेकिन मुझे लगता है कि यह स्पंदन की ताकत में से एक है।

बाकी चर्चा कुछ हटकर है। यदि आप चाहें तो हम मेल द्वारा उस भाग को जारी रख सकते हैं (मेरा जीथब मेल काम करता है)।

यह लॉक क्यों नहीं है? यह पहले से ही बुरी तरह से विकसित हो रहा है, और यह ठीक वैसा ही है जैसा पहले एक बंद मुद्दा था।

मैंने यहां एक सरल बनाया है:
https://github.com/danialdezfouli/flutterjsx
https://www.npmjs.com/package/flutterjsx
https://www.youtube.com/watch?v=Oj1JMSurphA

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