सीसी @ ल्यूकचर्च

@cbazza क्या आप इस बारे में विस्तार से बता सकते हैं कि आप इसे क्यों चाहते हैं? शायद इसका एक उदाहरण दिखाएँ कि यह आज की तुलना में कैसा दिखेगा?

ठीक है, इसलिए ' https://flutter.io/widgets-intro/#basic -widgets' पर "बेसिक विजेट्स" का उदाहरण निम्न जैसा दिखेगा:

import 'package:flutter/material.dart';

class MyAppBar extends StatelessWidget {
  MyAppBar({this.title});

  // Fields in a Widget subclass are always marked "final".

  final Widget title;

  <strong i="7">@override</strong>
  Widget build(BuildContext context) {
    let style = {
        height: 56.0, // in logical pixels
        padding: const EdgeInsets.symmetric(horizontal: 8.0),
        decoration: <BoxDecoration color={Colors.blue[500]}/>,
    };

    return <Container style={style}>
      <Row>
        <IconButton
            icon={<Icon name={Icons.menu}/>}
            tooltip='Navigation menu'
            onPressed={null}
        />
        <Expanded>
           {title}
    </Expanded>  
        <IconButton
            icon={<Icon name={Icons.search}/>}
            tooltip='Search'
            onPressed={null}
        />
      </Row>
    </Container>;
  }
}

class MyScaffold extends StatelessWidget {
  <strong i="8">@override</strong>
  Widget build(BuildContext context) {
    // Material is a conceptual piece of paper on which the UI appears.
    return <Material>
      <Column>
          <MyAppBar
             title={<Text 
               text='Example title'
               style={Theme.of(context).primaryTextTheme.title},
             />}
          />
          <Expanded>
            <Center>
              <Text text='Hello, world!'/>
            </Center>
          </Expanded>
      </Column>
    </Material>;
  }
}

void main() {
  runApp(<MaterialApp
    title='My app'
    home={<MyScaffold/>}
  />);
}

इस वाक्यविन्यास के बारे में कैसे ?:

import 'package:flutter/material.dart';

class MyAppBar extends StatelessWidget {
  MyAppBar({this.title});

  // Fields in a Widget subclass are always marked "final".

  final Widget title;

  <strong i="6">@override</strong>
  Widget build(BuildContext context) {
    return Container(
      height: 56.0, // in logical pixels
      padding: EdgeInsets.symmetric(horizontal: 8.0),
      decoration: BoxDecoration(color: Colors.blue[500]),
      child: Row(
        children: <Widget>[
          IconButton(
            icon: Icon(Icons.menu),
            tooltip: 'Navigation menu',
            onPressed: null,
          ),
          Expanded(
            child: title,
          ),
          IconButton(
            icon: Icon(Icons.search),
            tooltip: 'Search',
            onPressed: null,
          ),
        ],
      ),
    );
  }
}

class MyScaffold extends StatelessWidget {
  <strong i="7">@override</strong>
  Widget build(BuildContext context) {
    // Material is a conceptual piece of paper on which the UI appears.
    return Material(
      child: Column(
        children: <Widget>[
          MyAppBar(
            title: Text(
              'Example title',
              style: Theme.of(context).primaryTextTheme.title,
            ),
          ),
          Expanded(
            child: Center(
              child: Text('Hello, world!'),
            ),
          ),
        ],
      ),
    );
  }
}

void main() {
  runApp(MaterialApp(
    title: 'My app',
    home: MyScaffold(),
  ));
}

हम्म, थोड़ा सुधार लेकिन इतना अच्छा नहीं ...
यहाँ वे चीजें हैं जो XML का उपयोग करके पूरी की जाती हैं:
(1) कोई और 'बच्चा' और 'बच्चे' सामान नहीं
(2) तीसरे पक्ष के उपकरणों में हेरफेर करना आसान है (पार्स, विश्लेषण और पुन: उत्पन्न)
(3) ध्यान दें कि मार्कअप और प्रोग्रामिंग के बीच स्विचिंग का आसानी से पता चल जाता है। मेरा मतलब है कि एक्सएमएल के अंदर आपके पास कोड को सीमित करने के लिए '{}' है और कोड में आपके पास '{}' है। साथ ही सभी 'स्टाइल' चीजों को मुख्य संरचना से अलग कर दें।
मुझे पता है कि यह मूल रूप से प्रतिक्रिया के तरीके का पूरी तरह से समर्थन कर रहा है लेकिन आप वैसे भी आधे रास्ते हैं;)

सीसी @ kasperl

(1) कोई और 'बच्चा' और 'बच्चे' सामान नहीं

मैं वास्तव में समझ नहीं पा रहा हूं कि यह वांछनीय क्यों है। "बच्चे" और "बच्चे" विशेष नहीं हैं। उदाहरण के लिए लिस्टटाइल पर विचार करें। आप वह कैसे करेंगे? IconButton में "आइकन" या MaterialApp में "होम" क्यों हैं, कुछ ऐसा जिसे आप नाम देना चाहते हैं, लेकिन विस्तारित में "बच्चा" नहीं? ये तीनों केवल मनमाना तर्क हैं जो विजेट ऑब्जेक्ट लेने के लिए होते हैं। "बच्चे" बनाम "घर" के बारे में कुछ भी जादुई नहीं है।

(2) तीसरे पक्ष के उपकरणों में हेरफेर करना आसान है (पार्स, विश्लेषण और पुन: उत्पन्न)

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

(3) ध्यान दें कि मार्कअप और प्रोग्रामिंग के बीच स्विचिंग का आसानी से पता चल जाता है।

यह वांछनीय क्यों है? मेरा मतलब है, इनमें से कोई भी "प्रोग्रामिंग" के रूप में क्यों गिना जाएगा? यह सब सिर्फ अभिव्यक्ति है।

मेरा मतलब है कि एक्सएमएल के अंदर आपके पास कोड को सीमित करने के लिए '{}' है और कोड में आपके पास '{}' है।

मैं वास्तव में भेद को नहीं समझता।

साथ ही सभी 'स्टाइल' चीजों को मुख्य संरचना से अलग कर दें।

आप इसे आज स्पंदन में कर सकते हैं यदि आप वास्तव में चाहते हैं, तो शैली को एक चर में रखें जैसे आपने एक्सएमएल मामले में किया था।

मैं वास्तव में समझ नहीं पा रहा हूं कि यह वांछनीय क्यों है। "बच्चे" और "बच्चे" विशेष नहीं हैं। उदाहरण के लिए लिस्टटाइल पर विचार करें। आप वह कैसे करेंगे? IconButton में "आइकन" या MaterialApp में "होम" क्यों हैं, कुछ ऐसा जिसे आप नाम देना चाहते हैं, लेकिन विस्तारित में "बच्चा" नहीं? ये तीनों केवल मनमाना तर्क हैं जो विजेट ऑब्जेक्ट लेने के लिए होते हैं। "बच्चे" बनाम "घर" के बारे में जादुई कुछ भी नहीं है।

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

यह वांछनीय क्यों है? मेरा मतलब है, इनमें से कोई भी "प्रोग्रामिंग" के रूप में क्यों गिना जाएगा? यह सब सिर्फ अभिव्यक्ति है।

यह (2) से संबंधित है क्योंकि यह टूलमेकर, विशेष रूप से जीयूआई बिल्डरों के जीवन को बहुत आसान बनाता है क्योंकि उन्हें डार्ट को पूरी तरह से पार्स करने की आवश्यकता नहीं होती है; लेकिन यह कोड को पढ़ना भी आसान बनाता है।

मैं वास्तव में भेद को नहीं समझता।

एक्सएमएल का प्रारूप बहुत सरल है इसलिए जब आप '{}' देखते हैं तो आप जानते हैं कि यह डार्ट में अभिव्यक्ति की गणना कर रहा है। इसके विपरीत के लिए भी, जब डार्ट कोड पढ़ते हैं और आप देखते हैं ') आप जानते हैं कि XML मार्कअप से एक ऑब्जेक्ट पदानुक्रम बनाया जा रहा है।

इसके अलावा अंतिम एक्सएमएल प्रोसेसर में मैं माता-पिता की विशेषताओं के लिए वस्तुओं को पारित करने से बचूंगा और इसके बजाय नीचे के रूप में बाल टैग बनाउंगा:

this...
          <MyAppBar>
             <Title style={Theme.of(context).primaryTextTheme.title}>  
                 Example title
             </Title>
          </MyAppBar>

instead of this...
          <MyAppBar
             title={<Text 
               text='Example title'
               style={Theme.of(context).primaryTextTheme.title},
             />}
          />

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

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

इसके अलावा, मुझे सच में यकीन नहीं है कि यह कम बॉयलरप्लेट है।

तुलना करना:

   <Container style={style}>
      <Row>
        <IconButton
            icon={<Icon name={Icons.menu}/>}
            tooltip='Navigation menu'
            onPressed={null}
        />
        <Expanded> {title} </Expanded>  
      </Row>
    </Container>

   Container(style: style,
      child: Row(
        children: [
          IconButton(
            icon: Icon(Icons.menu),
            tooltip: 'Navigation menu',
            onPressed: null,
          ),
          Expanded(child: title),
        ],
      ),
    )

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

एक्सएमएल के साथ भी आप यह कैसे स्पष्ट करते हैं कि रो शून्य, एक या एक से अधिक बच्चे ले सकता है, जबकि केंद्र में बिल्कुल एक बच्चा होना चाहिए? अगर कोई ऐसा करे तो क्या होगा ?:

   <Center> <Test/> <Test/> </Center>

यह (2) से संबंधित है क्योंकि यह टूलमेकर, विशेष रूप से जीयूआई बिल्डरों के जीवन को बहुत आसान बनाता है क्योंकि उन्हें डार्ट को पूरी तरह से पार्स करने की आवश्यकता नहीं होती है;

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

लेकिन यह कोड को पढ़ना भी आसान बनाता है।

मैं बिल्कुल भी आश्वस्त नहीं हूं कि यहां XMLy संस्करण को पढ़ना आसान है। एक बार जब आप कुछ बिल्ड फ़ंक्शंस पढ़ लेते हैं, तो आप जल्दी से नेस्टेड कंस्ट्रक्टर सिंटैक्स के अभ्यस्त हो जाते हैं।

एक्सएमएल का प्रारूप बहुत सरल है इसलिए जब आप '{}' देखते हैं तो आप जानते हैं कि यह डार्ट में अभिव्यक्ति की गणना कर रहा है।

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

  <Test name={describe("}")}>

डार्ट को पार्स किए बिना यह कैसे पता चलेगा कि पहला "}" विशेषता अभिव्यक्ति का अंत नहीं है?

इसके विपरीत के लिए भी, जब डार्ट कोड पढ़ते हैं और आप देखते हैं ') आप जानते हैं कि XML मार्कअप से एक ऑब्जेक्ट पदानुक्रम बनाया जा रहा है।

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

इसके अलावा अंतिम एक्सएमएल प्रोसेसर में मैं माता-पिता की विशेषताओं के लिए वस्तुओं को पारित करने से बचूंगा और इसके बजाय नीचे के रूप में बाल टैग बनाउंगा:

मैं वास्तव में समझ नहीं पा रहा हूं कि आप यहां क्या प्रस्ताव दे रहे हैं। जहां तक ​​मैं बता सकता हूं, यह बिल्कुल भी अच्छी तरह से गठित एक्सएमएल नहीं है। क्या आप विस्तार से बता सकते हैं कि आप जिस वाक्य रचना का प्रस्ताव कर रहे हैं वह क्या है और यह कैसे काम करता है? उदाहरण के लिए, "टेक्स्ट" कंस्ट्रक्टर गायब हो गया लगता है; प्रोसेसर कैसे जानता है कि

देखिए, आप मेरी हर बात में मिलावट कर रहे हैं और यह बातचीत कहीं नहीं जा रही है। कानूनी शब्दों में आप "गवाह को बदनाम कर रहे हैं"।

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

https://facebook.github.io/react/tutorial/tutorial.html
https://facebook.github.io/react-native/docs/flatlist.html

एक और दिलचस्प बात यह है कि टाइपस्क्रिप्ट ने JSX को भी अपनाया है:
https://www.typescriptlang.org/docs/handbook/jsx.html

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

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

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

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

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

मुझे इसमें कोई संदेह नहीं है कि JSX "हॉट" है। रिएक्ट में, गैर-जेएसएक्स सिंटैक्स इस मुद्दे में प्रस्तावित वैकल्पिक सिंटैक्स की तुलना में बहुत खराब है (वह जो हमारे वर्तमान कोड की तरह दिखता है लेकिन "नए" और "कॉन्स्ट" कीवर्ड के बिना)। मैं यह समझने की कोशिश कर रहा हूं कि क्या रिएक्ट में JSX के "हॉट" होने के समान कारण स्पंदन पर लागू होते हैं।

JSX करने वाले टाइपस्क्रिप्ट के संबंध में, 2012 में मैं E4H निर्दिष्ट करने के प्रयासों में शामिल था, और उससे पहले भी E4X था। दोनों प्रयास मर गए। इसलिए मेरे लिए यह महत्वपूर्ण है कि हम समझें कि JSX बनाम अन्य सिंटैक्स के बारे में लोग वास्तव में क्या पसंद करते हैं।

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

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

लेकिन ऐसा करने में सक्षम होना क्यों फायदेमंद है?

फ़्लटर ऐप्स के माध्यम से स्क्रॉल करते समय यह बहुत स्पष्ट है जहां बिल्ड फ़ंक्शन हैं (वे विशाल नेस्टेड एक्सप्रेशन हैं)। यह "घोषणात्मक मार्कअप" के बारे में क्या है जो "कोड" से अलग होना महत्वपूर्ण है?

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

जहाँ तक मैं बता सकता हूँ, JSX उन चीज़ों को हैंडल नहीं करता है जिनके बारे में मैं पूछ रहा था। उदाहरण के लिए, रिएक्ट में चाइल्ड स्लॉट की अवधारणा नहीं है। सबसे नज़दीकी चीज़ जो मुझे मिल सकती है, वह कुछ ऐसा है जो वे JS पर वापस जाकर उसके अंदर JSX पर करते हैं, इसलिए आपको प्रोग्रामिंग भाषा और मार्कअप भाषा दोनों को पार्स करने में सक्षम होना चाहिए।

मैं यह समझने की कोशिश कर रहा हूं कि क्या रिएक्ट में JSX के "हॉट" होने के समान कारण स्पंदन पर लागू होते हैं।

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

E4X मरा या नहीं यह अप्रासंगिक है क्योंकि कुछ भी हमेशा के लिए नहीं रहता है। मैंने E4X के साथ एक्शनस्क्रिप्ट का बहुत उपयोग किया है और सोचा है कि Adobe ने वहां बहुत अच्छा काम किया है। फ़्लटर एक तरह से फ्लेक्स ऐप्स के साथ एडोब फ्लैश का एक नया संस्करण है।

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

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

लेकिन ऐसा करने में सक्षम होना क्यों फायदेमंद है?

कोड पठनीयता और सरलता जो बदले में अन्य लाभों का एक पूरा समूह चलाती है।

फ़्लटर ऐप्स के माध्यम से स्क्रॉल करते समय यह बहुत स्पष्ट है जहां बिल्ड फ़ंक्शन हैं (वे विशाल नेस्टेड एक्सप्रेशन हैं)। यह "घोषणात्मक मार्कअप" के बारे में क्या है जो "कोड" से अलग होना महत्वपूर्ण है?

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

जहाँ तक मैं बता सकता हूँ, JSX उन चीज़ों को हैंडल नहीं करता है जिनके बारे में मैं पूछ रहा था। उदाहरण के लिए, रिएक्ट में चाइल्ड स्लॉट की अवधारणा नहीं है

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

  new ListTile(
    title: new Text('CineArts at the Empire',
        style: new TextStyle(fontWeight: FontWeight.w500, fontSize: 20.0)),
    subtitle: new Text('85 W Portal Ave'),
    leading: new Icon(
      Icons.theaters,
      color: Colors.blue[500],
    ),
  ),

  <ListTile>
    <title> 
      <Text style={{fontWeight: FontWeight.w500, fontSize: 20.0}}>
         CineArts at the Empire
      </Text>
    </title>
    <subtitle>
      <Text>85 W Portal Ave</Text>
    </subtitle>
    <leading>
      <Icon data={Icons.theaters} color={Colors.blue[500]}/>
    </leading>
  </ListTile>,

यह डार्ट संस्करण की तुलना में लंबा दिखता है लेकिन मैं सब कुछ समान पंक्तियों में रख सकता था। बात यह है कि एक आईडीई/संपादक वैसे भी इन एक्सएमएल नोड्स को विस्तारित और संक्षिप्त करने के लिए '+' और '-' प्रदान कर सकता है।

रिएक्ट डेवलपर्स के लिए फ़्लटर को परिचित बनाएं और आपके पास फ़्लटर के लिए नए उपयोगकर्ताओं के एक समूह को आकर्षित करने का मौका है।

E4X मरा या नहीं यह अप्रासंगिक है क्योंकि कुछ भी हमेशा के लिए नहीं रहता है।

वह मरा या नहीं, यह मुद्दा नहीं है, इसलिए वह मरा। क्या यह मर गया क्योंकि इसने कोई समाधान नहीं दिया जो लोग चाहते थे? क्या यह कार्यान्वयन के मुद्दों के कारण मर गया? क्या यह पेटेंट मुद्दों के कारण मर गया? क्या यह बहुत जल्दी था? बहुत देर हो गई? मुझे लगता है कि पिछले अनुभवों से सबक सीखना महत्वपूर्ण है। जहां JSX सफल हुआ है, वहां E4X और E4H क्यों विफल हो गए?

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

अपने विशाल नेस्टेड भावों पर क्या आप आसानी से संरचना देख सकते हैं?

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

(हम आईडीई के साथ भी प्रयोग कर रहे हैं जो आपके लिए वर्चुअल "क्लोजिंग टैग" टिप्पणियां डालते हैं ताकि आप वास्तव में इसे लिखे बिना संरचना को देख सकें।)

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

मेरा अनुभव यह है कि घोषणात्मक बनाम अनिवार्यता वह भेद नहीं है जो यह निर्धारित करने के लिए मायने रखता है कि भाषा को पार्स करना कितना आसान है। (उदाहरण के लिए, एचटीएमएल "घोषणात्मक" है, लेकिन यह सबसे जटिल भाषाओं में से एक हो सकता है जिसे मैंने कभी भी निपटाया है।)

कोड पठनीयता और सरलता जो बदले में अन्य लाभों का एक पूरा समूह चलाती है।

यदि यह मुख्य लाभ है तो यह ऐसी चीज है जिसका हम परीक्षण कर सकते हैं। हम उन इंजीनियरों का मिश्रण ले सकते हैं जो एचटीएमएल, रिएक्ट, आईओएस कोड, एंड्रॉइड कोड, फ़्लटर, कमांड-लाइन ऐप आदि लिखने के आदी हैं, और उनमें से प्रत्येक को विभिन्न सिंटैक्स के साथ प्रस्तुत करते हैं, और उनसे यह वर्णन करने के लिए कहें कि वे क्या सोचते हैं। परिणामी UI जैसा दिखेगा। फिर हम माप सकते हैं कि कौन सा सिंटैक्स सर्वोत्तम परिणाम प्राप्त करता है। @InMatrix यह कुछ ऐसा है जिसे हम एनीमेशन के काम के पूरा होने के बाद देख सकते हैं, हो सकता है?

क्या इस संरचना को अन्य उपकरणों जैसे जीयूआई बिल्डरों द्वारा एक दूसरे के साथ आसानी से हेरफेर किया जा सकता है?

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

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

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

new ListView.builder(
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0,
  itemBuilder: (BuildContext context, int index) {
    return new Text('entry $index');
  },
)

यह इसे ठीक से संभालता है, आप बस यह नहीं जानते कि इसे कैसे करना है।

मेरा मतलब विशेष रूप से JSX था। मैं मानता हूँ कि आपका प्रस्तावित वाक्य-विन्यास समस्या से निपटने का एक पूर्णतः मान्य तरीका होगा।

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

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

वर्षों हो गए हैं और मुझे अब सभी विवरण याद नहीं आ रहे हैं। हालाँकि मेरा समग्र प्रभाव यह है कि मार्कअप और कोड के संयोजन के साथ UI को परिभाषित करना एक मिश्रित बैग है।

वह मरा या नहीं, यह मुद्दा नहीं है, इसलिए वह मरा। क्या यह मर गया क्योंकि इसने कोई समाधान नहीं दिया जो लोग चाहते थे? क्या यह कार्यान्वयन के मुद्दों के कारण मर गया? क्या यह पेटेंट मुद्दों के कारण मर गया? क्या यह बहुत जल्दी था? बहुत देर हो गई? मुझे लगता है कि पिछले अनुभवों से सबक सीखना महत्वपूर्ण है। जहां JSX सफल हुआ है, वहां E4X और E4H क्यों विफल हो गए?

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

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

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

(हम आईडीई के साथ भी प्रयोग कर रहे हैं जो आपके लिए वर्चुअल "क्लोजिंग टैग" टिप्पणियां डालते हैं ताकि आप वास्तव में इसे लिखे बिना संरचना को देख सकें।)

अजीब तरह का लेकिन यह एक्सएमएल क्लोजिंग टैग डालने जैसा है जिसका आपने पहले उल्लेख किया था वह बहुत ही वर्बोज़ था।

यदि यह मुख्य लाभ है तो यह ऐसी चीज है जिसका हम परीक्षण कर सकते हैं। हम उन इंजीनियरों का मिश्रण ले सकते हैं जो एचटीएमएल, रिएक्ट, आईओएस कोड, एंड्रॉइड कोड, फ़्लटर, कमांड-लाइन ऐप आदि लिखने के आदी हैं, और उनमें से प्रत्येक को विभिन्न सिंटैक्स के साथ प्रस्तुत करते हैं, और उनसे यह वर्णन करने के लिए कहें कि वे क्या सोचते हैं। परिणामी UI जैसा दिखेगा। फिर हम माप सकते हैं कि कौन सा सिंटैक्स सर्वोत्तम परिणाम प्राप्त करता है। @InMatrix यह कुछ ऐसा है जिसे हम एनीमेशन के काम के पूरा होने के बाद देख सकते हैं, हो सकता है?

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

बात यह है कि, आप एक्सएमएल संरचना में डार्ट अभिव्यक्ति के समान "कोई भी वैध डार्ट कोड" डाल सकते हैं।

ज़रूर, लेकिन GUI बिल्डरों के लिए यह केवल बाइट्स का एक ब्लॉक है जिसे छूने की आवश्यकता नहीं है और इसे आसानी से छोड़ा जा सकता है। सैद्धांतिक रूप से इसे डिजाइन/कोड इंटरचेंजबिलिटी व्यावहारिक रूप से संभव बनाना।

new ListView.builder(
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0,
  itemBuilder: (BuildContext context, int index) {
    return new Text('entry $index');
  },
)

let style = {
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0
};

<ListView.builder style={style}>
  {(context, index) => <Text> entry {index} </Text>}
</ListView.builder>

मैंने एडोब फ्लेक्स बिल्डर का व्यापक रूप से उपयोग किया है ...

डेवलपर्स ने इसे एक एक्शनस्क्रिप्ट टूल के रूप में देखा।

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

हालाँकि मेरा समग्र प्रभाव यह है कि मार्कअप और कोड के संयोजन के साथ UI को परिभाषित करना एक मिश्रित बैग है।

आज की दुनिया में नहीं। पायथन के दर्शन में अनिवार्य भाषाएँ विकसित हुई हैं और विकास के लिए महान हैं। प्रतिक्रिया के आगमन के साथ एम्बेडेड मार्कअप (एक्सएमएल) के साथ घोषणात्मक तकनीक मुख्यधारा बन गई; और JSON पसंदीदा टेक्स्ट आधारित डेटा प्रारूप बन गया।

E4X केवल एक्शनस्क्रिप्ट में लागू किया गया था

E4X एक ECMA मानक था। मोज़िला ने इसे कुछ समय के लिए भेज दिया, लेकिन फिर इसे हटा दिया (ब्राउज़र विक्रेता के लिए एक बहुत ही असामान्य कदम)। अन्य ब्राउज़र विक्रेता इसे कभी लागू नहीं करना चाहते थे। (हालांकि, उन्होंने अन्य नई ईसीएमए सुविधाओं को लागू किया है।) ई4एच के साथ, ब्राउज़र विक्रेताओं को इसे लागू करने में कभी दिलचस्पी नहीं थी (हालांकि फिर से, उन्होंने कई अन्य चीजों को लागू किया है जिन्हें मैंने आविष्कार करने में मदद की है)।

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

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

अजीब तरह का लेकिन यह एक्सएमएल क्लोजिंग टैग डालने जैसा है जिसका आपने पहले उल्लेख किया था वह बहुत ही वर्बोज़ था।

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

... ListView ...

एक जीयूआई संपादक इस मार्कअप को कैसे संभालेगा? मैं वास्तव में यह नहीं समझता कि इसके लिए UI की कल्पना कैसे करें।

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

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

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

JSX मुझे लगता है कि अन्य मुद्दों को हल करने का लक्ष्य है जहां आप एक साथ मिश्रण करना चाहते हैं जो आप HTML और जावास्क्रिप्ट के साथ कर रहे हैं। यह वास्तव में ऐसा नहीं लगता है कि मार्कअप विनिर्देश की अतिरिक्त जटिलता मार्कअप के साथ UI लिखने की आवश्यकताओं के अनुरूप है। खासकर जब आपके पास लक्ष्य के रूप में वास्तव में दस्तावेज़ मार्कअप भाषा नहीं है। कम से कम रोजमर्रा के उपयोगकर्ता के लिए नहीं।

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

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

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

E4X एक ECMA मानक था। मोज़िला ने इसे कुछ समय के लिए भेज दिया, लेकिन फिर इसे हटा दिया (ब्राउज़र विक्रेता के लिए एक बहुत ही असामान्य कदम)। अन्य ब्राउज़र विक्रेता इसे कभी लागू नहीं करना चाहते थे।

मैं कहूंगा कि केवल Adobe ने E4X को पूरी तरह से चैंपियन बनाया और डेवलपर्स के साथ उसका अच्छा अनुसरण किया। ब्राउज़र विक्रेता हर समय अपने ब्राउज़र से सामान जोड़ते और निकालते हैं; क्या Google ने MathML समर्थन नहीं हटाया?

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

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

एक जीयूआई संपादक इस मार्कअप को कैसे संभालेगा? मैं वास्तव में यह नहीं समझता कि इसके लिए UI की कल्पना कैसे करें।

let style = {
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0
};

<ListView.builder style={style}>
  {(context, index) => <Text> entry {index} </Text>}
</ListView.builder>

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

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

मैं केवल डार्ट कंपाइलर पर इन सरल एक्सटेंशन को जोड़ने के लिए कह रहा हूं ताकि यदि डेवलपर्स चाहें तो वे इस एक्सएमएल संरचना का उपयोग करके लिख सकें। पुराना तरीका काम करना जारी रखेगा और इसमें शामिल काम की मात्रा बहुत बड़ी नहीं है। आप वास्तव में देख सकते हैं कि JSX करने के लिए babel.js कंपाइलर को कोड की कितनी लाइनें लगती हैं और मैं सैकड़ों की बात कर रहा हूं न कि हजारों लाइन (मैंने अभी इसे चेक किया है)।

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

ज़रूर लेकिन रिएक्ट ऐसा ही रहा है और यह कोई मुद्दा नहीं है।

जब मैं प्रलेखन लिखता हूं, तो मुझे इसे दो बार लिखना होता है, एक बार जावा के लिए और एक बार UiBinder XML मार्कअप के लिए।

प्रतिक्रिया में नहीं क्योंकि मार्कअप कोड के अंदर रहता है।

यात्रा के लायक अतिरिक्त जटिलता है!

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

रिएक्ट यूआई/यूएक्स विकसित करने के लिए नवीनतम तकनीकों के साथ यात्रा का नेतृत्व कर रहा है। डेवलपर्स के साथ इसका जबरदस्त कर्षण है। आपका सबसे बड़ा जोखिम रिएक्ट बार से नहीं मिलना है।

JSX मुझे लगता है कि अन्य मुद्दों को हल करना है जहां आप एक साथ मिश्रण करना चाहते हैं जो आप HTML और जावास्क्रिप्ट के साथ कर रहे हैं

JSX सिर्फ HTML के लिए नहीं है, रिएक्ट नेटिव XML मार्कअप से व्यूज (जैसे स्पंदन विजेट) जेनरेट करता है।

मुझे लगता है कि असली सवाल यह है कि यूआई को तेजी से कैसे बनाया जा सकता है।

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

वैसे, डेवलपर टूल पर वास्तव में अच्छा काम किया गया है; कमाल का था 'फड़फड़ाता डॉक्टर'!!!
मैं अब गैस से खाना बना रहा हूं और खतरनाक रूप से रचनात्मक हो सकता हूं;)

मैं यहां उठाए गए पठनीयता प्रश्न का उत्तर देना चाहता हूं, हालांकि मैं समझता हूं कि पठनीयता केवल उन कई कारकों में से एक है जिन पर हमें विचार करने की आवश्यकता है।

कोड पठनीयता और सरलता जो बदले में अन्य लाभों का एक पूरा समूह चलाती है।

यदि यह मुख्य लाभ है तो यह ऐसी चीज है जिसका हम परीक्षण कर सकते हैं। हम उन इंजीनियरों का मिश्रण ले सकते हैं जो एचटीएमएल, रिएक्ट, आईओएस कोड, एंड्रॉइड कोड, फ़्लटर, कमांड-लाइन ऐप आदि लिखने के आदी हैं, और उनमें से प्रत्येक को विभिन्न सिंटैक्स के साथ प्रस्तुत करते हैं, और उनसे यह वर्णन करने के लिए कहें कि वे क्या सोचते हैं। परिणामी UI जैसा दिखेगा। फिर हम माप सकते हैं कि कौन सा सिंटैक्स सर्वोत्तम परिणाम प्राप्त करता है। @InMatrix यह कुछ ऐसा है जिसे हम एनीमेशन के काम के पूरा होने के बाद देख सकते हैं, हो सकता है?

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

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

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

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

यह सिर्फ निर्माण विधि नहीं है। यह अन्य सभी विधियां हैं जिन्हें बिल्ड विधि विजेट ट्री बनाने के लिए कॉल करती है। रिएक्ट में उप-पेड़ के टुकड़े बनाने के लिए छोटे तरीकों का उपयोग करना और फिर उन्हें बड़े पेड़ में कॉल करना बहुत आम है।

जेएसएक्स के साथ वेबस्टॉर्म में भी, प्रत्येक एक्सएमएल नोड में +/- होता है जिसका उपयोग स्क्रीन की ऊंचाई से बड़ी रीडिंग संरचनाओं को आसान बनाने के लिए नोड और बच्चों के विस्तार/पतन के लिए किया जा सकता है।

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

हम लोगों को अपनी निर्माण विधियों को छोटे पुन: प्रयोज्य विगेट्स में तोड़ने के लिए प्रोत्साहित करने का प्रयास करते हैं।

क्या यह वास्तव में एक पुन: प्रयोज्य विजेट या केवल एक रैपर/समग्र विजेट बन जाता है? मेरा मतलब है कि पुन: प्रयोज्य होने के लिए आपके पास कम से कम 2 उपयोग उदाहरण होने चाहिए।

https://flutter.io/catalog/samples/basic-app-bar/ पर AppBar इतना अनूठा है कि आप इसे वास्तव में एक पुन: प्रयोज्य घटक नहीं कह सकते; यह एक रैपर/समग्र घटक है और इन मामलों में यूआई के उस हिस्से को बनाने के लिए स्थानीय विधि का उपयोग क्यों न करें? मुझे लगता है कि अगर यह और चीजें करता है तो इसे एक रैपर/समग्र घटक में रखना समझ में आता है।

स्पंदन में हमने जो एक चीज पाई है, वह यह है कि बड़े निर्माण के तरीके प्रदर्शन के लिए महान नहीं हैं

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

https://flutter.io/catalog/samples/basic-app-bar/ पर AppBar इतना अनूठा है कि आप वास्तव में इसे एक पुन: प्रयोज्य घटक नहीं कह सकते

यह भी अपेक्षाकृत छोटा है, इसलिए यह ठीक है।

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

https://github.com/Kotlin/anko/wiki/Anko-Layouts

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

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

मैं इसमें शामिल लोगों को रिएक्ट नेटिव को एक स्पिन देने के लिए प्रोत्साहित करता हूं और देखता हूं कि हम किस बारे में बात कर रहे हैं।

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

@birkir मैं इस मुद्दे पर आपके साथ 100% हूं। JSX की कमी, जो Flutter के लिए एकदम सही है, Flutter को पुराना और जंग खाए हुए बनाता है, 1990 के दशक की तकनीक की तरह लगता है। वास्तव में ऐसा लगता है कि हर कोई, किसी न किसी रूप में, JSX को अपना रहा है; नवीनतम लोकप्रिय Vue.js ढांचा है।

+1

@zoechi JSX के साथ आपका पिछला अनुभव क्या है, क्या आपने वास्तव में इसका उपयोग किया है या बस इसे देखा है? मुझे लगता है कि आप लोग JSX को यह कहकर कम आंक रहे हैं कि यह यहाँ और वहाँ छोटे लाभ देगा। यदि आपके पास कोई उपयोगकर्ता नहीं है, तो आपके पास कोई उत्पाद नहीं है।

@birkir मुझे यहाँ JSX के बारे में बहुत उत्साह दिखाई देता है, लेकिन कोई भी यह समझाने की जहमत नहीं उठाता कि वास्तव में ऐसे DSL होने से फ़्लटर को क्या हासिल होगा, सिवाय शायद कुछ बेहतर पठनीयता के जो ज्यादातर व्यक्तिपरक है।

अधिक सुविधाएं आमतौर पर इसे सुधारने के बजाय केवल ढांचे को कम कर देती हैं।
उन्हें लागू करने से बहुत सारे संसाधनों की खपत होती है जो अन्य क्षेत्रों से गायब हैं जहां लापता सुविधाएं वास्तव में लोगों को कुछ अनुप्रयोगों को लागू करने से रोकती हैं।

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

फ़्लटर UI कोड को कम वर्बोज़ लिखने के लिए डार्ट को बेहतर बनाने की भी योजना है जो JSX के मामले को और भी कमजोर करता है।

तो आपके ठोस तर्क क्या हैं?

सच में !!! "कोई भी यह समझाने की जहमत नहीं उठाता कि वास्तव में स्पंदन क्या हासिल करेगा ... ब्ला ब्ला ब्ला"।
क्या आपने इस सूत्र को पूरा नहीं पढ़ा? क्या आपका ध्यान आपके JSX ज्ञान से अधिक है?

आप लोग एनआईएच सिंड्रोम से पीड़ित हैं (यहां आविष्कार नहीं किया गया है)। "अच्छे कलाकार नकल करते हैं, महान कलाकार चोरी करते हैं", औसत दर्जे के कलाकार, ठीक है, आपकी तरह व्यवहार करते हैं।

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

क्या हम कृपया वाद-विवाद करते समय रचनात्मक स्वर रख सकते हैं।

सुविधाओं को जोड़ना क्योंकि दूसरों के पास यह कमजोर तर्क है। ठीक।
स्पंदन में हॉट रीलोडिंग क्यों होती है? वह कहां से आया है? यीशु यार।

हम आप लोगों के लिए ठोस तर्क देने में कैसे विफल रहे? प्रोजेक्ट ट्रैक्शन और डेवलपर्स को आकर्षित करना हमारा नंबर एक कारण है।

कारण संख्या दो, पठनीयता :

https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/demo/cupertino/cupertino_buttons_demo.dart बनाम https://gist.github.com/birkir/e921158239c324ab95bb0b174383a562

कारण संख्या तीन, जीयूआई बिल्डर्स । मैं रीडमे में पहली पंक्ति उद्धृत करूंगा।

डेवलपर्स और डिजाइनरों को आईओएस और एंड्रॉइड के लिए आधुनिक मोबाइल ऐप बनाने में मदद करने के लिए एक नया मोबाइल ऐप एसडीके।

मुझे यह देखने से नफरत होगी कि फ़्लटर बीटा तक पहुंचने से पहले पॉलिमर के समान खरगोश के नीचे जा रहा है।

परियोजना कर्षण और डेवलपर्स को आकर्षित करना

संबंध अभी भी अस्पष्ट है।

कारण संख्या दो, पठनीयता:

डार्ट कोड को और अधिक पठनीय बनाना मेरे लिए एक बेहतर लक्ष्य लगता है

कारण संख्या तीन, जीयूआई बिल्डर्स। मैं रीडमे में पहली पंक्ति उद्धृत करूंगा।

जहां तक ​​मुझे याद है, यह पहले से ही ऊपर उल्लेख किया गया था कि ऐसा कोई कारण नहीं है कि डार्ट कोड का उपयोग करने से इसे रोका जा सके।

आपके प्रतिवाद वास्तव में विचार को खारिज नहीं कर सकते, है ना?

1. संबंध काफी स्पष्ट है। जब तक यह परियोजना के लोकप्रिय होने का लक्ष्य नहीं है?
2. महान! क्या यह JSX पठनीयता के करीब होगा? ऐसी चीज के लिए वर्तमान प्रस्ताव क्या है?
3. बताया गया कि किया जा सकता है । वर्तमान में उपलब्ध GUI बिल्डरों के लिए JSX समर्थन को अपनाना कहीं अधिक सरल होगा।

फ़्लटर UI कोड को कम वर्बोज़ लिखने के लिए डार्ट को बेहतर बनाने की भी योजना है

यह स्वीकार करते हुए अच्छा लगा कि वर्तमान तरीका कुछ सुधारों का उपयोग कर सकता है।
कृपया ऐसे प्रस्ताव पर विवरण प्रदान करें। प्रतिक्रिया के लिए प्रतिक्रियाशील मूल समुदाय के साथ बातचीत करना आपकी सबसे अच्छी शर्त है।

कई डार्ट भाषा सुविधा अनुरोध कोड को अधिक छोटा/पठनीय बना सकते हैं:

• डार्ट 2 . के लिए वैकल्पिक new और const
• हर जगह नामित तर्कों की अनुमति देने के प्रस्ताव की चर्चा के लिए मेटा-इश्यू - यह child तर्क वाले विजेट को नामित तर्क को छोड़ने की अनुमति दे सकता है।
  
  
  
  • तर्कों की परिवर्तनीय संख्या - यह children तर्क (जैसे पंक्ति और स्तंभ) वाले विजेट को इस नामित तर्क और इसकी सूची घोषणा को छोड़ने की अनुमति दे सकता है।
  
  

उन परिवर्तनों के साथ कोड इस तरह दिख सकता है:

  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Cupertino Buttons')),
      body: Column(
        Padding(padding: EdgeInsets.all(16.0),
          Text(
            'iOS themed buttons are flat. They can have borders or backgrounds but '
            'only when necessary.'
          ),
        ),
        Expanded(
          Column(mainAxisAlignment: MainAxisAlignment.center,
            Text(_pressedCount > 0
                   ? 'Button pressed $_pressedCount time${_pressedCount == 1 ? "" : "s"}'
                   : ' '),
            Padding(padding: EdgeInsets.all(12.0)),
            Align(alignment: Alignment(0.0, -0.2),
              Row(mainAxisSize: MainAxisSize.min,
                CupertinoButton(onPressed: () { setState(() { _pressedCount += 1; }); },
                  Text('Cupertino Button'),
                ),
                CupertinoButton(onPressed: null,
                  Text('Disabled'),
                ),
              ),
            ),
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: () { setState(() { _pressedCount += 1; }); },
              Text('With Background'),
            ),
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: null,
              Text('Disabled'),
            )
          ),
        ),
      )
    );
  }

इसके अलावा आपके आईडीई के आधार पर आप कोष्ठक के अंत में सिंथेटिक टिप्पणियां कर सकते हैं और आप अपने आईडीई में ऐसा कुछ देख सकते हैं:

  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Cupertino Buttons')),
      body: Column(
        Padding(padding: EdgeInsets.all(16.0),
          Text(
            'iOS themed buttons are flat. They can have borders or backgrounds but '
            'only when necessary.'
          ),
        ),
        Expanded(
          Column(mainAxisAlignment: MainAxisAlignment.center,
            Text(_pressedCount > 0
                   ? 'Button pressed $_pressedCount time${_pressedCount == 1 ? "" : "s"}'
                   : ' '), // Text
            Padding(padding: EdgeInsets.all(12.0)),
            Align(alignment: Alignment(0.0, -0.2),
              Row(mainAxisSize: MainAxisSize.min,
                CupertinoButton(onPressed: () { setState(() { _pressedCount += 1; }); },
                  Text('Cupertino Button'),
                ), // CupertinoButton
                CupertinoButton(onPressed: null,
                  Text('Disabled'),
                ), // CupertinoButton
              ), // Row
            ), // Align
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: () { setState(() { _pressedCount += 1; }); },
              Text('With Background'),
            ), // CupertinoButton
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: null,
              Text('Disabled'),
            ), // CupertinoButton
          ), // Column
        ), // Expanded
      ), // Column
    ); // Scafold
  }

यह बातचीत गर्म हो रही है। मैं सभी को हमारी आचार संहिता पढ़ने के लिए प्रोत्साहित करना चाहता हूं:
https://flutter.io/design-principles/#conflict -resolution
मैं इस बातचीत को कुछ दिनों के लिए बंद करने जा रहा हूं, जबकि हर कोई इस बात पर विचार करता है कि वे कैसे सम्मानपूर्वक और उत्पादक रूप से योगदान दे सकते हैं।

हम सभी जानते हैं कि UI बनाने के लिए सिंटैक्स मोबाइल विकास अनुभव का एक बहुत ही महत्वपूर्ण हिस्सा है। अभी के लिए सिंटैक्स थोड़ा वर्बोज़ है, मुझे मार्जिन जोड़ने के उद्देश्य से new कुछ करना होगा: margin: new EdgeInsets.symmetric(horizontal: 4.0) , मुझे लगता है कि एक आसान तरीका हो सकता है।

क्या एंड्रॉइड डेवलपर्स के लिए कोटलिन टीम ने जो किया है, क्या डीएसएल बनाना संभव होगा? इसे Anko कहा जाता है, Android UI बनाने के लिए एक DSL:

verticalLayout {
  padding = dip(30)
  editText {
    hint = "Name"
    textSize = 24f
  }
  button("Login") {
    textSize = 26f
  }
}

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

कृपया स्पंदन के लिए XML- जैसे सिंटैक्स का परिचय न दें।

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

मुझे लगता है कि कुछ कारणों से मैं स्पंदन में जोड़े गए एक्सएमएल-सिंटैक्स को देखना नहीं चाहता:

1. सीखने की एक और बात - खर्च की जा सकती है इसके बजाय फ्यूचर्स सीखें ;P
2. संदर्भ-स्विचिंग - आप एक्सएमएल और कोड के बीच संदर्भ स्विचिंग कर रहे हैं जो सिर्फ अनावश्यक संज्ञानात्मक भार है।
3. ऐसे दिन रहे हैं जब मैंने सुबह जावा में और दोपहर में पायथन में प्रोग्राम किया है। रिएक्ट के साथ आपको एक कोडबेस में जावास्क्रिप्ट, बैबेल, जेएसएक्स, एचटीएमएल, सीएसएस और बहुत कुछ समझने की आवश्यकता हो सकती है।
4. फ़्लटर में XML की आवश्यकता नहीं होने का कारण यह है कि डार्ट ने तर्कों का नाम दिया है जो XML विशेषताओं को बहुत अच्छी तरह से बदल देता है।
5. डार्ट में बहुत अच्छा डार्टफएमटी है जो बिना किसी प्रयास के कोड को वास्तव में अच्छी तरह से इंडेंट करता है।

एंड्रॉइड की तुलना में

1. आपको वैसे भी प्रोग्रामेटिक तरीके से सीखना है, चीजों को करने का एक और तरीका क्यों जोड़ें?
2. एंड्रॉइड में एक्सएमएल लेआउट डिवाइस पर परिवर्तन प्रदर्शित करने के लिए तेज़ है, लेकिन फ़्लटर में चलना व्यावहारिक रूप से तत्काल है, इसलिए एक्सएमएल जोड़ने से वह लाभ नहीं मिलेगा।
3. एंड्रॉइड एक्सएमएल + प्रोग्रामेटिक संयोजन जटिलता जोड़ता है, जैसे एक्सएमएल स्निपेट्स को फुलाकर और एक्सएमएल ट्री में प्रोग्रामेटिक रूप से इंजेक्ट करना।
4. फ़्लटर में इंस्टेंट रन इतना तेज़ है कि आपको यह देखने में मदद करने के लिए XML मॉडल की आवश्यकता नहीं है कि यह कैसे दिखाई देगा, आप बस एक कुंजी दबा सकते हैं और तुरंत परिवर्तन देख सकते हैं।
5. प्रोग्रामेटिक लेआउट मुद्दों की त्रुटियां एक्सएमएल में लेआउट मुद्दों से अलग हैं, इसलिए आपको चीजों के दो सेट समझने की जरूरत है।

मैं एक कदम और आगे बढ़ूंगा और pubspec.yaml को हटा दूंगा और इसे pubspec.dart से बदल दूंगा और डार्ट कोड में कॉन्फ़िगरेशन रखूंगा।

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

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

मुझे पता है कि यह बातचीत पुरानी है और हाँ यह काफी गर्म हो रही थी, लेकिन मैं यहाँ जो कुछ हो रहा है उसके बारे में कुछ पंक्तियाँ बताना चाहूँगा।

स्पंदन नया है। यह चीजों को करने का एक बिल्कुल नया तरीका है। हां, इसने प्रतिक्रिया प्रतिमान से उधार लिया था। लेकिन इसका मतलब यह नहीं है कि इसे अपने समान चरणों का पालन करने की आवश्यकता है। मुझे नहीं लगता कि इसका स्पंदन टीम का उद्देश्य डेवलपर्स को रिएक्ट नेटिव से स्पंदन में आने के लिए आकर्षित करना है, यह केवल कुछ नया बनाने के लिए है जिसमें डेवलपर्स को रुचि हो सकती है। Google इसे दुनिया के साथ साझा करने से पहले आंतरिक रूप से उपयोग करता है और वे इसके साथ उत्पादक रहे हैं यह। मैं @Hixie के साथ टिप्पणियों को साझा करता हूं कि यह UI बनाने के लिए JSX से अलग नहीं है। हाँ यह शुद्ध डार्ट को सही करने के लिए थोड़ा और क्रिया है। लेकिन यह वास्तव में आपके कोड को डीबग करना बहुत आसान बनाता है।

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

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

वाह, ब्लॉग पोस्ट xD लिख सकते थे

@ रॉकवोल ,

सीखने की एक और बात - खर्च की जा सकती है इसके बजाय फ्यूचर्स सीखें ;P

सीखने की बात वर्तमान पुनरावर्ती वस्तु निर्माण राक्षसी को सरल और रोजमर्रा के रिएक्ट नेटिव देवों से परिचित कराती है, इसलिए मेरा अनुमान है कि लोग इसे सीखना पसंद करेंगे।

संदर्भ-स्विचिंग - आप एक्सएमएल और कोड के बीच संदर्भ स्विचिंग कर रहे हैं जो सिर्फ अनावश्यक संज्ञानात्मक भार है।

कोई समस्या नहीं है, कोई संदर्भ-स्विच नहीं है, यह पर्यावरण का केवल एक हिस्सा है जो प्रोग्रामिंग UI/UX क्लीनर बनाता है।

तब यह स्पंदन कोड उत्पन्न करेगा जिसे कभी भी संपादित करने का इरादा नहीं है

क्यों नहीं? तब बहुत उपयोगी नहीं है।

@फ्रांजसिल्वा

मुझे नहीं लगता कि यह स्पंदन की टीम का उद्देश्य डेवलपर्स को रिएक्ट नेटिव से स्पंदन में आने के लिए आकर्षित करना है

सच में !!! रिएक्ट नेटिव हावी है और यह देखते हुए कि क्रॉस प्लेटफॉर्म टूल्स का उपयोग करने वाले मोबाइल डेवलपर्स की कुल संख्या सीमित है, क्या आपको वास्तव में लगता है कि फ़्लटर रिएक्ट नेटिव लोगों को आकर्षित किए बिना होम रन हिट बन सकता है?

हाँ यह शुद्ध डार्ट को सही करने के लिए थोड़ा और क्रिया है। लेकिन यह वास्तव में आपके कोड को डीबग करना बहुत आसान बनाता है।

यह सही कथन नहीं है। JSX कोड को डिबग करना, जो कि सिर्फ जावास्क्रिप्ट कोड है, कोई आसान या कठिन नहीं है, यह वही है।

मार्कअप लैंग्वेज या JSX या किसी तकनीक के शीर्ष पर बैठने वाली किसी भी चीज के खिलाफ होने का कारण यह है कि इसके लिए प्लेटफॉर्म से बहुत अधिक काम करने की आवश्यकता होती है।

कौन परवाह करता है कि मंच में कितना काम रखा गया था? देव केवल नवीनतम तकनीक चाहते हैं जो कोड पठनीयता और उत्पादकता में सुधार करें। कोई भी देव पुरानी और अप्रचलित तकनीकों का उपयोग नहीं करना चाहता जब नई चीजें बेहतर विकल्प प्रदान करती हैं।

मैं यह जानना पसंद करता हूं कि कोड में वास्तव में क्या हो रहा है और जादुई सिंटेक्स की तुलना में जो हो रहा है उस पर नियंत्रण है कि इसके सभी काम ओवरहेड जोड़ रहे हैं।

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

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

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

आइए @xinthink से ठोस उदाहरण लें:

अभी के लिए सिंटैक्स थोड़ा वर्बोज़ है, मुझे मार्जिन जोड़ने के उद्देश्य से new कुछ करना होगा: margin: new EdgeInsets.symmetric(horizontal: 4.0) , मुझे लगता है कि एक आसान तरीका हो सकता है।

यदि आप बाएँ और दाएँ मार्जिन जोड़ना चाहते हैं, तो आप इसे कैसे व्यक्त करना चाहेंगे? विशेष रूप से, आइए हम एक सरल उदाहरण लेते हैं, और देखते हैं कि यह विभिन्न वाक्यविन्यासों में कैसा दिखेगा।

  // Flutter as written today
  return new Container(
    margin: new EdgeInsets.symmetric(horizontal: 4.0),
    decoration: new ShapeDecoration(shape: new CircleBorder(), color: Colors.blue[100]),
    child: new AnimatedCrossFade(
      duration: const Duration(seconds: 3),
      firstChild: const FlutterLogo(style: FlutterLogoStyle.horizontal, size: 100.0),
      secondChild: const FlutterLogo(style: FlutterLogoStyle.stacked, size: 100.0),
      crossFadeState: _showHorizontal ? CrossFadeState.showFirst : CrossFadeState.showSecond,
    ),
  );

  // Flutter as written later this year once we remove "new" and "const" keywords
  return Container(
    margin: EdgeInsets.symmetric(horizontal: 4.0),
    decoration: ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100]),
    child: AnimatedCrossFade(
      duration: Duration(seconds: 3),
      firstChild: FlutterLogo(style: FlutterLogoStyle.horizontal, size: 100.0),
      secondChild: FlutterLogo(style: FlutterLogoStyle.stacked, size: 100.0),
      crossFadeState: _showHorizontal ? CrossFadeState.showFirst : CrossFadeState.showSecond,
    ),
  );

आप कैसे सलाह देंगे कि हम इन _सटीक_ शब्दार्थों को व्यक्त करें?

  // Remove "new" and "const", infer the class for enum values, allow int literals for doubles
  return Container(
    margin: EdgeInsets.symmetric(horizontal: 4),
    decoration: ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100]),
    child: AnimatedCrossFade(
      duration: Duration(seconds: 3),
      firstChild: FlutterLogo(style: horizontal, size: 100),
      secondChild: FlutterLogo(style: stacked, size: 100),
      crossFadeState: _showHorizontal ? showFirst : showSecond,
    ),
  );

Babel.js की यह साफ-सुथरी छोटी वेबसाइट है, जहाँ आप JSX टाइप कर सकते हैं और यह इसे सादे जावास्क्रिप्ट में बदल देता है:
https://babeljs.io/repl/# ?babili=false&evaluate=true&lineWrap=false&presets=es2015%2Creact%2Cstage-0&code=function%20hello()%20%7B%0A%20%20return%20%3Cdiv%3EHello% 20वर्ल्ड!%3C%2Fdiv%3E%3B%0A%7D

मैं DSX से डार्ट के लिए एक समान कार्य करूंगा। केवल अवधारणा का प्रमाण, देखते हैं कि इसमें मुझे कितना समय लगता है...

Airbnb की स्टाइल गाइड का उपयोग करते हुए और यह मानते हुए कि सभी चाइल्ड एलिमेंट स्वचालित रूप से child प्रॉपर्टीज को मैप कर सकते हैं, "DSX" में @ हिक्सी का नवीनतम उदाहरण यहां दिया गया है।

return (
  <Container
    margin={EdgeInsets.symmetric(horizontal: 4)}
    decoration={ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100])}
  >
    <AnimatedCrossFade
        duration={Duration(seconds: 3)}
        crossFadeState={_showHorizontal ? showFirst : showSecond}
    >
      <FlutterLogo style={horizontal} size={100} />
      <FlutterLogo style={stacked} size={100} />
    </AnimatedCrossFade>
  </Container>
);

अगर इरादा पठनीयता में सुधार करना है, तो मुझे लगता है कि भविष्य में डार्ट हुकुम में जीत जाएगा।

आपको यह जानने के लिए दस्तावेज़ीकरण की जांच करनी होगी कि टैग में क्या बदल सकता है (संभवतः केवल Widget s), या कितने बाल तत्वों की आवश्यकता/अनुमति है।

यदि आपका लक्ष्य जावास्क्रिप्ट से HTML को आउटपुट करना है, तो JSX एक मध्य मैदान के रूप में बहुत मायने रखता है। क्योंकि जब आप दिन के अंत में टैग चाहते हैं, तो React.createElement('div', null, 'foo') <div>foo</div> से कहीं अधिक खराब है।

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

एक्सएमएल का उपयोग करने से यह सक्षम होता है... देखिए, बात करते हुए 5 महीने हो गए हैं, अब मैं इसके बारे में कुछ कर रहा हूं इसलिए मुझे कुछ समय दें (मेरे पास पूर्णकालिक नौकरी है और सप्ताहांत में केवल 4 घंटे ही छोड़ सकता हूं)।

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

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

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

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

वेब डेवलपर्स समुदाय में रिएक्ट के लोकप्रिय होने का एक मुख्य कारण JSX का समर्थन था।

इतने अच्छे फीचर अनुरोध पर "डाउन वोट" देखना वाकई निराशाजनक है। यह पठनीयता में सुधार करता है और अपनाने में तेजी लाता है।

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

नए विचारों के लिए और जगह बनाएं!

@jayjun यह अद्भुत लग रहा है! क्या मैं इसे कहीं कोशिश कर सकता हूँ?

@sanketsahusoft बहुत जल्द चिंता न करें आप मेरे संस्करण को आजमा सकेंगे और यह @jayjun से भी बेहतर है।

त्वरित अद्यतन: 2 सप्ताहांत पहले मुझे यूआई बहुत अच्छा काम कर रहा था, पिछले सप्ताहांत में मुझे पार्सर पूरी तरह से काम कर रहा था और आधा ट्रांसपिलर काम कर रहा था। अगर मैं सुपरबॉवेल से बचता हूं तो आने वाले सप्ताहांत में मैं इसे खत्म करने की उम्मीद करता हूं;)

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

कार्लोस।

क्या इससे क्लोजिंग टैग का ट्रैक खोने की समस्या में मदद मिलेगी?
आइडिया: ऑटो जेनरेटेड क्लोजिंग टैग

यहाँ @Hixie के उदाहरण के लिए कुछ प्रस्तावित मार्कअप सिंटैक्स दिया गया है:

<Container margin=<EdgeInsets.symmetric horizontal=4 />
           decoration=<ShapeDecoration shape=<CircleBorder> color={{ Colors.blue[100] }} />>
    <AnimatedCrossFade duration=<Duration seconds=3 />
                       crossFadeState={{ _showHorizontal ? showFirst : showSecond }}>
      <FlutterLogo style=horizontal size=100 />
      <FlutterLogo style=stacked size=100 />
    </AnimatedCrossFade>
</Container>

@abarth , आपके द्वारा की गई दिलचस्प बात एक तीसरी विशेषता संभावना है जो एक और टैग होने पर अभिव्यक्तियों के रूप को सरल बनाती है।
जेएसएक्स में है:
1 - <tag attrib=""/> या <tag attrib=''/>
2 - <tag attrib={}/>
आपने एक और सुझाव दिया:
3 - <tag attrib=<anotherTag.../>/>
JSX के साथ आपको इसे इस प्रकार लिखना होगा:
<tag attrib={<anotherTag.../>}/>

@cbazza हाँ, स्पंदन में तीसरा मामला काफी सामान्य है, इसलिए अतिरिक्त { नेस्टिंग को छोड़ना समझ में आता है।

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

@cbazza कूल, मैं FutureBuilder जैसे बंद होने वाले कई विजेट का उपयोग करता हूं। मुझे आशा है कि आपका ट्रांसपिलर कुछ ऐसा उत्पन्न कर सकता है,

return new FutureBuilder(
  future: Firestore.instance
      .collection('stuff')
      .document(id)
      .get(),
  builder: (context, snapshot) {
    if (!snapshot.hasData) {
      switch (snapshot.connectionState) {
        case ConnectionState.waiting:
          return const Text('Loading...');
        default:
          return new Text('${id} not found');
      }
    }

    return new Text(snapshot.data['name']);
  },
);

@jayjun , हाँ, यह कोई समस्या नहीं है। ट्रांसपिलर एक साधारण एक्सएमएल प्रोसेसर है और जब पार्सिंग एक्सप्रेशन ({} के अंदर सब कुछ) की बात आती है, तो यह सिर्फ एक टेक्स्ट ब्लॉब बन जाता है, इसलिए यह इसे शब्दशः लिखता है।

@xinthink

क्या एंड्रॉइड डेवलपर्स के लिए कोटलिन टीम ने जो किया है, क्या डीएसएल बनाना संभव होगा?

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

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

बस केह रहा हू।

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

डार्ट, कोटलिन और स्विफ्ट सभी में समानताएं हैं:
https://sethladd.github.io/swift-is-like-kotlin-and-kinda-like-dart/

मुझे वह पसंद है :

1. यदि आप जावा से आते हैं तो डार्ट अधिक परिचित है।
2. आप अपने डार्ट कौशल ले सकते हैं और उनका उपयोग वेब पेज बनाने के लिए कर सकते हैं - जो ऐप बनाते समय मूल्यवान है, आप वेब पर सुविधाओं का निर्माण कर सकते हैं (और उन्हें वेबव्यू में दिखा सकते हैं) जहां यह अधिक समझ में आता है (शायद त्वरित व्यवस्थापक पृष्ठ या उत्पाद लिस्टिंग जो Google अनुक्रमित होने की आवश्यकता है)।
3. डार्ट शुरू से ही जावास्क्रिप्ट को संकलित करने के लिए बनाया गया था जो मुझे लगता है कि बाद में किसी भाषा में जोड़ना आसान नहीं है।

मूल रूप से यही कारण हैं कि मैंने डार्ट को कोटलिन / स्विफ्ट / रिएक्ट पर चुना।

_हालांकि डार्ट और स्विफ्ट को गूगल के नए फ्यूशिया ओएस में सपोर्ट करने का निर्णय मुझे भ्रमित कर रहा है।_

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

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

वेब पर रिएक्ट के लिए उपलब्ध विभिन्न सिंटैक्स पर एक नज़र डालें:
https://github.com/Workiva/over_react#fluent -style-component-consumption
दोनों डार्ट संस्करणों में JSX के खिलाफ कोई मौका नहीं है !!!

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

प्रोटोटाइप कब तक? मुझे इसका इस्तेमाल करना अच्छा लगेगा!

मैंने कुछ समय के लिए रिएक्ट का उपयोग किया, और JSX ने मेरी उत्पादकता को दस गुना बढ़ा दिया। यह एक विवादास्पद मुद्दा नहीं है: अन्य टीमों ने सही ढंग से फैसला किया कि यह बेहतर होगा, तो स्पंदन क्यों नहीं? (बयानबाजी: मैंने धागा पढ़ा... (चेहरे की हथेली))

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

कुछ दिलचस्प चीजें जिनके साथ मैं प्रयोग कर रहा हूं:
1) बाल टैग पर एक्सएमएल नेमस्पेस का उपयोग करना ताकि वे माता-पिता में सही डार्ट नामित तर्क के साथ सम्मिलित हो जाएं।
2) गुणों की तरह शैली को बेहतर ढंग से व्यवस्थित करने के लिए ऑपरेटर को फैलाएं ताकि उन्हें मानचित्र में एक्सएमएल के बाहर परिभाषित/समूहीकृत किया जा सके और फिर सामान्य प्रतिक्रिया सामग्री जैसे टैग पर लाया और फैलाया जा सके।
3) स्टाइलसीएसएस संपत्ति जो सीएसएस से स्पंदन शैलियों को उत्पन्न करती है।

(1) और (2) सामान्य हैं इसलिए सभी डार्ट स्पंदन कोड के लिए काम करता है।
(3) स्पंदन विजेट (कंटेनर, टेक्स्ट, आदि) के लिए विशिष्ट है और मैं अभी केवल उन 2 को कर रहा हूं।

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

सिर्फ इसलिए कि जेएस के लिए कुछ काम करता है इसका मतलब यह नहीं है कि यह डार्ट के लिए एक अच्छा विचार है।

JSX भाषा की परवाह किए बिना प्रतिक्रियाशील ढांचे में UI/UX विकास के लिए एक अविश्वसनीय विचार है। अगर मेरे पास अधिक खाली समय होता तो मैं LSX डालता जो लोगो के लिए JSX है;)

मैं नहीं देखता कि 2 भाषाएं एक से बेहतर क्यों होंगी।

आप आईओएस को ऑब्जेक्टिव-सी और स्विफ्ट (2 भाषाओं) के साथ प्रोग्राम कर सकते हैं
आप जावा और कोटलिन (2 भाषाओं) के साथ एंड्रॉइड प्रोग्राम कर सकते हैं
...

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

@cbazza

आप आईओएस को ऑब्जेक्टिव-सी और स्विफ्ट (2 भाषाओं) के साथ प्रोग्राम कर सकते हैं
आप जावा और कोटलिन (2 भाषाओं) के साथ एंड्रॉइड प्रोग्राम कर सकते हैं

यह JSX चर्चा से कैसे संबंधित है? इसे एक फायदा कैसे माना जा सकता है?
आप आईओएस पर स्विफ्ट का उपयोग कर सकते हैं क्योंकि यह ऑब्जेक्टिव-सी का उत्तराधिकारी है।
आप एंड्रॉइड पर कोटलिन का उपयोग कर सकते हैं क्योंकि इसे जावा में एक आसान सुधार माना जाता है।
ऐसा लगता है कि आप तर्क देते हैं कि JSX को डार्ट की जगह लेनी चाहिए। यह मेरे लिए ज्यादा मायने नहीं रखता।

@zoechi

यह JSX चर्चा से कैसे संबंधित है? इसे एक फायदा कैसे माना जा सकता है?
आप आईओएस पर स्विफ्ट का उपयोग कर सकते हैं क्योंकि यह ऑब्जेक्टिव-सी का उत्तराधिकारी है।
आप एंड्रॉइड पर कोटलिन का उपयोग कर सकते हैं क्योंकि इसे जावा में एक आसान सुधार माना जाता है।
ऐसा लगता है कि आप तर्क देते हैं कि JSX को डार्ट की जगह लेनी चाहिए। यह मेरे लिए ज्यादा मायने नहीं रखता।

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

@cbazza यह वही है

सादा डार्ट पर वास्तविक लाभ क्या है?

"जेएसएक्स एक हल्का सुधार है" किसी भी तरह से आश्वस्त नहीं है और यह कोई तर्क नहीं है।
यह सिर्फ एक व्यक्तिगत राय है (फिर से) इसका समर्थन करने के लिए किसी भी तर्क के बिना,
उपरोक्त अन्य प्रो-जेएसएक्स तर्कों के समान।

यदि आप अच्छे तर्क देने के इच्छुक नहीं हैं तो आप किसी से आपके सुझावों पर विचार करने की अपेक्षा नहीं कर सकते।

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

@zoechi 'अच्छे' तर्कों के लिए एक टूटे हुए रिकॉर्ड की तरह लगता है, पहले बहुत कुछ दिया गया था लेकिन आपको यह नहीं मिला; जो ठीक है, 'प्रत्येक के लिए अपना'।

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

वास्तव में नहीं, मेरा काम लगभग तैयार है और मुझे यह देखते हुए बहुत कम समय लगा कि मैंने केवल सप्ताहांत में ही इस पर काम किया है।

फिर से, DSX केवल एक हल्का सुधार है जिसे लोग उपयोग करना चुन सकते हैं या नहीं, क्योंकि यह वर्तमान तरीके को नहीं बदलता है, यह केवल एक विकल्प प्रदान करता है जिससे अन्य (रिएक्ट डेवलपर्स) तुरंत परिचित होंगे।

@cbazza

खूब दिए गए

ज़रूरी नहीं। केवल सामान्य दावे जो सच हो सकते हैं या नहीं।
कोई अतिरिक्त विवरण प्रदान नहीं किया गया जो दूसरों को सत्यापित करने की अनुमति देगा।

सच में नहीं, मेरा काम लगभग तैयार है

महान। फिर फ़्लटर टीम को कुछ भी करने की ज़रूरत नहीं है और इस मुद्दे को बंद किया जा सकता है; पी
क्या इसमें फ़्लटर द्वारा समर्थित सभी IDE में समर्थन स्वतः पूर्णता और सिंटैक्स जाँच शामिल है?

महान। फिर फ़्लटर टीम को कुछ भी करने की ज़रूरत नहीं है और इस मुद्दे को बंद किया जा सकता है; पी

;)

क्या इसमें फ़्लटर द्वारा समर्थित सभी IDE में समर्थन स्वतः पूर्णता और सिंटैक्स जाँच शामिल है?

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

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

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

https://blog.dantup.com/2014/08/you-have-ruined-html/

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

ऊपर दिए गए लेख में यह इतना गलत है, JSX के बिना प्रतिक्रिया मूल रूप से न के बराबर है और सभी प्रतिक्रियाशील वेब ढांचे अपने DSL पर मार्कअप और प्रोग्रामिंग के मिश्रण की अनुमति देते हैं।

समय आ गया है...
यह बहुत खुशी की बात है कि मैं ऑनलाइन DSX ट्रांसपिलर की घोषणा कर रहा हूं
https://spark-heroku-dsx.herokuapp.com/index.html

ट्रांसपिलर cbazza के साथ अच्छा काम
एक बात मैं कहूंगा कि JSX के साथ पालन करना आसान है क्लोजिंग टैग। जिस विचार का मैंने पहले उल्लेख किया था:
आइडिया: ऑटो जेनरेटेड क्लोजिंग टैग

आपके पहले उदाहरण में, स्पंदन कोड देगा (भविष्य में डार्ट में वैकल्पिक नया हटा दिया गया):

Material(
  child: Column(
    children: <Widget>[
      MyAppBar(
        title: Text(
          'Example title',
          style: Theme.of(context).primaryTextTheme.title,
        )-Text,
      )-MyAppBar,
      Expanded(
        child: Center(
          child: Text(
            'Hello, world!',
          )-Text,
        )-Center,
      )-Expanded,
    ],
  )-Column,
)-Material;

@cbazza मैं समुदाय और उन लोगों के लिए आपके काम की सराहना करता हूं जो इस तरह से UI बनाना चाहते हैं, लेकिन मुझे वास्तव में उम्मीद है कि मुझे फ़्लटर में ऐसा कुछ भी उपयोग करने के लिए मजबूर नहीं किया जाएगा :-((

फ़्लटर के लिए एक नवागंतुक के रूप में, लेकिन रिएक्ट से बहुत परिचित, कुछ चीजें मेरे सामने थीं:

• राज्य प्रबंधन मॉडल काफी हद तक समान है
• विजेट/घटक वर्चुअल रेंडर ट्री काफी हद तक समान है
• राज्य और घटक मॉडल को जानने के बाद, मैं मूल रूप से कुछ डार्ट विनिर्देशों और प्लेटफ़ॉर्म एपीआई को छोड़कर, अब एक ऐप लिखने के लिए तैयार हूं, लेकिन ...
• स्टाइलिंग भाषा एक ठोकर है। मैं https://flutter.io/web-analogs/ की बात कर रहा हूं, लेकिन यह पता लगाना आसान नहीं है कि चीजों को काम करने के लिए कौन से आयात की आवश्यकता है (EdgeInset? Color?) या जब मुझे क्लास इंस्टेंस के बजाय प्राइमेटिव का उपयोग करना चाहिए।
• @cbazza के DSX कनवर्टर से CSS पार्सर फ़्लटर मॉडल में लेआउट समकक्षों का पता लगाने के लिए वास्तव में उपयोगी है।

जेएसएक्स के बारे में:

• मुझे नहीं लगता कि स्पंदन पैटर्न का समर्थन करने के लिए नए JSX सिंटैक्स का आविष्कार करना आवश्यक है। इस थ्रेड में कुछ सिंटैक्स क्विबल्स को कुछ नए रिएक्ट पैटर्न का उपयोग करके हल किया जा सकता है जैसे उच्च-आदेश-घटक (फ़ंक्शन जो घटक वर्ग बनाते हैं) और प्रोप प्रस्तुत करते हैं (घटक जो तर्क के रूप में कार्य करते हैं; फ़ंक्शन रिटर्न तत्व)। उदाहरण के लिए, "चाइल्ड स्लॉट्स" नाम JSX में कुछ इस तरह से अनुवाद कर सकता है:

<Item
  right={() => new Text("Right")} {/* a named slot */}
  left={() => new Text("Left")}> {/* another named slot */}
  <ChildOne /> {/* generic children prop with 2 children */}
  <ChildTwo>
    <NestedChild />
  </ChildTwo>
</Item>

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

मुझे अभी भी लगता है, एंगुलर, रिएक्ट, आदि के साथ कुछ अनुभव के साथ स्पंदन के लिए एक नवागंतुक के रूप में, नियमित डार्ट तरीका, और डार्ट 2.0 में अधिक, इस डीएसएक्स से बेहतर है। यह कुछ एक्सएमएल और सीएसएस-ईश पैरामीटर से ज्यादा समझ में आता है। ‍♂️

@cbazza आपके दूसरे डेमो उदाहरण में डार्ट के 391 (दोनों रिक्त स्थान के बिना) की तुलना में 466 वर्ण हैं। मेरे लिए यह नेत्रहीन फूला हुआ दिखता है। मुझे यह शब्दार्थ सीखना होगा, जो मुझे सामान्य डार्ट कोड के साथ नहीं करना है। और मुझे नहीं पता कि इसके साथ सामान्य प्रयोजन प्रोग्रामिंग प्रतिमानों का उपयोग कैसे करें (यदि, प्रत्येक के लिए, आदि)।

अगर मेरे पास विकल्प होता, तो मैं वर्तमान मॉडल के साथ रहूंगा।

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

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

अगर लोग वास्तव में अब JSX जैसा सिंटैक्स चाहते हैं, तो समुदाय संचालित प्रयास जाने का रास्ता लगता है। और यह मामला बनाने में मदद करेगा (या नहीं) जब फ़्लटर टीम 1.0 रिलीज के बाद इसे मानती है।

व्यक्तिगत रूप से मैं निम्नलिखित तर्क से दृढ़ता से सहमत हूं: ऐसा इसलिए नहीं है क्योंकि JSX रिएक्ट के लिए काम करता है (जहां आप पहले से ही एक मार्कअप भाषा का उपयोग करके UI का निर्माण कर रहे हैं) कि यह स्वचालित रूप से फ़्लटर के लिए काम करता है।

@tehfailsafe

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

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

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

ऐसा इसलिए है क्योंकि वेब को उस तरह के सिस्टम के लिए डिज़ाइन नहीं किया गया था। यदि आपके पास HTML जैसी स्थिर मार्कअप भाषा है और आप इसे "गतिशील" करना चाहते हैं, तो आपको एक ऐसी प्रणाली का आविष्कार करना होगा, जिसके ऊपर काम करने की आवश्यकता हो। आप जिस चीज के साथ समाप्त होंगे वह कुछ निर्माण है जो अंतर्निहित मंच द्वारा विवश है।
(देखें: https://gbracha.blogspot.de/2014/09/a-domain-of-shadows.html)

दूसरी ओर स्पंदन की कोई मार्कअप भाषा नहीं है। मुझे अभी तक संसाधनों को कम गतिशील और कम अभिव्यंजक चीज़ों में निवेश करने का कोई कारण नहीं दिख रहा है।

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

इसके अलावा, धन्यवाद @cbazza :)

@यूरी-कई गुना

मुझे नहीं लगता कि यहां किसी को संदेह है कि JSX रिएक्ट क्लासिक रिएक्ट पर एक सुधार है। लेकिन जैसा मैंने कहा, वह समाधान अंतर्निहित प्लेटफॉर्म के गुणों से संबंधित समस्याओं के कारण बनाया गया था। स्पंदन में ये गुण नहीं हैं।

प्रश्न यह नहीं है कि 'क्या JSX प्रतिक्रिया के लिए सहायक है?' सवाल यह है कि 'क्या JSX जैसा कुछ स्पंदन के लिए मददगार है?'।

मेरा मानना ​​है कि उत्तर नहीं है।

विचार करने के लिए कुछ अन्य चीजें हैं:

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

ट्रांसपिलर cbazza के साथ अच्छा काम

@ रॉकवोल , धन्यवाद।

मैं समुदाय और उन लोगों के लिए आपके काम की सराहना करता हूं जो इस तरह से यूआई बनाना चाहते हैं, लेकिन मुझे वास्तव में उम्मीद है कि मुझे स्पंदन में ऐसा कुछ भी उपयोग करने के लिए मजबूर नहीं किया जाएगा :-((

@zoechi , धन्यवाद। हाँ, यह उन लोगों के लिए एक और विकल्प है जो JSX का उपयोग करना पसंद करते हैं। अगर यह आपकी बात नहीं है तो अच्छा है जैसे आप कर रहे हैं वैसे ही करते रहें, वहां कुछ भी नहीं बदलता है।

मुझे नहीं लगता कि स्पंदन पैटर्न का समर्थन करने के लिए नए JSX सिंटैक्स का आविष्कार करना आवश्यक है।

@alexkrolick , हाँ आप नामित मापदंडों के लिए रेंडर प्रॉप्स का उपयोग कर सकते हैं, लेकिन ऐसा कुछ भी नहीं है जो आप स्थितीय मापदंडों के बारे में कर सकते हैं। कुंजी यह थी कि मैं ट्रांसपिलर में कुछ भी हार्ड कोड नहीं करना चाहता था ताकि यह हर चीज के लिए काम करे।

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

@tenhobi , महान उपयोग तब, जाहिर है DSX सभी के लिए नहीं है।

अगर मेरे पास विकल्प होता, तो मैं वर्तमान मॉडल के साथ ही रहता।

@ बी-स्ट्रॉस, यह प्रतिस्थापन नहीं है, यह उन लोगों के लिए एक विकल्प है जो जेएसएक्स पसंद करते हैं।

प्यार और नफरत है, लेकिन ज्यादातर राय सादे डार्ट पर जेएसएक्स की उपयोगिता पर भिन्न होती है।

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

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

@tehfailsafe , सुनने के लिए धन्यवाद !!! आपने सिर पर कील ठोक दी है कि किसी चीज का इतना बड़ा प्रतिरोध क्यों है जो रिएक्ट नेटिव लोगों को वास्तव में खुश कर देगा।

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

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

दूसरी ओर स्पंदन की कोई मार्कअप भाषा नहीं है। मुझे अभी तक संसाधनों को कम गतिशील और कम अभिव्यंजक चीज़ों में निवेश करने का कोई कारण नहीं दिख रहा है।

@ बी-स्ट्रॉस, डीएसएक्स सादे डार्ट की तुलना में 'कम गतिशील' और 'कम अभिव्यंजक' कैसे है? डीएसएक्स डार्ट है क्या आपने ट्रांसपिलर की कोशिश नहीं की।

@ यूरी-कई गुना, धन्यवाद।

प्रश्न यह नहीं है कि 'क्या JSX प्रतिक्रिया के लिए सहायक है?' सवाल यह है कि 'क्या JSX जैसा कुछ स्पंदन के लिए मददगार है?'।

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

@alexkrolick , बहुत अच्छी टिप्पणियां।

@cbazza

यह प्रतिस्थापन नहीं है, यह उन लोगों के लिए एक विकल्प है जो JSX पसंद करते हैं।

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

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

तो आप प्रस्तावित करते हैं कि स्पंदन टीम को ऐसी किसी चीज़ के लिए सुविधाओं को रोकना चाहिए जो संदिग्ध है और वेब डेवलपर्स के एक विशिष्ट सबसेट के एक अंश को आकर्षित कर सकती है या नहीं भी कर सकती है?

सादा डार्ट की तुलना में DSX 'कम गतिशील' और 'कम अभिव्यंजक' कैसे है? डीएसएक्स डार्ट है क्या आपने ट्रांसपिलर की कोशिश नहीं की।

प्रत्येक डीएसएल परिभाषा के अनुसार जीपीएल से कम अभिव्यंजक है। DSX के साथ मैं किसी विजेट को सशर्त रूप से कैसे छिपाऊं? मैं एक संग्रह पर पुनरावृति कैसे करूं और प्रत्येक तत्व को एक विजेट में मैप करूं? मैं एक स्विच का उपयोग कैसे करूं? अब आपको अपने जीपीएल में पहले से मौजूद संरचनाओं के लिए वाक्यविन्यास और अर्थशास्त्र बनाना होगा। तो डीएसएल का आविष्कार पहले स्थान पर क्यों करें?

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

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

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

@ बी-स्ट्रॉस स्पष्ट होने के लिए, जेएसएक्स फ़ंक्शन कॉल के लिए संकलित करता है (रिएक्ट कॉल में createElement(ComponentClass) , डार्ट में यह कंस्ट्रक्टर होना चाहिए)।

<A property="a" />
new A(property: a)

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

केवल निर्माण तत्व नाम + विशेषताओं और फ़ंक्शन कॉल + तर्कों, और बच निकले अभिव्यक्तियों ( {...} ) के बीच परिवर्तन हैं।

• DSX के साथ मैं किसी विजेट को सशर्त रूप से कैसे छिपाऊं?

(JS)
  { condition && <A /> }
  { condition ? <A /> : <B /> }

• मैं एक संग्रह पर पुनरावृति कैसे करूं और प्रत्येक तत्व को एक विजेट में मैप करूं?

(JS)
  { ['a', 'b'].map(i => <A property={i} />) }

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

तो आप प्रस्तावित करते हैं कि स्पंदन टीम को ऐसी किसी चीज़ के लिए सुविधाओं को रोकना चाहिए जो संदिग्ध है और वेब डेवलपर्स के एक विशिष्ट सबसेट के एक अंश को आकर्षित कर सकती है या नहीं भी कर सकती है?

@ बी-स्ट्रॉस, रिएक्ट नेटिव वेब डेवलपमेंट नहीं है, यह क्रॉस प्लेटफॉर्म मोबाइल डेवलपमेंट है जो स्पंदन का मुख्य प्रतियोगी है; और हाँ JSX एक प्रकाश स्रोत की तरह है, यह बहुत सारे रिएक्ट नेटिव देवों को आकर्षित करेगा। मैंने अगस्त 2017 में इस सुविधा के लिए कहा था, बहुत अधिक बोलती हुई बहुत कम कार्रवाई।

प्रत्येक डीएसएल परिभाषा के अनुसार जीपीएल से कम अभिव्यंजक है। DSX के साथ मैं किसी विजेट को सशर्त रूप से कैसे छिपाऊं? मैं एक संग्रह पर पुनरावृति कैसे करूं और प्रत्येक तत्व को एक विजेट में मैप करूं? मैं एक स्विच का उपयोग कैसे करूं? अब आपको अपने जीपीएल में पहले से मौजूद संरचनाओं के लिए वाक्यविन्यास और अर्थशास्त्र बनाना होगा। तो डीएसएल का आविष्कार पहले स्थान पर क्यों करें?

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

DSL किन समस्याओं का समाधान करेगा जिनका आप अभी समाधान नहीं कर सकते हैं?

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

आप कहते रहते हैं कि यह बेहतर है, यह बेहतर क्यों है?

मैंने पहले अपने कारण बताए और उन्हें यहां नहीं दोहराऊंगा। JSX के लोग मुझसे सहमत होंगे लेकिन 'अपने-अपने' से।

मुझे इसमें कोई संदेह नहीं है कि DSX कुछ JSX लोगों को आकर्षित करेगा। मैं जानता हूं कि लोगों को अलग-अलग चीजें पसंद नहीं आतीं। और परिचित ही एकमात्र तर्क प्रतीत होता है। तो सीएसएस का उपयोग क्यों न करें?
जावास्क्रिप्ट का उपयोग क्यों नहीं करें? डार्ट से अधिक लोग इनका उपयोग करना जानते हैं।

हाँ, CSS का उपयोग करना डिज़ाइनर-डेवलपर वर्कफ़्लो को आसान बनाने के लिए समझ में आता है। डीएसएक्स इसका समर्थन करता है। जावास्क्रिप्ट पर डार्ट का लाभ निष्पादन गति (प्रदर्शन) है।

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

आप गलत पूर्वाग्रहों से इतने भरे हुए हैं कि सबसे अधिक संभावना है कि आप अपनी पूरी क्षमता तक पहुँचने से रोक रहे हैं। अपना दिमाग खोलो, अलग-अलग चीजों को आजमाओ।

@alexkrolick , विवरण के लिए धन्यवाद।

@cbazza

आप गलत पूर्वाग्रहों से इतने भरे हुए हैं कि सबसे अधिक संभावना है कि आप अपनी पूरी क्षमता तक पहुँचने से रोक रहे हैं। अपना दिमाग खोलो, अलग-अलग चीजों को आजमाओ।

मैं अब इस मुद्दे से सदस्यता समाप्त करूंगा। कृपया मुझे यहां या कहीं भी फिर कभी उल्लेख न करें, thx।

@ बी-स्ट्रॉस

सॉरी यार, मेरा मतलब आपकी भावनाओं को ठेस पहुँचाना नहीं था... मैं अपनी कुंठाओं को प्रबंधित करने की कोशिश करते हुए बस धीरे से आपका मार्गदर्शन करने की कोशिश कर रहा था। आखिर हम सब इंसान हैं।

@cbazza क्या आप कृपया मुझे एक ईमेल भेज सकते हैं? [email protected]

यह प्रस्ताव पुराने सूत्र में पहले ही बना दिया था लेकिन मुझे अब भी लगता है कि यह एक महत्वपूर्ण बिंदु है

आईएमएचओ ने 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,
                    ),
          ),

मैं स्पंदन को सरल बनाने के उद्देश्य से सहमत हूं जो JSX- जैसे सिंटैक्स का उपयोग नहीं करना चाहता है, और मैं कई विजेट्स में विभाजित करने की अवधारणा का भी समर्थन करता हूं, लेकिन अब यह मुझे लगता है कि MVC युग वापस jQuery में है। ऐसा परिदृश्य कि बाद में इसके लिए पैडिंग, सीमा और केंद्र लेआउट के साथ एक साधारण विजेट था, कई "}" प्रतीक पठनीयता को गंभीरता से प्रभावित करते हैं। हालांकि, यह एक अभिन्न विजेट है, मैं इसे विभाजित नहीं करना चाहता, कोई उपयोगी उपाय? हालांकि मेरी अंग्रेजी खराब है, मैं अपने विचार व्यक्त करने की बहुत कोशिश करता हूं।

प्रभु हम सबकी मदद करें।

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

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

मैं @zoechi से इतना सहमत हूं कि वे सह-अस्तित्व में रह सकते हैं ... बस इतना ही और मुझे लगा कि यह पुराने धागे पर तय हो गया है

@lrhn

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

ब्रावो, बिल्कुल यही।

रिएक्ट में आप इसे 4 तरीके से कर सकते हैं (और मुझे आज ही अन्य 2 तरीकों के बारे में पता चला !!!)

(1) आप JSX का उपयोग कर सकते हैं (जो मुझे पसंद है)
https://reactjs.org/docs/introducing-jsx.html

(2) आप मूल तरीके का उपयोग कर सकते हैं (जो स्पंदन के समान है)
https://reactjs.org/docs/react-without-jsx.html

ऊपर दिए गए लिंक के अंत में वे 2 आशाजनक सामुदायिक परियोजनाओं का भी उल्लेख करते हैं

(3) React.js मार्कअप के लिए हाइपरस्क्रिप्ट सिंटैक्स
https://github.com/mlmorg/react-hyperscript

(4) हाइपरस्क्रिप्ट के लिए संक्षिप्त वाक्य रचना।
https://github.com/ohanhi/hyperscript-helpers

विकल्प होना अच्छी बात है, वे दिन गए जब आप किसी भी रंग में फोर्ड प्राप्त कर सकते थे जब तक कि यह काला हो :)

@naiveaiguy यदि वर्तमान दृष्टिकोण और DSX है तो यह आपके लिए एक मुद्दा क्यों है?
(यही वह है जो मैं आपके डाउनवोट से प्राप्त करता हूं)

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

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

विकल्प होना अच्छी बात है, वे दिन गए जब आप किसी भी रंग में फोर्ड प्राप्त कर सकते थे
जब तक यह काला है तब तक पसंद आया :)

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

रिएक्ट में आप इसे 4 तरीके से कर सकते हैं (और मुझे आज ही अन्य 2 तरीकों के बारे में पता चला !!!)

अधिकांश समुदाय संचालित हैं, हालांकि रिएक्ट उन्हें संदर्भित करता है। बीच में अच्छा। अब, उनमें से केवल 2 आधिकारिक तौर पर समर्थित हैं: React.createElement और JSX तरीका, जो दूसरे के ऊपर एक आवरण है। JSX का मूल्य उस संदर्भ में कुख्यात है लेकिन यहाँ यह इतना स्पष्ट नहीं है। इस बात को ध्यान में रखते हुए, क्या हम केवल एक आधिकारिक मानक और DSX को संदर्भित करने वाले डॉक्स जब भी प्रासंगिक हों, को बीच में ही पूरा कर सकते हैं?

मेरा मानना ​​​​है कि फ़्लटर टीम को उन सुविधाओं की कमी पर ध्यान केंद्रित करना चाहिए जो वास्तव में डेवलपर्स को ऐप बनाने से रोकती हैं। मैं अपने प्रबंधकों को फ़्लटर की अनुशंसा नहीं कर सकता यदि हम मानचित्र समर्थन भी नहीं जोड़ सकते हैं और कैमरा सुविधाओं को विकसित करने में 2 सप्ताह लगते हैं।

ध्यान रखें, मैं DSX पर हमेशा के लिए दरवाज़ा बंद नहीं कर रहा हूँ। हो सकता है कि यह UI बिल्डिंग का समाधान बन जाए लेकिन हमें यह निर्णय लेने के लिए समुदाय के साथ प्रयोग करने की आवश्यकता है।

@zoechi व्यक्तिगत रूप से मुझे विश्वास नहीं है कि दो विचार स्पंदन की वर्तमान स्थिति में सह-अस्तित्व में हो सकते हैं - हमें वास्तव में इस प्रकृति के विभाजन को इतनी जल्दी प्रोत्साहित नहीं करना चाहिए - लेकिन इस बिंदु पर यह एकमात्र समझौता जैसा दिखता है।

@naiveaiguy

व्यक्तिगत रूप से मुझे विश्वास नहीं है कि दो विचार स्पंदन की वर्तमान स्थिति में सह-अस्तित्व में हो सकते हैं - हमें वास्तव में इस प्रकृति के विभाजन को इतनी जल्दी प्रोत्साहित नहीं करना चाहिए

क्या आप इस बारे में अधिक विशिष्ट हो सकते हैं कि वे सह-अस्तित्व में क्यों नहीं रह सकते हैं? (इस तथ्य को देखते हुए कि DSX सिर्फ वाक्यात्मक चीनी है, या जैसा कि @emalamela कहते हैं, "वर्तमान तरीके का सिर्फ एक आवरण")।

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

@emalamela

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

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

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

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

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

मैं कल्पना भी नहीं कर सकता कि संभावित गोद लेने वालों/उपयोगकर्ताओं/देवों की संख्या इस वजह से खो रही है, अगले महीनों में फिर से आना होगा।

मैं कल्पना भी नहीं कर सकता कि संभावित गोद लेने वालों/उपयोगकर्ताओं/देवों की संख्या इस वजह से खो रही है, अगले महीनों में फिर से आना होगा।

हाँ, 44 Mio को अपवोट करना और भी महत्वपूर्ण लगा :D

हाँ, 44 को अपवोट करना और भी महत्वपूर्ण लगा :D

जब 'अपवोट' द्वारा क्रमबद्ध किया जाता है, तो यह सुविधा अनुरोध 3131 खोले गए टिकटों की सूची में 7 वें स्थान पर है।

https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

@cbazza मैं इस सुविधा के खिलाफ बहस नहीं करना चाहता, लेकिन "यदि आप x नहीं करते हैं तो बहुत ही y होगा" जैसी टिप्पणियां केवल हास्यास्पद हैं।

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

@sonye

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

जब 'अपवोट' द्वारा क्रमबद्ध किया जाता है, तो यह सुविधा अनुरोध 3131 खोले गए टिकटों की सूची में 7 वें स्थान पर है।

@cbazza

यह सबसे डाउनवोट भी है। यह काफी विवादास्पद है।

@emalamela ,

यह सबसे डाउनवोट भी है। यह काफी विवादास्पद है।

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

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

new Card(
  child: Column(
    crossAxisAlignment: CrossAxisAlignment.start,
    children: <Widget>[
      AspectRatio(
        aspectRatio: 18 / 11,
        child: Image.asset('assets/diamond.png'),
      ),
      new Padding(
        padding: EdgeInsets.fromLTRB(16, 12, 16, 8),
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.start,
          children: <Widget>[
            Text('Title'),
            SizedBox(height: 8),
            Text('Secondary Text'),
          ],
        ),
      ),
    ],
  ),
)

बन जाता है:

<Card>
  <Column crossAxisAlignment={CrossAxisAlignment.start}>
    <AspectRatio aspectRatio={18 / 11}>
      <Image src={asset('assets/diamond.png')} />
    </AspectRatio>

    <Padding padding={EdgeInsets.fromLTRB(16, 12, 16, 8)}>
      <Column crossAxisAlignment={CrossAxisAlignment.start}>
        <Text>Title</Text>
        <SizedBox height={8} />
        <Text>Secondary Text</Text>
      </Column>
    </Padding>
  </Column>
</Card>

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

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

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

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

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

आप इस मुद्दे में टिप्पणियों की मात्रा की तलाश करके बता सकते हैं कि JSX (या इस मामले में DSX) एक बड़ी बात है।

JSX एक ऐसी चीज है जिसे आप तब तक नहीं जानते जब तक आप इसे आजमाते नहीं हैं। आपके कोड में पहले मार्कअप होना अजीब है लेकिन फिर यह कमाल हो जाता है।

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

और, जैसा कि @eseidelGoogle (https://youtu.be/h7HOt3Jb1Ts?t=2m41s) ने दूसरे व्यक्ति से कहा, "स्पंदन आईओएस और एंड्रॉइड को एक ही कोडबेस में लिखने का एक तरीका है। हम इसे तेज और आसान बनाने की कोशिश करते हैं [. ..] फ़्लटर हार्डवेयर तक सभी तरह से बात करता है [...] हमारे पास एक बहुत ही स्तरित दृष्टिकोण है, इसलिए आप जितना चाहें उतना कम या ज्यादा ले सकते हैं। [...] हमारे पास टूलिंग में निवेश का एक गुच्छा है ।"

कृपया JSX को लागू करें।

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

@rajaraodv सिर्फ इसलिए कि स्पंदन को प्रतिक्रियाशील शैली ढांचे के रूप में प्रचारित किया जाता है, इसका मतलब यह नहीं है कि यह सिर्फ ReactJS का स्वाद है।
अधिकांश टिप्पणियों से मुझे यह आभास होता है कि लोगों को यह स्वीकार करने में परेशानी होती है कि कुछ नया वैसा नहीं है जैसा वे पहले से जानते हैं।

आप थोड़ी देर के लिए स्पंदन के साथ काम करने की कोशिश कर सकते हैं कि यह वर्तमान में कैसा है और फिर उचित तर्क प्रदान करें कि आपको क्यों लगता है कि JSX/DSX बेहतर होगा, फिर "व्यक्तिगत वरीयता के कारण" या "क्योंकि यह बेहतर है" के बजाय एक तथ्यात्मक तरीके से सादा डार्ट। .

@zoechi , आप कुछ याद कर रहे हैं: स्पंदन प्रतिक्रिया से प्रेरित था, Flutter doc के अनुसार।
शायद यह सिर्फ मेरा मुद्दा है। मुझे वास्तव में लगता है कि मेरे पास UI कोड को पढ़ने में कठिन समय है, यहां तक ​​कि यह डार्ट 2 सिंटैक्स में भी है।

स्पंदन रिएक्ट नेटिव से प्रेरित था

मैं नहीं देखता कि यह कैसे कहता है "भाषा को छोड़कर सब कुछ वही है जिसे जेएस के बजाय स्पंदन कहा जाता है"।

मुझे सच में लगता है कि मुझे UI कोड पढ़ने में मुश्किल हो रही है

और आप दावा करते हैं कि इसका एकमात्र कल्पनीय समाधान DSX है?

क्या आपने माना है कि स्पंदन 1.0 भी नहीं है और समय के साथ आईडीई समर्थन में सुधार हो सकता है?

कोड संपादक में त्वरित सुधार ("रैप xxx") और क्लोजिंग लेबल जैसे बेहतर फ़्लटर आईडीई समर्थन प्राप्त करने के लिए हाल ही में केवल पहले छोटे कदम उठाए गए थे।

डेवलपर के अनुभव को बेहतर बनाने की असीमित संभावनाएं हैं और इस चर्चा में अधिकांश इस प्रकार हैं
"स्पंदन अभी तक सही नहीं है और इसलिए हमें DSX की आवश्यकता है"
आमतौर पर इस बारे में ठोस तर्क के बिना कि DSX कैसे या क्यों इसे हल करेगा या सुधारेगा।

@ज़ोइची ,

आप थोड़ी देर के लिए स्पंदन के साथ काम करने की कोशिश कर सकते हैं कि यह वर्तमान में कैसा है और फिर उचित तर्क प्रदान करें कि आपको क्यों लगता है कि JSX/DSX बेहतर होगा, फिर "व्यक्तिगत वरीयता के कारण" या "क्योंकि यह बेहतर है" के बजाय एक तथ्यात्मक तरीके से सादा डार्ट। .

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

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

और आप दावा करते हैं कि इसका एकमात्र कल्पनीय समाधान DSX है?

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

डेवलपर के अनुभव को बेहतर बनाने की असीमित संभावनाएं हैं और इस चर्चा में अधिकांश इस प्रकार हैं
"स्पंदन अभी तक सही नहीं है और इसलिए हमें DSX की आवश्यकता है"
आमतौर पर इस बारे में ठोस तर्क के बिना कि DSX कैसे या क्यों इसे हल करेगा या सुधारेगा।

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

मैं खुद को इसका उपयोग करते हुए नहीं देख सकता (लेकिन मैं इसे आज़माने के लिए तैयार हूँ)। मुझे नहीं लगता कि यह एक चांदी की गोली है, लेकिन इतना उत्साह है कि यह करने लायक है।

मुझे लगता है कि Google को भाषा की बाधाओं को दूर करना चाहिए ताकि समुदाय को वह बनाने की अनुमति मिल सके जो वे चाहते हैं।

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

धन्यवाद! ऐसा उत्साह देखकर खुशी हुई!

@seidelGoogle ,

Intellij और/या VS कोड (डार्ट-कोड के साथ) कैसे एक .dsx फ़ाइल से ब्रेकप्वाइंट और चरण दर कोड सेट करने में सक्षम होंगे? (मेरा मतलब है कि यह एक डार्ट फ़ाइल नहीं है)। .dsx फ़ाइल (जैसे .dart फ़ाइल के साथ) से स्वतः पूर्ण कार्यक्षमता के बारे में कैसे?

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

एक ट्रांसपिलर उपलब्ध है लेकिन इसे पूरी तरह से एकीकृत करने का कोई आसान तरीका नहीं है:
https://spark-heroku-dsx.herokuapp.com/index.html

PS यह टिकट केवल टिप्पणियों का आधा है !!!
https://github.com/flutter/flutter/issues/15922

@cbazza उस कंपाइलर के साथ कहीं रेपो है? कोड साझा करना और उस पर हैकिंग में समुदाय को शामिल करना बहुत अच्छा होगा, भले ही वह सही न हो।

@jonahwilliams , नहीं DSX ट्रांसपिलर कोड जारी नहीं किया गया है क्योंकि यह उसके लिए बहुत जल्दी है।
आप पूर्व-प्रसंस्करण क्षमताओं जैसे ब्रेकप्वाइंट, स्टेपिंग, ऑटो-पूर्ण, आदि का परीक्षण करने के लिए बस 2 हाथ से लिखी समकक्ष फाइलों (.dsx और .dart) का उपयोग कर सकते हैं।

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

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

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

यदि आपने स्रोत मानचित्र (https://pub.dartlang.org/packages/source_maps) उत्पन्न किए हैं, तो मुझे लगता है कि आईडीई में कम से कम कुछ बुनियादी समर्थन प्राप्त करना बहुत छोटा है, डार्ट/फ्लटर से स्वतंत्र है। लेकिन फिर, यह सब अनुमान है बिना यह जाने कि आपका टूलिंग क्या करता है और आप इसे कैसे काम करने की उम्मीद करेंगे।

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

परीक्षण के लिए आप स्रोत मानचित्रों का उपयोग करने का तरीका दिखाने के लिए किसी भी सरल प्रकार के ट्रांसपिलर के साथ आ सकते हैं। उदाहरण के लिए एक तुच्छ ट्रांसपिलर लिखें जो मूल फ़ाइल पर प्रत्येक पंक्ति के बीच एक रिक्त रेखा के साथ डार्ट/स्पंदन कोड उत्पन्न करता है। (.d2 => .dart, .d2 डार्ट/फ़्लटर फ़ाइल है, बाहर .dart फ़ाइल में मूल फ़ाइल की प्रत्येक पंक्ति के बीच एक रिक्त रेखा होगी)।

हां, मैं टेस्टफाइल के लिए स्रोत मानचित्र बनाने पर काम कर सकता हूं।

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

मैं चाहता हूं कि जेएसएक्स सिंटेक्स के एमी प्रस्तावक सिर्फ विलाप जारी रखने से पहले कुछ दिन वास्तव में स्पंदन के साथ काम करें। मैं एक Xaml आधारित प्रणाली से आया था, लेकिन जल्दी से इसकी आदत हो गई। बस इसे एक वास्तविक प्रयास दें।

@escamoteur
अरे, एस्केमोटर। क्या आपको लगता है कि मैंने स्पंदन सीखने में बहुत समय नहीं लगाया है?
Flutter.io/tutorials/layout/ में, "पैकिंग विजेट्स" अनुभाग के अंत में, ट्यूटोरियल द्वारा दिया गया कोड काम नहीं करता है।
मैंने फ़्लटर इश्यू ब्लॉक के तहत इस मुद्दे का उल्लेख किया है, लेकिन कोई भी इस पर ध्यान नहीं देना चाहता।

• डार्ट कोड: main.dart
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/main.dart

• पब्स्पेक: pubspec.yaml
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/pubspec.yaml

• https://flutter.io/tutorials/layout/

@JonathanSum क्या इस मुद्दे के विषय पर आपकी टिप्पणी से कोई संबंध है?

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

ग्रुप डार्ट: "डार्ट सिंटैक्स बेहतर है और JSX/DSX ठीक नहीं है"
समूह JSX / DSX: "JSX / DSX सिंटैक्स बेहतर है और डार्ट अच्छा नहीं है"

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

और मेरे 2 सेंट ... एक पूर्ण स्टैक देव के रूप में मेरे पास भाषाओं और दृष्टिकोणों की एक विस्तृत श्रृंखला है ... JSX कोड लिखने के मेरे पसंदीदा तरीकों में से एक है और मुझे उम्मीद है कि डार्ट्स के लिए एक वैकल्पिक वाक्यविन्यास होगा। और मैं यह नहीं कह रहा हूं कि वर्तमान सिंटैक्स खराब है, यह सिर्फ इतना है कि मैं JSX शैली पसंद करता हूं।

मुझे समूह JSX/DSX के इस उद्धरण से असहमत होना पड़ेगा

डार्ट बस अच्छा नहीं है

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

• एंड्रॉइड में एक्सएमएल लेआउट हैं।
• आईओएस में स्टोरीबोर्ड एक्सआईबी (एक्सएमएल) है
• जीटीके+ में पंगो आदि के लिए एक्सएमएल है।
• क्यूटी में क्यूएमएल (वाईएएमएल जैसा) है
• ज़ामरीन में एक्सएएमएल है

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

...

क्या यह वास्तव में इतना पागल प्रस्ताव है कि हमें फ़्लटर टीम/उपयोगकर्ताओं से इस तरह की प्रतिक्रिया प्राप्त करनी है?

@birkir और वे सभी कई मुसीबतें लाते हैं फ़्लटर के पास \ o/ नहीं है
दूसरी भाषा की कोई जरूरत नहीं है।
आप फ़्लटर में भी उसी भाषा के साथ दृश्य को अलग कर सकते हैं।

@birkir यह धागा डार्ट और सिंटैक्स के बारे में 100% है।

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

तो यह डार्ट के बारे में नहीं है ... लेकिन लेआउट के लिए डार्ट के अलावा स्पंदन को कुछ उपयोग करने की आवश्यकता है? ऐसा लगता है कि आपका यह कहना कि डार्ट काफी अच्छा नहीं है, जबकि यह भी दावा कर रहा है कि इसका डार्ट से कोई लेना-देना नहीं है?

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

मुझे खुशी है कि एक और क्रॉस प्लेटफॉर्म विकल्प है ... क्या ऐप्पल कुछ पेशकश करने वाला अगला होगा? और शायद वे देखेंगे कि हममें से कितने लोग प्रतिक्रिया/प्रतिक्रिया-मूल के बारे में क्या पसंद करते हैं? आईडीके अगर उनके पास कुछ भी खाना बनाना है।

फ़्लटर टीम ने यह प्रतिक्रिया देखी है (JSX/DSX दृष्टिकोण का अनुरोध करने पर) और वे

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

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

मुझे लगता है कि यदि संभव हो तो इंडेंट और विजेट को अन्य तरीकों से प्रारूपित करना जेएसएक्स के समान होगा और उन उपयोगकर्ताओं के लिए अनुकूल होगा जिनके पास एक्सएमएल और एचटीएमएल (लगभग सभी एंड्रॉइड देव) के साथ अनुभव है ... इस कोड को कोडलैब में जांचें

return new Container(
    margin: const EdgeInsets.symmetric(horizontal: 8.0),
    child: new Row(
      children: <Widget>[
        new Flexible(
          child: new TextField(
            controller: _textController,
            onSubmitted: _handleSubmitted,
            decoration: new InputDecoration.collapsed(
              hintText: "Send a message"),
          ),
        ),
        new Container(                                                 //new
          margin: new EdgeInsets.symmetric(horizontal: 4.0),           //new
          child: new IconButton(                                       //new
            icon: new Icon(Icons.send),                                //new
            onPressed: () => _handleSubmitted(_textController.text)),  //new
        ),                                                             //new
      ],
    ),
  );

इस डार्ट को jsx कोड में जांचें

<Container margin="">
   <Row>
       <Flexible>
            <TextField   controller=""
                                onSubmitted=""
                                decoration="">
                 <OtherWidget></OtherWidget>

            </TextField>
        </Flexible>
   </Row>
</Container>

और इस अन्य प्रारूप के साथ तुलना करें और अधिक htmlish

  return Container(margin: const EdgeInsets.symmetric(horizontal: 8.0), child:
            Row(children: <Widget>[
                Flexible(child:
                    TextField(controller: _textController,
                              onSubmitted: _handleSubmit,
                              decoration: new InputDecoration.collapsed(hintText: "manda un mensaje"),),
                    ),
                Container(margin: const EdgeInsets.symmetric(horizontal: 4.0),child:
                     IconButton(icon: Icon(Icons.send),
                               onPressed: ()=>_handleSubmit(_textController.text),),)
              ],
            )
    );

यह थोड़ा अधिक समान है और अब आपको html/xml/jsx के समान विभिन्न विजेट्स को नोटिस करने के लिए केवल बाएं से दाएं देखने की आवश्यकता है

तत्व (विजेट) विशेषताओं में नए विजेट की तुलना में अधिक इंडेंटेशन है, इसलिए यह अधिक स्पष्ट करता है कि कोड को समझ और जांच सकता है

बहुत अच्छा होगा अगर मैं अलग-अलग प्रारूपों पर इस प्रारूप के लिए स्वचालित इंडेंटेशन कर सकता हूं, अभी मैं इसे हाथ से करता हूं ....

यहां सभी टिप्पणियों को पढ़ने और निजी तौर पर मेरे दोस्तों (मूल मोबाइल ऐप डेवलपर्स, जावा/कोटलिन/ऑब्जेक्टिव-सी/स्विफ्ट दोस्तों) के साथ चर्चा करने के बाद, मेरा अवलोकन:

लोग दो चीजें मांग रहे हैं,

• __बेहतर पठनीयता और आसान लेखन__। कुछ सिंटैक्स शोर (कोष्ठक, अर्धविराम, new , child , children ) के साथ मिश्रित गहरा घोंसला कोडिंग के वर्तमान तरीके में कष्टप्रद है।
• __ कोड__ से अलग शैली/डिजाइन। दृश्य पृथक्करण पढ़ने के लिए अच्छा है (शैली को अनिवार्य कोड से एक नज़र से अलग करना) और टूलिंग के लिए एक वास्तविक पृथक्करण अच्छा है (उदाहरण के लिए, लेआउट संपादक के साथ आईडीई)।

भिन्न-भिन्न मतों वाले मुख्यतः दो समूह भी हैं,

• समस्या को हल करने के लिए एक और जटिलता पेश किए बिना वर्तमान सिंटैक्स में सुधार करना।
  इस दिशा में पहले से ही कुछ सुधार हुए हैं। उदाहरण के लिए, डार्ट 2.0 में वैकल्पिक new , const और प्रस्तावित virtual "closing tag" comments सुविधा।
• समस्या को हल करने के लिए अतिरिक्त मार्कअप भाषाओं (जेएसएक्स लाइक या एक्सएमएल लाइक) का परिचय देना।

आप आसानी से यह निष्कर्ष नहीं निकाल सकते कि वर्तमान में कौन सा बेहतर है। इसलिए समुदाय को पहले अपने प्रयोग करने दें और बाद में अंतिम निर्णय (स्वीकार या अस्वीकार) करें।

@hooluupog वर्चुअल क्लोजिंग टैग टिप्पणियाँ पहले से ही IntelliJ, AS, VSCode में कुछ समय से काम कर रही हैं

@ हिक्सी

यह बग अभी भी खुला है क्योंकि हमें यह पता नहीं चला है कि हम यहां क्या करना चाहते हैं। हम उत्सुकता से प्रयोगों को देख रहे हैं (उदाहरण के लिए cbazza) यह देखने के लिए कि लोग उनका उपयोग कैसे करते हैं।

लोग मेरे प्रयोगों का उपयोग नहीं कर सकते क्योंकि इसे अभी फ़्लटर में मूल रूप से एम्बेड नहीं किया जा सकता है; इसलिए यह एक बाहरी/ऑनलाइन प्रयोग बना हुआ है जहां लोग केवल क्षमता देख सकते हैं।

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

क्या आप समय-समय पर अधिक विशिष्ट हो सकते हैं कि हम प्रीप्रोसेसिंग का समर्थन करने के लिए बिल्ड सिस्टम में कुछ बदलाव की उम्मीद कब कर सकते हैं? क्या हम एक महीने, एक चौथाई, छह महीने, एक साल, 2 साल, एक दशक, एक जयंती, आदि की बात कर रहे हैं?

इसका मतलब डार्ट में ही E4X/H4X/JSX/DSX जैसा कुछ जोड़ना हो सकता है।

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

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

या शायद हम जानेंगे कि कोई भी वास्तव में इसका उपयोग नहीं करता है इसलिए हम कुछ नहीं करेंगे।

लोग किसी ऐसी चीज का उपयोग कैसे कर सकते हैं जो उनके लिए उपलब्ध नहीं है और फिर यह निष्कर्ष निकाल सकते हैं कि कुछ भी करने की आवश्यकता नहीं है क्योंकि लोग इसका उपयोग नहीं कर रहे हैं? यह मुझे मेलिसा मैककार्थी के एसएनएल पर 'यात्रा प्रतिबंध' के बारे में सीन स्पाइसर प्रतिरूपण की बहुत याद दिलाता है ... 'शब्द का परिपत्र उपयोग' :)

https://www.youtube.com/watch?v=1Dvo6EHEJQE&t=48s

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

प्रयोग को सक्षम करने के लिए प्रीप्रोसेसिंग क्षमताओं की बुरी तरह आवश्यकता होती है। इसके बिना कुछ भी आगे नहीं बढ़ता है और आप कुछ भी नया नहीं सीखेंगे।

लोग मेरे प्रयोगों का उपयोग नहीं कर सकते

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

क्या आप समय-समय पर अधिक विशिष्ट हो सकते हैं कि हम बिल्ड सिस्टम में कुछ बदलाव की उम्मीद कब कर सकते हैं

वास्तव में नहीं (उदाहरण के लिए https://en.wikipedia.org/wiki/Forward-looking_statement देखें कि इस तरह के बयान देना मुश्किल क्यों हो सकता है), लेकिन शायद आने वाले हफ्तों में नहीं।

डार्ट भाषा को बदलने की कोई जरूरत नहीं है

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

JSX को बैकलॉग में जोड़ें और इसे लाखों-प्लस-एक अन्य तत्काल आवश्यकताओं के साथ प्रतिस्पर्धा करने दें, ग्लैडीएटर-शैली?

रिएक्ट वेब के लिए लिखा गया है और इस प्रकार HTML लिखने के लिए एक सरल समाधान की आवश्यकता है। JSX लोकप्रिय नहीं हुआ क्योंकि यह UI लिखने का सबसे अच्छा समाधान है, बल्कि इसलिए कि यह HTML लिखने का सबसे अच्छा समाधान है।

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

अगर हम वाचालता को कम करना चाहते हैं तो मैं इसके बजाय अंको (https://github.com/Kotlin/anko/wiki/Anko-Layouts) से प्रेरणा लेना चाहूंगा। वहां आप कहीं भी नए स्थानीय चर परिभाषित कर सकते हैं और बच्चों की सूची को गतिशील रूप से बनाने के लिए सामान्य फॉर-लूप का उपयोग कर सकते हैं, जिससे कोड का पालन करना आसान हो सकता है। इसके अलावा, लेआउटबिल्डर आंखों पर आसान हो जाएगा क्योंकि प्रत्येक घोंसले का स्तर पहले से ही लैम्ब्डा फ़ंक्शन है (अतिरिक्त बिल्डर लैम्ब्डा पास करने की कोई आवश्यकता नहीं है)। वैसे भी, यह सिर्फ प्रेरणा के लिए है और मुझे नहीं लगता कि Flutter को 1:1 की नकल करनी चाहिए।

रिएक्ट वेब के लिए लिखा गया है और इस प्रकार HTML लिखने के लिए एक सरल समाधान की आवश्यकता है। JSX लोकप्रिय नहीं हुआ क्योंकि यह UI लिखने का सबसे अच्छा समाधान है, बल्कि इसलिए कि यह HTML लिखने का सबसे अच्छा समाधान है।

रिएक्ट नेटिव वेब डेवलपमेंट नहीं है और न ही यह HTML का उपयोग करता है। अनुभवी रिएक्ट डेवलपर्स से पूछें (या इसे और अन्य JSX थ्रेड को पूरी तरह से पढ़ें) और आप देखेंगे कि JSX को कई रिएक्ट डेवलपर्स द्वारा UI लिखने का सबसे अच्छा तरीका माना जाता है।

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

यह कथन स्पष्ट रूप से दर्शाता है कि आप JSX को नहीं जानते हैं। JSX (DSX के रूप में) होस्टिंग भाषा (जावास्क्रिप्ट/डार्ट) से सभी प्रोग्रामिंग संरचनाओं (फॉर-लूप, आदि) का उपयोग करता है।

यह टिकट केवल JSX जैसी कार्यक्षमता में रुचि रखता है, अन्य तरीकों (जैसे Anko) के लिए कृपया वहां चर्चा के लिए अपना खुद का टिकट बनाएं।

रिएक्ट नेटिव वेब डेवलपमेंट नहीं है और न ही यह HTML का उपयोग करता है। अनुभवी रिएक्ट डेवलपर्स से पूछें (या इसे और अन्य JSX थ्रेड को पूरी तरह से पढ़ें) और आप देखेंगे कि JSX को कई रिएक्ट डेवलपर्स द्वारा UI लिखने का सबसे अच्छा तरीका माना जाता है।

रिएक्ट नेटिव से बहुत पहले रिएक्ट सामने आया। JSX का मूल डिज़ाइन HTML रेंडरिंग पर आधारित है, न कि मूल UI पर। JSX जो बेहतर करता है, उसके लिए कोई भी एक भी ठोस तर्क नहीं दिखा पाया है। तुलना करने से

new Scaffold(
  appBar: new AppBar(
    title: new Text(widget.title),
  ),
  body: new Column(
    child: ...,
  ),
)

प्रति

<Scaffold
    appBar={<AppBar title={<Text>{widget.title}</Text>} />}
  >
  <Column>
    ...
  </Column>
</Scaffold>

आपने अप-टू-डेट तुलना नहीं की है और आप केवल एक पंक्ति में अधिक सामग्री डाल रहे हैं। आपको इसकी तुलना करनी चाहिए:

Scaffold(
  appBar: AppBar(title: Text(widget.title)),
  body: Column(
    child: ...,
  ),
)

ध्यान दें कि कैसे सभी बदसूरत {<{<>} />} और बंद </...> टैग चले गए हैं।

यह कथन स्पष्ट रूप से दर्शाता है कि आप JSX को नहीं जानते हैं। JSX (DSX के रूप में) होस्टिंग भाषा (जावास्क्रिप्ट/डार्ट) से सभी प्रोग्रामिंग संरचनाओं (फॉर-लूप, आदि) का उपयोग करता है।

नहीं, आप JSX के भीतर if स्टेटमेंट या फॉर-लूप (या स्विच या कोई अन्य स्टेटमेंट) का उपयोग नहीं कर सकते:

function render(data) {
  return (
    <div>
      // This is impossible
      let total = 0;
      for (let item of data.list) {
        total += item.value;
        <div>{ total }</div>
        <div>{ item.name }</div>
      }
    </div>
  )
}

केवल अभिव्यक्तियों की अनुमति है। इसलिए आपको सशर्त ऑपरेटरों ( c ? x : y , जो else if बहुत बदसूरत बनाता है) और Array.map आदि (जो बहुत बदसूरत भी हो सकता है) का उपयोग करना चाहिए या अपने कोड के कुछ हिस्सों को रेंडर फ़ंक्शन के शीर्ष पर या एक अलग सहायक फ़ंक्शन में। स्पंदन के साथ भी ऐसा ही है। Anko में यह सीमा नहीं है और लेखन (कुछ) UI कोड को और अधिक स्वाभाविक बनाता है।

मुझे लगता है कि JSX को शुरू करने के बारे में एक चर्चा में यह पूछना काफी मान्य और आवश्यक है कि क्या यह वास्तव में सबसे अच्छा समाधान है या यदि हम कुछ बेहतर पा सकते हैं। अन्यथा हम संसाधनों को गलत कार्यों पर बर्बाद कर देंगे।

रिएक्ट नेटिव से बहुत पहले रिएक्ट सामने आया। JSX का मूल डिज़ाइन HTML रेंडरिंग पर आधारित है, न कि मूल UI पर।

JSX का मूल डिज़ाइन ट्री संरचनाओं को बनाने/हेरफेर करने के परिचित तरीके के बारे में है जो विशेष रूप से UI कार्य करते समय दिखाई देते हैं; घटक पदानुक्रम सोचें (https://facebook.github.io/jsx/) जो वेब विकास, मूल विकास, किसी भी UI विकास आदि में दिखाई देते हैं।

JSX जो बेहतर करता है, उसके लिए कोई भी एक भी ठोस तर्क नहीं दिखा पाया है।

यही वह बिंदु है, हम वर्तमान तरीके को प्रतिस्थापित नहीं करना चाहते हैं, हम एक वैकल्पिक तरीका जोड़ना चाह रहे हैं जो रिएक्ट डेवलपर्स से परिचित हो।

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

नहीं, आप JSX के भीतर if स्टेटमेंट या फॉर-लूप (या स्विच या कोई अन्य स्टेटमेंट) का उपयोग नहीं कर सकते:

ऐसा नहीं है कि मैं आपको ऐसा करने की सलाह देता हूं लेकिन यह संभव है: एक अनाम फ़ंक्शन बनाएं और उसे कॉल करें।

function render(data) {
  return (
    <div>
      { ()=>{
        // This is *not* impossible
        let divs=[];
        let total = 0;
        for (let item of data.list) {
          total += item.value;
          divs.push(<div>{ total }</div>);
          divs.push(<div>{ item.name }</div>);
        }
        return divs;
      }() }
    </div>
  )
}

मुझे लगता है कि JSX को शुरू करने के बारे में चर्चा में यह पूछना काफी मान्य और आवश्यक है कि क्या यह वास्तव में सबसे अच्छा समाधान है।

सबसे अच्छा समाधान जैसी कोई चीज नहीं है, यह सब कुछ पसंद करने के बारे में है, किसी परिचित चीज़ का उपयोग करने का विकल्प है जो सीधे फ़्लटर विजेट्स पर मैप करता है और कोई ओवरहेड नहीं जोड़ता है।

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

@<Scaffold>
  <appBar:AppBar>
     <title:Text [widget.title]/>
  </appBar:AppBar>
  <Column>
    {kids}
  </Column>
</Scaffold>@

और आपको मिलता है:

--------new Scaffold(
--------  appBar: new AppBar(
--------    title: new Text(
--------      widget.title,
--------    ),
--------  ),
--------  child: new Column(
--------    child: kids,
--------  ),
--------);

DSX JSX के समान है, लेकिन डार्ट और स्पंदन के लिए, इसलिए इसकी अपनी विशेषताएं हैं जो ऊपर दिए गए लिंक पर वर्णित हैं।

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

@charafau क्या आप "एंड्रॉइड से एक्सएमएल लेआउट" का उदाहरण/आईएमजी/लिंक साझा कर सकते हैं जिसका आप जिक्र कर रहे हैं?

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

रिएक्ट JSX टैग में लूप के लिए नहीं डालता है क्योंकि रिएक्ट की अवधारणा घटक के बारे में है। ऊपरी भाग तर्क है और नीचे का भाग JSX है, और यह हमेशा ऐसा ही होता है। सब कुछ कई घटकों में विभाजित है और एक बड़े घटक में एक साथ जुड़ा हुआ है।

वास्तव में, यहां अधिकांश लोग जो JSX के विरुद्ध केवल अनुमान लगा सकते हैं कि JSX किसी प्रकार का HTML, XML, या कम वर्बोज़ समाधान है।

@JonathanSum

यहाँ अधिकांश लोग जो JSX के विरुद्ध केवल अनुमान लगा सकते हैं कि JSX किसी प्रकार का HTML है

मुझे लगता है कि ऐसा इसलिए है क्योंकि व्यक्तिगत वरीयता के अलावा जेएसएक्स/डीएसएक्स के पक्ष में कोई अन्य तर्क नहीं था। जैसा कि पहले ही ऊपर चर्चा की गई है, यह ठीक है, लेकिन कृपया यह मत समझिए कि लोग JSX के खिलाफ हैं क्योंकि वे इसे नहीं समझते हैं, जब अच्छे तथ्यात्मक तर्कों की कोई सूची नहीं है जो दिखाते हैं कि JSX सादे डार्ट से बेहतर है।

मुझे लगता है कि ऐसा इसलिए है क्योंकि व्यक्तिगत वरीयता के अलावा जेएसएक्स/डीएसएक्स के पक्ष में कोई अन्य तर्क नहीं था।

वास्तव में नहीं, कई पहले दिए गए थे, बस दोनों धागे को पूरी तरह से पढ़ें। मैंने पहले इन 2 बातों का जिक्र किया था:
(1) कोई और 'बच्चा' और 'बच्चे' सामान नहीं
(2) तीसरे पक्ष के उपकरणों में हेरफेर करना आसान है (पार्स, विश्लेषण और पुन: उत्पन्न)

(2) के साथ आप केवल डार्ट के साथ संभव नहीं चीजों को करने के लिए मार्कअप को बढ़ा सकते हैं; उदाहरण के लिए DSX का स्प्रेड ऑपरेटर या छोटे सेट से कई फ़ंक्शन पैरामीटर उत्पन्न करना।

दूसरों ने बहुत सारे अच्छे अंक प्रदान किए हैं लेकिन मैं इसे आपके लिए नहीं खोद रहा हूं;)

(1) जैसा कि बताया गया है कि डार्ट में ऐसी चीजों को बदला/सुधार भी किया जा सकता है और पहले से ही चर्चाएं थीं। यह सिर्फ डार्ट 2 रिलीज से पहले नहीं होगा।
सिर्फ यह मानते हुए कि डीएसएक्स सभी प्रकार की नई सुविधाओं की अनुमति देता है और डार्ट वास्तव में मेरी राय में उचित तर्क नहीं है।
(2) मुझे पूरा यकीन है कि यह डार्ट के साथ भी किया जा सकता है और निश्चित रूप से डार्ट के लिए पहले से ही एक पार्सर है।

दूसरों ने बहुत सारे अच्छे अंक प्रदान किए हैं लेकिन मैं इसे आपके लिए नहीं खोद रहा हूं;)

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

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

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

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

यह भी एक तथ्य है कि पूर्ण डार्ट भाषा को पार्स करने की तुलना में एक्सएमएल को पार्स करना बहुत आसान है और हर भाषा में एक एक्सएमएल पार्सर होता है, जबकि केवल डार्ट में एक पूर्ण और पूर्ण डार्ट भाषा पार्सर होता है। क्या आप देख सकते हैं कि यह भी एक वैध तर्क है?

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

वैकल्पिक DSX सिंटैक्स के लिए तर्क:

1) रिएक्ट (वेब ​​और देशी) से आने वाले अधिक डेवलपर्स को ऑनबोर्ड और आकर्षित करें
2) रिएक्ट नेटिव घटकों को फ़्लटर विजेट में पोर्ट करने का बेहतर अनुभव
3) विगेट्स में बच्चे/बच्चों के गुणों की निरंतरता को बढ़ाता है
4) कोड पठनीयता (राय तर्क)
5) डार्ट लाइनिंग से अलग लॉजिक लाइनिंग देखें
6) UI निर्माण टूल के लिए एक दुनिया खोलता है
7) पूर्व प्रोसेसर के लिए पारिस्थितिकी तंत्र खोलता है

डीएसएक्स +1

डीएसएक्स +1

पक्ष/विपक्ष का एक समूह लिखना पसंद करता, लेकिन इन सभी टिप्पणियों को पढ़कर, मुझे ऐसा लगता है कि मैं सब कुछ बार-बार दोहराने वाला हूं।
इतना भोला और अज्ञानी होना बंद करो, कोई नहीं कहता कि आपको DSX का उपयोग करके UI लिखने के लिए मजबूर किया जाएगा, यह केवल एक विकल्प है (बेहतर विकल्प)।
एक कारण है कि आप JS को 101203103 विभिन्न तरीकों से लिख सकते हैं।

खैर, हमेशा एक विश्लेषक प्लगइन लिखने का विकल्प होता है जो DSX को पार्स करता है और उन्हें नियमित डार्ट फ़ंक्शन कॉल में परिवर्तित करता है, ताकि कंपाइलर को कोई अतिरिक्त काम न करना पड़े।

असली सवाल यह है कि क्या विश्लेषक प्लगइन्स कंपाइलर के संदर्भ में लागू होते हैं।

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

टीएलडीआर; यदि आप चाहते हैं कि DSX इतना खराब हो, तो एक विश्लेषक प्लगइन लिखें और इसे स्वयं डार्ट में लाएं। इंटरनेट आपको प्यार करेगा, आपको हजारों गिथब सितारे मिलेंगे, और आपको ऐसा लगेगा जैसे यह प्रतिक्रिया है। जीत-जीत।

पुनश्च मैं आपसे इसे करने के लिए भी दौड़ लगाऊंगा

खैर, हमेशा एक विश्लेषक प्लगइन लिखने का विकल्प होता है जो DSX को पार्स करता है और उन्हें नियमित डार्ट फ़ंक्शन कॉल में परिवर्तित करता है, ताकि कंपाइलर को कोई अतिरिक्त काम न करना पड़े।

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

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

यदि आप सूत्र पढ़ते हैं, तो पहले दिन से यही विचार रहा है। हम सिर्फ एक ट्रांसपिलर बनाने के लिए स्पंदन/डार्ट से समर्थन चाहते हैं।

टीएलडीआर; यदि आप चाहते हैं कि DSX इतना खराब हो, तो एक विश्लेषक प्लगइन लिखें और इसे स्वयं डार्ट में लाएं। इंटरनेट आपको प्यार करेगा, आपको हजारों गिथब सितारे मिलेंगे, और आपको ऐसा लगेगा जैसे यह प्रतिक्रिया है। जीत-जीत।

धागा पढ़ें, यह पहले से ही @cbazza द्वारा किया जा चुका है (विश्लेषक प्लगइन इसे काटने वाला नहीं है)

https://github.com/flutter/flutter/issues/11609#issuecomment -388484681

पुनश्च मैं आपसे इसे करने के लिए भी दौड़ लगाऊंगा

महान! यह कैसे काम करेगा इसका एक सिद्धांत भी देखना दिलचस्प होगा।

एसजीटीएम। मान लीजिए कि हम सभी किसी प्रकार के प्री-प्रोसेसिंग समर्थन की प्रतीक्षा कर रहे हैं।

मैं कंस्ट्रक्टर के माध्यम से पैरामीटर पास करने की तुलना में बिल्डर सिंटैक्स पसंद करता हूं

<strong i="6">@override</strong>
Widget build(BuildContext context) {
    return container()
      .height(56.0)
      .padding(8.0)
      .decoration(BoxDecoration(color: Colors.blue[500]))
      .child(text("Hello world!")
                   .style(...)
                  .build());
}

जैसे https://fblitho.com/

Text.create(context)
    .text("Hello World")
    .textSizeDip(50)
    .build();

डीएसएक्स +1

मुझे JSX के लिए तर्क मिलते हैं, लेकिन मुझे लगता है कि बहुत से लोग (स्वयं शामिल) हैं जो प्रोग्रामिंग भाषा में एक्सएमएल को जाम करने के विचार से नफरत करते हैं। यह सिर्फ गलत लगता है (लेकिन मुझे पूरी तरह से लगता है कि दूसरे ऐसा महसूस नहीं करते हैं)।

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

@wstrange
मैं तुम्हें समझ सकता हुँ। मैं जेएसएक्स के खिलाफ हुआ करता था और जेएस को एक्सएमएल/एचटीएमएल के साथ मिलाता था .... फिर मैंने कोशिश की। प्रतिक्रिया के साथ कुछ महीने बिताने के बाद, मुझे JSX से प्यार हो गया। दो हत्यारे फायदे हैं:

1. कोई नया वाक्यविन्यास और उपयोगिता नहीं
2. चर, कार्यों आदि का कोई और गुजरना नहीं।

@wstrange ,

यह देखते हुए कि एक बार लागू होने के बाद सुविधाओं को हटाना लगभग असंभव है,

यह एक दिया नहीं है, किसने सोचा होगा कि Google मैथएमएल को क्रोम से हटा देगा?

आइए देखें कि फ़्लटर ऐप के निर्माण के तरीके में पर्याप्त बदलाव करने से पहले डार्ट 2 सिंटैक्स की कुछ नई सुविधाएँ कैसे चलती हैं।

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

@ बेसोनोव ,

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

@cbazza मैं फ़्लटर के बारे में ठीक यही बात कह सकता था। इसका उपयोग करते हुए कुछ सप्ताह बिताएं और आप JSX को मिस नहीं करेंगे।

प्रतिक्रिया हमें सब कुछ बताती है।

अब तक, +1 लगभग दोगुना -1

@escamoteur ,
हां, कहने के लिए बहुत ही उचित कथन है लेकिन मैंने स्पंदन के साथ बहुत समय बिताया है और मैं निश्चित रूप से देख सकता हूं कि डीएसएक्स इसमें कितना मूल्य जोड़ देगा। जैसा कि @leedstyh ने देखा है, DSX के प्रशंसक लगभग 2-से-1 तक दौड़ का नेतृत्व करते हैं, जो कि इस मंच के लोगों को स्पंदन करने वाले लोगों को देखते हुए बहुत आश्चर्यजनक है।

मेरा एक सवाल है:

DSX सिंटैक्स का उपयोग करते समय, हम परोक्ष रूप से यह मान लेते हैं कि नेस्टेड बच्चे/बच्चे विजेट प्रकार के हैं। क्या होगा यदि हम स्पष्ट रूप से यह बताना चाहते हैं कि हम चाहते हैं कि नेस्टेड बच्चे/बच्चे एक विशिष्ट उप-प्रकार के विजेट हों?

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

मुझे लगता है कि हमें कम से कम v1 रिलीज के बाद यूआई घोषित करने के लिए हर किसी को कोशिश करने और स्पंदन के तरीके से परिचित होने के लिए कुछ समय देना चाहिए। तब हम इस फीचर को बेहतर तरीके से देख सकते थे।

@sandangel ,

बहुत अच्छा कैच !!! मैं आपको अपनी आभासी टोपी देता हूं। मेरे शुरुआती प्रोटोटाइप में शुरू से ही कुछ छेद थे जिनके बारे में मैं जानता था और बस लोगों को उन्हें खोजने और आगे आने का इंतजार कर रहा था। मैं बस उम्मीद कर रहा था कि लोग इस पर लड़ने के बजाय तकनीक पर चर्चा करने में रुचि रखते हैं।

मेरे पास इसका समाधान नामस्थान पर सरणी प्रकार को किसी अन्य पैरामीटर के रूप में प्रदान करना है। जैसे-जैसे नाम स्थान बड़ा होता जा रहा है, हम 'बच्चों' के लिए '*' का संक्षिप्त रूप सेट कर सकते हैं।

उदाहरण 2 में https://spark-heroku-dsx.herokuapp.com/index.html पर, यदि क्रियाएँ डिफ़ॉल्ट 'विजेट' के बजाय 'कंटेनर' की एक सरणी होती हैं, तो यह निम्नलिखित विकल्पों की तरह दिखाई देगी:

        <actions:children:Container>
            <IconButton 
                icon={new Icon(Icons.search)}
                tooltip='Search'
                onPress={null}
            />
        </actions:children:Container>

        <actions:*:Container>
            <IconButton 
                icon={new Icon(Icons.search)}
                tooltip='Search'
                onPress={null}
            />
        </actions:*:Container>

हाय @cbazza , आपकी प्रतिक्रिया के लिए धन्यवाद।

मैं आपके समाधान के बारे में सोच रहा हूं। क्या हम w3शूल-एक्सएमएल नेमस्पेस में वर्णित एक्सएमएल नेमस्पेस का दुरुपयोग कर रहे हैं?

जैसा कि यह बताता है कि XML दस्तावेज़ में नामकरण विरोध को हल करने के लिए नेमस्पेस का मुख्य रूप से उपयोग किया जाता है।

तो जब कोई उपरोक्त एक्सएमएल पढ़ता है, तो वे सोच सकते हैं कि आप नामस्थान 'क्रियाओं' के नामस्थान 'बच्चों' के तहत एक कंटेनर टैग घोषित कर रहे हैं, न कि आप हर नेस्टेड बच्चों को कंटेनर होना चाहिए। यह मुझे भ्रमित करता है जब मैंने पहली बार उपरोक्त स्पष्टीकरण को पढ़े बिना आपके प्रस्ताव वाक्य रचना को पढ़ा।

क्या हमारे पास कुछ बेहतर हो सकता है?

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

प्रतिक्रिया-मूल से आते हुए, मैंने पहले JSX जैसे कार्यान्वयन का समर्थन किया, और नेस्टेड वस्तुओं को पसंद नहीं किया, लेकिन मैं OOP का आनंद लेना शुरू कर रहा हूं और सब कुछ एक वस्तु के रूप में देख रहा हूं!

रिएक्ट-नेटिव से आने वाले लोगों के लिए, मैं इस प्लगइन की अत्यधिक अनुशंसा करता हूँ! https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer

@clarktank
क्या आप प्रतिक्रिया-मूल (जेएसएक्स), स्पंदन (ओओपी), और एक से दूसरे तक अपनी यात्रा के साथ अपने विस्तार का विस्तार कर सकते हैं?

@cbazza मुझे लगता है कि कोणीय टेम्पलेट सिंटैक्स एक्सएमएल सेमेन्टिक्स का पालन करता है और जैसा कि मुझे पता है कि कोणीय वाक्यविन्यास और एक्सएमएल दस्तावेज़ के बीच कोई संघर्ष उपयोग मामला नहीं है।

टाइपस्क्रिप्ट में, हमारे पास सामान्य घटक के लिए समर्थन है।
तो मुझे लगता है कि हमारे पास ऐसा कुछ हो सकता है:

<children<Container>>
  <Container/>
</children>

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

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

प्रतिक्रिया हमें सब कुछ बताती है।

अब तक, +1 लगभग दोगुना -1

इसका कोई मतलब नहीं है।

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

@sandangel ,

मुझे लगता है कि कोणीय टेम्पलेट सिंटैक्स एक्सएमएल सेमेन्टिक्स का पालन करता है और जैसा कि मुझे पता है कि कोणीय वाक्यविन्यास और एक्सएमएल दस्तावेज़ के बीच कोई संघर्ष उपयोग मामला नहीं है।

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

<children<Container>>
  <Container/>
</children>

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

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

जिस तरह से फ़्लटर कोड में UI घोषित करता है, उसमें कुछ भी नया नहीं है, शायद DSX का उपयोग करना आपके लिए अप्राकृतिक / असुविधाजनक है लेकिन JSX डेवलपर्स के लिए ऐसा नहीं है। JSX/DSX स्पंदन के लिए एकदम सही है, यह एक दस्ताने की तरह फिट बैठता है और अगर आपको दस्ताने पसंद नहीं हैं तो नंगे हाथ जाएं;)

@ ए14एन ,

इसका कोई मतलब नहीं है।

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

@cbazza मेरा मतलब है कि जब हम बच्चे/बच्चों के लिए उप-प्रकार के विजेट को लागू करने के बारे में ऊपर दिए गए प्रश्न का उत्तर देने का प्रयास कर रहे हैं, तो मुझे लगता है कि डार्ट कोड जेएसएक्स की तुलना में बेहतर काम कर रहा है।

DSX XML नहीं है, यह XML जैसा है इसलिए इसे XML शब्दार्थ का पालन करने की आवश्यकता नहीं है

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

मुझे यकीन नहीं है लेकिन मैंने ऊपर आपकी कुछ टिप्पणियां पढ़ी हैं और मुझे लगता है कि आपने जेएसएक्स/एक्सएमएल नोड को एक दूसरे के रूप में उल्लेख किया है। वैसे भी, व्यक्तिगत रूप से मुझे लगता है कि समाधान के रूप में नामस्थान का उपयोग करना आदर्श नहीं है।

बस तुलना करें

<actions:children:Container>

</actions:children:Container>

तथा

actions: <Container>[]

वाक्य - विन्यास।

@sandangel ,

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

@a14n वोट ही वोट है, इसका पक्का मतलब है।

मैं आपकी भावना का सम्मान करता हूं, शायद यह सच है। लेकिन रिवर्स रेशियो (1 से 2) के साथ भी, इसका मतलब अभी भी 33% उपयोगकर्ता आधार है। क्या आप कह सकते हैं कि 33% एक छोटा सा हिस्सा है?

जो लोग JSX जैसा अनुभव चाहते हैं

हाँ, कुछ लोग देख रहे हैं। इसका मतलब यह भी है कि _JSX की तरह की कमी लोगों को स्पंदन चुनने से रोकने का एक कारण है।

स्पंदन का लक्ष्य अधिक डेवलपर्स है, न केवल सभी मुद्दों को पढ़ते हैं।

@jstansbe
मैं एक स्व-सिखाया प्रोग्रामर हूं, और अधिकांश स्व-सिखाए गए लोगों की तरह, मैंने जावास्क्रिप्ट के साथ शुरुआत की।
फिर मैंने रिएक्ट और रिएक्ट-नेटिव सीखना शुरू किया। मुझे लगता है कि हाल के वर्षों में, विशेष रूप से ES6 के बाद, OOP शैली को Javascript में जोड़ा गया था।

इसलिए मेरे जैसे लोगों को प्रोग्रामिंग की ओओपी शैली की आदत नहीं है। भले ही रिएक्ट नेटिव Component स्पंदन में Widgets की तरह ही कक्षाएं हों।

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

निजी तौर पर, मुझे लगता है कि शुद्ध ओओपी बड़ी परियोजनाओं के लिए अधिक समझ में आता है।

@क्लार्कटैंक ,

कंप्यूटर भाषाओं पर चर्चा करते समय आपको निम्न बातों की जानकारी होनी चाहिए:
(1) वाक्य-विन्यास - वर्ण और शब्द जो भाषा बनाते हैं
(2) शब्दार्थ - उन वर्णों और शब्दों का अर्थ

उदाहरण के लिए, कई भाषाओं में फ़ंक्शन कॉल निम्न की तरह दिखती हैं (अर्थात निम्न सिंटैक्स है):

a = someFunction(param1, param2)

अब कल्पना कीजिए कि कोई अन्य भाषा फ़ंक्शन कॉल के लिए गोल कोष्ठक के बजाय वर्ग कोष्ठक का उपयोग करने का निर्णय लेती है; यह निम्नलिखित की तरह दिखेगा:

a = someFunction[param1, param2]

यहाँ बात यह है कि वाक्य रचना अलग है लेकिन शब्दार्थ एक ही है। मेरा मतलब है कि दोनों मूल रूप से फ़ंक्शन कॉल कर रहे हैं लेकिन एक अलग वाक्यविन्यास के साथ।

JSX तरह का शुद्ध OOP चित्र छुपाता है। मूल रूप से, यह छुपाता है कि हुड के नीचे क्या होता है।

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

नोट: रिएक्ट वेब डेवलपर्स के लिए डिज़ाइन किया गया था, और वेब डेवलपर्स का उपयोग html सिंटैक्स के लिए किया जाता है। यही कारण है कि JSX वेब डेवलपर्स के बीच इतना लोकप्रिय है।

JSX लोकप्रिय है क्योंकि यह घटक ट्री पदानुक्रमों को प्रबंधित करने का एक शानदार तरीका है, चाहे वह वेब, मोबाइल या किसी UI विकास के लिए हो। नीचे दिए गए कोड में सूचना आपको नहीं पता कि ड्रॉपडाउन घटक वेब के लिए है या मोबाइल उदाहरण के लिए।

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

// Using JSX to express UI components.
var dropdown =
  <Dropdown>
    A dropdown list
    <Menu>
      <MenuItem>Do Something</MenuItem>
      <MenuItem>Do Something Fun!</MenuItem>
      <MenuItem>Do Something Else</MenuItem>
    </Menu>
  </Dropdown>;

render(dropdown);

निजी तौर पर, मुझे लगता है कि शुद्ध ओओपी बड़ी परियोजनाओं के लिए अधिक समझ में आता है।

वह भी कैसे? (यह देखते हुए कि जेएसएक्स/डीएसएक्स या शुद्ध जावास्क्रिप्ट/डार्ट का उपयोग हुड के नीचे बिल्कुल वही चीज़ उत्पन्न करता है)।

@cbazza

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

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

@क्लार्कटैंक ,

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

मेरे लिए यह बाकी कोड से अलग दिखना वास्तव में एक लाभ है।

(मैं पाठ की दीवार के लिए अग्रिम रूप से क्षमा चाहता हूं।)

किसी ऐसे व्यक्ति के रूप में जिसने रिएक्ट-नेटिव या स्पंदन का उपयोग नहीं किया है, अपने आप को एक निश्चित स्रोत मानने के लिए कि क्या कच्चा डार्ट या JSX / DSX "बेहतर" है, यह मुद्दा धागा पढ़ने के लिए आकर्षक है। हालांकि कुछ चीजें हैं जो मैं अपने $0.02 को नीचे रखना चाहूंगा।

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

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

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

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

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

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

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

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

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

शास्त्रीय:

Widget build(BuildContext context) {
  return Center(
    child: Text("foo"),
  );
}

यह पहले से ही लीक से हटकर पठनीय, लिखने में आसान, टाइप/जेनेरिक संगत, और बिना किसी अनावश्यक दोहराव के है।

वर्तमान सिंटैक्स के साथ संभवतः आपके पास एकमात्र शिकायत हो सकती है "यह जानना मुश्किल है कि विजेट का समापन कोष्ठक कहां है"

लेकिन फिर, आधिकारिक तौर पर समर्थित IDEs का डार्ट प्लगइन इस समस्या को हल करता है। ताकि जब हम vscode में पहले से कोड खोलते हैं, तो हम देखेंगे

Widget build(BuildContext context) {
  return Center(
    child: Text("foo"),
  ); // Center
}

"यूआई कोड से आकस्मिक कोड को अलग करना मुश्किल है" के लिए, प्रतिक्रिया नियम स्पंदन पर भी लागू होते हैं:

विजेट या तो गूंगा या स्मार्ट होना चाहिए। स्मार्ट विजेट में UI तर्क नहीं है। गूंगा विजेट में UI तर्क के अलावा कुछ नहीं है।

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

JSX का उपयोग प्रतिक्रिया में किया जाता है क्योंकि JS सिंटैक्स भयानक है

बहुत ही सुविचारित कथन और बस सच नहीं है।

render() {
  return React.createElement(Container, { padding: EdgeInsets.all(20.0) },
    React.createElement(Text, { style: { color: Colors.black } },
      'foo'
    )
  );
}

Widget build(BuildContext context) {
  return Container(
    padding: EdgeInsets.all(20.0),
    child: Text(
      'foo',
      style: TextStyle(color: Colors.black)
    ),
  );
}

render() {
  return (
    <Container padding={EdgeInsets.all(20.0)}>
      <Text style={{ color: Colors.black }}>foo</Text>
    </Container>
  );
}

Widget build(BuildContext context) {
  return (
    <Container padding={EdgeInsets.all(20.0)}>
      <Text style={TextStyle(color: Colors.black)}>{'foo'}</Text>
    </Container>
  );
}

बहुत ही सुविचारित कथन और बस सच नहीं है।

डिफ़ॉल्ट प्रतिक्रिया वाक्य रचना में बहुत सारे अनावश्यक वर्ण हैं।
आइए शब्दों की पुनरावृत्ति की तुलना करें और प्रत्येक सिंटैक्स के लिए वर्णों की गणना करें (फ़ंक्शन परिभाषा, इंडेंटेशन और 'रिटर्न' को छोड़कर)

JSX के बिना प्रतिक्रिया:

• 133 वर्ण, जिसमें 3 कोष्ठक, 3 कोष्ठक, 3 : , 4 , और 11 रिक्त स्थान शामिल हैं
• React.createElement दो बार लिखा गया

जेएसएक्स:

• 104 वर्ण, 2 कोष्ठक, 3 कोष्ठक, 1 : , 4 <> और 5 रिक्त स्थान के साथ
• Container और Text दो बार लिखा गया

डार्ट:

• 99 वर्ण, 2 कोष्ठक, 4 : , 3 , और 4 रिक्त स्थान के साथ
• कोई दोहराव नहीं

पात्रों के संदर्भ में, यहाँ स्पष्ट विजेता डार्ट सिंटैक्स है।

अब हमें अन्य डार्ट बारीकियों को भी ध्यान में रखना होगा।

डार्ट सिंगल चाइल्ड बनाम मल्टी-चाइल्ड टाइप करता है, इसमें const कंस्ट्रक्टर होते हैं और जेनरिक और यहां तक ​​कि पोजिशनिंग पैरामीटर की अनुमति देता है। JSX इनमें से किसी का भी समर्थन नहीं करता है।

कुछ उदाहरण जो बुरी तरह से JSX में परिवर्तित हो जाएंगे:

हमेशा नहीं children :

Scaffold(
  appBar: AppBar(),
  body: Container(),
)

OR

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

const स्वयं विजेट पर निर्माता

const Padding(
  padding: const EdgeInsets.all(4.0),
)

जेनरिक

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

तैनात सहारा:

Text("foo")

नामांकित निर्माता

Positioned.fill(
  child: Container(),
);

बिल्डर्स (डार्ट संघ प्रकार का समर्थन नहीं करता है इसलिए children विजेट और फ़ंक्शन दोनों नहीं हो सकते हैं)

Builder(
  builder: (context) => Container(),
)

@rrousselGit

जैसा कि डीएसएक्स से पहले कई बार उल्लेख किया गया है, बस एक अलग है
सिंटैक्स और यह डार्ट का सुपरसेट है, इसलिए वह सब कुछ जिसके साथ आप कर सकते हैं
डार्ट आप इसे DSX के अंदर कर सकते हैं। आप दोनों को मिक्स एंड मैच भी कर सकते हैं
सिंटैक्स जैसा कि आप फिट देखते हैं। जाहिर है आपने चेक करने की जहमत भी नहीं उठाई
समर्थन करने के लिए किए गए DSX सुविधाओं में से कुछ क्या हैं?
डार्ट:
https://spark-heroku-dsx.herokuapp.com/index.html

-1-----------------------------------------------------
डार्ट में:

Scaffold(
  appBar: AppBar(),
  body: Container(),
)

OR

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

डीएसएक्स में:

<Scaffold
  appBar={<AppBar/>}
  body={<Container/>}
/>

OR

<SingleChildScrollView>
  <Container
    height={100.0}
  />
</SingleChildScrollView>

-2-----------------------------------------------------
डार्ट में:

const Padding(
  padding: const EdgeInsets.all(4.0),
)

डीएसएक्स में:

const Padding(
  padding: const EdgeInsets.all(4.0),
)

-3--------------------------------------------------------
डार्ट में:

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

डीएसएक्स में:

<NotificationListener<ScrollNotification>
  onNotification={(foo) {

  }}
  child={child}
/>

-4 ----------------------------------------
डार्ट में:

Text("foo")

डीएसएक्स में:

<Text ["foo"]/>

-5-----------------------------------------------------
डार्ट में:

Positioned.fill(
  child: Container(),
);

डीएसएक्स में:

<Positioned.fill>
  <Container/>
</Positioned.fill>

-6-----------------------------------------------------
डार्ट में:

Builder(
  builder: (context) => Container(),
)

डीएसएक्स में:

<Builder
  builder={(context) => <Container/>}
/>

लेकिन फिर प्रतिक्रिया से स्पंदन में आसान रूपांतरण होने का तर्क अमान्य है। चूंकि JSX आपके प्रोटोटाइप से मौलिक रूप से अलग है:

<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

और यहां या आपके लिंक से आपका कोई भी उदाहरण वास्तव में कोड को सरल नहीं करता है या पठनीयता में सुधार करता है

जितना मैं लापता JSX की आपकी भावना से संबंधित हो सकता हूं (स्पंदन शुरू करते समय वही मिला), कुछ अनुभव के बाद, मूल वाक्यविन्यास वास्तव में बहुत अच्छा लगता है

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

मैं इसके बजाय एक पसंद करूंगा:

// main.dart
import 'package:flutter/material.dart';

part 'main.g.dart';

class MyState extends StatefulWidget {
  <strong i="14">@override</strong>
  _MyStateState createState() => _MyStateState();
}

class _MyStateState extends State<MyState> {
  <strong i="15">@override</strong>
  Widget build(BuildContext context) {
    return $myStateStateTemplate(theme: Theme.of(context));
  }
}

ए के साथ संयुक्त

// main.xml
<strong i="19">@theme</strong> ThemeData

<Container  color={@theme.cardColor} />

जो तब एक कस्टम कोड-जेन का उपयोग करके निम्नलिखित डार्ट फ़ाइल उत्पन्न करता है:

part of 'main.dart';

Widget $myStateStateTemplate({ThemeData theme}) {
  return Container(
    color: theme.cardColor,
  );
}

अंतिम परिणाम UI/तर्क को अलग करने के लिए "DSX" से भी बेहतर है। यह संभावित UI जेनरेटर के लिए भी बेहतर है। और built का उपयोग करके इसे लागू करना बहुत आसान है।

चूंकि JSX आपके प्रोटोटाइप से मौलिक रूप से अलग है:

सच में !!! इन चर्चाओं में केवल एक चीज कट्टरपंथी थी, जो कि विरोधियों की प्रतिक्रिया थी।

जैसा कि इस टिकट के शीर्षक में कहा गया है, DSX JSX जैसा है, यह JSX-समान नहीं है अन्यथा इसे JSX कहा जाता; और इसके परिवर्धन मामूली हैं और डेवलपर्स को विकल्प प्रदान करते हैं।

आप इसे इस तरह लिख सकते हैं:

<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

or

<MyAppBar>
    <title:Text ['Example title'] style={Theme.of(context).primaryTextTheme.title}/>
</MyAppBar>

or

<MyAppBar
    title={<Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    <Text>}
/>

or

<MyAppBar
    title={<Text ['Example title'] style={Theme.of(context).primaryTextTheme.title}/>}
/>

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

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

यहां पोस्ट किए गए बहुत सारे कोड और उदाहरण ( विशेष रूप से ) के बाद, मैं इस निष्कर्ष पर पहुंचा हूं कि JSX DSX और डार्ट के विपरीत JS में बहुत अधिक मूल्य जोड़ता है। लेकिन मेरे दृष्टिकोण से एक विशेषता बहुत महत्वपूर्ण है: क्लोजिंग टैग। पसंद:

<SingleChildScrollView>
  <Container
    height={100.0}
  />
</SingleChildScrollView>

इसके विपरीत यहाँ की तरह गहरी संरचनाओं में बहुत सारी संज्ञानात्मक जटिलता को कम करता है:

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

लेकिन ठीक है, अगर आप इसे इस तरह इस्तेमाल करते हैं:

<Scaffold
  appBar={<AppBar/>}
  body={<Container/>}
/>

एक छोटा सा लाभ है।

जैसा कि इस टिकट के शीर्षक में कहा गया है, DSX JSX जैसा है, यह JSX-समान नहीं है

आपने मेरे "लेकिन फिर प्रतिक्रिया से स्पंदन में आसान रूपांतरण होने का तर्क अमान्य है।"

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

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

सच नहीं। आप अपनी टेम्पलेट फ़ाइल के अंदर if और सामान कर सकते हैं। cshtml या कोणीय टेम्प्लेट देखें।

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

जबकि एक DSX को बहुत अधिक काम करने की आवश्यकता होगी।

@Bessonov उन्होंने हाल ही में क्लोजिंग टैग का मजाक उड़ाने के लिए समर्थित IDEs पर आभासी टिप्पणियां जोड़ीं।

तो आपके बनाम कोड में आप निम्नलिखित देखेंगे:

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ), // Container
) // SingleChildScrollView

टैग बंद करने के लाभ। उन्हें टाइप किए बिना

@rrousselGit

उन्होंने हाल ही में क्लोजिंग टैग का मजाक उड़ाने के लिए समर्थित आईडीई पर आभासी टिप्पणियां जोड़ीं।

हाँ, मैंने इसे उद्धृत टिप्पणी में देखा है। लेकिन यह वही नहीं है। यह एक संरेखित बदलाव पेश करता है और पढ़ने के प्रवाह को परेशान करता है। और यह मुझे अन्य आईडीई और टेक्स्ट प्रोसेसर में मदद नहीं करता है।

बात एक टेम्पलेट फ़ाइल है

IMHO टेम्प्लेट NIH सिंड्रोम से ग्रस्त हैं। मैं यह नहीं कहता कि PHP और HTML को मिलाने का तरीका ऐसा करने का सही तरीका है। लेकिन प्रतिक्रिया JSX के साथ दिखाती है कि इसे और बेहतर कैसे किया जा सकता है।

@rrousselGit

आपने मेरे "लेकिन फिर प्रतिक्रिया से स्पंदन में आसान रूपांतरण होने का तर्क अमान्य है।"

नहीं, मैंने टिप्पणी को बिल्कुल भी नहीं छोड़ा, इसका कोई मतलब नहीं है कि आप मुझे बताएं कि JSX से आने वाले लोग DSX को बहुत जटिल पाएंगे।

DSX के लिए आधे तर्क...

DSX को चुनने के कई कारण हैं, लेकिन विकल्प के साथ लोग वही चुनेंगे जो उनके पास किसी भी कारण से पसंद हो।

सच नहीं। आप अपनी टेम्पलेट फ़ाइल के अंदर और सामान कर सकते हैं। cshtml या कोणीय टेम्पलेट देखें।

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

जबकि एक DSX को बहुत अधिक काम करने की आवश्यकता होगी।

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

नहीं, मैंने टिप्पणी को बिल्कुल भी नहीं छोड़ा, इसका कोई मतलब नहीं है कि आप मुझे बताएं कि JSX से आने वाले लोग DSX को बहुत जटिल पाएंगे।

वर्तमान डार्ट कार्यान्वयन पर भी यही बात लागू होती है।

वैसे भी, मुझे नहीं लगता कि हम यहां एक-दूसरे को मना सकते हैं। तो मैं बस कुछ और कारणों की सूची दूंगा कि क्यों मैं JSX को स्पंदन में नापसंद करता हूं और फिर "प्रतीक्षा करें और देखें"।

1. विजेट निर्माण प्रतिक्रिया से अलग है

प्रतिक्रिया में, यह पुस्तकालय है जो घटकों के निर्माण को संभालता है। JSX ठीक है क्योंकि यह कहता है "इस बारे में चिंता न करें कि चीजें कैसे काम करती हैं। हम आपके लिए चीजें करते हैं"।

स्पंदन में ऐसा नहीं है। हम प्रत्येक बिल्ड कॉल पर मैन्युअल रूप से एक नया विजेट तुरंत चालू करते हैं। यह समझना वास्तव में महत्वपूर्ण है, और JSX इसे कम स्पष्ट करेगा।

और, उस तर्क की निरंतरता में:

2. लोग सोच सकते हैं कि <Foo /> कुछ खास करता है जो new Foo() नहीं करता है

<Foo /> एक विधि में विशेष लगता है। ऐसा लगता है कि यह ढांचे में अंतर्निहित कुछ बाहरी करता है। जो प्रतिक्रिया में सच है, जहां घटकों को React.Element में लपेटा जाता है।
यह प्रतिक्रिया में अनुवाद करता है <Foo /> != new Foo() और Foo तक सीधी पहुंच नहीं है।

यह स्पंदन में लागू नहीं होता है और भ्रम पैदा कर सकता है।

भी :

<Foo>
  <Bar />
</Foo>

प्रतिक्रिया में, यदि Foo कभी भी अपने बच्चे का उपयोग नहीं करता है तो Bar कभी भी तत्काल नहीं होता है। और Foo को render मेथड रिटर्न के बाद इंस्टेंट किया जाता है।
जबकि स्पंदन में यह विपरीत है। Bar और Foo दोनों तुरंत बन जाते हैं

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

3. सामान्य तौर पर डार्ट/स्पंदन जेएस/प्रतिक्रिया नहीं है

अगर हम डार्ट में JSX जोड़ते हैं, तो मैं पहले से ही टाइप यूनियन के बारे में मुद्दों को देख सकता हूं या कर सकता हूं
return foo && <Component /> या प्रतिक्रिया में आगामी async प्रतिपादन।
"हमारे पास पहले से ही JSX है, इसलिए हमारे पास वह भी हो सकता है!"

डार्ट में नवीनतम JSX/प्रतिक्रिया सुविधा को लागू नहीं करने के लिए, मैं एक मालिकाना वाक्यविन्यास या बिल्कुल भी वाक्यविन्यास पसंद नहीं करूंगा

4. JSX कुछ डार्ट बारीकियों को अस्पष्ट बनाता है

एक छोटा सा उदाहरण, Scaffold के लिए appbar a PrefferedSizeWidget की आवश्यकता है।
यदि हमने JSX का उपयोग करके Scaffold बनाया है, तो लोग उम्मीद करेंगे कि आप किसी दिए गए JSX को दूसरे के साथ बदल सकते हैं। जो सच नहीं है

मेरा मतलब है, यह बहुत अस्पष्ट बनाता है कि हम ऐसा क्यों कर सकते हैं

<Scaffold
  appbar={<AppBar />}
/>

लेकिन नहीं

<Scaffold
  appbar={<Container />}
/>

@rrousselGit

वैसे भी, मुझे नहीं लगता कि हम यहां एक-दूसरे को मना सकते हैं। तो मैं बस कुछ और कारणों की सूची दूंगा कि क्यों मैं JSX को स्पंदन में नापसंद करता हूं और फिर "प्रतीक्षा करें और देखें"।

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

1. विजेट निर्माण प्रतिक्रिया से अलग है

मेरे लिए यह कोई मायने नहीं रखता क्योंकि यह सिर्फ एक कार्यान्वयन विवरण है, वैचारिक रूप से एक बार जब आप कुछ एक्सएमएल देखते हैं, तो रिएक्ट में यह एक घटक है, स्पंदन में यह एक विजेट है।

1. लोग सोच सकते हैं कुछ खास करता है कि नया फू () नहीं

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

1. सामान्य तौर पर डार्ट/स्पंदन जेएस/प्रतिक्रिया नहीं है

हां, हम अंत में किसी बात पर सहमत होते हैं, लेकिन भले ही वे अलग-अलग हों, आम धागा यह है कि वे घोषणात्मक यूआई ढांचे हैं और मुझे लगता है कि घोषणात्मक वृक्ष संरचनाएं जेएसएक्स/डीएसएक्स के साथ अच्छी तरह से संभाली जाती हैं। यह आपको घोषणात्मक प्रोग्रामिंग तरीके से सोचने पर रखता है।

यदि हम डार्ट में JSX जोड़ते हैं, तो मैं पहले से ही टाइप यूनियन के बारे में मुद्दों को देख सकता हूं या प्रतिक्रिया में return foo && <Component /> या आगामी async रेंडरिंग करने में सक्षम हो सकता हूं।
"हमारे पास पहले से ही JSX है, इसलिए हमारे पास वह भी हो सकता है!"

हम डार्ट में JSX नहीं जोड़ रहे हैं, हम DSX जोड़ रहे हैं, यह अलग है लेकिन JSX से समानता है और परिचित होना बहुत बड़ी बात है।

डार्ट में नवीनतम JSX/प्रतिक्रिया सुविधा को लागू नहीं करने के लिए, मैं एक मालिकाना सिंटैक्स या कोई सिंटैक्स बिल्कुल पसंद नहीं करूंगा।

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

1. JSX कुछ डार्ट बारीकियों को अस्पष्ट बनाता है

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

@cbazza मैंने आपकी पोस्ट पढ़ने में घंटों बिताए और मैं वास्तव में इस मुद्दे पर आपके प्रयास की सराहना करता हूं। लेकिन मुझे लगता है कि तर्क को समाप्त करना (तरह का) आसान है। याद रखें कि फ्लक्स प्रतिक्रिया के लिए आधिकारिक राज्य प्रबंधन समाधान था लेकिन अब हर कोई रेडक्स का उपयोग कर रहा है? और प्रतिक्रिया-मूल के लिए कितने नेविगेशन काम हैं? बस एक DSX रेपो बनाएं और प्रतिक्रिया देने वाले देवों को कूदने दें।

@rrousselGit

मैंने पहले कभी डार्ट में part / part of सिंटैक्स नहीं देखा है, और मुझे इसके लिए कोई दस्तावेज़ खोजने में परेशानी हो रही है। क्या डार्ट/स्पंदन आधिकारिक तौर पर इसका समर्थन करता है? मुझे FLUI में ऐसा कुछ उपयोग करना अच्छा लगेगा।

@cbazza

आप DSX औचित्य के साथ मंडलियों में घूमते रहते हैं। DSX JSX नहीं है। DSX JSX जैसा है। DSX रिएक्ट डेवलपर्स के लिए एक परिचित सिंटैक्स है। DSX डार्ट के लिए केवल थिंक सिंटैक्टिक शुगर है। लोग सीखेंगे कि DSX JSX नहीं है। (और इसी तरह।)

जबकि मुझे वह बिंदु मिलता है जिसे आप उन सभी स्पष्टीकरणों के साथ बनाने की कोशिश कर रहे हैं, मुझे लगता है कि तथ्य यह है कि आपको उन्हें सामान्य रूप से डीएसएक्स की प्रकृति के बारे में एक प्रमुख मुद्दे का खुलासा करना है, और यह एक ऐसा बिंदु है जिसे rrouselGit भी लाया गया है। यहां तक ​​​​कि जब आप यह कहते रहते हैं कि DSX _not_ JSX है, तो इसे खोजने वाले लोग सोचेंगे कि यह है, और यह एक समस्या है। JSX, और जो लोग इसका उपयोग करते हैं, वे एक ऐसे पारिस्थितिकी तंत्र से आते हैं जो कि डार्ट/स्पंदन से मौलिक स्तरों पर अवधारणात्मक रूप से भिन्न है। जैसे, "परिचित" के लिए एक विशेषता विकसित करना एक अच्छी बात नहीं है। इस तरह के अधिक स्पष्ट कारणों में से एक है, जैसा कि बताया गया था, लोग कुछ इस तरह की कोशिश करने जा रहे हैं:

Widget build(BuildContext context) {
    return isDialogVisible && <Widget>...</Widget>;
}

क्योंकि वे Javascript/JSX से आते हैं, वे उम्मीद करते हैं कि सिंटैक्स DSX में काम करेगा। जब ऐसा नहीं होता है, तो यह संज्ञानात्मक असंगति का एक बिंदु बन जाता है जो वास्तव में न केवल DSX में बल्कि पूरे स्पंदन में उनकी रुचि को _चोट_ सकता है। परिचित तब फायदेमंद होता है जब इसका उपयोग लोगों को कुछ नया करने में आसानी करने के साधन के रूप में किया जाता है, लेकिन यह दोधारी तलवार हो सकती है - जब 90% विशेषताएं समान होती हैं, तो शेष 10% केवल निराश और परेशान करने का काम कर सकती हैं।

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

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

@andrewackerman

part / part of एक मौजूदा डार्ट सुविधा है। यह किसी तरह दो फाइलों को एक में मिला देता है। आमतौर पर कोड जनरेशन के लिए उपयोग किया जाता है।

कुछ वास्तविक मामले परिदृश्य हैं जो ऐसी तकनीक का उपयोग करते हैं। जैसे json_serializable जो toJSON विधि और fromJSON फैक्ट्री को उनके गुणों के आधार पर कक्षाओं के लिए उत्पन्न करता है।

part / part of वास्तव में अपने आप कुछ भी नहीं करते हैं। दिलचस्प बात यह है कि जब आप इसे source_gen जैसी किसी चीज़ से जोड़ते हैं।

@sunnylqm

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

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

@andrewackerman

मुझे कुछ भी सही ठहराने की जरूरत नहीं है, मुझे पूरा विश्वास है कि DSX हिट होगा और अकेले इस टिकट पर लगभग 100 लोग इसमें रुचि रखते हैं।

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

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

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

बस एक समयरेखा बनाएं और आप यूआई विकास विकास देखेंगे। Android और iOS का विकास अपने मौजूदा तरीकों से 10 साल पहले शुरू हुआ था, इसलिए यह 10 साल पुरानी तकनीकों (पूरी तरह से अनिवार्य तकनीक) का उपयोग करता है। रिएक्टिव यूआई डेवलपमेंट (घोषणात्मक) तकनीक लगभग 8 साल पहले वेब के लिए दिखाई देने लगी थी। रिएक्ट 5 साल पहले सामने आया था और यह JSX के साथ प्रौद्योगिकियों को मूल रूप से संयोजित करने वाला पहला प्रतिक्रियाशील ढांचा था। Vue अब नवीनतम प्रतिक्रियाशील ढांचा है जो पुरानी 'प्रौद्योगिकियों के पृथक्करण' तकनीकों का समर्थन करता है लेकिन यह JSX का भी समर्थन करता है। मोबाइल पर स्पंदन नवीनतम है और यह रिएक्ट के रूप में रिएक्टिव फ्रेमवर्क तकनीकों का उपयोग करता है और यह DSX का लाभ उठा सकता है जैसे Vue JSX का लाभ उठाता है। Vue कोणीय को मार रहा है क्योंकि यह डेवलपर्स को विकल्प प्रदान कर रहा है और अत्यधिक राय नहीं दे रहा है।

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

प्रतिक्रिया डेवलपर्स बात करते हैं जैसे JSX भविष्य का तरीका है,

यह है !!!

लेकिन मैंने अभी तक इसे किसी भी वास्तविक कर्षण प्राप्त करने वाले ढांचे में प्रतिक्रिया के अलावा कहीं भी पॉप अप नहीं देखा है।

Vue JSX का उपयोग करता है

@cbazza

मुझे कुछ भी सही ठहराने की जरूरत नहीं है, मुझे पूरा विश्वास है कि DSX हिट होगा और अकेले इस टिकट पर लगभग 100 लोग इसमें रुचि रखते हैं।

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

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

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

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

Vue JSX का उपयोग करता है

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

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

यह है !!!

जब तक मैं इसे गैर-जावास्क्रिप्ट विकास वातावरण में पकड़ता नहीं देखता, तब तक मैं सम्मानपूर्वक असहमत रहूंगा।

Vue JSX का उपयोग करता है

Vue निर्दिष्ट में उपयोग की एक विस्तृत विविधता है। JSX बस "वहाँ" है। लेकिन यह प्रमुख वाक्य रचना नहीं है
आप चाहें तो JSX को Angular में प्लग कर सकते हैं। हालांकि कोई नहीं करता

प्रतिक्रिया डेवलपर्स बात करते हैं जैसे JSX भविष्य का तरीका है,
यह है !!!

भविष्य के लिए एक बड़ा उम्मीदवार वेब-घटक है। और वे सीधे html में उसी तरह उपयोग किए जाते हैं जैसे आप Angular या Vue के सबसे सामान्य रूप में पाते हैं

@andrewackerman

केवल तथ्य यह है कि डेवलपर को निर्माण करने से पहले मैन्युअल क्रियाओं की एक और चेकलिस्ट से गुजरना पड़ता है, यह कई लोगों के लिए बंद करने के लिए पर्याप्त है।

मैनुअल क्रियाओं के बारे में किसने कुछ कहा? क्या मैंने खुद को स्पष्ट नहीं किया कि मैं पूर्ण निर्बाध आईडीई एकीकरण (डेवलपर्स के लिए सर्वोत्तम संभव उपयोगकर्ता अनुभव) प्राप्त करने का प्रयास कर रहा हूं।

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

इसका DSX का उपयोग करने वाले लोगों से क्या लेना-देना है? मैंने JSX का 2 वर्षों से अधिक समय से उपयोग किया है और इसके स्रोत कोड की कम परवाह नहीं कर सकता। क्या आपको डार्ट में प्रोग्राम करने में सक्षम होने के लिए डार्ट कंपाइलर के सोर्स कोड को देखने की जरूरत है?

मैं जो कहूंगा वह यह है कि उनमें से एक में भी मैंने कभी जेएसएक्स को वास्तव में उपयोग नहीं किया है - लोग रेंडर + जेएसएक्स दृष्टिकोण पर .vue दृष्टिकोण (टेम्पलेट-स्क्रिप्ट-स्टाइलिंग) को बड़े पैमाने पर पसंद करते हैं।

JSX एक नया अतिरिक्त है, इसलिए इसे फैलने में समय लगेगा लेकिन महत्वपूर्ण बिंदु यह है कि Vue डेवलपर्स को 'सही तरीके और एकमात्र तरीके' का उपयोग करने के लिए मजबूर किए बिना अन्य दृष्टिकोणों को स्वीकार करता है कि चीजों को Vue में किया जाना चाहिए।

Vue अभी भी एक Javascript फ्रेमवर्क है। स्पंदन सबसे निश्चित रूप से नहीं है।

Riiiiight, इसलिए JSX के बजाय आप स्पंदन के साथ DSX का उपयोग करते हैं।

@rrousselGit

भविष्य के लिए एक बड़ा उम्मीदवार वेब-घटक है।

वेब घटक ज़ोबी हैं, मृत लेकिन फिर भी चल रहे हैं; वे कनाडा में कंगारुओं की तरह व्यापक हैं। मैं कई दिनों तक चल सकता था लेकिन पचाने से बचने के लिए...
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/

@cbazza

मैनुअल क्रियाओं के बारे में किसने कुछ कहा? क्या मैंने खुद को स्पष्ट नहीं किया कि मैं पूर्ण निर्बाध आईडीई एकीकरण (डेवलपर्स के लिए सर्वोत्तम संभव उपयोगकर्ता अनुभव) प्राप्त करने का प्रयास कर रहा हूं।

आपने यह भी कहा कि ऐसा करने के लिए आपको फ़्लटर/डार्ट टीम से प्रीप्रोसेसिंग समर्थन की आवश्यकता है। क्या मैं इसमें गलत हूँ?

इसका DSX का उपयोग करने वाले लोगों से क्या लेना-देना है? मैंने JSX का 2 वर्षों से अधिक समय से उपयोग किया है और इसके स्रोत कोड की कम परवाह नहीं कर सकता।

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

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

मैं आप पर झूठ बोलने या कुछ भी करने का आरोप नहीं लगा रहा हूं, मैं सिर्फ इतना कह रहा हूं कि JSX ने विश्वास का एक स्तर अर्जित किया है जो DSX ने नहीं किया है, तो अगर आप लोगों को इसके साथ छेड़छाड़ नहीं करने देंगे तो आप कुछ सिर कैसे मोड़ेंगे?

JSX एक नया अतिरिक्त है, इसलिए इसे फैलने में समय लगेगा लेकिन महत्वपूर्ण बिंदु यह है कि Vue डेवलपर्स को 'सही तरीके और एकमात्र तरीके' का उपयोग करने के लिए मजबूर किए बिना अन्य दृष्टिकोणों को स्वीकार करता है कि चीजों को Vue में किया जाना चाहिए।

JSX लगभग 2 वर्षों से Vue में है। और स्वयं Vue के विपरीत, JSX एक पूर्व-मौजूदा तकनीक है जिसे किसी परिचय की आवश्यकता नहीं है, विशेष रूप से प्रतिक्रिया से परिचित लोगों के लिए। अगर JSX तूफान से Vue.js की दुनिया में ले जाने वाला था, तो मैं मदद नहीं कर सकता, लेकिन मुझे लगता है कि यह अब तक ऐसा कर चुका होता। (विशेष रूप से यदि यह कोई संकेत है कि जितने लोग दावा करते हैं, उतने लोग फ़्लटर में JSX के लिए संघर्ष कर रहे हैं।)

Riiiiight, इसलिए JSX के बजाय आप स्पंदन के साथ DSX का उपयोग करते हैं।

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

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

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

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

वेब घटक ज़ोबी हैं, मृत लेकिन फिर भी चल रहे हैं; वे कनाडा में कंगारुओं की तरह व्यापक हैं। मैं कई दिनों तक चल सकता था लेकिन पचाने से बचने के लिए...

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

@andrewackerman

क्षमा करें यार मेरे पास समय नहीं है कि मैं अंतहीन बहस करूं और जो मैंने पहले कहा था उसे बार-बार दोहराऊं; हम किसी भी तरह से समझौता नहीं करेंगे, इसलिए आपके FLUI के साथ शुभकामनाएँ।

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

ऑनलाइन DSX ट्रांसपिलर फरवरी 2018 से लाइव है और कोई भी इसका उपयोग कर सकता है, इसलिए किसी भी चीज़ के लिए मेरी बात मानने की कोई आवश्यकता नहीं है। 'संकलन' दबाएं और यह बाएं पैनल पर जो लिखा है उसे संकलित करता है और परिणाम दाएं पैनल पर रखता है। डीबगर खोलें और आप एएसटी लिखा हुआ देखेंगे।
https://spark-heroku-dsx.herokuapp.com/index.html

समस्या यह है कि, जहां JSX को जावास्क्रिप्ट जैसी कमजोर-टाइप की गई गतिशील भाषा पर बनाया गया था, DSX को डार्ट जैसी दृढ़ता से टाइप की गई स्थिर भाषा पर बनाया जा रहा है।

ओओपी (ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग) अवधारणा और 'कक्षाओं' के लिए वाक्यविन्यास जैसे इससे कोई बड़ा अंतर नहीं आता है। यह टाइपलेस जावास्क्रिप्ट या टाइप किए गए डार्ट में लगभग समान है; वही 'if' स्टेटमेंट, 'for' स्टेटमेंट, आदि के लिए कहा जा सकता है

इसे अभी भी मेज पर कुछ लाने की जरूरत है जो लोगों को इसका इस्तेमाल करने के लिए मनाने जा रही है।

जाहिरा तौर पर यह पहले से ही इस टिकट में 100 लोगों के लिए है; और यह सिर्फ मेरे द्वारा इसका उपयोग करने से 100 गुना बड़ा है; मेरे लिए काफी अच्छा।

@cbazza

क्षमा करें यार मेरे पास समय नहीं है कि मैं अंतहीन बहस करूं और जो मैंने पहले कहा था उसे बार-बार दोहराऊं; हम किसी भी तरह से समझौता नहीं करेंगे, इसलिए आपके FLUI के साथ शुभकामनाएँ।

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

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

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

मैंने यह भी नहीं देखा कि वह लिंक एक कामकाजी उदाहरण था। मैंने पहले कभी उसकेोकूप्प का उपयोग नहीं किया है और यह सिर्फ एक सार या कुछ जैसा दिखता है, इसलिए यह मुझ पर है। :पी

(हालांकि मैं यह बताऊंगा कि ऑनलाइन सैंडबॉक्स के साथ छेड़छाड़ करना ट्रांसपिलर को अधिक व्यावहारिक वातावरण में परीक्षण करने के समान नहीं है।)

ओओपी (ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग) अवधारणा और 'कक्षाओं' के लिए वाक्यविन्यास जैसे इससे कोई बड़ा अंतर नहीं आता है। यह टाइपलेस जावास्क्रिप्ट या टाइप किए गए डार्ट में लगभग समान है; वही 'if' स्टेटमेंट, 'for' स्टेटमेंट, आदि के लिए कहा जा सकता है

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

जाहिर तौर पर यह इस टिकट में पहले से ही 100 लोगों के लिए है; और यह सिर्फ मेरे द्वारा इसका उपयोग करने से 100 गुना बड़ा है; मेरे लिए काफी अच्छा।

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

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

इस चर्चा में निवेश की गई ऊर्जा की मात्रा और वर्तमान ढांचे को बेहतर बनाने के लिए क्या अच्छा किया जा सकता था, इस पर विचार करने के बजाय मुझे दुख होता है।

@andrewackerman

समस्या यह है कि, जहां JSX को जावास्क्रिप्ट जैसी कमजोर-टाइप की गई गतिशील भाषा पर बनाया गया था, DSX को डार्ट जैसी दृढ़ता से टाइप की गई स्थिर भाषा पर बनाया जा रहा है।

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

@escamoteur बिल्कुल!

@escamoteur मैं इस पर आपके साथ हूं। _द 100._

@ बेसोनोव

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

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

@andrewackerman
आपको क्यों लगता है कि यह मायने रखता है? JSX इंटरफ़ेस का वर्णन करने का एक तरीका है। यह अपने आप में भाषा अज्ञेयवादी है। यहाँ देखो। यह जावास्क्रिप्ट नहीं है। लेकिन ठीक है, यह JSX के साथ क्यों नहीं किया जा सकता है? (इसके अलावा इसका कोई कार्यान्वयन नहीं है (अभी तक))

और.. आप जानते हैं... प्रवाह fb से भी आता है:

फ्लो जावास्क्रिप्ट के लिए एक स्थिर टाइपचेकर है।

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

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

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

हाँ, यहाँ नफरत की मात्रा महाकाव्य है, बस इस पर विचार करें:
3587 खुले टिकट हैं, यदि आप उन्हें "अंगूठे नीचे" से क्रमबद्ध करते हैं तो आपको मिलता है
1 (यह वाला) 57 "अंगूठे नीचे" के साथ
3586 (अन्य टिकट) 1 या उससे कम "अंगूठे नीचे" के साथ

@ बेसोनोव

आपको क्यों लगता है कि यह मायने रखता है? JSX इंटरफ़ेस का वर्णन करने का एक तरीका है। यह अपने आप में भाषा अज्ञेयवादी है। इधर देखो। यह जावास्क्रिप्ट नहीं है। लेकिन ठीक है, यह JSX के साथ क्यों नहीं किया जा सकता है? (इसके अलावा इसका कोई कार्यान्वयन नहीं है (अभी तक))

यह UI _in Javascript_ (इसलिए नाम का "JS" भाग) का वर्णन करने का एक तरीका है। और नहीं, चूंकि यह एक इनलाइन डीएसएल है, यह _not_ भाषा-अज्ञेयवादी है। और अगर ऐसा था भी, तो यह अभी भी इसे "बेहतर विकल्प" नहीं बनाता है, क्योंकि वहां बहुत सारे भाषा-अज्ञेयवादी डीएसएल हैं जो यूआई घोषणाओं के लिए अपर्याप्त रूप से अपर्याप्त होंगे।

और.. आप जानते हैं... प्रवाह fb से भी आता है:

फ्लो टाइपस्क्रिप्ट की तरह ही है: जावास्क्रिप्ट के लिए एक स्थिर प्रकार की जाँच प्रणाली। यह एक रिएक्ट टूल नहीं है, न ही रिएक्ट को इसके साथ प्रयोग करने के लिए डिज़ाइन किया गया था। रिएक्ट सबसे पहले और सबसे महत्वपूर्ण एक जावास्क्रिप्ट लाइब्रेरी है, और JSX को रिएक्ट के साथ उपयोग करने के लिए डिज़ाइन किया गया था। रिएक्ट विकास में जो भी द्वितीयक उपकरण और उपयोगिताएँ पेश की जाती हैं, वे अंततः रिएक्ट + जेएसएक्स इंटरऑपरेबिलिटी के लिए अप्रासंगिक हैं।

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

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

जब तक, निश्चित रूप से, आप हर दिन भी DSX का उपयोग कर रहे हैं और हमें Flutter में DSX का उपयोग करने के व्यावहारिक लाभों के बारे में बता सकते हैं?

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

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

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

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

क्या हम इस विषय पर चर्चा को फिर से शुरू कर सकते हैं?
वास्तव में, मुझे इस मुद्दे को खुला रखने का कोई कारण नहीं दिखता।

डार्ट टीम ने कहा कि उनकी अन्य प्राथमिकताएं हैं। और समर्थक JSX पक्ष स्वेच्छा से अपना DSX कार्यान्वयन करने के लिए तैयार है

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

फिर समाज को अपना काम करने दें।

इसे ऐसे ही खुला छोड़ दें क्योंकि लोग JSX के लिए नए टिकट खोलना जारी रखेंगे (जैसा कि पहले भी दो बार हो चुका है)।

इसे ऐसे ही खुला छोड़ दें क्योंकि लोग JSX के लिए नए टिकट खोलना जारी रखेंगे (क्योंकि ऐसा पहले भी दो बार हो चुका है)।

यहाँ अंतर यह है कि अब हम निम्नलिखित के साथ उत्तर देने में सक्षम होंगे:

"हम इसे अभी के लिए डार्ट/स्पंदन में लागू करने की योजना नहीं बनाते हैं। लेकिन आप सामुदायिक विकल्पों पर एक नज़र डाल सकते हैं [यहां] और [वहां] या पढ़ सकते हैं [यह मुद्दा]"

और समस्या को डुप्लिकेट के रूप में बंद करें।

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

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

अंत में DSX JSX के करीब आने का सिर्फ एक तरीका है, इसलिए हमें इन दोनों चर्चाओं को एक धागे में मिलाना नहीं चाहिए।

इसके लिए कोई बड़ी बात नहीं है, मुझे सच में लगता है कि 1 भाषा केवल एक बड़ा लाभ है, जेएसएक्स सिंटैक्स अधिक चीजों के साथ आएगा जैसे जेएस से एक्सएमएल को अलग करना, आदि ... अच्छा नहीं है।

ऐसी मेरी राय है।

यह अब तक का सबसे लंबा और व्यर्थ जीथब मुद्दा है जिसे मैंने देखा है।

@cbazza अच्छा काम
डीएसएक्स + 1

@ बैरीयान , धन्यवाद

कृपया इस प्रकार की टिप्पणी से बचें, चाहे वह "+1" हो या "धन्यवाद"।
यह सभी ग्राहकों को कुछ भी दिलचस्प नहीं के लिए एक ईमेल भेजता है।

कृपया इस प्रकार की टिप्पणी से बचें, चाहे वह "+1" हो या "धन्यवाद"।
यह सभी ग्राहकों को कुछ भी दिलचस्प नहीं के लिए एक ईमेल भेजता है।

आपके लिए कुछ भी दिलचस्प नहीं है !!!
कृपया लोगों को यह बताने से बचें कि वे क्या कह सकते हैं या क्या कर सकते हैं और केवल उस पर ध्यान केंद्रित करें जो आप कह सकते हैं या कर सकते हैं।

@cbazza

यार, यह बुनियादी शिष्टाचार है। इस थ्रेड पर कोई भी नया संदेश सभी ने इसकी सदस्यता ली है, इसलिए ऐसी टिप्पणी पोस्ट करना अशिष्टता है जो चर्चा में योगदान नहीं करती है क्योंकि यह बिना किसी कारण के लोगों को परेशान करती है। "+1" और "धन्यवाद" जैसी बुनियादी प्रतिक्रियाओं को एक साधारण थम्स अप प्रतिक्रिया के साथ व्यक्त किया जा सकता है, तो बस ऐसा करें।

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

@andrewackerman ,

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

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

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

मुझे कुछ बताएं, क्या आपके पास अपने स्वयं के प्रश्नों के उत्तर हैं जब उन्हें FLUI पर लागू किया जाता है? आइए हम FLUI पर थोड़ी चर्चा करें?

@cbazza

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

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

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

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

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

मैं _you_ से आपकी स्थिति का बचाव करने के लिए कह रहा हूं। आपने बार-बार कहा है कि JSX/DSX सबसे अच्छा/भविष्य है, लेकिन अभी तक यह नहीं बताया है कि कैसे या क्यों। कई लोगों ने DSX के बारे में वैध चिंताएँ व्यक्त की हैं, लेकिन उन्हें संबोधित करने के बजाय, आप "यदि आपको यह पसंद नहीं है, तो इसका उपयोग न करें" प्रतिवाद के पीछे छिपकर इसे दूर कर दें। मेरा "उद्देश्य" आपको उन सवालों के जवाब देने के लिए है जो _any_ तकनीकी परियोजना के बारे में पूछे जाने की आवश्यकता है, सबसे पहले और सबसे महत्वपूर्ण यह है कि लोगों को कभी भी विकल्पों पर इसका उपयोग क्यों करना चाहिए। (और जैसा कि मैंने पहले समझाया है, परिचित होना पर्याप्त कारण नहीं है।)

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

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

मुझे कुछ बताएं, क्या आपके पास अपने स्वयं के प्रश्नों के उत्तर हैं जब उन्हें FLUI पर लागू किया जाता है? आइए हम FLUI पर थोड़ी चर्चा करें?

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

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

andrewackerman अच्छा काम
+ 1

@andrewackerman

बहुत बढ़िया

यार, आपको @jstansbe से एक तारीफ मिलती है जो एक थंब अप की तुलना में बहुत अधिक जानकारी देती है और आप तारीफ पर थंब डाउन करते हैं?

जाहिर है आपने मेरे संकेत को दिल से नहीं लिया, लेकिन मेरे चरित्र के बारे में निष्कर्ष पर नहीं पहुंचे क्योंकि आप मुझे बिल्कुल नहीं जानते।

तथ्य यह है कि आप मेरी प्रतिक्रियाओं का उल्लेख करते हैं कि मैंने बहुत समय और प्रयास किया है कि मैं उन्हें सोच-समझकर और निष्पक्ष बना सकूं क्योंकि मैं उन्हें बना सकता हूं

मैं आपकी सराहना करता हूं और आपके सभी 'लंबे लेखन' को पढ़ता हूं, हर चीज का जवाब देता हूं: बिल्कुल नहीं, लेकिन जब मैं ठीक से जवाब देता हूं तो आप मेरे जवाब को नहीं समझते हैं और निष्कर्ष निकालते हैं कि मैं खारिज कर रहा हूं।

मेरे लिए यह स्पष्ट है कि आप JSX के साथ बहुत अनुभवी नहीं हैं, आप वास्तव में यह नहीं समझते हैं कि यह कैसे काम करता है। इसलिए इसे दोगुना करने के बजाय बस इसे अपना लें और मैं इसे और विस्तार से बताऊंगा। उदाहरण के लिए JSX और DSX केवल निम्नलिखित 2 परिवर्तन करता है (पहले कई बार उल्लेख किया गया है):

(1)
<A property="a" />
    becomes
new A(property: a)

(2)
<A property="a">
  <B />
  <C />
</A>
    becomes
new A(property: a, children: <Widget>[new B(), new C()])

बाकी सब कुछ मेजबान भाषा द्वारा नियंत्रित किया जाता है, उदाहरण के लिए: यह उसी नाम के घटकों के आयात को कैसे संभालता है; उत्तर: मेजबान भाषा। मैं खारिज नहीं कर रहा हूं, यह जिस तरह से डिजाइन किया गया है और इसकी ताकत का स्रोत है। आप देखते हैं कि यदि आप मार्कअप और प्रोग्रामिंग को अलग-अलग फाइलों में अलग करते हैं, तो आप मार्कअप के अंदर प्रोग्रामिंग को 'if' आदि के लिए सरल निर्माण के साथ डुप्लिकेट करना शुरू करते हैं। आप मार्कअप के अंदर एक घोषणात्मक प्रोग्रामिंग भाषा का निर्माण करते हैं जो कभी भी उतना शक्तिशाली नहीं हो सकता मुख्य प्रोग्रामिंग भाषा। तो प्रोग्रामिंग भाषा में मार्कअप लाकर आपके पास दोनों दुनिया के सर्वश्रेष्ठ हैं और यह जेएसएक्स/डीएसएक्स की शक्ति है।

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

जबकि आप किसी भी प्रकार की विपरीत राय से किसी को लताड़ते हैं।

यह सच नहीं है, आपकी राय विपरीत हो सकती है लेकिन आप कुछ सच होने का दावा नहीं कर सकते जब मैं अन्यथा प्रमाणित कर सकता हूं।

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

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

मैं आपसे अपनी स्थिति का बचाव करने के लिए कह रहा हूं।

मैंने इसे पहले ही कई बार किया है और निष्कर्ष यह है कि सादा डार्ट या डीएसएक्स उपयोगकर्ता वरीयता के लिए नीचे आता है; और महत्वपूर्ण बात यह है कि लोगों को एक तरह से मजबूर करने के बजाय विकल्प प्रदान करना है।

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

मैं DSX का उपयोग करूंगा क्योंकि मैं इसे पसंद करता हूं, जैसे रिक्त स्थान या टैब, चर नाम से पहले या बाद में परिभाषा टाइप करें। इसके लिए लड़ने का कोई मतलब नहीं है, बस यह स्वीकार करें कि लोगों की अलग-अलग प्राथमिकताएँ हैं; वहाँ 1 से अधिक प्रोग्रामिंग संपादक हैं, है ना?

परिचित होना पर्याप्त कारण नहीं है

बस आपकी राय, हम लगभग हर भाषा में "if" स्टेटमेंट का उपयोग क्यों करते हैं, 'for' स्टेटमेंट, 'क्लास', और अब 'asyn/await'।

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

बहुत अच्छा, अब तुम्हें मेरा सम्मान मिला।

आप दो अलग-अलग मौकों (तीन के करीब) के लिए सीधे तौर पर जिम्मेदार हैं, जहां चीजों के बहुत गर्म होने के कारण इस धागे को अस्थायी रूप से बंद करना पड़ा।

बात यह है कि भले ही यह फिर से बंद हो जाए, लेकिन यह लोगों को JSX जैसी क्षमताओं के लिए पूछने से नहीं रोकेगा।

अपने अहंकार को रोकें, आलोचनाओं को व्यक्तिगत हमलों के रूप में व्याख्या करना बंद करें और महत्वपूर्ण सवालों के जवाब दें।

मेरा कोई अहंकार नहीं है, लेकिन मेरा गुस्सा गुस्सा है, इसलिए कोई गलती नहीं है जब कोई मुझे चिढ़ाता है (वह तुरंत बाहर आ जाता है)। आपको ठेस पहुंचाने के लिए नहीं लेकिन आपके सवाल महत्वपूर्ण नहीं थे।

या तो वह, या डीएसएक्स के साथ शांति बनाएं जो कभी जमीन पर न उतरे।

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

यार, आपको @jstansbe से एक तारीफ मिलती है जो एक थंब अप की तुलना में बहुत अधिक जानकारी देती है और आप तारीफ पर थंब डाउन करते हैं?

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

यह मेरे लिए स्पष्ट है कि आप JSX के साथ बहुत अनुभवी नहीं हैं ...

क्या इस सूत्र पर मेरी पहली ही टिप्पणी में मेरे अस्वीकरण ने शायद आपको इत्तला दे दी?

... आप वास्तव में यह नहीं समझते कि यह कैसे काम करता है।

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

बाकी सब कुछ मेजबान भाषा द्वारा नियंत्रित किया जाता है, उदाहरण के लिए: यह उसी नाम के घटकों के आयात को कैसे संभालता है; उत्तर: मेजबान भाषा।

और यह उस मामले में समझ में आता है जहां मार्कअप भाषा और मेजबान भाषा अलग हैं। JSX के साथ, मार्कअप भाषा को होस्ट भाषा के _extension_ के रूप में डिज़ाइन किया गया है। जैसे, JSX को JS के विस्तार के रूप में डिज़ाइन किया गया था, और इसीलिए यह उतना ही काम करता है जितना यह करता है। DSX डार्ट के लिए JSX का कार्यान्वयन है।

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

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

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

दूसरे, यदि आप अपने UI कोड में if s और for s से कहीं अधिक जटिल कुछ भी कर रहे हैं (जो ऐसे निर्माण हैं जिन्हें आसानी से कई मार्कअप समाधानों में संभाला जा सकता है), तो मैं तर्क दूंगा कि यह एक संकेत है कि वैसे भी आपके डिजाइन में कुछ गड़बड़ है। एमवीसी/एमवीवीएम डिजाइन सिद्धांतों के अनुसार, यदि आप अपने यूआई निर्माण में जटिल तर्क शामिल कर रहे हैं, तो यह बदबूदार कोड का एक संभावित संकेत है और आपको वैसे भी एक नया स्वरूप पर गंभीरता से विचार करना चाहिए।

(यह कहना नहीं है कि आप जेएसएक्स का उपयोग करके एमवीवीएम फैशन में घोषणात्मक यूआई नहीं लिख सकते हैं, लेकिन यह केवल कुछ ऐसा है जो थोड़ा उद्देश्य लाभ के लिए परेशानी को आमंत्रित करता है। ऐसा कुछ क्यों उपयोग करें जिसमें आप _can_ कोड लिखते हैं जो मानकों के अनुरूप है जब आप उपयोग कर सकते हैं ऐसा कुछ जिससे कोड लिखना मुश्किल हो जाता है कि _is't_?)

यह सच नहीं है, आपकी राय विपरीत हो सकती है लेकिन आप कुछ सच होने का दावा नहीं कर सकते जब मैं अन्यथा प्रमाणित कर सकता हूं।

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

लेकिन यह बात है, मैं चाहता था कि फ़्लटर टीम DSX को लागू करे, लेकिन फिर मैंने ऐसा किया, जिसे उन्हें लागू करने की आवश्यकता है वह सामान्य सामान है जो DSX पर निर्भर नहीं है और DSX एकमात्र लाभार्थी नहीं है।

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

ब्राउज़र जेएस इंजन स्रोत मानचित्रों का समर्थन करता है जो ब्राउज़र में नई भाषाओं के एक पारिस्थितिकी तंत्र को सक्षम करता है जो जेएस में स्थानांतरित हो जाता है; इसने डार्ट के निर्माण को सक्षम बनाया !!!

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

मैं DSX का उपयोग करूंगा क्योंकि मैं इसे पसंद करता हूं, जैसे रिक्त स्थान या टैब, चर नाम से पहले या बाद में परिभाषा टाइप करें। इसके लिए लड़ने का कोई मतलब नहीं है, बस यह स्वीकार करें कि लोगों की अलग-अलग प्राथमिकताएँ हैं; वहाँ 1 से अधिक प्रोग्रामिंग संपादक हैं, है ना?

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

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

बस आपकी राय, हम लगभग हर भाषा में "if" स्टेटमेंट का उपयोग क्यों करते हैं, 'for' स्टेटमेंट, 'क्लास', और अब 'async/await'।

सबसे पहले, वे कीवर्ड ( async/await को छोड़कर) कई दशकों के दौरान C और BASIC जैसी भाषाओं की अपार लोकप्रियता के कारण सामान्य प्रोग्रामिंग शब्दावली बन गए। जैसा कि मैंने पहले उल्लेख किया है, JSX अपनी लंबी उम्र में सिद्ध होने से बहुत दूर है - यह लगभग 5 वर्षों से है और विकल्प उपलब्ध होने के बावजूद रिएक्ट के बाहर कोई महत्वपूर्ण उपयोग देखना बाकी है।

दूसरा, परिचित और परंपरा के बीच एक बड़ा अंतर है। if , while , for , struct , class , enum , try/catch/finally , async/await ... किसी अवधारणा को मौखिक रूप से प्रस्तुत करने के ये सभी बेहतरीन तरीके हैं। उन खोजशब्दों का उपयोग करने से बचाव करने के कारण हैं जो उनसे परे हैं - वे वैचारिक समझ में आते हैं। (बेशक, इसका मतलब यह नहीं है कि वे स्थिरांक हैं। कुछ भाषाएं if ... then करती हैं। कुछ if ... elif करते हैं जबकि अन्य if ... else if करते हैं और फिर भी अन्य if...endif करते हैं। foreach करते हैं, अन्य from करते हैं। और इसी तरह, और आगे।)

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

बात यह है कि भले ही यह फिर से बंद हो जाए, लेकिन यह लोगों को JSX जैसी क्षमताओं के लिए पूछने से नहीं रोकेगा।

वे वैसे भी इसके लिए पूछते हैं, और इस मुद्दे को यहाँ फिर से निर्देशित किया जाता है। मैं नहीं देखता कि धागा कैसे बंद हो जाएगा।

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

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

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

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

लेकिन फिर, शायद आप एक अपवाद हैं।

ठीक है, यह बातचीत उन चर्चाओं से बहुत आगे निकल गई है जिन्हें हम फ़्लटर समुदाय में स्वीकार्य मानते हैं, और इसलिए मैं इस थ्रेड को लॉक करने और बग को बंद करने जा रहा हूँ। हम यहां कैसे व्यवहार करते हैं, इस बारे में अधिक जानकारी के लिए कृपया https://flutter.io/design-principles/#conflict -resolution पढ़ने पर विचार करें।

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

मैं यह पूछना चाहता हूं कि लोग इस विषय पर तब तक नई बग नहीं खोलते जब तक कि कुछ बहुत ही रचनात्मक और नया न हो जो सामने आने लायक हो।