cc lukechurch

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(),
  ));
}

Huumm ، تحسن طفيف لكن ليس جيدًا ...
فيما يلي الأشياء التي يتم إنجازها باستخدام XML:
(1) لا مزيد من مواد "الأطفال" و "الأطفال"
(2) سهولة التعامل مع أدوات الطرف الثالث (التحليل والتحليل والتجديد)
(3) لاحظ أن التبديل بين الترميز والبرمجة يمكن اكتشافه بسهولة. أعني داخل XML لديك "{}" لتحديد الشفرة وفي الكود لديك " افصل أيضًا جميع عناصر "النمط" عن الهيكل الرئيسي.
أعلم أن هذا يؤيد تمامًا طريقة React تمامًا ولكنك في منتصف الطريق على أي حال ؛)

cc @ kasperl

(1) لا مزيد من مواد "الأطفال" و "الأطفال"

أنا لا أفهم حقًا لماذا هذا أمر مرغوب فيه. "الطفل" و "الأطفال" ليسا مميزين. ضع في اعتبارك ListTile على سبيل المثال. كيف ستفعل ذلك؟ لماذا يوجد "رمز" في IconButton ، أو "home" في MaterialApp ، شيء تريد تسمية له ، ولكن ليس "child" في Expanded؟ الثلاثة كلها مجرد حجج عشوائية تحدث لأخذ كائنات القطعة. لا يوجد شيء سحري في "الطفل" مقابل "المنزل".

(2) سهولة التعامل مع أدوات الطرف الثالث (التحليل والتحليل والتجديد)

يمكنك تحليل كود Dart وإعادة إنشائه. لكنني أوافق على أنه يجب علينا أن نجعل ذلك أسهل. نأمل في السنوات القادمة أن يوفر فريق Dart واجهات برمجة تطبيقات أفضل لهذا الغرض.

(3) لاحظ أن التبديل بين الترميز والبرمجة يمكن اكتشافه بسهولة.

لماذا هذا مرغوب فيه؟ أعني ، لماذا يعتبر أي من هذا "برمجة"؟ كل هذا مجرد تعبيرات.

أعني داخل XML لديك "{}" لتحديد الشفرة وفي الكود لديك "

أنا لا أفهم حقًا التمييز.

افصل أيضًا جميع عناصر "النمط" عن الهيكل الرئيسي.

يمكنك القيام بذلك اليوم في Flutter إذا كنت تريد ذلك حقًا ، فقط ضع النمط في متغير كما فعلت في حالة XML.

أنا لا أفهم حقًا لماذا هذا أمر مرغوب فيه. "الطفل" و "الأطفال" ليسا مميزين. ضع في اعتبارك ListTile على سبيل المثال. كيف ستفعل ذلك؟ لماذا يوجد "رمز" في IconButton ، أو "home" في MaterialApp ، شيء تريد تسمية له ، ولكن ليس "child" في Expanded؟ الثلاثة كلها مجرد حجج عشوائية تحدث لأخذ كائنات القطعة. لا يوجد شيء سحري في "الطفل" مقابل "المنزل".

أقل من ذلك ، لا تحتاج لقولها لأنها موروثة في الهيكل.

لماذا هذا مرغوب فيه؟ أعني ، لماذا يعتبر أي من هذا "برمجة"؟ كل هذا مجرد تعبيرات.

إنه مرتبط بـ (2) لأنه يجعل حياة صانعي الأدوات ، وخاصة منشئو واجهة المستخدم الرسومية ، أسهل بكثير لأنهم لا يحتاجون إلى تحليل Dart بالكامل ؛ ولكنه أيضًا يجعل قراءة الكود أسهل.

أنا لا أفهم حقًا التمييز.

تنسيق XML بسيط جدًا ، لذا عندما ترى "{}" تعرف أنها تحسب تعبيرًا في dart. نفس الشيء بالنسبة للعكس ، عند قراءة رمز dart وسترى) تعلم أنه يتم إنشاء تسلسل هرمي للكائن من ترميز XML.

أيضًا في معالج 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؟ لا يبدو أن صيغة XML-ish تتعامل مع هذا بشكل جيد.

كما أنني لست متأكدًا من أنها أقل تشويشًا.

يقارن:

   <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),
        ],
      ),
    )

ليس من الواضح على الإطلاق أن صيغة XML-ish أنظف أو أقل متداخلة. هناك الكثير من علامات الترقيم وبعض الازدواجية في المحتوى (على سبيل المثال في علامات الإغلاق). وكان عليك إضافة بعض الأسماء ، لذا بالتأكيد ، ستفقد "الطفل" ، لكنك تحصل على "الاسم" على الأيقونة.

أيضًا باستخدام XML ، كيف يمكنك توضيح أن Row يمكن أن يأخذ صفرًا أو طفلًا واحدًا أو أكثر من طفل واحد ، بينما يجب أن يكون للمركز طفل واحد بالضبط؟ ماذا سيحدث إذا فعل أحدهم هذا ؟:

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

إنه مرتبط بـ (2) لأنه يجعل حياة صانعي الأدوات ، وخاصة منشئو واجهة المستخدم الرسومية ، أسهل بكثير لأنهم لا يحتاجون إلى تحليل Dart بالكامل ؛

لن يحتاجوا إلى تحليل Dart بالكامل إذا كان لدينا Dart parsing API أيضًا ، على الرغم من ذلك ، أليس كذلك؟ أعني ، كنت ستحلل ما تريد تحليله وتترك الباقي. كما أنني لست متأكدًا من أنه من الأسهل تحليله بالفعل ، لأنه ليس XML في الواقع ؛ انظر أدناه.

ولكنه أيضًا يجعل قراءة الكود أسهل.

لست مقتنعًا على الإطلاق بأن إصدار XMLy هنا أسهل في القراءة. بمجرد قراءة بعض وظائف البناء ، ستعتاد بسرعة على بناء جملة المُنشئ المتداخل.

تنسيق XML بسيط جدًا ، لذا عندما ترى "{}" تعرف أنها تحسب تعبيرًا في dart.

إنها ليست XML في الواقع ، على الرغم من ذلك ، أليس كذلك؟ إنه نوع من أنواع XML. هل توجد قواعد إعراب محددة جيدًا لها؟ على سبيل المثال ، هل هذا صحيح؟

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

كيف تعرف أن "}" الأول ليس نهاية تعبير السمة ، بدون تحليل Dart؟

نفس الشيء بالنسبة للعكس ، عند قراءة رمز dart وسترى) تعلم أنه يتم إنشاء تسلسل هرمي للكائن من ترميز XML.

أنت تعرف هذا اليوم عندما ترى الكلمة الرئيسية new أيضًا ، أليس كذلك؟ أو بالفعل في اقتراح الترميز الجديد الأقل أعلاه عندما ترى أي كلمة بأحرف كبيرة. هل هذه حقًا ميزة لـ XML ، أم أنك أكثر دراية بـ XML من Dart؟

أيضًا في معالج XML النهائي ، كنت أتجنب تمرير الكائنات إلى سمات الوالدين وبدلاً من ذلك أنشئ علامات فرعية على النحو التالي:

أنا حقًا لا أفهم ما تقترحه هنا. إنها ليست XML منسقة جيدًا على الإطلاق بقدر ما أستطيع أن أقول. هل يمكنك أن تشرح بالتفصيل ما هو بالضبط بناء الجملة الذي تقترحه وكيف يعمل؟ على سبيل المثال ، يبدو أن مُنشئ "النص" قد اختفى ؛ كيف يعرف المعالج ذلك

انظر ، أنت تمزج كل ما أقوله وهذه المحادثة لن تذهب إلى أي مكان. من الناحية القانونية أنت "تغري الشاهد".

إذا كنت مهتمًا حقًا بمعرفة سبب كون JSX ساخنًا ، فما عليك سوى البحث عن "برنامج تعليمي للتفاعل" على Google ولاحظ أنه على مدار العامين الماضيين ، تستخدم جميع المقالات الموجودة على React JSX. لم يتم ذكر الطريقة الأصلية لإنشاء تسلسلات هرمية للمكونات في React (والتي تعادل الطريقة الحالية في Flutter) مرة أخرى لأن JSX أصبحت الطريقة المفضلة (أفضل ممارسة).

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

شيء آخر مثير للاهتمام هو أن Typescript تبنت JSX أيضًا:
https://www.typescriptlang.org/docs/handbook/jsx.html

لقد فشلت في استيعاب أن تحليل XML (مع بعض التعليمات البرمجية الإضافية لتخطي "{}" بشكل صحيح) هي أوامر من حيث الحجم أبسط من التحليل الكامل للغة برمجة مثل Dart. هذه هي الحقيقة. أنت تفترض أن صانعي الأدوات سوف يستخدمون Dart في تطويرهم ، وليس الحال ، فمن المرجح أن Intellij يستخدم Kotlin و Java على IDEs الخاص بهم الذي يدعم Dart (هم حالة خاصة لأنهم متخصصون في تحليل اللغة ؛ كل شخص آخر سوف يكافح من أجل بشكل كامل تحليل Dart من لغة أخرى).

ما يعجبني في وضع XML داخل لغة أخرى هو أنه يوفر فصلًا معرفيًا بين الاثنين لأن XML يختلف كثيرًا عن لغات البرمجة. بمجرد التمرير عبر الملف المصدر ، يمكنك بسهولة معرفة ما هو الكود وما هو الترميز التعريفي. لا يمكن تحقيق ذلك باستخدام رمز dart الذي يتظاهر بأنه ترميز.

توقف عن انتقاء الأشياء التي لم يتم تحديدها بشكل كامل. تم الرد على كل شكوكك لذلك فقط تعرف على المزيد حول كيفية التعامل مع ذلك في JSX. ليس لدي الوقت لهذا هنا.

اعتذاري إذا بدوت دفاعيًا أو عدوانيًا. هذا موضوع تم طرحه عدة مرات ولكن لم يكن لدي أبدًا أي شخص يرغب في مناقشة القضية بالفعل من قبل ، لذلك كنت أجد هذه المحادثة مفيدة جدًا في تعليمي السبب وراء الطلب. من فضلك لا تأخذ نبرتي الجدلية على أنها رافضة ، أنا مهتم جدًا بمدخلاتك هنا.

من فضلك لا تشعر أنك مضطر للرد. أنا أعلق هنا حتى يكون هناك شفافية فيما يتعلق بالمشكلات التي يتعين علينا حلها قبل أن نتمكن من اتخاذ قرار أو تصميم بطريقة أو بأخرى. هذا في الأساس مجرد حوار سقراطي. مشاركتك مرحب بها ولكن بالتأكيد لا يجب أن تشعر أن الدفاع عن اقتراحك مسؤوليتك.

ليس لدي شك في أن JSX "مثيرة". في React ، تكون البنية التي لا تحتوي على JSX أسوأ بكثير من الصيغة البديلة المقترحة في هذه المسألة (تلك التي تبدو مثل الكود الحالي ولكن بدون الكلمات الرئيسية "الجديدة" و "الثابتة"). ما أحاول فهمه هو ما إذا كانت نفس الأسباب التي تجعل JSX "ساخنة" في React تنطبق على Flutter.

فيما يتعلق باستخدام TypeScript لـ JSX ، شاركت في عام 2012 في جهود لتحديد E4H ، وحتى قبل ذلك كان هناك E4X . كلتا المحاولتين ماتت. لذلك من المهم بالنسبة لي أن نفهم بالضبط ما يحبه الناس في JSX مقابل الصيغ الأخرى.

لا يعد تحليل XML أمرًا سهلاً ، كما أن تحليل نوع XML ولكن باستخدام الأقواس المتعرجة بطريقة ما ليس بالأمر السهل أيضًا. إن تحليل نوع XML ولكن باستخدام الأقواس المتعرجة بطريقة أو بأخرى ما يكون مضمّنًا في لغة أخرى هو أمر أقل سهولة. ومع ذلك ، فإن مدى سهولة تنفيذ ذلك ربما لا يمثل مشكلة كبيرة لأنه سيتم تنفيذه مرة أو مرتين ، ثم سيتم إعادة استخدام المكتبة التي تقوم بذلك. (لقد شاركت بشكل كبير في كتابة المواصفات لتحليل HTML وشاركت في عمل مماثل لـ XML ، وقمت بتطبيق محلل لـ Dart ، لذلك لدي فكرة جيدة عن مدى صعوبة تحليل لغات الترميز مقابل لغات البرمجة في الواقع يكون.)

ما يعجبني في وضع XML داخل لغة أخرى هو أنه يوفر فصلًا معرفيًا بين الاثنين لأن XML يختلف كثيرًا عن لغات البرمجة. بمجرد التمرير عبر الملف المصدر ، يمكنك بسهولة معرفة ما هو الكود وما هو الترميز التعريفي. لا يمكن تحقيق ذلك باستخدام رمز dart الذي يتظاهر بأنه ترميز.

لكن لماذا من المفيد أن تكون قادرًا على فعل ذلك؟

من الواضح جدًا عند التمرير عبر تطبيقات Flutter حيث توجد وظائف البناء (إنها التعبيرات المتداخلة العملاقة). ما هو موضوع "الترميز التعريفي" المهم فصله عن "الكود"؟

توقف عن انتقاء الأشياء التي لم يتم تحديدها بشكل كامل. تم الرد على كل شكوكك لذلك فقط تعرف على المزيد حول كيفية التعامل مع ذلك في JSX. ليس لدي الوقت لهذا هنا.

بقدر ما أستطيع أن أقول ، JSX لا تتعامل مع الأشياء التي كنت أسأل عنها. على سبيل المثال ، لا تمتلك React مفهوم الفتحات الفرعية. أقرب شيء يمكن أن أجده هو شيء يفعلونه من خلال التبديل مرة أخرى إلى JS ثم العودة إلى JSX بداخلها ، لذلك يجب أن تكون قادرًا على تحليل كل من لغة البرمجة ولغة الترميز.

ما أحاول فهمه هو ما إذا كانت نفس الأسباب التي تجعل JSX "ساخنة" في React تنطبق على Flutter.

نعم ، نفس الشيء ينطبق هنا. الطريقة الحالية تبدو جيدة بالنسبة لك لأن هذا هو الخيار الوحيد الذي لديك. امنح الناس خيارًا ثانيًا وسيحدث نفس الشيء.

سواء مات E4X أم لا ، لا علاقة له لأنه لا يوجد شيء يعيش إلى الأبد. لقد استخدمت ActionScript مع E4X كثيرًا واعتقدت أن Adobe قامت بعمل ممتاز هناك. بطريقة ما ، يعد Flutter مجرد إصدار أحدث من Adobe Flash مع تطبيقات Flex.

(لقد شاركت بشكل كبير في كتابة المواصفات لتحليل HTML وشاركت في عمل مماثل لـ XML ، وقمت بتطبيق محلل لـ Dart ، لذلك لدي فكرة جيدة عن مدى صعوبة تحليل لغات الترميز مقابل لغات البرمجة في الواقع يكون.)

من الرائع أن تعلم أن تحليل لغة الترميز أمر تافه مقارنة بتحليل لغة برمجة ضرورية.

لكن لماذا من المفيد أن تكون قادرًا على فعل ذلك؟

سهولة قراءة الكود وبساطته والتي بدورها تقود مجموعة كاملة من المزايا الأخرى.

من الواضح جدًا عند التمرير عبر تطبيقات Flutter حيث توجد وظائف البناء (إنها التعبيرات المتداخلة العملاقة). ما هو موضوع "الترميز التعريفي" المهم فصله عن "الكود"؟

على تعابيرك المتداخلة العملاقة ، هل يمكنك بسهولة رؤية الهيكل؟ هل يمكن التلاعب بهذا الهيكل بسهولة بواسطة أدوات أخرى مثل أدوات إنشاء واجهة المستخدم الرسومية بالتبادل؟ أعني مثل استخدام Adobe Flex Builder في القيام به ، وسحب وإسقاط عناصر واجهة المستخدم ، وقم بتوصيلها على واجهة المستخدم ، ثم قم بالتبديل إلى عرض الكود وقم فقط بتحرير أي شيء تريده ثم عد إلى وضع واجهة المستخدم الرسومية واستمر في معالجة الأدوات. لا يمكنك فعل ذلك بسهولة عندما يدخل المبرمج داخل "التعبيرات المتداخلة العملاقة" ويكتب أي شفرة سهام صالحة لا تتبع الهيكل الذي يتوقعه محرر واجهة المستخدم الرسومية. مع بنية XML ثابتة ليست مشكلة.

بقدر ما أستطيع أن أقول ، JSX لا تتعامل مع الأشياء التي كنت أسأل عنها. على سبيل المثال ، لا تمتلك React مفهوم الفتحات الفرعية

إنه يتعامل معها بشكل جيد ، فأنت لا تعرف كيفية القيام بذلك. من الآن فصاعدًا ، ضع المثال المعني هنا وسأقدم لك ما أعتقد أنه يجب أن يكون عليه إصدار 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>,

يبدو أطول من إصدار dart لكن كان بإمكاني وضع كل شيء في نفس عدد الأسطر. الشيء هو IDE / محرر يمكنه توفير "+" & "-" لتوسيع وطي عقد XML على أي حال.

اجعل Flutter يبدو مألوفًا لمطوري React ولديك فرصة لجذب مجموعة من المستخدمين الجدد إلى Flutter.

سواء مات E4X أم لا ، لا علاقة له لأنه لا يوجد شيء يعيش إلى الأبد.

سواء ماتت ليست القضية ، هذا هو سبب موتها. هل مات لأنه لم يقدم الحل الذي أراده الناس؟ هل مات بسبب قضايا التنفيذ؟ هل ماتت بسبب قضايا براءات الاختراع؟ هل كان الوقت مبكرا جدا؟ بعد فوات الأوان؟ أعتقد أنه من المهم تعلم الدروس من التجارب السابقة. لماذا فشلت E4X و E4H حيث نجحت JSX؟

ما أجده مثيرًا للاهتمام هو أن الأشخاص الجدد على Flutter يطلبون غالبًا شيئين: لغة الترميز وصور GIF المتحركة. ثم بعد ثلاثة أشهر ، ما زالوا يطلبون صور GIF متحركة ، لكن ليس لغة ترميزية. قد يكون السبب في ذلك هو أن لغة الترميز ليست ضرورية حقًا بمجرد أن تعتاد على كتابة طرق الإنشاء في Dart. من المحتمل أنهم ما زالوا يريدون لغة ترميزية لكنهم عملوا حول الإغفال ولذلك لا تفكر في السؤال بعد الآن. يجدر بنا معرفة أيهما لأننا بخلاف ذلك نجازف بإنفاق الجهد على شيء يعد اختيارًا خاطئًا (في أي من الاتجاهين).

على تعابيرك المتداخلة العملاقة ، هل يمكنك بسهولة رؤية الهيكل؟

نعم ، على الأقل بنفس سهولة استخدام XML. أنا شخصياً أجد XML ليكون مطولاً للغاية ويشوش البنية. لكني أعتقد أن هذا يتعلق أكثر بما اعتدت عليه.

(نقوم أيضًا بتجربة IDEs التي تضع تعليقات "علامة الإغلاق" الافتراضية لك حتى تتمكن من رؤية الهيكل دون الحاجة إلى كتابته بالفعل.)

من الرائع أن تعلم أن تحليل لغة الترميز أمر تافه مقارنة بتحليل لغة برمجة ضرورية.

تجربتي هي أن التوضيحي مقابل الإلزامي ليس التمييز المهم عندما يتعلق الأمر بتحديد مدى سهولة تحليل اللغة. (على سبيل المثال ، HTML هي لغة "تعريفية" ولكنها قد تكون من بين أكثر اللغات تعقيدًا التي تعاملت معها على الإطلاق.)

سهولة قراءة الكود وبساطته والتي بدورها تقود مجموعة كاملة من المزايا الأخرى.

إذا كانت هذه هي الفائدة الرئيسية ، فهذا شيء يمكننا اختباره. يمكننا أن نأخذ مزيجًا من المهندسين المعتادين على كتابة HTML ، و React ، و iOS code ، و Android code ، و Flutter ، وتطبيقات سطر الأوامر ، وما إلى ذلك ، ونقدم لكل منهم تراكيب مختلفة ، ونطلب منهم وصف ما يعتقدون أنه ستبدو واجهة المستخدم الناتجة. يمكننا بعد ذلك قياس البنية التي تحصل على أفضل النتائج. InMatrix هل هذا شيء يمكننا النظر إليه بعد انتهاء عمل الرسوم المتحركة ، ربما؟

هل يمكن التلاعب بهذا الهيكل بسهولة بواسطة أدوات أخرى مثل أدوات إنشاء واجهة المستخدم الرسومية بالتبادل؟

نعم ، من حيث المبدأ على الأقل. يجب أن يكون تحويل تعبيرات Dart ميكانيكيًا إلى XML أو JSON أو أي لغة منظمة أخرى يمكن استخدامها بشكل مباشر نسبيًا. إنها مجرد مسألة تحويل بناء الجملة ، المعلومات الفعلية هي نفسها. أنا شخصياً لن أقوم بتحويله إلى صيغة مختلفة إذا كنت أقوم بإنشاء محرر واجهة المستخدم الرسومية ، فسأحلله في بنية بيانات في الذاكرة مباشرة من Dart.

لا يمكنك فعل ذلك بسهولة عندما يدخل المبرمج داخل "التعبيرات المتداخلة العملاقة" ويكتب أي شفرة سهام صالحة لا تتبع الهيكل الذي يتوقعه محرر واجهة المستخدم الرسومية. مع بنية XML ثابتة ليست مشكلة.

الشيء هو أنه يمكنك وضع "أي رمز سهام صالح" في بنية XML تمامًا كما هو الحال في تعبير Dart. إنها قابلة للتبديل ميكانيكيًا حرفياً. لذلك لا أرى حقًا كيف يساعد استخدام XML في هذا الأمر تحديدًا. على سبيل المثال ، كيف يمكنك تحويل هذا إلى XML ؟:

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

إنه يتعامل معها بشكل جيد ، فأنت لا تعرف كيفية القيام بذلك.

قصدته على وجه التحديد JSX. أوافق على أن الصيغة التي اقترحتها ستكون طريقة صالحة تمامًا للتعامل مع المشكلة.

لقد عملت على Adobe's Flex SDK ، والذي يجمع بين ترميز XML و ActionScript ، على مدار العامين الماضيين حيث كان المنتج موجودًا في Adobe. أتفهم جاذبية الترميز لتحديد واجهات المستخدم ولكن يمكنني أيضًا تذكر بعض العيوب:

• يمكن تعريف مرئيات التطبيق المرن من حيث الترميز والكود. كما أتذكر ، تميل التعليمات البرمجية إلى الهيمنة في تطبيقات العالم الحقيقي الكبيرة. القراءة ليست بالضرورة فائدة للتطبيقات المحددة على أنها هجينة معقدة من الترميز والتعليمات البرمجية.
• كان على IDE "Flex Builder" دعم التطبيقات التي تم تحديدها بواسطة الترميز والرمز. هذا جعل من الصعب بناء IDE وصيانته. يميل المطورون إلى مشاهدته كأداة أكشن سكريبت.
• كان تطوير "مترجم" XML وصيانته عبئًا كبيرًا أبقى فريقًا من المهندسين مشغولين بدوام كامل. أدى الحفاظ على المترجم ومجموعة الأدوات في نفس الوقت إلى إبطاء تطور SDK بشكل عام.

لقد مرت سنوات ولم أعد أستطيع تذكر كل التفاصيل. ومع ذلك ، فإن انطباعي العام هو أن تحديد واجهات المستخدم بمزيج من الترميز والرمز هو حقيبة مختلطة في أحسن الأحوال.

سواء ماتت ليست القضية ، هذا هو سبب موتها. هل مات لأنه لم يقدم الحل الذي أراده الناس؟ هل مات بسبب قضايا التنفيذ؟ هل ماتت بسبب قضايا براءات الاختراع؟ هل كان الوقت مبكرا جدا؟ بعد فوات الأوان؟ أعتقد أنه من المهم تعلم الدروس من التجارب السابقة. لماذا فشلت E4X و E4H حيث نجحت JSX؟

لقد مات لأن E4X تم تنفيذه فقط في ActionScript والذي تم استخدامه فقط داخل Adobe Flash / Flex وقامت Adobe بقتل المشروع. وبدلاً من ذلك ، غيرت Adobe اتجاهها نحو المعايير المفتوحة حيث لا يوجد مزود مصدر واحد مع إمكانية القفل وانهيار النظام البيئي.

ما أجده مثيرًا للاهتمام هو أن الأشخاص الجدد على Flutter يطلبون غالبًا شيئين: لغة الترميز وصور GIF المتحركة. ثم بعد ثلاثة أشهر ، ما زالوا يطلبون صور GIF متحركة ، لكن ليس لغة ترميزية. قد يكون السبب في ذلك هو أن لغة الترميز ليست ضرورية حقًا بمجرد أن تعتاد على كتابة طرق الإنشاء في Dart. من المحتمل أنهم ما زالوا يريدون لغة ترميزية لكنهم عملوا حول الإغفال ولذلك لا تفكر في السؤال بعد الآن. يجدر بنا معرفة أيهما لأننا بخلاف ذلك نجازف بإنفاق الجهد على شيء يعد اختيارًا خاطئًا (في أي من الاتجاهين).

حسنًا ، إذا طلبت منك شيئين ولم تفعل أيًا منهما خلال 3 أشهر وكان هناك بديل لأول شيء ، فسأطلب منك أيضًا ما هو مستحيل تمامًا نظرًا لاستجابتك وأداء التسليم السابق.

(نقوم أيضًا بتجربة IDEs التي تضع تعليقات افتراضية "لعلامة الإغلاق" حتى تتمكن من رؤية الهيكل دون الحاجة إلى كتابته بالفعل.)

إنه أمر مضحك ولكنه يشبه وضع علامة إغلاق XML التي ذكرتها من قبل بشكل مطول للغاية.

إذا كانت هذه هي الفائدة الرئيسية ، فهذا شيء يمكننا اختباره. يمكننا أن نأخذ مزيجًا من المهندسين المعتادين على كتابة HTML ، و React ، و iOS code ، و Android code ، و Flutter ، وتطبيقات سطر الأوامر ، وما إلى ذلك ، ونقدم لكل منهم تراكيب مختلفة ، ونطلب منهم وصف ما يعتقدون أنه ستبدو واجهة المستخدم الناتجة. يمكننا بعد ذلك قياس البنية التي تحصل على أفضل النتائج. InMatrix هل هذا شيء يمكننا النظر إليه بعد انتهاء عمل الرسوم المتحركة ، ربما؟

بالتأكيد يمكنك القيام بذلك ، فأنا متأكد من أنك ستكتشف أنه "بمجرد قيامك بـ React (باستخدام JSX) ، لن تعود ببساطة". استطلع رأي مطوري React ذوي الخبرة واسألهم عما إذا كانوا يعتقدون أن JSX سيئ وأنه لا يجب أن يتم ذلك مطلقًا. أظهر طريقك واسألهم عما إذا كانوا يريدون استبدال JSX بما لديك. قبل القيام بذلك ، أغلق الأبواب وأغلق المكان لأن هؤلاء المطورين سيأخذون أشياءهم ويسارعون للوصول إلى أقرب مخرج.

الشيء هو أنه يمكنك وضع "أي رمز سهام صالح" في بنية XML تمامًا كما هو الحال في تعبير Dart.

بالتأكيد ، ولكن بالنسبة لمنشئي واجهة المستخدم الرسومية ، فإن هذا مجرد كتلة من البايت لا تحتاج إلى لمسها ويمكن تخطيها بسهولة. جعل قابلية التبادل في التصميم / الكود ممكنًا عمليًا بدلاً من المبدأ.

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>

لقد استخدمت Adobe Flex Builder بشكل موسع ...

يميل المطورون إلى مشاهدته كأداة أكشن سكريبت.

نعم ، لكنني غالبًا ما قمت بالتبديل من عرض التصميم إلى عرض الكود والعكس صحيح.
عند بدء تشغيل الشاشة ، سأذهب إلى عرض التصميم واستخدم السحب / الإفلات لتخطيط الحاجيات وإنشاء أول شاشة ثابتة. ثم أقوم بإضافة بعض التعليمات البرمجية وبعض البيانات الثابتة لملء الشاشة حتى أتمكن من إظهار شيء ما يعمل وكأنه أشياء جاهزة للإنتاج. كانت الإنتاجية مذهلة. مع تقدم التطوير ، قمت بتوصيل الواجهة الأمامية بالنهاية الخلفية وزاد مقدار كود ActionScript ونعم لقد سيطر على الكود بشكل عام ولكن حتى مع اقتراب وقت الإصدار ، غالبًا ما كنت أستخدم طريقة عرض التصميم لتعديل واجهة المستخدم دون الحاجة إلى البحث في الشفرة.

ومع ذلك ، فإن انطباعي العام هو أن تحديد واجهات المستخدم بمزيج من الترميز والرمز هو حقيبة مختلطة في أحسن الأحوال.

ليس في عالم اليوم. تطورت اللغات الحتمية في فلسفة بايثون وهي رائعة للتطوير. أصبحت التقنيات التصريحية ذات العلامات المضمنة (XML) سائدة مع ظهور React ؛ وأصبح JSON تنسيق البيانات المفضل المستند إلى النص.

تم تنفيذ E4X فقط في ActionScript

كان E4X أحد معايير ECMA. قامت Mozilla بشحنها لفترة من الوقت ، ولكن بعد ذلك قامت بإزالتها (وهي خطوة غير معتادة بالنسبة لبائع المستعرضات). لم يرغب بائعو المستعرضات الآخرون في تنفيذه. (لقد طبقوا ميزات ECMA جديدة أخرى ، على الرغم من ذلك). مع E4H ، لم يكن بائعي المستعرضات أبدًا مهتمين بتنفيذها (على الرغم من أنهم طبقوا الكثير من الأشياء الأخرى التي ساعدت في ابتكارها).

حسنًا ، إذا طلبت منك شيئين ولم تفعل أيًا منهما خلال 3 أشهر وكان هناك بديل لأول شيء ، فسأطلب منك أيضًا ما هو مستحيل تمامًا نظرًا لاستجابتك وأداء التسليم السابق.

هذه إحدى النظريات الممكنة. يميل الناس إلى طلب العديد من الأشياء الأخرى إلى جانب ذلك ، والعديد من الأشياء التي يطلبونها يتم تنفيذها ، وهناك حلول بديلة لصور GIF المتحركة أيضًا ، لذلك لست متأكدًا من أن هذا يفسر الموقف تمامًا.

إنه أمر مضحك ولكنه يشبه وضع علامة إغلاق XML التي ذكرتها من قبل بشكل مطول للغاية.

بالفعل. هذه ميزة اختيارية لـ IDE ، وهي ميزة لا يتعين عليك كتابتها في الكود ، مما يُحدث فرقًا كبيرًا فيما إذا كان الإسهاب يمثل مشكلة أم لا.

... ListView ...

كيف سيتعامل محرر واجهة المستخدم الرسومية مع هذا الترميز؟ لا أفهم حقًا كيفية تصور واجهة المستخدم لهذا الغرض.

قد تكون هذه حجة مضادة لهذا الطلب ، و / أو ربما بعض الأفكار التي يجب وضعها في الاعتبار إذا كنت تريد الترميز. لدي شعور قوي بأن إضافة الترميز تخلق بعض التحديات مع GWT ، فأنا أكره أن أرى واجهة برمجة تطبيقات أخرى تمر بها.

لقد رأيت إطارين آخرين يمرون بهذا الانتقال فيما يتعلق ببناء واجهة المستخدم. يعمل ترميز مثل هذا بشكل رائع للأدوات ، وهو أمر رائع حتى الآن لمطوري IDE. من الأسهل فصل مسؤوليات من يفعل ماذا. على الرغم من أنني أعتقد أنه يمكن القيام به بشكل أفضل.

بدأت GWT بهذه الطريقة ، ببناء واجهة مستخدم باستخدام Java. ثم جاء UiBinder ، حيث يمكنك إنشاء واجهة المستخدم بترميز xml ، مع المواصفات. ثم تمكنت الأداة ، Eclipse Plugin ، من إنشاء واجهة مستخدم في ترميز xml. يقوم Android بذلك أيضًا ، فلا داعي للتعمق في هذه النقطة. إذن ما رأيته يحدث ، يعمل الترميز بشكل رائع لمطوري UI IDE. لكن في الحقيقة ، يعد الترميز استثمارًا ضخمًا في الوقت المناسب وإضافة أدوات معقدة لنقله إلى برنامج حقيقي. والأدوات هي آخر ما يأتي دائمًا. في هذه الأثناء ، بينما يتجلى كل ذلك في الواقع ، هناك عالمان. طريقتان مثيرتان لفعل كل شيء. واحد باللغة الافتراضية والآخر في الترميز. لذلك أنا أدعم GWT اليوم. عندما أكتب الوثائق ، يجب أن أكتبها مرتين ، مرة لجافا ومرة ​​لتوصيف UiBinder XML. لذا فإن السؤال الحقيقي ، إذا كنت تريد السير في طريق الترميز ، أعتقد أنه يجب طرح السؤال ، هل التعقيد الإضافي يستحق الرحلة!

أعتقد أن JSX تهدف إلى حل المشكلات الأخرى حيث تريد أن تدمج معًا ما تفعله باستخدام HTML وجافا سكريبت. لا يبدو حقًا أن التعقيد الإضافي لمواصفات الترميز يناسب احتياجات كتابة واجهة المستخدم مع الترميز. خاصة عندما لا تكون لغة ترميز المستندات هي الهدف. على الأقل ليس للمستخدم اليومي.

على نحو إيجابي. أحب العمل على الأدوات. لذلك يمكنني أن أرى لغة الترميز مفيدة جدًا. من الأسهل بكثير كتابة وتعديل AST عند استخدامك للترميز.

ولكن مرة أخرى ، إذا كان لديك ما يكفي من العقول في الوظيفة ، فلا يهم حقًا ما تفعله. في نهاية اليوم ، إذا تمكن المطور من كتابة تطبيقه بشكل أسرع باستخدام واجهة برمجة التطبيقات الخاصة بك ، فسوف تحصل على قوة دفع. ولكن بأي ثمن يتكبده الفريق الهندسي.

أعتقد أن السؤال الحقيقي هو ، كيف يمكن بناء واجهة المستخدم بشكل أسرع. أعتقد أن الأدوات يمكن أن تكتب النبال ، وتتخطى أي ترميز للرجل المتوسط. وهدفي ليس حقًا أن أقول أنه لا يستحق كل هذا العناء ، ولكن حقًا احسب التكلفة على جميع الجبهات إذا تم السير على الطريق!

كان E4X أحد معايير ECMA. قامت Mozilla بشحنها لفترة من الوقت ، ولكن بعد ذلك قامت بإزالتها (وهي خطوة غير معتادة بالنسبة لبائع المستعرضات). لم يرغب بائعو المستعرضات الآخرون في تنفيذه.

أود أن أقول إن Adobe فقط هي التي دافعت عن E4X وحظيت بمتابعة جيدة مع المطورين. يقوم بائعو المستعرضات بإضافة وإزالة عناصر من متصفحاتهم طوال الوقت ؛ ألم تقم Google بإزالة دعم MathML؟

هذه إحدى النظريات الممكنة. يميل الناس إلى طلب العديد من الأشياء الأخرى إلى جانب ذلك ، والعديد من الأشياء التي يطلبونها يتم تنفيذها ، وهناك حلول بديلة لصور GIF المتحركة أيضًا ، لذلك لست متأكدًا من أن هذا يفسر الموقف تمامًا.

هذا هو الشيء المتعلق بـ React و JSX. وأنت لا تفهم تمامًا ما يجلبه React إلى الطاولة حتى تتطور معه لفترة ، ثم يصبح الليل و اليوم ضد جميع الأطر الأخرى.

كيف سيتعامل محرر واجهة المستخدم الرسومية مع هذا الترميز؟ لا أفهم حقًا كيفية تصور واجهة المستخدم لهذا الغرض.

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

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

أود أن أمثل \كمستطيل وإذا كان طفله / أطفاله حيث توجد أدوات أخرى سأضع مستطيلات لذلك بداخله.
نظرًا لأن الطفل في هذه الحالة عبارة عن وظيفة ، يمكنك ببساطة وضع مستطيل يقول "غير قابل للتعديل / رمز" لإخبار المستخدمين أن هذه الأداة تم إنشاؤها من رمز أو في هذه الحالة تستنتج بسهولة أن الوظيفة عبارة عن غلاف ضحل إلىالقطعة وببساطة تقديم ذلك ؛ أعني مستطيلًا يقول أن الوظيفة عبارة عن غلاف ضحل للوظيفة وداخلها مستطيل عنصر واجهة مستخدم عنصر القائمة (\في هذه الحالة).

لكن في الحقيقة ، يعد الترميز استثمارًا ضخمًا في الوقت المناسب وإضافة أدوات معقدة لنقله إلى برنامج حقيقي.

كل ما أطلبه هو إضافة هذه الامتدادات البسيطة على مترجم Dart حتى يتمكن المطورون إذا أرادوا ذلك من الكتابة باستخدام بنية XML هذه. الطريقة القديمة ستستمر في العمل ومقدار العمل المطلوب للقيام بذلك ليس ضخمًا على الإطلاق. يمكنك في الواقع معرفة عدد سطور التعليمات البرمجية التي يحتاجها مترجم babel.js لتنفيذ JSX وأنا أتحدث عن مئات وليس آلاف الأسطر (لقد راجعتها للتو).

والأدوات هي آخر ما يأتي دائمًا. في هذه الأثناء ، بينما يتجلى كل ذلك في الواقع ، هناك عالمان. طريقتان مثيرتان لفعل كل شيء. واحد باللغة الافتراضية والآخر في الترميز

بالتأكيد لكن React كانت على هذا النحو وهذه ليست مشكلة على الإطلاق.

عندما أكتب الوثائق ، يجب أن أكتبها مرتين ، مرة لجافا ومرة ​​لتوصيف UiBinder XML.

ليس في React لأن الترميز موجود داخل الكود.

هل التعقيد الإضافي يستحق الرحلة!

تمامًا ، إنها مثل حجة ما إذا كان يجب عليك تدريب مطوريك بأحدث التقنيات والمخاطرة بمغادرتهم لشركتك. الخطر الأكبر هو إبقائهم غير مدربين. لذلك يجب أن تتبنى أحدث التقنيات المتاحة وإلا ستخاطر بالتخلف عن الركب.

تقود React الرحلة بأحدث التقنيات لتطوير UI / UX. لديها جاذبية هائلة مع المطورين. أكبر مخاطرك هي عدم تلبية شريط React.

أعتقد أن JSX تهدف إلى حل المشكلات الأخرى حيث تريد أن تدمج معًا ما تفعله باستخدام HTML وجافا سكريبت

JSX ليس فقط لـ HTML ، فإن React Native تنشئ طرق عرض (مثل Flutter Widgets) من ترميز XML.

أعتقد أن السؤال الحقيقي هو ، كيف يمكن بناء واجهة المستخدم بشكل أسرع.

أشبه بكيفية بناء UI / UX بشكل أفضل. معنى أفضل: أسرع ، جودة أعلى (كود وواجهة مستخدم / UX) ، تفاعل سلس بين المصمم والمطور ، إلخ.

بالمناسبة ، عمل رائع حقًا تم القيام به على أدوات المطور ؛ "الطبيب الرفرفة" كان رائعا !!!
أنا الآن أطبخ بالغاز ويمكن أن أكون مبدعًا بشكل خطير ؛)

أردت فقط الرد على سؤال قابلية القراءة المطروح هنا ، على الرغم من أنني أفهم أن قابلية القراءة هي واحدة فقط من العديد من العوامل التي نحتاج إلى وضعها في الاعتبار.

سهولة قراءة الكود وبساطته والتي بدورها تقود مجموعة كاملة من المزايا الأخرى.

إذا كانت هذه هي الفائدة الرئيسية ، فهذا شيء يمكننا اختباره. يمكننا أن نأخذ مزيجًا من المهندسين المعتادين على كتابة HTML ، و React ، و iOS code ، و Android code ، و Flutter ، وتطبيقات سطر الأوامر ، وما إلى ذلك ، ونقدم لكل منهم تراكيب مختلفة ، ونطلب منهم وصف ما يعتقدون أنه ستبدو واجهة المستخدم الناتجة. يمكننا بعد ذلك قياس البنية التي تحصل على أفضل النتائج. InMatrix هل هذا شيء يمكننا النظر إليه بعد انتهاء عمل الرسوم المتحركة ، ربما؟

هناك بالتأكيد طرق لدراسة قابلية قراءة الكود تجريبيًا ، ويمكننا إجراء مناقشة أكثر جدية عندما يحين وقت التخطيط للربع الرابع. لجعل هذه الدراسة مفيدة ، نحتاج إلى تحديد أنواع مهام القراءة المهمة للمطورين في سياق برمجة Flutter. بالإضافة إلى قراءة طريقة الإنشاء بالكامل وتصور ما قد تكون عليه واجهة المستخدم الناتجة ، تؤثر إمكانية القراءة أيضًا على المهام الأصغر مثل تحديد طريقة الإنشاء في ملف سهم ، ومطابقة الأقواس ، وقراءة التعليقات المضمنة ، وما إلى ذلك.

لدعم بعض تلك المهام ذات النطاق الضيق ، يمكننا تجربة تحسينات واجهة المستخدم في المحرر أولاً ، والتي عادة ما تكون أرخص من تقديم لغة ترميزية والحفاظ عليها. تعد ميزة تسمية الإغلاق في كود VS واحدة من تحسينات واجهة المستخدم هذه ، ويجب أن نفهم مدى نجاحها في حل مشكلة مطابقة الدعامة التي تحددها لمعالجتها. هناك الكثير من الخيارات الأخرى في هذا المكان لم نجربها بعد. على سبيل المثال ، يمكن استخدام خط أو لون خلفية مختلف لعرض طريقة الإنشاء لمساعدة المطور عقليًا على فصله عن باقي التعليمات البرمجية الخاصة به.

الشيء الآخر الذي أذهلني على أنه مهم هو كيف يمكننا تشجيع الناس على عدم كتابة طريقة بناء عملاقة والاستفادة من طبيعة تكوين إطار العمل. إذا كانت طريقة الإنشاء أطول من ارتفاع شاشتك ، فسيكون من الصعب قراءتها بغض النظر عن كونها Dart أو XML.

الشيء الآخر الذي أذهلني على أنه مهم هو كيف يمكننا تشجيع الناس على عدم كتابة طريقة بناء عملاقة والاستفادة من طبيعة تكوين إطار العمل. إذا كانت طريقة الإنشاء أطول من ارتفاع شاشتك ، فسيكون من الصعب قراءتها بغض النظر عن كونها Dart أو XML.

إنها ليست طريقة البناء فقط. إنها جميع الطرق الأخرى التي تستدعيها طريقة الإنشاء لبناء شجرة عناصر واجهة المستخدم. من الشائع جدًا في React استخدام طرق أصغر لبناء قطع شجرية فرعية ثم استدعاءها في الشجرة الأكبر.

أيضًا في WebStorm مع JSX ، تحتوي كل عقدة XML على +/- والتي يمكن استخدامها لتوسيع / ​​طي العقدة والتوابع لجعل هياكل القراءة أكبر من ارتفاع الشاشة أسهل.

أحد الأشياء التي وجدناها في Flutter هو أن أساليب البناء الكبيرة ليست جيدة للأداء ، ونحاول تشجيع الأشخاص على تقسيم أساليب البناء الخاصة بهم إلى أدوات أصغر قابلة لإعادة الاستخدام. على وجه الخصوص ، في Flutter ، وجود طريقة بناء مبنية على نتائج طرق أخرى هو نوع من المضاد الذي نفضل تثبيطه بدلاً من تسهيله. (يعد هذا إلى حد ما إدراكًا حديثًا ، لذا فإن الكثير من الأمثلة والحاجيات لدينا لا تفعل ذلك جيدًا حتى الآن).

نحاول تشجيع الأشخاص على تقسيم أساليب الإنشاء إلى أدوات أصغر قابلة لإعادة الاستخدام.

هل أصبحت حقًا أداة قابلة لإعادة الاستخدام أو مجرد أداة مجمعة / مركبة؟ أعني أن تكون قابلاً لإعادة الاستخدام ، يجب أن يكون لديك ما لا يقل عن مثيلين للاستخدام.

يعد AppBar الموجود على https://flutter.io/catalog/samples/basic-app-bar/ فريدًا جدًا بحيث لا يمكنك تسميته مكونًا قابلًا لإعادة الاستخدام ؛ إنه مكون مجمّع / مركب وفي هذه الحالات لماذا لا تستخدم طريقة محلية فقط لبناء هذا الجزء من واجهة المستخدم؟ أعتقد أنه إذا فعلت المزيد من الأشياء ، فمن المنطقي وضعها في مكون مجمّع / مركب.

شيء واحد وجدناه في Flutter هو أن أساليب البناء الكبيرة ليست جيدة للأداء

نظرًا لأنك ذكرت الأداء ، فإن تشغيل حلقة الرسوم المتحركة سيؤدي إلى حدوث مشكلات في الأداء من أجل رسم متحرك سلس. لا تريد استدعاء طريقة الإنشاء 60 مرة في الثانية أو أكثر ، خاصة إذا أخذنا في الاعتبار أن طريقة الإنشاء هي رمز مستخدم (على سبيل المثال ، يمكن أن يكون لها حلقة طويلة جدًا تستغرق وقتًا طويلاً وستتسبب في تخطي الرسوم المتحركة). كوني مبتدئ Flutter ربما فهمت ذلك بشكل خاطئ.

يعد AppBar الموجود على https://flutter.io/catalog/samples/basic-app-bar/ فريدًا جدًا بحيث لا يمكنك تسميته حقًا مكونًا قابلًا لإعادة الاستخدام

إنها أيضًا صغيرة نسبيًا ، لذا لا بأس.

فيما يتعلق بالأداء ، هذا خارج عن الموضوع إلى حد ما بالنسبة لهذه المشكلة ، لذا يرجى تقديم مشكلة جديدة إذا كنت ترغب في مناقشتها (أو إرسال رسالة إلكترونية إلى flutter-dev أو النشر على مكدس الفائض ، كل ما تفضله).

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

من الجنون أن ترى هذه القضية مدفونة. في رأيي ، سيكون من الأفضل لـ Flutter تنفيذ بناء جملة يشبه JSX لإنشاء عناصر واجهة مستخدم.

أنا ببساطة لا أفهم الجمهور المستهدف ، فالعديد من مطوري iOS و Android يتحركون للتفاعل بشكل أصلي ، ويبدو أنها فرصة مثالية لجني حصة في السوق.

أنا أشجع الأشخاص المعنيين على إعطاء رد فعل أصلي تدور حوله ومعرفة ما نتحدث عنه.

لا أفتقد JSX قليلاً في Flutter. سيؤدي هذا فقط إلى تضخيم الإطار والأدوات لبضعة مكاسب صغيرة هنا وهناك.

birkir أنا معك 100٪ في هذه القضية. إن عدم وجود JSX ، الذي يتناسب تمامًا مع Flutter ، يجعل Flutter يبدو قديمًا وصدئًا ، وكأنه تقنية التسعينيات. في الواقع يبدو أن الجميع ، بطريقة أو بأخرى ، يتبنون JSX ؛ أحدثها هو إطار عمل Vue.js الشهير.

+1

zoechi ما هي تجربتك السابقة مع JSX ، هل استخدمتها بالفعل أو نظرت إليها للتو؟ أعتقد أنكم يا رفاق تقللون من شأن JSX بالقول إنها ستعطي مكاسب صغيرة هنا وهناك. إذا لم يكن لديك أي مستخدمين ، فليس لديك منتج.

birkir أرى الكثير من الإثارة حول JSX هنا ولكن لا أحد يبدو أنه يكلف نفسه عناء شرح ما سيكسبه Flutter بالضبط من امتلاك DSL ، باستثناء ربما بعض سهولة القراءة الأفضل والتي تكون في الغالب ذاتية.

عادةً ما تؤدي المزيد من الميزات إلى خفض إطار العمل بدلاً من تحسينه.
يستهلك تنفيذها أيضًا الكثير من الموارد المفقودة من مناطق أخرى حيث تمنع الميزات المفقودة الأشخاص فعليًا من تنفيذ تطبيقات معينة.

لذلك إذا كنت متحمسًا بشأن حصول Flutter على شيء مثل JSX ، فيجب أن تستثمر وقتك وطاقتك في كتابة حجج مقنعة.
مجرد إضافة شيء ما لأن الآخرين يمتلكونه أيضًا ، ربما يكون هو أضعف حجة على الإطلاق.

هناك أيضًا خطط لتحسين Dart لجعل كتابة كود Flutter UI أقل إسهابًا مما يضعف حالة JSX أكثر.

إذن ما هي حججك المقنعة؟

هل حقا !!! "لا يبدو أن أحدًا يكلف نفسه عناء شرح ما سيكسبه Flutter بالضبط ... بلاه بلاه بلاه".
ألم تقرأ هذا الموضوع بالكامل؟ هل مدى انتباهك أكبر من معرفتك بـ JSX؟

أنتم يا رفاق تعاني من متلازمة المعاهد الوطنية للصحة (لم يخترع هنا). "الفنانون الجيدون ينسخون ؛ الفنانون العظماء يسرقون" ، الفنانون المتوسطون ، حسنًا ، يتصرفون مثلك.

مجرد حقيقة أن دعم JSX بسيط نسبيًا ، وسيساعد بشكل كبير في جذب عملاء جدد (مطورو الأجهزة المحمولة من React Native) إلى النظام الأساسي ، مما يجعله أمرًا لا يحتاج إلى تفكير وهو أمر لا يمكنك رؤيته يا رفاق. إنها ليست جريئة بشكل جيد للمنصة.

هل يمكننا من فضلك الحفاظ على نبرة بناءة عند المناقشة.

تعد إضافة ميزات لأن الآخرين يمتلكونها حجة ضعيفة. تمام.
لماذا الرفرفة لديها إعادة تحميل ساخنة؟ من اين جاء هذا؟ يسوع يا صاح.

كيف فشلنا في تقديم حجة قوية لكم يا رفاق؟ جذب المشروع وجذب المطورين هو السبب الأول لدينا.

السبب الثاني ، المقروئية :

https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/demo/cupertino/cupertino_buttons_demo.dart مقابل https://gist.github.com/birkir/e921158239c324ab95bb0b174383a562

السبب الثالث ، بناة واجهة المستخدم الرسومية . سأقتبس السطر الأول في التمهيدي.

تطبيق SDK جديد للهاتف المحمول لمساعدة المطورين والمصممين على بناء تطبيقات جوال حديثة لنظامي التشغيل iOS و Android.

أنا أكره أن أرى Flutter ينزل في نفس حجرة البوليمر مثل Polymer قبل أن تصل إلى مرحلة بيتا.

جر المشروع وجذب المطورين

العلاقة لا تزال غير واضحة.

السبب الثاني ، المقروئية:

يبدو أن جعل رمز Dart أكثر قابلية للقراءة هو هدف أفضل بالنسبة لي

السبب الثالث ، بناة واجهة المستخدم الرسومية. سأقتبس السطر الأول في التمهيدي.

بقدر ما أتذكر ، فقد سبق ذكره أعلاه أنه لا يوجد سبب يجعل استخدام رمز Dart يمنع ذلك.

لا تستطيع حججك المضادة رفض الفكرة حقًا ، أليس كذلك؟

1. العلاقة واضحة جدا. ما لم يكن هدفًا أن يحظى المشروع بالشعبية؟
2. باهر! هل ستكون قريبة من قابلية قراءة JSX؟ ما هو الاقتراح الحالي لمثل هذا الشيء؟
3. وذكر أنه يمكن القيام بذلك . سيكون تكييف دعم JSX لمنشئي واجهة المستخدم الرسومية المتاحين أبسط بكثير.

هناك أيضًا خطط لتحسين Dart لجعل كتابة رمز Flutter UI أقل إسهابًا

من الجميل أن نرى إقرارًا بأن الطريقة الحالية يمكن أن تستخدم بعض التحسينات.
يرجى تقديم تفاصيل عن هذا الاقتراح. أفضل رهان لك هو التفاعل مع مجتمع React Native للحصول على تعليقات.

يمكن للعديد من طلبات ميزة لغة Dart أن تجعل الكود قصيرًا / أكثر قابلية للقراءة:

• اختياري new و const لـ Dart 2
• قضية وصفية لمناقشة الاقتراح للسماح بالوسائط المسماة في كل مكان - - قد يسمح هذا لعنصر واجهة مستخدم يحتوي على وسيطة 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'),
            )
          ),
        ),
      )
    );
  }

علاوة على ذلك ، اعتمادًا على IDE الخاص بك ، يمكنك اختيارًا الحصول على تعليقات تركيبية في نهاية الأقواس ويمكنك رؤية شيء مثل هذا في IDE الخاص بك:

  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
سأغلق هذه المحادثة لبضعة أيام بينما يفكر الجميع في كيفية المساهمة باحترام وإنتاجية.

نعلم جميعًا أن بناء الجملة لبناء واجهة المستخدم هو جزء مهم جدًا من تجربة تطوير الأجهزة المحمولة. في الوقت الحالي ، تعد البنية مطولة بعض الشيء ، ولا بد لي من استخدام new شيء فقط لغرض إضافة الهامش: margin: new EdgeInsets.symmetric(horizontal: 4.0) ، أعتقد أنه قد يكون هناك طريقة أسهل.

هل سيكون من الممكن بناء DSL مثل ما فعله فريق Kotlin لمطوري Android؟ يطلق عليه Anko ، DSL لبناء واجهة مستخدم Android:

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

تساعد البنية الموجزة في إبقاء الكود قابلاً للقراءة وصيانتها ، كما يمكن أن يجعل عمل المبنى ممتعًا ، إنه مهم. يرجى تقدير فريق Flutter على محمل الجد قبل اتخاذ القرار. كلنا نحب أن نرى Flutter يحقق نجاحًا أكبر في السنوات القادمة.

من فضلك لا تقم بإدخال صيغة تشبه XML إلى Flutter.

لقد قمت بالبرمجة في Android Java لأكثر من عام ، ثم بدأت في البحث عن مجموعة أدوات عبر الأنظمة الأساسية لتجربتها.
لقد بدأت مع React Native ثم جربت React. لم تعجبني صيغة JSX حقًا لأنها ليست جافا سكريبت تمامًا وليست لغة تأشير النص الفائق ، لذا فهي مجرد شيء آخر يجب تعلمه.
عندما جربت Flutter وجدت أنه من الأسهل البدء (ربما يرجع ذلك أساسًا إلى خلفية Java الخاصة بي).

أعتقد أن بعض الأسباب التي تجعلني لا أرغب في إضافة بناء جملة XML إلى الرفرفة:

1. شيء آخر يجب تعلمه - يمكن إنفاقه على تعلم العقود الآجلة بدلاً من ذلك ؛ P
2. تبديل السياق - أنت تقوم بتبديل السياق بين XML والرمز وهو مجرد تحميل معرفي غير ضروري.
3. كانت هناك أيام قمت فيها بالبرمجة في Java في الصباح و Python في فترة ما بعد الظهر. باستخدام React ، قد تحتاج إلى فهم Javascript و Babel و JSX و HTML و CSS والمزيد في قاعدة كود واحدة.
4. السبب في أن XML ليس ضروريًا في Flutter هو أن dart قد قامت بتسمية الوسائط التي تحل محل سمات XML بشكل جيد.
5. يحتوي Dart على dartfmt الرائع جدًا الذي يضع مسافة بادئة للكود جيدًا دون أي جهد.

مقارنة بنظام Android

1. يجب أن تتعلم الطريقة الآلية على أي حال ، فلماذا تضيف طريقة أخرى للقيام بالأشياء؟
2. يعد تخطيط XML في android أسرع لعرض التغييرات على الجهاز ، ولكن التشغيل في Flutter يكون فوريًا عمليًا على أي حال ، لذا فإن إضافة XML لن يوفر هذه الميزة.
3. تضيف التركيبة البرمجية لـ Android XML + التعقيد ، مثل تضخيم مقتطفات XML والحقن في شجرة XML برمجيًا.
4. يعد التشغيل الفوري سريعًا جدًا في Flutter ، ولا تحتاج إلى نموذج XML للمساعدة في تصور كيفية ظهوره ، يمكنك فقط الضغط على مفتاح ورؤية التغيير على الفور.
5. تختلف الأخطاء من مشكلات التخطيط البرنامجي عن مشكلات التخطيط في XML ، لذلك هناك مجموعتان من الأشياء التي تحتاج إلى فهمها.

سأذهب خطوة أخرى إلى الأمام وأزل pubspec.yaml واستبدله بـ pubspec.dart ولدي تكوين في كود dart.

إذا كان المطورون يشكون من صعوبة تخطيط الصفحات بصريًا - فستكون الفكرة هي إنشاء مصمم تخطيط يتيح لك تعيين السمات وصفحات التصميم بشكل مرئي عن طريق السحب والإفلات. بعد ذلك ، سيُنشئ رمز Flutter الذي لا يُقصد تعديله مطلقًا - ولكنه ينشئ فئات يمكن استخدامها لإنشاء تطبيقك.

لن تحتاج إلى تحرير ثنائي الاتجاه (XML / تنسيق) مثل Android XML ، ولكنك تقوم فقط بحفظ التنسيق الخاص بك لوقت لاحق. إذا كنت بحاجة إلى تغييره ، يمكنك إعادة إنشاء الكود و (نأمل) فقط تغيير بعض الوسائط.

أعلم أن هذه المحادثة قديمة ونعم كانت ساخنة جدًا ، لكني أرغب في ترك بضعة أسطر لما أعتبره يحدث هنا.

الرفرفة جديدة. إنها طريقة جديدة تمامًا للقيام بالأشياء. نعم ، لقد استعار من نموذج رد الفعل. لكن هذا لا يعني أنها بحاجة إلى اتباع نفس خطواتها. لا أعتقد أن هدف فريق flutter هو جذب المطورين من التفاعل الأصلي إلى الرفرفة ، إنه فقط لبناء شيء جديد قد يجده المطورون مهتمين به. تستخدمه Google داخليًا قبل مشاركته مع العالم وكانوا منتجين معه هو - هي. أشارك التعليقات مع Hixie التي تفيد بأن إنشاء واجهة المستخدم لا يختلف عن JSX. نعم ، إنها مطولة أكثر قليلاً إلى سهم نقي. ولكنه في الواقع يجعل تصحيح أخطاء التعليمات البرمجية أسهل كثيرًا.

السبب الذي يجعل الدردشة ضد لغة الترميز أو JSX أو أي شيء يجلس فوق التكنولوجيا هو أنها تتطلب الكثير من العمل من النظام الأساسي. يمكنك أن تكون سعيدًا بتأليف لغة ترميز لواجهة مستخدم ، ولكن سيكون لديك الكثير من المطورين الذين يعملون على النظام الأساسي وهم يبكون ويسحبون الشعر لجعله يعمل من أجلك. وجهة نظر أخرى هي أن JSX عملت من أجل مجتمع Javascript ، حيث يكون هدفها الرئيسي كما هو الحال دائمًا هو تسهيل الأمور على المطور وعدم القلق بشأن المفاضلات. لا تفهموني خطأ كان React (JSX) للويب مطابقًا في الجنة لأن HTML هو ترميز على أي حال. لكن بالنسبة إلى React Native ، انظر إلى جميع الأكواد الموجودة في المستودع التي كان عليهم القيام بها لجعلها تعمل. تتطلب إضافة JSX إلى الرفرفة قدرًا كبيرًا من العمل وشيئين يجب التفكير فيهما عند إضافة ميزات جديدة. ومرة أخرى فقط لتتمكن من إزالة المعلمة الفرعية والقيمة الثابتة والكلمات الرئيسية الجديدة ؟. أفضل معرفة ما يحدث بالفعل في الكود والتحكم في ما يحدث بدلاً من امتلاك بناء جملة سحري بحيث يكون كل ما يفعله هو إضافة النفقات العامة.

حسنا هذا رأيي. لا تريد أن تبدأ مناقشة عملاقة جديدة. فقط لذكر حقيقة أن JSX رائع لمجتمع رد فعل / جافا سكريبت لأنه يعمل لصالحهم ، لكن بالنسبة إلى Dart / flutter أجد أنه من المبالغة بعض الشيء إضافة JSX فقط لجذب المطورين من React Native.

واو ، من الممكن أن يكون قد كتب منشور مدونة xD

Rockvole ،

شيء آخر يجب تعلمه - يمكن إنفاقه على تعلم العقود الآجلة بدلاً من ذلك ؛ P

الشيء الذي يجب تعلمه يجعل بناء الكائن العودي الحالي أبسط ومألوفًا لمطوري React Native يوميًا ، لذلك أعتقد أن الناس سيفضلون تعلم ذلك.

تبديل السياق - أنت تقوم بتبديل السياق بين XML والرمز وهو مجرد تحميل معرفي غير ضروري.

ليست مشكلة ، لا يوجد تبديل سياق ، إنه مجرد جزء من البيئة التي تجعل برمجة UI / UX أكثر نظافة.

بعد ذلك ، سيُنشئ رمز Flutter الذي لا يُقصد به تحريره على الإطلاق

ولم لا؟ ليست مفيدة جدا بعد ذلك.

تضمين التغريدة

لا أعتقد أن هدف فريق الرفرفة هو جذب المطورين من التفاعل الأصلي إلى الارتجاف

هل حقا !!! يهيمن React Native ، وبالنظر إلى أن العدد الإجمالي لمطوري الأجهزة المحمولة الذين يستخدمون أدوات متعددة المنصات محدود ، هل تعتقد حقًا أن Flutter يمكن أن تصبح نجاحًا رئيسيًا دون جذب الأشخاص الأصليين من React؟

نعم ، إنها مطولة أكثر قليلاً إلى سهم نقي. ولكنه في الواقع يجعل تصحيح أخطاء التعليمات البرمجية أسهل كثيرًا.

هذا ليس بيانًا صحيحًا. تصحيح أخطاء كود JSX ، الذي هو مجرد كود جافا سكريبت ليس أسهل أو أصعب ، إنه نفس الشيء.

السبب الذي يجعل الدردشة ضد لغة الترميز أو JSX أو أي شيء يجلس فوق التكنولوجيا هو أنها تتطلب الكثير من العمل من النظام الأساسي.

من يهتم بكمية العمل التي تم وضعها في المنصة؟ يريد المطورون فقط أحدث التقنيات التي تعمل على تحسين قابلية قراءة الكود والإنتاجية. لا يوجد مطور يريد استخدام تقنيات قديمة وعفا عليها الزمن عندما توفر العناصر الأحدث بديلاً أفضل.

أفضل معرفة ما يحدث بالفعل في الكود والتحكم في ما يحدث بدلاً من امتلاك بناء جملة سحري بحيث يكون كل ما يفعله هو إضافة النفقات العامة.

هذا غير منطقي ، أعرف بالضبط ما يحدث مع JSX ، إنها طبقة صغيرة جدًا تحول واحدًا إلى آخر تقريبًا ولكنها توفر الكثير من الفوائد. وقت تجميع ضئيل إذا سألتني.

فقط لذكر حقيقة أن JSX رائع لمجتمع رد فعل / جافا سكريبت لأنه يعمل لصالحهم ، لكن بالنسبة إلى Dart / flutter أجد أنه من المبالغة بعض الشيء إضافة JSX فقط لجذب المطورين من React Native.

يجب أن تعمل JSX أيضًا بشكل رائع مع Dart / Flutter. انها ليست مبالغة بأي حال من الأحوال. هل هناك أي سبب وجيه لعدم عمل JSX مع Dart / Flutter؟ إذا كنت سأقوم بترميزها وإصدارها ، فلماذا لا تكون مناسبة لتطوير Dart / Flutter؟

لنأخذ المثال الملموس من 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,
    ),
  );

كيف تنصحنا بالتعبير عن هذه الدلالات _exact_؟

  // 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 وتحويله إلى Javascript عادي:
https://babeljs.io/repl/# ؟ babili = false & Evaluation = true & lineWrap = false & presets = es2015٪ 2Creact٪ 2Cstage-0 & code = function٪ 20hello ()٪ 20٪ 7B٪ 0A٪ 20٪ 20return٪ 20٪ 3Cdiv٪ 3EHello٪ 20world!٪ 3C٪ 2Fdiv٪ 3E٪ 3B٪ 0A٪ 7D

سأفعل ما يعادل DSX إلى Dart. مجرد إثبات للمفهوم ، دعنا نرى كم من الوقت سيستغرق ...

إليك أحدث مثال لـ @ Hixie في "DSX" ، باستخدام دليل أسلوب Airbnb وافتراض أن جميع العناصر الفرعية يمكن تعيينها تلقائيًا إلى خصائص child .

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>
);

إذا كان الهدف هو تحسين قابلية القراءة ، أعتقد أن Dart يفوز في المستقبل في البستوني.

يجب عليك التحقق من الوثائق لمعرفة ما يمكن أن يتحول إلى علامات (من المفترض أن يكون Widget s فقط) ، أو عدد العناصر الفرعية المطلوبة / المسموح بها.

إذا كان هدفك هو إخراج HTML من JavaScript ، فإن JSX لها معنى كبير كحل وسط. لأنه عندما تريد العلامات في نهاية اليوم ، يكون React.createElement('div', null, 'foo') أسوأ بكثير من <div>foo</div> .

إذا كان هدفك هو إخراج شجرة من كائنات Dart من ... Dart ، والشجرة المنسقة بشكل جيد لمصممي Dart يمكن قراءتها بشكل مثالي (يمكن القول أكثر) ، لا أرى أي نقطة في الالتفاف عبر XML. وأنا لا أفتقد ملفات XML التي تأتي من Android.

هذا ما يتيحه استخدام XML ... انظر ، لقد مرت 5 أشهر مع التحدث فقط ، والآن أفعل شيئًا حيال ذلك ، لذا امنحني بعض الوقت (لدي وظيفة بدوام كامل ولا يمكنني توفير سوى حوالي 4 ساعات في عطلات نهاية الأسبوع).

وجدت هذا الموضوع مثيرًا للاهتمام على كلا الجانبين. بصفتي مطور React مهتمًا بـ Flutter ، هناك بعض الحجج الأخرى التي لم أذكرها (على الرغم من أنني قمت بقراءة جميع التعليقات لفترة وجيزة فقط).

1. إعلان علامة الإغلاق يزيد من فهم الأطفال مقابل الخصائص. لسوء الحظ ، يمكن أن تكون واجهة المستخدم متداخلة بعمق ، ويساعد وجود علامة واضحة مقابل علامة غير معروفة) في توضيح وتحليل الأطفال. كما يسمح لي أيضًا بنقل الكود بين المكونات ومعرفة ما إذا كان هناك شيء ما في غير محله (علامة إغلاق قبل علامة على سبيل المثال.) وهذا أكثر تعقيدًا مع تداخل متعدد).

2. رد فعلي الأولي لرؤية عدة مكونات متداخلة داخل المنشئات يعطيني ذكريات الماضي عن "رد الاتصال الجحيم" . لقد كانت حقبة مؤلمة للغاية من JS بدأت في التحسن ، والعودة إليها تبدو وكأنها خطوة إلى الوراء.

3. فيما يتعلق بالرقم 2 ، الحقيقة المؤسفة هي أنه يتعين علينا إقناع الناس بالتبديل (أو على الأقل تجربتها). كثير من الناس يستخدمون React / React Native وأكثر من ذلك يستخدمون HTML / JS. قد يكون إنشاء برنامج تعليمي / دليل بسيط ومألوف في الغالب من الناحية النحوية والذي يستهدف على وجه التحديد بعض نقاط الألم في React مقنعًا للغاية لأولئك الذين يعانون من الإرهاق قليلاً.

أحد الأسباب الرئيسية التي جعلت React أصبحت شائعة في مجتمع مطوري الويب هو دعم JSX.

إنه لأمر مخيب للآمال حقًا أن ترى "تصويتات سلبية" على مثل هذه الميزة الرائعة. يحسن القراءة ويسرع التبني.

أعتقد أن هذا فرق كبير بين Open JavaScript و Dart. يعد JavaScript مفتوح المصدر حقًا ، في حين أن الطلب الموجود على Dart يدخل في محادثة مثل هذه وفي النهاية يتم تحفيزك باستخدام الأصوات السلبية.

إفساح المجال لأفكار جديدة!

jayjun هذا يبدو مذهلا! هل يمكنني تجربتها في مكان ما؟

sanketsahusoft لا تقلق قريبًا ستتمكن من تجربة الإصدار الخاص بي وهو أفضل منjayjun.

تحديث سريع: منذ 2 عطلة نهاية الأسبوع ، حصلت على واجهة المستخدم تعمل بشكل رائع ، وفي نهاية الأسبوع الماضي حصلت على المحلل اللغوي يعمل بشكل كامل ونصف المترجمة يعمل. في عطلة نهاية الأسبوع القادمة آمل أن أنهيها إذا تجنبت Superbowl ؛)

لدي جلد كثيف وبغل مثل العناد ، لذا لم ألاحظ حتى هذه الأصوات السلبية ، شكرًا لتوجيههم على الرغم من ذلك.

كارلوس.

هل سيساعد هذا في مشكلة فقدان مسار علامات الإغلاق؟
الفكرة: علامات الإغلاق المُنشأة تلقائيًا

إليك بعض بناء جملة الترميز المقترح لمثال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 ، الشيء المثير للاهتمام الذي فعلته هو إضافة إمكانية سمة ثالثة تبسط مظهر التعبيرات عندما تكون علامة أخرى.
JSX لديها:
1 - <tag attrib=""/> أو <tag attrib=''/>
2 - <tag attrib={}/>
لقد اقترحت واحدًا آخر:
3 - <tag attrib=<anotherTag.../>/>
مع JSX عليك كتابتها على النحو التالي:
<tag attrib={<anotherTag.../>}/>

cbazza نعم ، الحالة الثالثة شائعة جدًا في Flutter ، لذا فمن المنطقي تخطي التداخل الإضافي { .

abarth آه لكني أجعل معظم هذه الأشياء غير ضرورية باستخدام أنماط تشبه css !!! يقوم المرشح بتوسيع هذه الأنماط الشبيهة بـ css إلى استدعاءات Flutter المناسبة. أصبح هيكل العلامات الآن أكثر نظافة ويمكن استيراد الأنماط بسهولة من أدوات المصمم مثل InVision و Figma و Atomic وما إلى ذلك.

cbazza Cool ، أستخدم العديد من الأدوات ذات الإغلاق مثل 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 ، نعم ، هذه ليست مشكلة. المترجمة عبارة عن معالج XML بسيط وعندما يتعلق الأمر بتحليل التعبيرات (كل شيء بداخل {}) ، فإنه يصبح مجرد كائن نصي لذلك يكتبه حرفياً.

تضمين التغريدة

هل سيكون من الممكن بناء DSL مثل ما فعله فريق Kotlin لمطوري Android؟

يبدو أن الكثير من الأشخاص يرغبون في استخدام لغة Kotlin مع Flutter. بصراحة ، لا أفهم ، لماذا قرر المطورون إعادة اختراع العجلات في Dart؟

في رأيي المتواضع ، لا يحتاج Flutter إلى JSX. يجب أن يختار Flutter Kotlin بدلاً من Dart. يسمح لنا Kotlin بكتابة منطق معقد لواجهة المستخدم مع بناء جملة جميل خارج الصندوق ، ولديه مجتمع ضخم ، وأدوات جاهزة للإنتاج ، وتم اختباره للمعركة في تطوير Android ...

فقط أقول.

Kotlin رائع ، أنا من المعجبين به ولكنه لا يعمل على نظام iOS ..... في الواقع إنه يعمل ولكن لم يتم إصداره بعد (مرحلة ما قبل الإصدار الآن).
بالنسبة لتطوير UI / UX ، ما زلت أفضل JSX بدلاً من Anko DSL. تعجبني حقيقة أنه يمكنني فصل الترميز التعريفي بصريًا عن الكود الضروري وأن أكون قادرًا على مزج المكونات ومطابقتها معًا بسهولة تامة.

هناك أوجه تشابه بين Dart و Kotlin و Swift:
https://sethladd.github.io/swift-is-like-kotlin-and-kinda-like-dart/

أحب ذلك :

1. Dart مألوف أكثر إذا كنت قادمًا من Java.
2. يمكنك الاستفادة من مهارات Dart الخاصة بك واستخدامها لبناء صفحات الويب - وهو أمر ذو قيمة عند إنشاء التطبيقات ، ويمكنك إنشاء ميزات على الويب (وإظهارها في WebView) حيث يكون ذلك أكثر منطقية (ربما صفحات إدارة سريعة أو قوائم المنتجات التي بحاجة إلى فهرسة جوجل).
3. تم إنشاء Dart منذ البداية للتجميع إلى جافا سكريبت والذي أفترض أنه ليس من السهل إضافته إلى لغة لاحقًا.

هذه هي الأسباب التي دفعتني إلى اختيار Dart بدلاً من Kotlin / Swift / React.

_ على الرغم من أن قرار دعم Dart و Swift في نظام التشغيل googles الجديد Fuchsia OS أمر محير بالنسبة لي.

لست متأكدًا من أن Dart مألوفة أكثر إذا كنت قادمًا من Java. لقد جئت من Java وليس لدي مشاكل مع Kotlin أو Swift ؛ في الأساس ، يتم عكس إعلان النوع ، فلا شيء جديد حقًا كما تم استخدامه في باسكال وأكشن سكريبت.

نعم ، يمكنك إنشاء صفحات ويب باستخدام Dart ولكني لا أرى أهمية كبرى في ذلك. اللغة الأخرى الوحيدة التي تعمل بشكل جيد على الويب هي TypeScript ، حيث إنها تتكامل بشكل جيد مع أفضل 3 أطر عمل ويب شائعة.

ألقِ نظرة على الصيغة المختلفة المتاحة لـ React on the Web:
https://github.com/Workiva/over_react#fluent -style-المكون-الاستهلاك
كلا الإصدارين Dart ليس لهما فرصة ضد JSX !!!

تم تصميم TypeScript للترجمة إلى Javascript وهو أفضل من Dart لذلك. كما أنه يدعم JSX.
يتم ضغط دارت من جميع الجوانب. تتمتع Swift بزخم ، لذا من الحكمة دعمها على نظام Fuchsia OS مع طفلك.

كم من الوقت حتى النموذج الأولي؟ أنا أحب استخدامه!

لقد استخدمت React لفترة من الوقت ، وزادت JSX إنتاجيتي بمقدار عشرة أضعاف. هذه ليست قضية مثيرة للجدل: الفرق الأخرى قررت ، بشكل صحيح ، أن هذا سيكون أفضل ، فلماذا لا Flutter؟ (بلاغي: قرأت الخيط ... (راحة اليد))

أنا أعمل عليه في نهاية هذا الأسبوع ، لكني أواصل توسيع النطاق بأفكار جديدة ، لذا آمل أن أحصل على شيء ما في نهاية هذا الأسبوع.

بعض الأشياء الممتعة التي أجربها:
1) استخدام مساحة اسم xml على العلامات الفرعية بحيث يتم إدراجها باستخدام وسيطة Dart المسماة الصحيحة في الأصل.
2) نشر عامل التشغيل لتنظيم نمط مثل الخصائص بشكل أفضل بحيث يمكن تعريفها / تجميعها خارج xml في الخريطة ثم إحضارها ونشرها على علامة مثل عناصر React النموذجية.
3) styleCSS خاصية تولد أنماط رفرفة من CSS.

(1) & (2) عامة لذا فهي تعمل مع جميع أكواد Dart Flutter.
(3) متخصص لكل أداة Flutter Widget (حاوية ، نص ، إلخ) وأنا أفعل ذلك فقط في الوقت الحالي.

@ yuriy-manifold لمجرد أن شيئًا ما يعمل لصالح JS لا يعني أنها فكرة جيدة لـ Dart.
إذا كنت قد قرأت المناقشات أعلاه ، فسترى أنها في الواقع مثيرة للجدل.
لا أفهم لماذا تكون لغتان أفضل من لغة واحدة.

لمجرد أن شيئًا ما يعمل لصالح JS لا يعني أنها فكرة جيدة لـ Dart.

JSX هي فكرة رائعة لتطوير UI / UX في إطار تفاعلي بغض النظر عن اللغة. إذا كان لدي المزيد من وقت الفراغ ، فسأضع LSX وهو JSX للشعار ؛)

لا أفهم لماذا تكون لغتان أفضل من لغة واحدة.

يمكنك برمجة iOS باستخدام Objective-C و Swift (لغتان)
يمكنك برمجة Android باستخدام Java و Kotlin (لغتان)
...

لا يزال يتعين علي رؤية حجة لصالح JSX.
تحتوي المناقشات المذكورة أعلاه فقط على حجج مثل "إنه أفضل" ، أو "يزيد الإنتاجية" ، أو ما شابه ذلك ولكن لا توجد حجة لماذا أو كيف سيكون في الواقع أفضل من رمز Dart الخالص ، لا سيما بالنظر إلى تغييرات اللغة المخطط لها التي من شأنها تقليل الاختلاف بين JSX-like و
نقية رمز دارت أكثر من ذلك.

تضمين التغريدة

يمكنك برمجة iOS باستخدام Objective-C و Swift (لغتان)
يمكنك برمجة Android باستخدام Java و Kotlin (لغتان)

كيف يرتبط ذلك بمناقشة JSX؟ كيف يمكن اعتبار ذلك ميزة؟
يمكنك استخدام Swift على iOS لأنه خليفة Objectiv-C.
يمكنك استخدام Kotlin على Android لأنه يعتبر تحسينًا رائعًا لجافا.
يبدو أنك تجادل بأن JSX يجب أن يحل محل Dart. هذا ليس له معنى كبير بالنسبة لي.

تضمين التغريدة

كيف يرتبط ذلك بمناقشة JSX؟ كيف يمكن اعتبار ذلك ميزة؟
يمكنك استخدام Swift على iOS لأنه خليفة Objectiv-C.
يمكنك استخدام Kotlin على Android لأنه يعتبر تحسينًا رائعًا لجافا.
يبدو أنك تجادل بأن JSX يجب أن يحل محل Dart. هذا ليس له معنى كبير بالنسبة لي.

لقد قلت ذلك بالفعل (JSX هو تحسن بسيط على الطريقة الحالية) لكنك توصلت إلى نتيجة خاطئة (JSX لتحل محل Dart).

cbazza هذا أكثر من نفس الشيء

ما هي الميزة الفعلية على سهل دارت؟

"JSX هو تحسين بسيط" ليس مقنعًا بأي شكل من الأشكال وليس حجة.
إنه مجرد رأي شخصي دون (مرة أخرى) أي حجة لدعمه ،
مماثلة مع الحجج الأخرى الموالية لـ JSX أعلاه.

لا يمكنك أن تتوقع من أي شخص أن يفكر في اقتراحاتك إذا لم تكن على استعداد لتقديم حجج جيدة.

تؤدي إضافة شيء مثل JSX إلى Dart إلى قدر هائل من العمل والتعقيد في أدوات Flutter و IDE. تحتاج إلى تقديم الحجج المناسبة للآخرين حتى يفكروا في النظر إليها.

zoechi يبدو وكأنه سجل مكسور يطلب حججًا "جيدة" ، تم تقديم الكثير من قبل لكنك لم تفهمها ؛ وهو أمر جيد ، "لكل واحد على حدة".

تؤدي إضافة شيء مثل JSX إلى Dart إلى قدر هائل من العمل والتعقيد في أدوات Flutter و IDE. تحتاج إلى تقديم الحجج المناسبة للآخرين حتى يفكروا في النظر إليها.

ليس عمليًا جاهزًا تقريبًا ولم يستغرق الأمر وقتًا طويلاً مع الأخذ في الاعتبار أنني عملت عليه فقط في عطلات نهاية الأسبوع.

مرة أخرى ، يعد DSX مجرد تحسين بسيط يمكن للناس اختيار استخدامه أم لا ، لأنه لا يغير الطريقة الحالية ، إنه يوفر فقط بديلاً يكون الآخرون (مطورو React) على دراية به على الفور.

تضمين التغريدة

أعطيت الكثير

ليس حقيقيا. مجرد ادعاءات عامة يمكن أن تكون صحيحة أم لا.
لم يتم تقديم تفاصيل إضافية من شأنها أن تسمح للآخرين بالتحقق منها.

ليس حقًا ، عملي جاهز تقريبًا

باهر. ثم ليست هناك حاجة لفريق Flutter لفعل أي شيء ويمكن إغلاق المشكلة ؛ ص
هل يشمل ذلك دعم الإكمال التلقائي وعمليات التحقق من بناء الجملة في جميع IDEs التي يدعمها Flutter؟

باهر. ثم ليست هناك حاجة لفريق Flutter لفعل أي شيء ويمكن إغلاق المشكلة ؛ ص

؛)

هل يشمل ذلك دعم الإكمال التلقائي وعمليات التحقق من بناء الجملة في جميع IDEs التي يدعمها Flutter؟

تدعم معظم IDEs بالفعل XML و JSX لذلك لن يكون من الصعب عليهم إضافة الإضافات الثانوية الخاصة بي.

أتساءل عما إذا كان بناء جملة JSX قد يكون أكثر تقديرًا في الزاوية Dart؟ يبدو أن الأمر يتعلق بموقف "ما أنت معتاد عليه" وليس "أفضل". ربما يبدو بناء جملة JSX أكثر طبيعية لمطوري الويب.

أعلم أن البرمجة تبدو محرجة بالنسبة لي حتى مجرد استخدام كود مختلف يبرز الألوان ليوم واحد.

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

نعم ، سيكون الأشخاص الزاويون مرتاحين جدًا مع JSX ولكنهم كذلك سيكونون مطوري React Native وهذا لتطوير الأجهزة المحمولة. بالتأكيد لن يتم أخذ JSX بواسطة مطوري Flutter الحاليين ولكن هذا البديل الثاني سوف يجذب مطورين جدد إلى Flutter وهذا أمر مؤكد.

لقد أخطأت المقالة أعلاه ، حيث أن React بدون JSX غير موجود أساسًا وجميع أطر الويب التفاعلية تسمح بخلط الترميز والبرمجة على DSL.

حان الوقت ...
إنه لمن دواعي سروري أن أعلن عن محول DSX عبر الإنترنت
https://spark-heroku-dsx.herokuapp.com/index.html

عمل جيد مع transpiler cbazza
هناك شيء واحد أود أن أقوله أنه من الأسهل متابعته باستخدام JSX وهو علامات الإغلاق. الفكرة التي ذكرتها من قبل:
الفكرة: علامات الإغلاق المُنشأة تلقائيًا

في المثال الأول الخاص بك ، قد يعطي رمز flutter لـ (أزل الخيار الاختياري الجديد في Dart المستقبلي):

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 أقدر عملك من أجل المجتمع والأشخاص الذين يرغبون في إنشاء واجهات مستخدم بهذه الطريقة ، لكنني آمل حقًا ألا أجبر أبدًا على استخدام أي شيء كهذا في Flutter: - (((

باعتباري وافدًا جديدًا إلى Flutter ولكن على دراية كبيرة بـ React ، فقد برزت بعض الأشياء بالنسبة لي:

• نموذج إدارة الدولة هو نفسه إلى حد كبير
• شجرة العرض الافتراضية لعنصر واجهة المستخدم / المكون هي نفسها إلى حد كبير
• بمعرفة الحالة ونموذج المكون ، أشعر بشكل أساسي بأنني مستعد لكتابة تطبيق الآن ، باستثناء بعض تفاصيل Dart وواجهات برمجة تطبيقات النظام الأساسي ، ولكن ...
• لغة التصميم حجر عثرة. أنا أشير إلى https://flutter.io/web-analogs/ ولكن ليس من السهل معرفة ما هي الواردات المطلوبة لجعل الأشياء تعمل (EdgeInset؟ Color؟) أو متى يجب علي استخدام العناصر الأولية بدلاً من مثيلات الفصل الدراسي.
• محلل CSS من محول DSX الخاص بـcbazza مفيد حقًا لاكتشاف مكافئات التخطيط في نموذج Flutter.

بخصوص JSX:

• لا أعتقد أنه من الضروري ابتكار صيغة JSX جديدة لدعم أنماط Flutter. يمكن حل بعض مشكلات بناء الجملة في هذا الخيط باستخدام بعض أنماط React الأحدث مثل مكونات الترتيب الأعلى (الدوال التي تبني فئات المكونات) وتقديم الدعائم (المكونات التي تأخذ الوظائف كوسائط ؛ ترجع الدوال العناصر). على سبيل المثال ، يمكن ترجمة "الفتحات الفرعية" المسماة إلى شيء مثل هذا في 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 كانت أن Dart قد حدد الحجج.
• لماذا من المهم أن يعرف العنصر ما إذا كان لديه عدة أطفال أو طفل واحد؟ ربما يمكن لبناء "جزء" أن يزيل غموض واجهة برمجة التطبيقات هذه.

ما زلت أعتقد ، كوافد جديد إلى Flutter مع بعض الخبرة مع Angular و React وما إلى ذلك ، أن طريقة Dart العادية ، وأكثر من ذلك في Dart 2.0 ، أفضل من DSX هذا. إنها أكثر منطقية من بعض معلمات XML و CSS-ish. 🤷‍♂️

cbazza يحتوي مثالك التجريبي الثاني على 466 حرفًا مقارنة بـ 391 حرفًا (كلاهما بدون مسافات). بالنسبة لي يبدو منتفخًا بصريًا. يجب أن أتعلم دلالاتها ، وهو ما لا يتعين علي فعله باستخدام كود Dart العادي. وليس لدي أي فكرة عن كيفية استخدام نماذج البرمجة للأغراض العامة معها (إذا ، لكل منهم ، وما إلى ذلك).

إذا كان لدي الخيار ، فسألتزم بالنموذج الحالي.

كل شخص يعطي رأيه الشخصي فقط حول مقارنة كلا الصيغتين ، لكن علينا أن نتفق على حقيقة واحدة: إنها ميزة مثيرة للجدل للغاية. يوجد حب وكراهية ، لكن معظم الآراء تختلف حول فائدة JSX على Dart العادي.

على أي حال ، أعتقد أنه من غير المعقول تمامًا مطالبة فريق Flutter بالالتزام بدعم هذه الميزة قبل الإصدار 1.0. في حين أن الطريقة الحالية لبناء واجهة المستخدم قد لا تبدو رائعة للجميع - إلا أنها تعمل (وتعمل بشكل رائع في بعض الآراء).

إذا كان الناس يرغبون حقًا في بناء جملة شبيه بـ JSX الآن ، فإن الجهد الذي يدفعه المجتمع يبدو أنه السبيل للذهاب. وسيساعد ذلك في إثبات الحالة (أو لا) عندما يعتبرها فريق Flutter في ما بعد الإصدار 1.0.

أنا شخصياً أتفق بشدة مع الحجة التالية: ليس لأن JSX يعمل مع React (حيث تقوم بالفعل ببناء واجهة المستخدم باستخدام لغة الترميز) التي تعمل تلقائيًا مع Flutter.

تضمين التغريدة

النبأ العظيم هو أنه حتى لو تم تبني هذا من قبل فريق Flutter (والذي لا يعتمد على الأرجح على هذا الموضوع) لن يتم إجبار أحد على استخدامه. إنه خيار. لا أفهم سبب كونها مشحونة عاطفيًا لدرجة أن بعض الأشخاص قد يرغبون في كتابة تعليمات برمجية باستخدام صيغة لا تحبها ...

لا يهمني ما يحبه أو لا يحبه الآخرون. لكني أهتم بالميزات التي تساعدني في التقدم في طلبي. الموارد محدودة ، وأنا أفضل أن يكون لدي مشغل فيديو / دفق مناسب ، وجهات نظر أطفال أصلية ، وبعض تنسيقات الرسومات المتجهة.

على سبيل المثال ، يمكنك الآن في React and React Native كتابة تطبيقك بالكامل بدون JSX ، إنه مجرد خيار. هذا ما تبدو عليه React بدون JSX:
[...]
إنه أكثر فوضوية من إصدار JSX ، ولا يستخدمه أحد تقريبًا. من المحتمل أن هذا هو السبب في أن بعضًا منا ممن أتوا من React سيقدر إمكانية تجنب الاضطرار إلى القيام بذلك هذا النمط مرة أخرى.

ذلك لأن الويب لم يتم تصميمه لنظام كهذا. إذا كانت لديك لغة ترميز ثابتة مثل HTML وتريد "تفعيلها" ، فعليك ابتكار نظام يحتاج إلى العمل فوق ذلك. ما ستنتهي به هو بعض الإنشاءات المقيدة بالمنصة الأساسية.
(انظر: https://gbracha.blogspot.de/2014/09/a-domain-of-shadows.html)

من ناحية أخرى ، لا تحتوي Flutter على لغة ترميزية. لا يزال يتعين عليّ أن أرى سببًا لاستثمار الموارد في شيء أقل ديناميكية وأقل تعبيرًا.

أود معرفة ما إذا كان الأشخاص الذين يختلفون معها قد استخدموا React مع JSX وبدونها. أنا أشجع الجميع على تجربته ، لذا فإن هذه المناقشة ستكون أقل نظرية. بعد منحنى التعلم الضحل الأولي ، يصبح الأمر طبيعيًا جدًا (ولا يتعلق الأمر فقط بعدد الأحرف ، لأن علامات الإغلاق تسمح لك بقراءته بسهولة). لا يختلف الأمر عن تعلم أي شيء آخر جديد ، مثل Flutter ، والذي يعزز الإنتاجية على المدى الطويل. وأنا أوافق على أنه ليس للجميع ، ولهذا السبب سيكون اختياريًا.
أعتقد أنه من المهم أن نضع في اعتبارنا أن لدينا مصالح بعضنا البعض في الاعتبار - مما يجعل من السهل بناء الأشياء. أعتقد أن هذا المترجم سيساعد ، وسيكون من الأسهل اعتماده إذا كان لديه دعم رسمي.

أيضا ، شكرا لك cbazza :)

@ yuriy- مشعب

لا أعتقد أن أي شخص هنا يشك في أن JSX React هو تحسين على React الكلاسيكية. ولكن كما قلت ، تم إنشاء هذا الحل بسبب مشاكل تتعلق بخصائص النظام الأساسي الأساسي. لا يمتلك Flutter هذه الخصائص.

السؤال ليس "هل JSX مفيدة لـ React؟" السؤال هو "هل شيء مثل JSX مفيد لـ Flutter؟".

أعتقد أن الجواب هو لا.

هناك بعض الأشياء الأخرى التي يجب مراعاتها:

• يمكن أن يؤدي فصل مواصفات التخطيط عن كود التطبيق إلى جعل الكود أكثر إثباتًا للمستقبل ؛ على سبيل المثال ، لن يؤثر اقتراح بناء جملة Dart 2 هذا على طرق build إذا تم تحويلها وفقًا لبرنامج pragma قابل للترقية إلى رمز Dart من تنسيق محايد مثل JSX.
• يتيح تحديد التنسيق على أنه ترميز إمكانية فصل محرك العرض عن علاقة محرك عناصر واجهة المستخدم (ذات الحالة / الافتراضية) مع ReactDOM و React Native ، مما يجعل من السهل نقل عناصر واجهة المستخدم إلى الأنظمة الأساسية الجديدة.
• يؤدي تحديد تنسيق العلامات إلى تسهيل نقل التخطيطات الموجودة إلى Flutter ، على سبيل المثال من Sketch أو أدوات التصميم الأخرى

عمل جيد مع transpiler cbazza

Rockvole ، شكرا لك.

أقدر عملك من أجل المجتمع والأشخاص الذين يرغبون في إنشاء واجهات مستخدم بهذه الطريقة ، لكنني آمل حقًا ألا أجبر أبدًا على استخدام أي شيء كهذا في Flutter: - (((

zoechi ، شكرا لك. نعم ، إنه مجرد خيار آخر للأشخاص الذين يحبون استخدام JSX. إذا لم يكن هذا هو الشيء الرائع الخاص بك ، فاستمر في فعل ما تفعله ، فلن يتغير شيء هناك.

لا أعتقد أنه من الضروري ابتكار صيغة JSX جديدة لدعم أنماط Flutter.

alexkrolick ، نعم ، يمكنك استخدام أدوات العرض للمعلمات المسماة ولكن لا يمكنك فعل أي شيء بخصوص المعلمات الموضعية. كان المفتاح هو أنني لم أرغب في ترميز أي شيء في جهاز التحويل بحيث يعمل مع كل شيء.

ما زلت أعتقد ، كوافد جديد إلى Flutter مع بعض الخبرة مع Angular و React وما إلى ذلك ، أن طريقة Dart العادية ، وأكثر من ذلك في Dart 2.0 ، أفضل من DSX هذا. إنها أكثر منطقية من بعض معلمات XML و CSS-ish.

tenhobi ، استخدام رائع لذلك ، من الواضح أن DSX ليس للجميع.

إذا كان لدي الخيار ، فسألتزم بالنموذج الحالي.

@ b-Strauss ، هذا ليس بديلاً ، إنه خيار للأشخاص الذين يحبون JSX.

يوجد حب وكراهية ، لكن معظم الآراء تختلف حول فائدة JSX على Dart العادي.

lukaspili ، DSX مخصص للأشخاص الأصليين الذين يحبون JSX ، إذا كنت لا ترى فوائدها ، فلا تستخدمها. انها ليست DSX مقابل عادي دارت. إنه DSX مقابل JSX ، كلما اقترب الرقم 2 كلما كان ذلك أفضل.

النبأ العظيم هو أنه حتى لو تم تبني هذا من قبل فريق Flutter (والذي لا يعتمد على الأرجح على هذا الموضوع) لن يتم إجبار أحد على استخدامه. إنه خيار. لا أفهم سبب كونها مشحونة عاطفيًا لدرجة أن بعض الأشخاص قد يرغبون في كتابة تعليمات برمجية باستخدام صيغة لا تحبها ...

tehfailsafe شكرا لكم على الاستماع !!! لقد أصبت برأسك لماذا هذه المقاومة الهائلة لشيء من شأنه أن يجعل سكان React Native سعداء حقًا.

لا يهمني ما يحبه أو لا يحبه الآخرون. لكني أهتم بالميزات التي تساعدني في التقدم في طلبي. الموارد محدودة ، وأنا أفضل أن يكون لدي مشغل فيديو / دفق مناسب ، وجهات نظر أطفال أصلية ، وبعض تنسيقات الرسومات المتجهة.

@ b-Strauss ، بمجرد انتقال المعجبين الأصليين إلى Flutter ، سيكون هناك أطنان من الأشخاص للمساعدة في هذه الأشياء الأخرى المطلوبة. الأولوية 1 هي سرقة حصة الذهن من React Native وجعلها بسيطة قدر الإمكان لكي يتحرك الأشخاص الأصليون في React.

من ناحية أخرى ، لا تحتوي Flutter على لغة ترميزية. لا يزال يتعين عليّ أن أرى سببًا لاستثمار الموارد في شيء أقل ديناميكية وأقل تعبيرًا.

@ b-Strauss ، كيف تكون DSX "أقل ديناميكية" و "أقل تعبيراً" من Dart العادي؟ DSX هو دارت ألم تجرب المترجمة.

@ yuriy-manifold ، شكرا لك.

السؤال ليس "هل JSX مفيدة لـ React؟" السؤال هو "هل شيء مثل JSX مفيد لـ Flutter؟".

@ ب-ستروس ، بالطبع هو عليه. إنه ليس مفيدًا لمطوري Flutter الحاليين ولكنه مفيد جدًا للمصممين الذين يمكنهم إخراج CSS من أدواتهم ، وهو مفيد جدًا للأشخاص المخولين في النظام الأساسي React Native.

alexkrolick ، ملاحظات جيدة جدا.

تضمين التغريدة

هذا ليس بديلاً ، إنه خيار للأشخاص الذين يحبون JSX.

أفهم ذلك ... لن يؤثر علي بهذه الطريقة ، ولكن كما قلت من قبل ، هناك ميزات مفقودة الآن أحتاجها لإنشاء تطبيق رفرفة.

بمجرد أن ينتقل معجبو React Native إلى Flutter ، سيكون هناك أطنان من الأشخاص للمساعدة في هذه الأشياء الأخرى المطلوبة. الأولوية 1 هي سرقة حصة الذهن من React Native وجعلها بسيطة قدر الإمكان لكي يتحرك الأشخاص الأصليون في React.

لذا تقترح أن يقوم فريق الرفرفة بتعليق الميزات لشيء مشكوك فيه وقد يجذب أو لا يجذب جزءًا صغيرًا من مجموعة فرعية معينة من مطوري الويب؟

كيف يكون DSX "أقل ديناميكية" و "أقل تعبيرا" من Dart العادي؟ DSX هو دارت ألم تجرب المترجمة.

كل DSL هو بحكم التعريف أقل تعبيرًا من GPL. باستخدام DSX ، كيف يمكنني إخفاء عنصر واجهة مستخدم بشكل مشروط؟ كيف يمكنني التكرار عبر مجموعة وتعيين كل عنصر إلى عنصر واجهة مستخدم؟ كيف يمكنني استخدام مفتاح؟ عليك الآن أن تعدل بناء الجملة والدلالات للتركيبات التي لديك بالفعل في جي بي إل الخاص بك. فلماذا اخترع DSL في المقام الأول؟

خارج المسار هو عليه. إنه ليس مفيدًا لمطوري Flutter الحاليين ولكنه مفيد جدًا للمصممين الذين يمكنهم إخراج CSS من أدواتهم ، وهو مفيد جدًا للأشخاص المخولين في النظام الأساسي React Native.

لم يكن هذا هو السؤال ... ما هي المشاكل التي يمكن أن يحلها DSL ولا يمكنك حلها الآن؟ أنت تستمر في القول إنه أفضل ، لماذا هو أفضل؟ ليس لدي شك في أن DSX ستجذب بعض الأشخاص من JSX. أعرف أن الناس لا يحبون الأشياء المختلفة. ويبدو أن الألفة هي الحجة الوحيدة. فلماذا لا تستخدم CSS؟
لماذا لا تستخدم JavaScript؟ المزيد من الناس يعرفون كيفية استخدام هذه من Dart.

إذا صممت نظامك بناءً على شيء آخر لغرض وحيد هو أن تكون مألوفًا ، فأنت لا تبتكر حقًا.

لتوضيح @ b-Strauss ، فإن JSX تقوم بترجمة استدعاءات الوظائف (في استدعاءات React إلى createElement(ComponentClass) ، في Dart يجب أن تكون مُنشئات).

<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} />) }

• كيف يمكنني استخدام مفتاح؟
  بقدر ما أعرف في Dart كما في JS ، لا يمكنك استخدام مفتاح مضمن لأنه ليس تعبيرًا. إذا كنت خارج شجرة عناصر واجهة المستخدم ، يمكنك فقط استخدام مفتاح التبديل بشكل طبيعي.

لذا تقترح أن يقوم فريق الرفرفة بتعليق الميزات لشيء مشكوك فيه وقد يجذب أو لا يجذب جزءًا صغيرًا من مجموعة فرعية معينة من مطوري الويب؟

@ b-Strauss ، React Native ليس تطويرًا للويب ، إنه تطوير الأجهزة المحمولة عبر الأنظمة الأساسية وهو المنافس الرئيسي لـ Flutter ؛ ونعم ، JSX مثل مصدر الضوء ، وسوف يجذب الكثير من مطوري React Native. لقد طلبت هذه الميزة في أغسطس 2017 ، فالكثير من الحديث قليل جدًا عن العمل.

كل DSL هو بحكم التعريف أقل تعبيرًا من GPL. باستخدام DSX ، كيف يمكنني إخفاء عنصر واجهة مستخدم بشكل مشروط؟ كيف يمكنني التكرار عبر مجموعة وتعيين كل عنصر إلى عنصر واجهة مستخدم؟ كيف يمكنني استخدام مفتاح؟ عليك الآن أن تعدل بناء الجملة والدلالات للتركيبات التي لديك بالفعل في جي بي إل الخاص بك. فلماذا اخترع DSL في المقام الأول؟

أنت مخطئ تمامًا. النبأ السار هو أنني كنت مخطئًا مرة واحدة أيضًا. تحاول معظم (وليس كلها) DSL إعادة إنشاء تركيبات البرمجة في الترميز (وهذا ليس قويًا جدًا) ، JSX يجلب الترميز إلى البرمجة (مع الاستفادة الكاملة من اللغة المضيفة). الاختلاف تحويلي. الإجابة على جميع أسئلتك هي في الأساس استخدام الطريقة التي تقوم بها في Dart لأنها Dart. كل شيء بين '{}' هو رمز Dart باستثناء عامل الانتشار. إنها كلها تعبيرات dart ولكن يمكنك أيضًا استخدام وظائف مجهولة تقوم بإرجاع تعبير. كما ترى في ناقل التحويل علامة (\) هو مجرد عنصر جديد على عنصر واجهة المستخدم (نص جديد ()).

ما هي المشاكل التي يمكن أن يحلها DSL ولا يمكنك حلها الآن؟

لماذا تستخدم Dart عندما يمكنك استخدام الأصفار والآحاد ، أليس هذا كل ما هو ضروري لحل أي مشكلة في الحوسبة؟

أنت تستمر في القول إنه أفضل ، لماذا هو أفضل؟

لقد قدمت أسبابي من قبل ولن أكررها هنا. سيوافقني الأشخاص في JSX لكن "كل واحد منهم خاص به".

ليس لدي شك في أن DSX ستجذب بعض الأشخاص من JSX. أعرف أن الناس لا يحبون الأشياء المختلفة. ويبدو أن الألفة هي الحجة الوحيدة. فلماذا لا تستخدم CSS؟
لماذا لا تستخدم JavaScript؟ المزيد من الناس يعرفون كيفية استخدام هذه من Dart.

نعم ، يعد استخدام CSS أمرًا منطقيًا لتسهيل سير عمل المصمم والمطور. يدعم DSX ذلك. ميزة Dart على Javascript هي سرعة التنفيذ (الأداء).

إذا صممت نظامك بناءً على شيء آخر لغرض وحيد هو أن تكون مألوفًا ، فأنت لا تبتكر حقًا.

أنت مليء بالتحيزات الخاطئة التي من المرجح أن تمنعك من الوصول إلى إمكاناتك الكاملة. افتح عقلك ، جرب أشياء مختلفة.

alexkrolick ، شكرا لك على التفاصيل.

تضمين التغريدة

أنت مليء بالتحيزات الخاطئة التي من المرجح أن تمنعك من الوصول إلى إمكاناتك الكاملة. افتح عقلك ، جرب أشياء مختلفة.

سأقوم بإلغاء الاشتراك من هذه القضية الآن. من فضلك لا تذكرني هنا أو في أي مكان مرة أخرى ، تشك.

@ ب- ستروس

آسف يا رجل ، لم أقصد إيذاء مشاعرك ... كنت أحاول فقط إرشادك بلطف أثناء محاولتي إدارة إحباطاتي. كلنا بشر بعد كل شيء.

cbazza هل يمكنك أن ترسل لي بريدًا إلكترونيًا من فضلك؟ [email protected]

سبق أن قدمت هذا الاقتراح في الموضوع القديم ولكن ما زلت أعتقد أن هذه نقطة مهمة

IMHO إزالة الحاجة إلى استخدام new/const ساعد كثيرًا بالفعل. لدي صعوبات حقيقية في طريقة تنسيق dart لتنسيق الأشجار. لا يركز بشكل كافٍ على بنية الشجرة 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 قد عاد إلى المسج. مثل هذا السيناريو الذي كان يحتوي على عنصر واجهة مستخدم بسيط ، مع تنسيق الحشو والحدود والمركز له لاحقًا ، فإن العديد من رموز "}" تؤثر بشكل خطير على قابلية القراءة. ومع ذلك ، فهي عنصر واجهة مستخدم متكامل ، ولا أريد تقسيمها ، أي مفيد المحلول؟ على الرغم من ضعف لغتي الإنجليزية ، إلا أنني أحاول جاهدة التعبير عن أفكاري.

ربنا يساعدنا جميعا.

حسنًا ، هذا لن يذهب إلى أي مكان. لا يبدو أن أي شخص على وشك تبديل الجوانب في أي وقت قريب. نحن بالتأكيد بحاجة للتوصل إلى نوع من التسوية هنا. بالطبع "pro-DSX" مقابل "anti-DSX" لا يوجد بهما حل وسط مرضي عن بعد ، وهو إدراك محبط. هل يمكننا إعادة صياغة مواقفنا بحيث تكون أكثر توافقًا؟

naiveaiguy "هم" يمكن أن يكون لديهم DSX.
إذا لم ينفذها فريق Flutter ، يمكن أن تكون مبادرة مفتوحة المصدر.
هذا لا يعني أن نهج Pure-Dart كما هو الآن لن يعمل بعد الآن.
يمكن أن يتعايش كلا العالمين.

أتفق كثيرًا مع zoechi على أنهما يمكنهما التعايش ... هذا كل شيء وأعتقد أن هذا قد تم تسويته على الخيط القديم

تضمين التغريدة

إرضاء الجميع ، كونوا متحضرين وبناءين. نحن نناقش الأسلوب هنا ، وهو شيء ذاتي للغاية ، لذلك بغض النظر عن مدى إعجاب الجميع بما يفضلونه ، فمن غير المرجح أن يكون متفوقًا بطبيعته على تفضيلات أي شخص آخر. ضع قائمة بالمزايا والعيوب التي تراها في التركيبات الحالية والمقترحة ، لكن تذكر أنه لا يرى الجميع الأمر بنفس الطريقة ، وهذا جيد تمامًا.

برافو ، هذا كل شيء على الإطلاق.

في React ، يمكنك القيام بذلك بأربع طرق (وقد اكتشفت الطريقتين الأخريين اليوم !!!)

(1) يمكنك استخدام JSX (وهو ما أحبه)
https://reactjs.org/docs/introducing-jsx.html

(2) يمكنك استخدام الطريقة الأصلية (التي تشبه Flutter)
https://reactjs.org/docs/react-without-jsx.html

في نهاية الرابط أعلاه يذكرون مشروعين مجتمعين واعدين

(3) صيغة Hyperscript لترميز React.js
https://github.com/mlmorg/react-hyperscript

(4) النحو المقتضب للخط المفرط.
https://github.com/ohanhi/hyperscript-helpers

يعد وجود بدائل أمرًا جيدًا ، فقد ولت الأيام التي يمكنك فيها الحصول على سيارة فورد بأي لون تفضله طالما أنها سوداء :)

naiveaiguy لماذا هي مشكلة بالنسبة لك إذا كان هناك النهج الحالي و DSX؟
(هذا ما أستمده من تصويتك المعارض)

naiveaiguy "هم" يمكن أن يكون لديهم DSX.
إذا لم ينفذها فريق Flutter ، يمكن أن تكون مبادرة مفتوحة المصدر.
هذا لا يعني أن نهج Pure-Dart كما هو الآن لن يعمل بعد الآن.
يمكن أن يتعايش كلا العالمين.

أتفق تماما مع هذا. على الرغم من أنني أعتقد أنه يجب أن يكون حلاً قابلاً للتوصيل بدلاً من حل خارج الصندوق. يعد وجود معيار واحد يعمل ولكن القدرة على تخصيص التجربة بأشياء إضافية نموذجًا رائعًا. بهذه الطريقة يمكن لفريق Flutter الحفاظ على تركيزه على (ما أعتقد أنه) قضايا أكثر صلة ، يمكن للمجتمع تجربة أدوات / حلول مختلفة ومن ثم يمكننا إجراء مناقشة مع المزيد من البيانات والخبرة مع DSX أو أي بدائل أخرى للحالية الحالية ميتا.

وجود بدائل أمر جيد ، لقد ولت الأيام التي يمكنك فيها الحصول على سيارة فورد بأي لون تريده
أحب طالما أنه أسود :)

صحيح أن. ومع ذلك ، أعتقد أننا يمكن أن نتفق جميعًا على أننا لا نريد أن يصبح Dart / Flutter نظامًا بيئيًا آخر لـ JS / Web Frontend. لم يخرج Flutter من الإصدار التجريبي حتى الآن ونريده بالفعل أن يحتوي على معيارين لشيء ذاتي نوعًا ما.

في React ، يمكنك القيام بذلك بأربع طرق (وقد اكتشفت الطريقتين الأخريين اليوم !!!)

معظمهم مدفوعون بالمجتمع على الرغم من أن React تشير إليهم. جيد في منتصف الطريق. الآن ، اثنان منهم فقط مدعومين رسميًا: React.createElement وطريقة JSX ، وهي عبارة عن غلاف فوق الآخر. إن قيمة JSX مشهورة في هذا السياق ولكنها ليست بهذا الوضوح هنا. مع وضع ذلك في الاعتبار ، هل يمكننا أن نلتقي في منتصف الطريق من خلال وجود معيار رسمي واحد فقط وتشير المستندات إلى DSX متى كان ذلك مناسبًا؟

أعتقد أن فريق Flutter يجب أن يركز على الميزات الناقصة التي تمنع المطورين حقًا من إنشاء التطبيقات. لا يمكنني أن أوصي Flutter لمديري إذا لم نتمكن حتى من إضافة دعم الخرائط واستغرق تطوير ميزات الكاميرا أسبوعين.

ضع في اعتبارك أنني لن أغلق الباب على DSX إلى الأبد. ربما سيصبح الحل لبناء واجهة المستخدم ولكننا بحاجة إلى أن يقوم المجتمع بتجربته لاتخاذ هذا القرار.

zoechi شخصيًا لا أعتقد أن الفكرتين يمكن أن تتعايشا في الحالة الحالية لـ Flutter - لا ينبغي لنا حقًا تشجيع الانقسام من هذا النوع في وقت مبكر - ولكن في هذه المرحلة يبدو أنه الحل الوسط الوحيد.

تضمين التغريدة

أنا شخصياً لا أعتقد أنه يمكن للفكرتين أن تتعايشا في الحالة الحالية لـ Flutter - لا ينبغي لنا حقًا أن نشجع انقسامًا من هذا النوع في وقت مبكر

هل يمكن أن تكون أكثر تحديدًا بشأن سبب عدم تمكنهم من التعايش؟ (بالنظر إلى حقيقة أن DSX هو مجرد سكر تركيبي ؛ أو كما يقول emalamela "مجرد غلاف بالطريقة الحالية").

ولماذا من السابق لأوانه تقديم صيغة مختلفة لنفس الشيء بالضبط؟ أنا أسأل أساسًا لماذا هناك حاجة لتأجيل هذا ، ما الذي سيكون مختلفًا في المستقبل غير الموجود الآن؟

تضمين التغريدة

ومع ذلك ، أعتقد أننا يمكن أن نتفق جميعًا على أننا لا نريد أن يصبح Dart / Flutter نظامًا بيئيًا آخر لـ JS / Web Frontend.

أنا شخصياً أفضل عدم وضع أي قيود على ما يمكن أن يفعله الناس باستخدام Dart / Flutter. دع السوق / المجتمع يقرر. في الأساس ، إذا كان ما تم إنشاؤه لا يضيف قيمة ، فلن يستخدمه الناس ويموت. إذا أصبح شائعًا ، فذلك لأن المجتمع وجده مفيدًا وقيّمه. لا حاجة لاختيار الفائزين والخاسرين الآن.

الشيء الوحيد الذي يمنعني من تجربة Flutter هو حقيقة أنهم اختاروا عدم استخدام JSX.
IMHO JSX هو الخيار الأفضل للتعبير عن التسلسل الهرمي للمكونات

سمعت عن Flutter ، وأردت تجربتها ، وتوقفت فورًا عن التفكير في اللحظة التي رأيت فيها بناء الجملة ، وهو أمر مؤسف لأن هناك احتمالية أن هذه قطعة رائعة من التكنولوجيا. لبناء المنتجات.

لقد كنت أقوم بتطوير React / React Native منذ 2.5 عام ، والتضحية بفاعلية الإنتاجية التي يوفرها بناء جملة JSX عندما يتعلق الأمر بوصف واجهة المستخدم. سأفكر بجدية في قضاء الوقت في تعلم كل شيء عن Flutter ودراسة ما إذا كان الأمر يستحق التبديل عندما يتم دعم هذه الميزة خارج الصندوق.

لا أستطيع حتى أن أتخيل أن عدد المتبنين / المستخدمين / المطورين المحتملين يخسر Flutter بسبب ذلك ، وسوف يعاد النظر في الأشهر القادمة.

لا أستطيع حتى أن أتخيل أن عدد المتبنين / المستخدمين / المطورين المحتملين يخسر Flutter بسبب هذا ، وسوف يعاد النظر في الأشهر القادمة.

نعم ، وجد 44 Mio أنه من المهم بدرجة كافية للتأييد: د

نعم ، وجد 44 أنه مهم بما يكفي للتأييد: د

عند الترتيب حسب "التصويت الإيجابي" ، يتم إدراج طلب الميزة هذا في المرتبة السابعة في قائمة 3131 تذكرة مفتوحة.

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

cbazza ، لا أريد المجادلة ضد الميزة ولكن التعليقات مثل "إذا لم تفعل x فسيحدث y بشكل فظيع" هي مجرد تعليقات سخيفة.

لقد كنت أقوم بتطوير React / React Native منذ 2.5 عام ، والتضحية بفاعلية الإنتاجية التي يوفرها بناء جملة JSX عندما يتعلق الأمر بوصف واجهة المستخدم. سأفكر بجدية في قضاء الوقت في تعلم كل شيء عن Flutter ودراسة ما إذا كان الأمر يستحق التبديل عندما يتم دعم هذه الميزة خارج الصندوق.

تضمين التغريدة

نظرًا لأنك ذكرت الإنتاجية ، هل يمكنك تقديم مثال يُظهر بوضوح خسارة الإنتاجية الناتجة عن استخدام نمط Flutter بدلاً من JSX؟ يجب أن يُبنى المثال على أساس معرفة ما يكفي من JS و Dart لتكون قادرًا على ترميز المثال المذكور. أعتقد أنه إذا لم نأخذ ذلك في الحسبان ، فإننا نقارن أيضًا بين لغات البرمجة ، وهي ليست نفس المناقشة.

عند الترتيب حسب "التصويت الإيجابي" ، يتم إدراج طلب الميزة هذا في المرتبة السابعة في قائمة 3131 تذكرة مفتوحة.

تضمين التغريدة

وهو أيضًا الأكثر تصويتًا. إنه مثير للجدل تمامًا.

emalamela ،

وهو أيضًا الأكثر تصويتًا. إنه مثير للجدل تمامًا.

نظرًا لأن طلب الميزة هذا هو بديل للطريقة الحالية ولا يغير الطريقة الحالية ، فلا ينبغي أن يكون هناك أي خلاف على الإطلاق ؛ إذا كنت لا تحب JSX / DSX ، فاستمر في البرمجة كما تفعل اليوم.

ما يسمى الجدل موجود فقط لأن فريق Flutter يحتاج إلى القيام بعمل لتمكين المجتمع من القيام DSX بشكل صحيح. إذا كانت أدوات Flutter (مترجم ، محلل ، دعم ID ، إلخ) تدعم المعالجة المسبقة مع خرائط المصدر ، لكان 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 (تستغرق ثوانٍ) ، فالشروط الذهنية مرئي للغاية. ثانيًا ، سهولة الاستخدام. أود أن أزعم أنه يمكن استخدام JSX حتى بدون معرفة JS / Dart أو أي شيء عن واجهة برمجة التطبيقات الأساسية. هذا مناسب جدًا لشخص يتعلم البرمجة فقط ، أو لشخص ما هو جزء من فريقي ، يمكن للمصممين الآن ترميز واجهة المستخدم.

وصف التطبيق تعريفي تمامًا (وليس تعبيريًا فقط) ، عندما تعمل في مشروع كبير بمئات المكونات ، فإن طريقة وصف واجهة المستخدم هذه تحدث فرقًا كبيرًا (عليك تجربتها لتقديرها حقًا). لم يعجبني JSX عندما رأيته لأول مرة أيضًا ، فبمجرد استخدامه شعرت بالحق ، هكذا أريد أن أصف واجهة المستخدم من الآن فصاعدًا ، لقد كان اختراقًا واضحًا في الطريقة التي أتعامل بها مع بناء الواجهات.

لا يتعلق الأمر بكتابة سطور أقل من التعليمات البرمجية ، ولا يتعلق بامتلاك "سكر تركيبي" ، بل يتعلق ببناء أدوات للبشر. أنا أيضًا ضد الحجة القائلة بأنه يجب على الجميع استخدام JSX ، فهذا سخيف. أنت تستخدم الأداة التي تسمح لك بإنجاز عملك بشكل أسرع مع تشويش أقل ، في حالة الكثيرين (بما فيهم أنا) ، ستكون JSX (أو DSX في حالة Flutter) ، هذا كل شيء.

أنا قادم من React ، وفي المرة الأولى أجرب Flutter. من الغريب حقًا أن فريق flutter ليس لديه صيغة JSX ، أعني بجدية! في عالم JS ، ينتشر JSX بشكل كبير في كل بدائل React الآن! JSX صديقة للغاية للمطورين. يرجى تنفيذ هذا في أسرع وقت ممكن ، حتى تتمكن من المساعدة في تنمية المجتمع.

يمكنك إخبار JSX (أو DSX في هذه الحالة) بأنها مشكلة كبيرة بمجرد البحث عن مقدار التعليقات في هذه المشكلة.

JSX شيء لا تعرف أنك تحبه حتى تجربه. من الغريب في البداية أن يكون لديك ترميز في التعليمات البرمجية الخاصة بك ولكن بعد ذلك يصبح رائعًا.

يبدو أنه غير ضروري بالنسبة للرجال الذين يعرفون بالفعل الرفرفة / النبال ، فهمت. ولكن بالنسبة إلى شخص لم يسبق له أن لمس سهم (مثلي) ، فإن JSX أسهل طريقة للبدء بها وهذه هي النقطة. إذا كنتم تريدون أن يأتي المزيد من الأشخاص والبدء في بناء أشياء أكثر روعة ، فيجب أن تكون الأدوات أسهل.

وكما قالeseidelGoogle (https://youtu.be/h7HOt3Jb1Ts؟t=2m41s) للرجل الآخر "Flutter هي طريقة للكتابة إلى iOS و Android في قاعدة بيانات واحدة. نحاول أن نجعل ذلك سريعًا وسهلاً [. ..] يتحدث Flutter على طول الطريق وصولاً إلى الأجهزة [...] لدينا نهج متعدد الطبقات للغاية ، لذلك يمكنك أن تأخذ القليل أو بقدر ما تريد. [...] لدينا مجموعة من الاستثمار في الأدوات . "

تنفيذ JSX ، من فضلك جميلة.

أنا من محبي Dart وأيضًا مستخدم كبير للتفاعل. أجد دائمًا Dart terser وأكثر قابلية للصيانة من JSX. لذلك ، أعتقد أن JSX / DSX يمكن وربما ينبغي تنفيذها بطريقة مجتمعية.

rajaraodv لمجرد الترويج لـ Flutter كإطار نمط تفاعلي لا يعني أنها مجرد نكهة لـ ReactJS.
من معظم التعليقات لدي انطباع أن الناس لديهم مشاكل في قبول أن شيئًا جديدًا يختلف عما يعرفونه بالفعل.

يمكنك محاولة العمل مع Flutter لفترة من الوقت كما هو الحال حاليًا ثم تقديم الحجج المناسبة التي تجعلك تعتقد أن JSX / DSX سيكون أفضل من Dart العادي بطريقة واقعية بدلاً من مجرد "بسبب التفضيل الشخصي" أو "لأنه أفضل" .

zoechi ، أنت تفتقد شيئًا: الرفرفة مستوحاة من React ، وفقًا لوثيقة Flutter.
ربما هذه هي مشكلتي فقط. أشعر حقًا بأنني أجد صعوبة في قراءة رمز واجهة المستخدم ، حتى في صيغة Dart 2.

تم استلهام الرفرفة من React Native

لا أرى كيف يقول ذلك "كل شيء هو نفسه باستثناء اللغة تسمى Flutter بدلاً من JS".

أشعر حقًا أنني أجد صعوبة في قراءة رمز واجهة المستخدم

وأنت تدعي أن الحل الوحيد الذي يمكن تخيله لذلك هو DSX؟

هل اعتبرت أن Flutter ليس حتى 1.0 وأن دعم IDE يمكن أن يتحسن بمرور الوقت؟

لم يكن هناك سوى الخطوات الصغيرة الأولى التي تم اتخاذها مؤخرًا للحصول على دعم أفضل لـ Flutter IDE في محرر الكود مثل الإصلاحات السريعة ("التفاف xxx") وإغلاق الملصقات.

هناك احتمالات غير محدودة لتحسين تجربة المطور ومعظمها في هذه المناقشة مثل
"Flutter ليس مثاليًا بعد وبالتالي نحتاج إلى DSX"
عادة بدون حجج ملموسة حول كيف أو لماذا تحل DSX أو تحسن ذلك.

zoechi ،

يمكنك محاولة العمل مع Flutter لفترة من الوقت كما هو الحال حاليًا ثم تقديم الحجج المناسبة التي تجعلك تعتقد أن JSX / DSX سيكون أفضل من Dart العادي بطريقة واقعية بدلاً من مجرد "بسبب التفضيل الشخصي" أو "لأنه أفضل" .

مرة أخرى ، تعتبر لعبة Plain Dart أو DSX مجرد مسألة أسلوب ، فلا فائدة من مناقشة أيهما أفضل. إنه مجرد تفضيل شخصي وللناس أسبابهم لاختيار أحدهما أو الآخر.

ما حدث في عالم React هو أنه بمجرد استخدامك لـ JSX ، فإنك ببساطة لا تعود. كما ذكر آخرون أعلاه ، فأنت مدمن على JSX بعد استخدامه لفترة. تم اعتماد JSX من قبل آخرين خارج عالم React (Typescript ، Vue) وهو مناسب تمامًا لـ Flutter.

وأنت تدعي أن الحل الوحيد الذي يمكن تخيله لذلك هو DSX؟

ما يحتاجه المجتمع هو قدرات المعالجة المسبقة العامة مع دعم خريطة المصدر المضمنة في أدوات Dart (مترجم ، محلل ، IDE ، إلخ) بحيث يمكن للمجتمع DSX أو أي شيء أفضل أن يطوره المجتمع ودمجه بالكامل في Flutter (مصحح أخطاء ، تلقائي- كاملة ، إلخ).

هناك احتمالات غير محدودة لتحسين تجربة المطور ومعظمها في هذه المناقشة مثل
"Flutter ليس مثاليًا بعد وبالتالي نحتاج إلى DSX"
عادة بدون حجج ملموسة حول كيف أو لماذا تحل DSX أو تحسن ذلك.

بالتأكيد ، الشيء هو أن هذه التذكرة لا تتعلق بشيء عام "تحسين تجربة المطور". إنه محدد للغاية ويتعلق بالحصول على دعم JSX في Flutter. يريد المجتمع DSX كبديل لطريقة Dart البسيطة.

لا أستطيع أن أرى نفسي أستخدم هذا (لكنني على استعداد لتجربته). لا أعتقد أن هذه رصاصة فضية ، لكن هناك الكثير من الحماس الذي يستحق القيام به.

أعتقد أن Google يجب أن تزيل عقبات اللغة للسماح للمجتمع ببناء ما يريد.

لست على دراية بأي عقبات تمنع أي شخص خارج فرق Flutter / Dart في Google من كتابة شيء يشبه JSX لـ Dart / Flutter. أحب أن أرى البق على هؤلاء إذا كان شخص ما يحاول. (من الممكن أيضًا أن أكون قد فاتني التعليقات أعلاه ، لأنني أعترف أنني لم أقرأ كل كلمة من هذا الخطأ الطويل جدًا.) :)

شكرا! سعيد لرؤية هذا الحماس!

eseidelGoogle ،

كيف يمكن لـ Intellij و / أو VS Code (مع Dart-Code) تعيين نقاط التوقف والتنقل عبر التعليمات البرمجية من ملف .dsx؟ (أعني أن هذا ليس ملف dart.). ماذا عن وظيفة الإكمال التلقائي من ملف .dsx (كما هو الحال مع ملف .dart)؟

لقد استثمرت الكثير في الأدوات ولكن الأدوات لا تدعم المعالجة المسبقة (مع خرائط المصدر) للغة جديدة (مثل DSX) تنتقل إلى Dart / Flutter بسلاسة.

يتوفر ناقل ولكن لا توجد طريقة سهلة لدمجها بالكامل:
https://spark-heroku-dsx.herokuapp.com/index.html

ملاحظة: هذه التذكرة ليست سوى نصف التعليقات !!!
https://github.com/flutter/flutter/issues/15922

cbazza هل هناك ريبو مع هذا المترجم في مكان ما؟ سيكون من الرائع مشاركة الكود وإشراك المجتمع في اختراقه ، حتى لو لم يكن مثاليًا.

jonahwilliams ، لم يتم إصدار كود مرسل DSX لأنه من السابق لأوانه القيام بذلك.
يمكنك ببساطة استخدام ملفين مكافئين مكتوبين بخط اليد (.dsx و. dart) لاختبار إمكانات المعالجة المسبقة مثل نقاط التوقف ، والتنقل ، والإكمال التلقائي ، وما إلى ذلك.

بمجرد أن تدعم الأدوات المعالجة المسبقة بنوع من خرائط المصدر ، يمكنني إضافة ذلك إلى المترجم وإلغاء الحظر. وهذا من شأنه أيضًا أن يمكّن الآخرين من تجربة رغبات قلوبهم.

لا أعمل على Flutter ، لكن يبدو من غير المعقول أن تطلب أدوات معينة لإفادة الآخرين ، ولكن بعد ذلك أرفض أيضًا إصدار أي كود مصدر مبكر أو أمثلة لما تريد أن تتكامل معه الأدوات.

لما يستحق الأمر ، لا أعرف أي لغة أو مجموعة أدوات توفر خطاطيف معالجة مسبقة من أي نوع - ربما لأنه ببساطة ليس سهلاً ، هناك الكثير من الحالات والافتراضات حول اللغة وبناء الجملة.

إذا أنشأت خرائط مصدر (https://pub.dartlang.org/packages/source_maps) ، أتخيل أن الحصول على بعض الدعم الأساسي على الأقل في IDE أمر تافه جدًا ، ومستقل عن Dart / Flutter. لكن مرة أخرى ، هذا كله تخمين دون معرفة ما تفعله أدواتك وكيف تتوقع أن تعمل.

matanlurey ، دعم المعالجة المسبقة عبر خرائط المصدر هو آلية عامة لا تعتمد على أي مترجم محدد. إنها وظيفة تهدف إلى دعم أي لغة يمكن تخيلها في المستقبل. يدعمه متصفح / مصحح الأخطاء Chrome بشكل جيد ويمكنني تصحيح أي لغة تنتقل إلى JS.

للاختبار ، يمكنك التوصل إلى أي نوع بسيط من الناقلين لتوضيح كيفية استخدام خرائط المصدر. على سبيل المثال ، اكتب ناقلًا تافهًا يقوم بإنشاء رمز Dart / Flutter مع سطر فارغ بين كل سطر في الملف الأصلي. (.d2 => .dart ، .d2 هو ملف Dart / Flutter ، ملف dart. سيحتوي على سطر فارغ بين كل سطر في الملف الأصلي).

نعم ، يمكنني العمل على إنشاء خريطة مصدر لملف اختبار.

يتردد Flutter حاليًا في محاولة إرضاء NativeScript و ReactNative و Android و Web والمطورين الآخرين الذين اعتادوا على تخطيطات XML مماثلة. لديهم أشياء أكثر أهمية للقيام بها ، لذلك دعونا نتفكك ونذهب للنوم.

تمنيت أن تقضي مؤيدة Amy لـ JSX Syntax بعض الأيام في العمل حقًا مع Flutter قبل مواصلة الرثاء. لقد جئت من نظام قائم على Xaml ولكن سرعان ما اعتدت عليه. فقط جربها بشكل حقيقي.

تضمين التغريدة
مرحبًا ، escamoteur. هل تعتقد أنني لم أمضِ الكثير من الوقت في تعلم الرفرفة؟
في flutter.io/tutorials/layout/ ، في نهاية قسم "أدوات التعبئة" ، لا يعمل الكود الذي قدمه البرنامج التعليمي.
لقد ذكرت المشكلة تحت كتلة مشكلة الرفرفة ، لكن لا أحد يريد أن يهتم بهذا الأمر.

• كود Dart: main.dart
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/main.dart

• Pubspec: pubspec.yaml
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/pubspec.yaml

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

JonathanSum هل هناك أي صلة من تعليقك على موضوع هذه القضية؟

تضمين التغريدة
قال escamoteur إنه يأمل أن يقضي مؤيد JSX Syntax فقط بعض الأيام في العمل مع Flutter قبل مواصلة الرثاء.
يوضح هذا التعليق أننا قضينا الكثير من الأيام في العمل مع Flutter ، وطلب JSX هو حقًا شعورنا من قلوبنا.

Group Dart: "بناء جملة Dart أفضل بكثير و JSX / DSX ليس جيدًا"
Group JSX / DSX: "بناء جملة JSX / DSX أفضل بكثير و Dart ليس جيدًا"

لا أستطيع أن أكون الشخص الوحيد الذي يرى هذا؟ كلا الجانبين يصحح نقاط لصالحه وضد موقفه. أعتقد أن ما ضاع هنا هو أن cbazza لم يكن لديه انتقادات فحسب ، بل قام أيضًا بشيء حيال ذلك. محاولة سد فجوة مطوري الويب / التفاعل / التفاعل الأصلي والرفرفة من أجل الاستفادة من Flutter.

و 2 سنتي ... بصفتي مطورًا مكدسًا كاملاً ، لدي خبرة مع مجموعة واسعة من اللغات والأساليب ... JSX هي إحدى الطرق المفضلة لكتابة الكود وآمل أن يكون هناك بناء جملة بديل لـ Darts .. وأنا لا أقول أن بناء الجملة الحالي سيء ، فقط لأنني أفضل أسلوب JSX.

يجب أن لا أتفق مع هذا الاقتباس من Group JSX / DSX

دارت ليست جيدة فقط

Dart هي لغة جيدة جدًا وقوية ، ولا أحد يفسد اللغة. المناقشة ليست حول Dart ، ولكن طبقة تركيبية فوقها يستخدمها معظم مطوري واجهة المستخدم بالفعل اليوم ، ونقترح أن يتضمن Flutter شيئًا من هذا القبيل.

• Android لديه تخطيطات XML.
• iOS به Storyboard XIB (XML)
• يحتوي GTK + على XML لـ Pango وما إلى ذلك.
• Qt لديها QML (مثل YAML)
• Xamarin لديه XAML

تحتوي معظم هذه الأطر واللغات على لغات ترميز واجهة المستخدم التي تفصل طريقة العرض عن منطق وحدة التحكم. ثم تأتي React بمقاربة مختلفة (نقترحها هنا) وأعتقد أنه يجب أن نتفق على أن RN تطير الآن من حيث نمو المستخدم وشعبيته ، وقد أكون مخطئًا ، ولكن بشكل أساسي بسبب JSX.

...

هل هو حقًا اقتراح مجنون لدرجة أننا يجب أن نحصل على هذا النوع من التعليقات من فريق Flutter / المستخدمين؟

birkir وكلهم يجلبون مجموعة من المتاعب التي لا يمتلكها Flutter \ o /
ليست هناك حاجة للغة أخرى.
يمكنك أيضًا فصل العرض في Flutter ، حتى مع نفس اللغة.

birkir هذا الموضوع هو 100٪ حول Dart والنحو.

المناقشة ليست حول Dart ، ولكن طبقة تركيبية فوقها يستخدمها معظم مطوري واجهة المستخدم بالفعل اليوم ، ونقترح أن يتضمن Flutter شيئًا من هذا القبيل.

إذن لا يتعلق الأمر بـ Dart ... لكن Flutter يحتاج إلى استخدام شيء ما إلى جانب Dart للتخطيطات؟ يبدو أن قولك Dart ليس جيدًا بما يكفي بينما تدعي أيضًا أن هذا لا علاقة له بـ Dart؟

لا أعتقد أنه مهم في هذه المرحلة ، فقد رأى فريق Flutter هذه التعليقات (عند طلب نهج JSX / DSX) ويريدون الاستمرار في مسارهم الأصلي. أعتقد حقًا أنه يمكن التعامل معها بشكل أفضل ولكن لا يبدو أنهم يعارضون إنشاء المجتمع للحلول.

يسعدني أن هناك خيارًا آخر عبر الأنظمة الأساسية ... هل ستكون Apple هي التالية التي تقدم شيئًا ما؟ وربما سيرون ما الذي يعجب الكثير منا بشأن التفاعل / التفاعل الأصلي؟ IDK إذا كان لديهم أي شيء يطبخ.

لقد رأى فريق Flutter هذه التعليقات (عند طلب نهج JSX / DSX) وهم

لا يزال هذا الخطأ مفتوحًا لأننا لم نتوصل إلى معرفة ما نريد القيام به هنا. نحن ننظر بفارغ الصبر إلى التجارب (مثل تجارب cbazza) لنرى كيف يستخدمها الناس. نحن نخطط ، في مرحلة ما ، لتوفير وسيلة ربط في نظام الإنشاء لأدوات التشفير مثل هذا ، على الرغم من أن هذا ليس شيئًا من المحتمل أن نقوم به في المستقبل القريب. على المدى الطويل ، نأمل في استخدام ما نتعلمه هنا للتأثير على تطور Dart كلغة. قد يعني هذا إضافة شيء مثل E4X / H4X / JSX / DSX إلى Dart نفسها. أو ربما نتعلم أنه لا أحد ينتهي به الأمر باستخدامه ، لذا لن نفعل شيئًا. أو ربما يحتاج الجميع إلى شيء مختلف ، لذا فإن خطافات codegen والحزم المخصصة مثل cbazza هي الحل. لا نعرف بعد.

jstansbe - تعتقد Apple أن النظام الأساسي المتقاطع يعني IPhone و IPad و Mac OS. من المرجح أن يضيفوا أبراجًا أعلى الحديقة المسورة بدلاً من بناء شيء عبر منصة :)

أعتقد أنه مما إذا كان من الممكن وضع مسافة بادئة وتنسيق عنصر واجهة المستخدم بطريقة أخرى سيكون أكثر شبهاً بـ jsx ويكون مناسبًا للمستخدمين الذين لديهم خبرة في xml و html (تقريبًا جميع مطوري android) ... تحقق من هذا الرمز في codelab

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
      ],
    ),
  );

تحقق من هذا dart to jsx code

<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

تحتوي سمات العنصر (عنصر واجهة المستخدم) على مسافة بادئة أكثر من عناصر واجهة المستخدم الجديدة ، لذا فإن هذا يوضح بشكل أكبر إمكانية فهم الشفرة والتحقق منها

سيكون رائعًا إذا كان بإمكاني الحصول على مسافة بادئة تلقائية لهذا التنسيق في الجوانب المختلفة ، والآن أفعل ذلك يدويًا ...

بعد قراءة جميع التعليقات هنا والمناقشة بشكل خاص مع أصدقائي (مطورو تطبيقات الأجهزة المحمولة الأصليون ، java / kotlin / target-c / swift guys) ، ملاحظتي:

يطلب الناس شيئين ،

• __إمكانية قراءة أفضل وكتابة أسهل__. التداخل العميق الممزوج ببعض أصوات بناء الجملة (الأقواس ، الفاصلة المنقوطة ، new ، child ، children ) مزعج في الطريقة الحالية للترميز.
• __نمط / تصميم منفصل عن الكود__. يعد الفصل المرئي مفيدًا للقراءة (التمييز بين النمط من التعليمات البرمجية الضرورية بنظرة واحدة) والفصل الحقيقي مفيد للأدوات (على سبيل المثال ، IDE مع محرر التخطيط).

هناك أيضًا مجموعتان رئيسيتان لهما آراء مختلفة ،

• تحسين البنية الحالية دون إدخال تعقيد آخر لحل المشكلة.
  كانت هناك بالفعل بعض التحسينات في هذا الاتجاه ، على سبيل المثال ، ميزة new و const في Dart 2.0 والميزة المقترحة virtual "closing tag" comments .
• تقديم لغات ترميز إضافية (مثل JSX أو XML مثل) لحل المشكلة.

لا يمكنك بسهولة استنتاج أيهما أفضل في الوقت الحاضر. لذلك دع المجتمع يجري تجاربه أولاً ثم يتخذ القرار النهائي (القبول أو الرفض) لاحقًا.

hooluupog تعليقات علامة الإغلاق الافتراضية تعمل بالفعل في IntelliJ، AS، VSCode منذ فترة

تضمين التغريدة

لا يزال هذا الخطأ مفتوحًا لأننا لم نتوصل إلى معرفة ما نريد القيام به هنا. نحن ننظر بفارغ الصبر إلى التجارب (مثل تجارب cbazza) لنرى كيف يستخدمها الناس.

لا يمكن للأشخاص استخدام تجاربي لأنه لا يمكن دمجها بسلاسة الآن في Flutter ؛ لذلك تظل تجربة خارجية / عبر الإنترنت حيث يمكن للناس فقط رؤية الإمكانات.

نحن نخطط ، في مرحلة ما ، لتوفير وسيلة ربط في نظام الإنشاء لأدوات التشفير مثل هذا ، على الرغم من أن هذا ليس شيئًا من المحتمل أن نقوم به في المستقبل القريب. على المدى الطويل ، نأمل في استخدام ما نتعلمه هنا للتأثير على تطور Dart كلغة.

هل يمكنك أن تكون أكثر تحديدًا في الوقت المناسب عندما نتوقع بعض الحركة على تغييرات نظام البناء لدعم المعالجة المسبقة؟ هل نتحدث عن شهر ، ربع ، ستة أشهر ، سنة ، سنتان ، عقد ، يوبيل ، إلخ؟

قد يعني هذا إضافة شيء مثل E4X / H4X / JSX / DSX إلى Dart نفسها.

يرجى قراءة الفقرات العلوية من مواصفات JSX لترى أنه ليست هناك حاجة لتغيير لغة Dart لأن JSX / DSX لا تحتوي على دلالات ، وليس من المفترض أن يتم تنفيذها بواسطة المحركات أو دمجها في اللغات. الغرض منه هو استخدامه في المعالج المسبق (ناقل الترددات). يمكن استخدام DSX مع Flutter & on Web لجعل React-Dart مثل React.js تمامًا ولكن مع لغة Dart.

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

أو ربما نتعلم أنه لا أحد ينتهي به الأمر باستخدامه ، لذا لن نفعل شيئًا.

كيف يمكن للناس استخدام شيء غير متاح لهم لاستخدامه في المقام الأول ثم يستنتجون أنه لا يلزم فعل أي شيء لأن الناس لا يستخدمونه؟ هذا يذكرني كثيرًا بانتحال شخصية شون سبايسر لميليسا مكارثي على SNL حول "حظر السفر" ... "التعميم باستخدام كلمة" :)

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

أو ربما يحتاج الجميع إلى شيء مختلف ، لذا فإن خطافات codegen والحزم المخصصة مثل cbazza هي الحل. لا نعرف بعد.

هناك حاجة ماسة إلى قدرات المعالجة المسبقة لتمكين التجريب. بدونها لا شيء يتحرك للأمام ولن تتعلم أي شيء جديد.

لا يمكن للناس استخدام تجاربي

أعتقد أنك تقلل من شأن مدى استعداد الناس لتجربة الأشياء ، حتى عندما لا تكون مصقولة تمامًا. على سبيل المثال ، يمكن لأي شخص بسهولة كتابة نص برمجي شل يلف flutter run لإجراء المعالجة المسبقة أولاً ، ثم الاتصال بـ flutter run . لدي برنامج نصي يلف إعادة التحميل السريع للقيام بشيء مشابه (أقوم بتشغيل المحلل أولاً ، وبعد ذلك فقط إذا تم تمريره ، أرسل إشارة إعادة التحميل الساخنة إلى البرنامج النصي flutter ).

هل يمكنك أن تكون أكثر تحديدًا في الوقت المناسب عندما نتوقع بعض الحركة على تغييرات نظام البناء

ليس حقًا (انظر على سبيل المثال https://en.wikipedia.org/wiki/Forward-looking_statement لمعرفة سبب صعوبة الإدلاء بمثل هذه العبارات) ، ولكن ربما لا يحدث ذلك في الأسابيع المقبلة.

ليست هناك حاجة لتغيير لغة Dart

هذا ممكن تمامًا ، حقًا. أنا أقول فقط أنه بناءً على هذه التجارب ، قد نصل إلى أي عدد من الاستنتاجات ، على طول الطريق من "عدم فعل أي شيء" إلى "إضافة ميزات جديدة جذرية إلى بناء جملة اللغة" وأي شيء بينهما. النقطة المهمة هي أننا لم نتخذ أي قرارات بعد ، ونحن منفتحون جدًا على تعلم ما يجب القيام به بناءً على كل هذه المناقشات والتجارب.

أضف JSX إلى الأعمال المتراكمة ودعها تنافس ، على غرار المصارع ، مع المتطلبات العاجلة الأخرى التي تزيد عن مليون زائد واحد؟

تمت كتابة React للويب وبالتالي فهي تحتاج إلى حل بسيط لكتابة HTML. لم تصبح JSX شائعة لأنها الحل الأفضل لكتابة واجهات المستخدم ، ولكن لأنها أفضل حل لكتابة HTML.

لا يحتوي Flutter على هذا القيد ، لذلك لا ينبغي أن نتصالح مع حل متواضع وموسع للأسباب الخاطئة.

إذا أردنا تقليل الإسهاب ، أفضل الاستلهام من Anko على سبيل المثال (https://github.com/Kotlin/anko/wiki/Anko-Layouts). هناك يمكنك تحديد متغيرات محلية جديدة في أي مكان واستخدام حلقات for-loops عادية لإنشاء قائمة بالأطفال ديناميكيًا ، مما يسهل متابعة الكود. أيضًا ، سيصبح LayoutBuilder أسهل على العين نظرًا لأن كل مستوى متداخل هو بالفعل وظيفة لامدا على أي حال (لا حاجة لتمرير أداة إنشاء لامدا إضافية). على أي حال ، هذا للإلهام فقط ولا أعتقد أنه يجب على Flutter نسخ 1: 1.

تمت كتابة React للويب وبالتالي فهي تحتاج إلى حل بسيط لكتابة HTML. لم تصبح JSX شائعة لأنها الحل الأفضل لكتابة واجهات المستخدم ، ولكن لأنها أفضل حل لكتابة HTML.

React Native ليس تطوير ويب ولا يستخدم HTML. اسأل مطوري React ذوي الخبرة (أو اقرأ هذا وخيط JSX الآخر بالكامل) وسترى أن JSX يعتبره العديد من مطوري React أفضل طريقة لكتابة واجهات المستخدم.

هناك يمكنك تحديد متغيرات محلية جديدة في أي مكان واستخدام حلقات for-loops عادية لإنشاء قائمة بالأطفال ديناميكيًا ، مما يسهل متابعة الكود.

يوضح هذا البيان بوضوح أنك لا تعرف JSX. يستخدم JSX (كما في DSX) جميع تركيبات البرمجة (للحلقات ، إلخ) من لغة الاستضافة (Javascript / Dart).

هذه التذكرة مهتمة فقط بالوظائف المشابهة لـ JSX ، بالنسبة للمناهج الأخرى (مثل Anko) ، يرجى إنشاء تذكرتك الخاصة للمناقشة هناك.

React Native ليس تطوير ويب ولا يستخدم HTML. اسأل مطوري React ذوي الخبرة (أو اقرأ هذا الموضوع وخيط JSX الآخر بالكامل) وسترى أن JSX يعتبره العديد من مطوري React أفضل طريقة لكتابة واجهات المستخدم.

ظهر React قبل وقت طويل من React Native. يعتمد التصميم الأصلي لـ JSX على عرض HTML ، وليس على واجهات المستخدم الأصلية. لم يتمكن أحد من إظهار حجة واحدة مقنعة لما تقوم به 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) جميع تركيبات البرمجة (للحلقات ، إلخ) من لغة الاستضافة (Javascript / Dart).

لا ، لا يمكنك استخدام عبارات if أو for-loops (أو switch أو أي عبارة أخرى) ضمن JSX:

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 وما إلى ذلك (والذي يمكن أن يكون أيضًا قبيحًا جدًا) أو نقل أجزاء من الكود الخاص بك إلى أعلى وظيفة التصيير أو في وظيفة مساعد منفصلة. إنه نفس الشيء مع Flutter ، بالطبع. لا يوجد لدى Anko هذا القيد ويجعل كتابة (بعض) كود واجهة المستخدم أكثر طبيعية.

أعتقد أنه في مناقشة حول تقديم JSX أمر صحيح وضروري تمامًا أن نسأل عما إذا كان هذا هو الحل الأفضل حقًا أو إذا كان بإمكاننا إيجاد شيء أفضل. وإلا فإننا سنهدر الموارد في المهام الخاطئة.

ظهر React قبل وقت طويل من React Native. يعتمد التصميم الأصلي لـ JSX على عرض HTML ، وليس على واجهات المستخدم الأصلية.

يتعلق التصميم الأصلي لـ JSX بطريقة مألوفة لإنشاء / معالجة هياكل الأشجار التي تظهر بشكل خاص عند القيام بأعمال واجهة المستخدم ؛ فكر في التسلسلات الهرمية للمكونات (https://facebook.github.io/jsx/) التي تظهر في تطوير الويب ، والتطوير المحلي ، وأي تطوير لواجهة المستخدم ، وما إلى ذلك.

لم يتمكن أحد من إظهار حجة واحدة مقنعة لما تقوم به JSX بشكل أفضل.

هذه هي النقطة ، نحن لا نتطلع إلى استبدال الطريقة الحالية ، بل نتطلع إلى إضافة طريقة بديلة مألوفة لمطوري React.

سيكون اقتراح Anko الخاص بك مألوفًا لمطوري Android Kotlin ، لذا انطلق واقترح مواصفات تعمل مع التسلسل الهرمي الحالي لـ Flutter في تذكرة منفصلة. بمجرد أن أرى (أو أحاول إصدارًا عبر الإنترنت من المواصفات الخاصة بك) ، سأكون قادرًا على معرفة ما إذا كان بإمكانه إنشاء / التعامل مع التسلسل الهرمي لعناصر Flutter الحالي.

لا ، لا يمكنك استخدام عبارات if أو for-loops (أو switch أو أي عبارة أخرى) ضمن JSX:

لا أنصحك بفعل هذا ولكن من الممكن: إنشاء وظيفة مجهولة واستدعائها.

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 ، من الصحيح والضروري تمامًا السؤال عما إذا كان هذا هو الحل الأفضل بالفعل.

لا يوجد شيء اسمه الحل الأفضل ، فالأمر كله يتعلق بالاختيار ، واختيار استخدام شيء مألوف يرسم مباشرة إلى أدوات Flutter ولا يضيف أي نفقات إضافية.

بالمناسبة ، جرب ما يلي على المترجمة عبر الإنترنت في:
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 ولكن لـ Dart & Flutter لذا فهو يحتوي على ميزات خاصة به موضحة في الرابط أعلاه.

عندما أرى هذا ، أحصل على ذكريات الماضي من تخطيطات xml من Android .. لا أعتقد أنه من الجيد تنفيذ ذلك. الآن بما أنك لست مضطرًا إلى كتابة new و const حتى يبدو الأمر أفضل.

charafau هل يمكنك مشاركة مثال / img / رابط لـ "تخطيطات xml من Android" الذي تشير إليه؟

لا ، wkornewald. إذا لم تصبح JSX شائعة لأنها الحل الأفضل لكتابة واجهات المستخدم ، ولكن لأنها أفضل حل لكتابة HTML ، فلماذا لا تزال React تستخدم JSX لإنشاء تطبيق جوال وتطبيق سطح مكتب؟ حتى تطبيق Github لسطح المكتب الخاص بك ، وتطبيق Walmart للجوّال عبر الأنظمة الأساسية ، وتطبيق Tesla ، و Skype تم إنشاؤها أيضًا بواسطة RN.

لا تضع React حلقة for في علامة JSX لأن مفهوم React يدور حول المكوِّن. الجزء العلوي هو المنطق والجزء السفلي هو JSX ، وهو دائمًا هكذا. يتم فصل كل شيء إلى العديد من المكونات وربطها معًا في مكون كبير.

في الواقع ، لا يستطيع معظم الأشخاص الموجودين هنا ضد JSX سوى تخمين JSX هو نوع من أنواع HTML أو XML أو حل أقل تفصيلاً.

تضمين التغريدة

معظم الناس هنا ضد JSX يمكنهم فقط تخمين JSX هو نوع من HTML

أعتقد أنه بالأحرى لأنه لم تكن هناك حجج أخرى لصالح JSX / DSX بخلاف التفضيل الشخصي. هذا جيد بالطبع كما تمت مناقشته أعلاه ، ولكن من فضلك لا تلمح إلى أن الناس ضد JSX لأنهم لا يفهمون ذلك ، عندما لا توجد قائمة بالحجج الواقعية الجيدة التي تظهر أن JSX أفضل من Dart العادي.

أعتقد أنه بالأحرى لأنه لم تكن هناك حجج أخرى لصالح JSX / DSX بخلاف التفضيل الشخصي.

ليس حقًا ، لقد تم إعطاء الكثير من قبل ، فقط اقرأ الموضوعين بالكامل. لقد ذكرت هذين الشيئين من قبل:
(1) لا مزيد من مواد "الأطفال" و "الأطفال"
(2) سهولة التعامل مع أدوات الطرف الثالث (التحليل والتحليل والتجديد)

باستخدام (2) يمكنك تحسين الترميز للقيام بأشياء غير ممكنة باستخدام Dart فقط ؛ على سبيل المثال عامل انتشار DSX أو إنشاء العديد من معلمات الوظيفة من مجموعة أصغر.

قدم آخرون الكثير من النقاط الجيدة لكنني لا أبحث عنها من أجلك ؛)

(1) كما ذكرنا ، يمكن أيضًا تغيير / تحسين مثل هذه الأشياء في Dart وكانت هناك مناقشات بالفعل. هذا لن يحدث قبل إصدار Dart 2.
مجرد افتراض أن DSX يسمح بكل أنواع الميزات الجديدة وأن Dart لا يمثل حجة عادلة في رأيي.
(2) أنا متأكد من أن هذا يمكن أن يتم بشكل جيد مع Dart وهناك بالطبع محلل لـ Dart.

قدم آخرون الكثير من النقاط الجيدة لكنني لا أبحث عنها من أجلك ؛)

ليست هناك حاجة للبحث عنهم من أجلي ، ولكن هذا يحدث كثيرًا وقد تتمكن من إقناع الآخرين بأن لديك بالفعل حججًا صحيحة.
لقد تابعت المناقشة ولا أتذكر الحجج الواقعية الجيدة والتي قد تكون هي نفسها بالنسبة للآخرين. إذا قمت بتلخيصها ، يمكنك فقط نشر رابط للأسئلة التالية.

كما تمت مناقشته من قبل ، يمكنني قبول التفضيل الشخصي كحجة صحيحة ، ولكن إذا كنت تدعي أن لديك الكثير من الحجج الواقعية أيضًا ، فأعتقد أنه من المناسب طلب توضيحها.

أنت تستمر في طلب "الحجج الصحيحة" وعندما يتم إعطاؤها لك رفضها على أنها "ستحصل على هذا في المستقبل" أو "هذه ليست حجة صالحة".

الحقيقة هي أن Dart / Flutter لديها أطفال / أطفال صاخبون في كل مكان عند إنشاء عنصر واجهة مستخدم ولا يوجد XML / DSX. إنها الآن حجة صالحة لاستخدام DSX لإزالة ضوضاء الأطفال / الأطفال. هل يمكنك فقط قبول ذلك كحجة صحيحة؟ (فقط لأنك تقول أن Dart سيحصل على ذلك في المستقبل ، فهذا لا يجعل الحجة غير صالحة).

ومن الحقائق أيضًا أن تحليل XML أسهل بكثير من تحليل لغة Dart بالكامل وكل لغة موجودة بها محلل XML ، في حين أن Dart فقط لديها محلل لغة Dart كامل وكامل. هل ترى أن هذه حجة صحيحة أيضًا؟

هناك الكثير من الحجج الصحيحة ، فهي غير صالحة لك فقط ولهذا السبب توقفت عن الجدل حولها. إذا كان الناس مهتمين بما قيل ، فما عليك سوى قراءة الموضوعين على JSX بالكامل. ليس لدي اهتمام بإقناعك باستخدام DSX ، فأنت سعيد باستخدام Dart البسيط ، فليكن ؛ انا لست.

وسيطات بناء جملة DSX اختياري:

1) على متن الطائرة واجتذاب المزيد من المطورين القادمين من React (الويب والأصلي)
2) تجربة أفضل لنقل مكونات React Native إلى أدوات Flutter
3) يدفع تناسق خصائص الأطفال / الأطفال في الأدوات
4) قراءة الكود (حجة برأي)
5) عرض المنطق linting منفصلة عن dart linting
6) يفتح عالمًا لأدوات بناء واجهة المستخدم
7) يفتح النظام البيئي للمعالجات المسبقة

DSX +1

DSX +1

كنت سأحب كتابة مجموعة من المؤيدين / السلبيات ، ولكن من خلال قراءة كل هذه التعليقات ، أشعر أنني سأكرر كل شيء مرارًا وتكرارًا.
توقف عن السذاجة والجهل ، لا أحد يقول أنك ستضطر إلى كتابة واجهات مستخدم باستخدام DSX ، إنه ببساطة خيار (بديل أفضل).
هناك سبب يجعلك تكتب JS في 101203103 بطرق مختلفة.

حسنًا ، هناك دائمًا خيار كتابة مكون إضافي للمحلل يوزع DSX ويحولها إلى استدعاءات دالة Dart عادية ، بحيث لا يضطر المترجم إلى القيام بأي عمل إضافي.

السؤال الحقيقي هو ما إذا كانت المكونات الإضافية للمحلل تنطبق في سياق المترجم.

إذا سألتني ، يجب أن يكون DSX مشتركًا فقط ، من الناحية المثالية من خلال نوع من المكونات الإضافية. أعتقد أنه من غير الضروري للغاية إضافته إلى اللغة نفسها ، حيث يتعين على مستخدمي Dart من جانب الخادم والويب أن يتكيفوا مع التغييرات ، وليس فقط مستخدمي Flutter. الغالبية العظمى من التعليمات البرمجية المكتوبة في Dart لا تحتاج حتى عن بعد إلى أي صيغة XML ، لذا فإن فرضها على الجميع يعد قرارًا سيئًا.

TLDR ؛ إذا كنت تريد DSX بهذا السوء ، فاكتب ملحق محلل وأحضره إلى Dart بنفسك. سوف يحبك الإنترنت ، وستحصل على الآلاف من نجوم Github ، وستشعر تمامًا كما لو كانت React. الفوز.

ملاحظة: سوف أسابقك للقيام بذلك

حسنًا ، هناك دائمًا خيار كتابة مكون إضافي للمحلل يوزع DSX ويحولها إلى استدعاءات دالة Dart عادية ، بحيث لا يضطر المترجم إلى القيام بأي عمل إضافي.

لا توجد حاليًا طريقة في لغة dart لتنفيذ هذا دون أي اختراقات (فكر في ظروف السباق والواردات المتكررة والأشياء). يجب دمج هذا على المستوى حيث سيعمل كل شيء كما هو متوقع ، وإعادة التحميل السريع ، والتحليل الثابت ، وما إلى ذلك.

إذا سألتني ، يجب أن يكون DSX مشتركًا فقط ، من الناحية المثالية من خلال نوع من المكونات الإضافية. أعتقد أنه من غير الضروري للغاية إضافته إلى اللغة نفسها ، حيث يتعين على مستخدمي Dart من جانب الخادم والويب أن يتكيفوا مع التغييرات ، وليس فقط مستخدمي Flutter. الغالبية العظمى من التعليمات البرمجية المكتوبة في Dart لا تحتاج حتى عن بعد إلى أي صيغة XML ، لذا فإن فرضها على الجميع يعد قرارًا سيئًا.

إذا قرأت الموضوع ، فهذه هي الفكرة منذ اليوم الأول. نريد فقط الدعم من الرفرفة / السهام لعمل ناقل.

TLDR ؛ إذا كنت تريد DSX بهذا السوء ، فاكتب ملحق محلل وأحضره إلى Dart بنفسك. سوف يحبك الإنترنت ، وستحصل على الآلاف من نجوم Github ، وستشعر تمامًا كما لو كانت React. الفوز.

اقرأ الموضوع ، لقد تم تنفيذ هذا بالفعل بواسطة cbazza (لن يقوم البرنامج المساعد للمحلل بقصه)

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

ملاحظة: سوف أسابقك للقيام بذلك

باهر! مجرد مجرد نظرية لكيفية عمل هذا سيكون من المثير للاهتمام رؤيته.

SGTM. أعتقد أننا جميعًا ننتظر نوعًا من دعم المعالجة المسبقة ، إذن.

أنا أفضل بناء جملة منشئ من تمرير المعلمات من خلال المنشئ

<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();

DSX +1

أحصل على الحجج الخاصة بـ JSX ، لكن أعتقد أن هناك العديد من الأشخاص (من ضمنهم أنفسهم) الذين يكرهون فكرة تشويش XML في لغة برمجة. إنه شعور خاطئ (لكنني أتفهم تمامًا أن الآخرين لا يشعرون بنفس الطريقة).

نظرًا لأنه يكاد يكون من المستحيل إزالة الميزات بمجرد تنفيذها ، فإنني أقترح مبدأ الحذر المسبق. دعونا نرى كيف تعمل بعض ميزات بناء جملة Dart 2 الأحدث قبل الالتزام بتغيير جوهري في طريقة إنشاء تطبيقات Flutter.

تضمين التغريدة
استطيع ان افهمك. اعتدت أن أكون ضد JSX وأمزج js مع xml / html .... ثم جربتها. بعد بضعة أشهر قضيتها في رد الفعل ، وقعت في حب JSX. ميزتان قاتلة هما:

1. لا يوجد بناء الجملة والمرافق الجديدة
2. لا مزيد من تمرير المتغيرات والوظائف وما إلى ذلك.

wstrange ،

نظرًا لأنه يكاد يكون من المستحيل إزالة الميزات بمجرد تنفيذها ،

هذا ليس معطى ، من كان يظن أن Google ستزيل MathML من Chrome؟

دعونا نرى كيف تعمل بعض ميزات بناء جملة Dart 2 الأحدث قبل الالتزام بتغيير جوهري في طريقة إنشاء تطبيقات Flutter.

إنه ليس تغييرًا للطريقة التي يتم بها إنشاء تطبيقات Flutter على الإطلاق ، إنها مجرد طريقة بديلة لا تغير الطريقة الحالية ، والأهم من ذلك أنها مجرد صيغة مختلفة لمكتبة الفصل. يقوم ناقل الشفرات البسيط برسم الخرائط دون الحاجة إلى أي معلومات من فئات Flutter ، لذا فهو يعمل بشكل جيد مع كود أي شخص ، وكذلك Flutter الآن وفي المستقبل.

@ بيسونوف ،

نعم ، أنت لا تعرف React حتى تقضي بضعة أشهر في العمل معها ثم تدرك مدى روعة المكتبة في التعامل مع التسلسلات الهرمية للمكونات.

cbazza يمكنني أن أقول نفس الشيء بالضبط عن Flutter. اقضِ بضعة أسابيع في استخدامه ولن تفوتك JSX.

رد الفعل يخبرنا كل شيء.

كما هو الحال الآن ، +1 ضعف مرات -1 تقريبًا

esamoteur ،
نعم ، تصريح عادل للغاية لكنني قضيت الكثير من الوقت مع Flutter ويمكنني بالتأكيد رؤية القيمة التي ستضيفها DSX إليها. كما لاحظ leedstyh ، يقود عشاق DSX السباق بنسبة 2 إلى 1 تقريبًا وهو أمر مذهل نظرًا لأن الأشخاص في هذا المنتدى هم أشخاص Flutter.

عندي سؤال:

عند استخدام صيغة DSX ، نفترض ضمنيًا أن الطفل / الأطفال المتداخل من النوع Widget. ماذا لو أردنا أن نذكر صراحةً أننا نريد أن يكون الطفل / الأطفال المتداخل نوعًا فرعيًا محددًا من الأداة؟

على سبيل المثال ، عندما أريد أن لا يقبل الأطفال من عنصر واجهة المستخدم المخصص الخاص بي سوى قائمة الحاوية ، يمكنني وضع تعليقات توضيحية على الأطفال بـ List<Container> وسيعطي IDE خطأ بمجرد وضع أي شيء مختلف عن Container. كما أعلم أنه لا توجد طريقة لفرض النوع الآمن مثل هذا عند استخدام dsx. ربما يكون لدينا بعض الأخطاء عند تجميع التطبيق ، لكنني أعتقد أن الخطأ الذي يظهر عندما أكتب لا يزال يمثل تجربة أفضل.

أعتقد أننا يجب أن نمنح الجميع بعض الوقت للتجربة والتعرف على طريقة الرفرفة لإعلان واجهة المستخدم ، على الأقل بعد إصدار v1. ثم يمكننا إلقاء نظرة أفضل على هذه الميزة.

sandangel ،

صيد جيد جدا !!! أنا ألقي قبعتي الافتراضية لك. كان النموذج الأولي الخاص بي يحتوي على بعض الثغرات منذ البداية التي كنت على دراية بها وأنتظر فقط أن يجدها الناس ويتقدمون. كنت أتمنى فقط أن يهتم الناس بمناقشة التكنولوجيا بدلاً من القتال عليها.

الحل الذي يجب أن أقوم به لهذا هو توفير نوع المصفوفة كمعامل آخر في مساحة الاسم. نظرًا لأن مساحة الاسم تكبر ، يمكننا تعيين النموذج المختصر لـ "يكون" الأطفال "*".

في المثال 2 على https://spark-heroku-dsx.herokuapp.com/index.html ، إذا كانت الإجراءات عبارة عن مصفوفة من "Container" بدلاً من "Widget" الافتراضية ، فستبدو مثل البدائل التالية:

        <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 ، شكرا لك على ردك.

أنا أتساءل عن الحل الخاص بك. هل نسيء استخدام مساحة اسم xml كما هو موضح في مساحات أسماء w3shool-XML ؟

كما تنص على أن مساحة الاسم تستخدم بشكل أساسي لحل تعارض التسمية في مستند XML.

لذلك عندما يقرأ شخص ما XML أعلاه ، قد يعتقد أنك تعلن عن علامة حاوية تحت مساحة الاسم "الأطفال" لمساحة الاسم "إجراءات" ، فأنت لا تفرض على كل العناصر الفرعية المتداخلة أن تكون حاوية. إنه يربكني عندما قرأت لأول مرة بناء جملة الاقتراح الخاص بك دون قراءة التفسير أعلاه.

هل يمكننا الحصول على شيء أفضل؟

DSX ليس XML ، إنه يشبه XML لذا فهو لا يحتاج إلى اتباع دلالات XML ، نوعًا ما مثل لغة القالب الزاوي ؛) على أي حال ، أنا دائمًا منفتح على بدائل أو اقتراحات أفضل وأحب إجراء مناقشة هنا.

قادمة من React-native ، قمت أولاً بدعم JSX مثل التنفيذ ، ولم تعجبني الكائنات المتداخلة ، لكنني بدأت في الاستمتاع بـ OOP ورؤية كل شيء ككائن!

بالنسبة للأشخاص القادمين من React-native ، أوصي بشدة بهذا المكون الإضافي! https://marketplace.visualstudio.com/items؟itemName=CoenraadS.bracket-pair-colorizer

تضمين التغريدة
هل يمكنك توسيع نطاق خبرتك باستخدام التفاعل الأصلي (JSX) و Flutter (OOP) ورحلتك من واحدة إلى أخرى؟

cbazza أعتقد أن بناء جملة القالب الزاوي يتبع دلالات xml وكما أدرك أنه لا توجد حالة استخدام تعارض بين بناء الجملة الزاوي ووثيقة xml.

في الكتابة المطبوعة ، لدينا دعم للمكون العام .
لذلك أعتقد أنه يمكننا الحصول على شيء مثل هذا:

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

ولكن مرة أخرى ، يتم استخدام المكون العام لنوع التحقق من إدخال الخاصية. لا أعرف ما إذا كان بناء الجملة أعلاه له معنى دلالي صحيح في حالة الاستخدام هذه.

أشعر حقًا أن فريق Flutter قد أنشأ واجهة برمجة التطبيقات الحالية خصيصًا للطريقة الجديدة لإعلان واجهة المستخدم التي يفترضون أنها أفضل من JSX وأي جهد نحاول ربط بناء جملة JSX بواجهة برمجة التطبيقات الحالية يجعله يبدو غير طبيعي / غير مريح للاستخدام.

رد الفعل يخبرنا كل شيء.

كما هو الحال الآن ، +1 ضعف ما يقرب من -1

هذا لا يعني أي شيء.

باستثناء أولئك الذين يشاهدون جميع مشكلات Flutter ، يضاعفون المشكلة التي تهبط في هذه المشكلة لأنهم معتادون بالفعل على JSX (وهم يبحثون عنها بوضوح). هذا يعني بالأحرى _ أن الأشخاص الذين يريدون تجربة شبيهة بـ JSX يضاعفون الأشخاص الذين يشاهدون جميع المشكلات التي صوتوا -1_. (جزء من الأشخاص الذين صوتوا +1 لم يجربوا الرفرفة حقًا)

sandangel ،

أعتقد أن بناء جملة القالب الزاوي يتبع دلالات xml وكما أدرك أنه لا توجد حالة استخدام تعارض بين بناء الجملة الزاوي ووثيقة xml.

بالتأكيد ولكن JSX لا تستخدم مساحة الاسم لذا فهي ليست ميزة XML ذات أهمية.

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

نظرًا لأنك قمت بتقسيم "الأطفال" إلى علامة خاصة بها ، فهذا يذكرني نوعًا ما بعلامة التجزئة الجديدة لـ React. إنه توازن بين الإسهاب والإيجاز وهذا أمر مؤكد.

أشعر حقًا أن فريق Flutter قد أنشأ واجهة برمجة التطبيقات الحالية خصيصًا للطريقة الجديدة لإعلان واجهة المستخدم التي يفترضون أنها أفضل من JSX وأي جهد نحاول ربط بناء جملة JSX بواجهة برمجة التطبيقات الحالية يجعله يبدو غير طبيعي / غير مريح للاستخدام.

لا يوجد شيء جديد في الطريقة التي يعلن بها Flutter عن واجهة المستخدم في الكود ، فربما يكون استخدام DSX غير طبيعي / غير مريح لك ولكن لمطوري JSX ليس كذلك. يعد JSX / DSX مثاليًا لـ Flutter ، فهو يناسب القفازات وإذا كنت لا تحب القفازات ، فاستخدمها ؛)

@ a14n ،

هذا لا يعني أي شيء.

من المؤكد أنه يفعل !!! يمكنك أن تجادل مع "الشعور" ، "التفكير" ، "المشتبه به" ، "إيمهو" ، "الرأي" ولكن هذه بيانات ، نقطة بيانات محددة. إذا كانت البيانات غير مجدية فلا يجب جمعها. أعتقد أن البيانات غير مجدية لأنها لا ترسم صورتك.

أعنيcbazza عندما نحاول الإجابة على السؤال الذي طرحته أعلاه حول فرض نوع فرعي من عنصر واجهة المستخدم للأطفال / الأطفال ، أشعر أن Dart code تقوم بعمل أفضل من JSX.

DSX ليس XML ، إنه يشبه XML لذلك لا يحتاج إلى اتباع دلالات XML

بالتأكيد ولكن JSX لا تستخدم مساحة الاسم لذا فهي ليست ميزة XML ذات أهمية.

لست متأكدًا ولكني قرأت بعض تعليقاتك أعلاه وأعتقد أنك ذكرت عقدة JSX / XML بالتبادل. على أي حال ، أنا شخصياً أعتقد أن استخدام مساحة الاسم كحل ليس مثاليًا.

قارن فقط

<actions:children:Container>

</actions:children:Container>

و

actions: <Container>[]

بناء الجملة.

sandangel ،

نعم ، صيغة وضع العلامات أكثر تفصيلاً لهذه الحالة ولهذا السبب ذكرت أن الصيغة القصيرة للأطفال هي "*". على أي حال ، هذه الحالة هي الاستثناء وليس القاعدة. في معظم الأوقات لا تحتاج حتى إلى تحديد "الأطفال" ، ناهيك عن "الحاوية" ؛ ولكن يجب أن تكون الوظيفة موجودة لتغطية جميع حالات الاستخدام الممكنة.

@ a14n التصويت هو تصويت ، فهذا يعني بالتأكيد.

أنا أحترم مشاعرك ، ربما هذا صحيح. ولكن حتى مع وجود نسبة عكسية (1 إلى 2) ، فإن هذا لا يزال يعني 33٪ من المستخدمين. هل يمكنك القول أن 33٪ حصة صغيرة؟

الأشخاص الذين يرغبون في تجربة شبيهة بتجربة JSX

نعم ، بعض الناس يشاهدون. وهذا يعني أيضًا أن عدم وجود تشبه JSX هو أحد الأسباب التي تمنع الناس من اختيار الرفرفة.

يهدف Flutter إلى المزيد من المطورين ، وليس فقط المطورين الذين يقرؤون جميع المشكلات.

تضمين التغريدة
أنا مبرمج علمي ذاتيًا ، ومثل معظم العصاميين ، بدأت باستخدام جافا سكريبت.
ثم بدأت في تعلم React و React-Native. أعتقد أنه في السنوات الأخيرة ، خاصة بعد ES6 ، تمت إضافة أسلوب OOP إلى Javascript.

لذا فإن الأشخاص مثلي ليسوا معتادين على أسلوب البرمجة OOP. على الرغم من أن React الأصلي Component عبارة عن فئات مثل Widgets في Flutter.

نوع JSX يخفي صورة OOP النقية. في الأساس ، يخفي ما يحدث تحت الغطاء. ملاحظة: تم تصميم React لمطوري الويب ، ويستخدم مطورو الويب في بناء جملة html. لهذا السبب تحظى JSX بشعبية كبيرة بين مطوري الويب.

أنا شخصياً أعتقد أن OOP النقي أكثر منطقية للمشاريع الكبيرة.

clarktank ،

عند مناقشة لغات الكمبيوتر ، يجب أن تكون على دراية بما يلي:
(1) النحو - الحروف والكلمات التي تتكون منها اللغة
(2) دلالات - معنى تلك الشخصيات والكلمات

على سبيل المثال ، تبدو استدعاءات الوظائف في العديد من اللغات كما يلي (على سبيل المثال ، تحتوي على النحو التالي):

a = someFunction(param1, param2)

تخيل الآن أن لغة أخرى قررت استخدام الأقواس المربعة بدلاً من الأقواس المستديرة لاستدعاءات الوظائف ؛ سيبدو كما يلي:

a = someFunction[param1, param2]

الشيء هنا هو أن بناء الجملة مختلف ولكن الدلالات هي نفسها. أعني أن كليهما يقومان أساسًا باستدعاءات وظيفية ولكن بصيغة مختلفة.

نوع JSX يخفي صورة OOP النقية. في الأساس ، يخفي ما يحدث تحت الغطاء.

ليس صحيحا على الإطلاق. JSX / DSX هي مجرد صيغة مختلفة لنفس الشيء بالضبط (الدلالات هي نفسها). في حالة JSX ، تقوم علامات XML فقط بإنشاء مكونات React (تمامًا كما يمكنك القيام بذلك في Pure Javascript). في حالة DSX ، تقوم علامات XML فقط بإنشاء Flutter Widgets (تمامًا كما يمكنك القيام بذلك في Pure Dart). التركيب اللغوي مختلف ولكنه يولد نفس الشيء تمامًا لذا فهو متطابق تحت الغطاء.

ملاحظة: تم تصميم React لمطوري الويب ، ويستخدم مطورو الويب في بناء جملة html. لهذا السبب تحظى JSX بشعبية كبيرة بين مطوري الويب.

تحظى JSX بشعبية لأنها طريقة رائعة لإدارة التسلسلات الهرمية لشجرة المكونات ، سواء للويب أو للجوال أو أي تطوير لواجهة المستخدم. لاحظ في الكود أدناه أنك لا تعرف ما إذا كان مكون القائمة المنسدلة للويب أو للجوال على سبيل المثال.

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);

أنا شخصياً أعتقد أن OOP النقي أكثر منطقية للمشاريع الكبيرة.

كيف هذا؟ (بالنظر إلى أن استخدام JSX / DSX أو Pure Javascript / Dart يولد نفس الشيء تمامًا تحت الغطاء).

تضمين التغريدة

لقد استخدمت التفاعل الأصلي لمدة عام تقريبًا ولم يكن لدي أي فكرة عن أن عناصر JSX هي كائنات يتم إنشاء مثيل لها ، حتى بدأت باستخدام Flutter / Dart. من وجهة نظري ، فإنه يخفي صورة OOP ، على الرغم من أنه كما قلت ، فإنه يفعل نفس الشيء من الناحية المعنوية تحت الغطاء!

في التطبيقات الكبيرة ، يمكن أيضًا أن تصبح JSX قبيحة مثل الكائنات المتداخلة بشدة. لذا من الناحية التركيبية ، أفضل أن أبقى متسقًا بدلاً من تقديم نمط آخر قد يكون محيرًا.

clarktank ،

في التطبيقات الكبيرة ، يمكن أيضًا أن تصبح JSX قبيحة مثل الكائنات المتداخلة بشدة. لذا من الناحية التركيبية ، أفضل أن أبقى متسقًا بدلاً من تقديم نمط آخر قد يكون محيرًا.

بالنسبة لي ، فإن مظهره مختلفًا عن بقية الكود هو في الواقع فائدة.

(أعتذر مقدمًا عن جدار النص.)

كشخص لم يستخدم إما React-Native أو Flutter لفترة كافية لأعتبر نفسي مصدرًا نهائيًا سواء كان Dart أو JSX / DSX "أفضل" ، كان موضوع هذه المشكلة رائعًا إلى حد ما للقراءة. هناك بعض الأشياء التي أود أن أضع 0.02 دولار عليها.

في البداية ، أجد نفسي أتفق مع العديد من الأشخاص حول طبيعة ماهية JSX في الواقع وكيف تفيد المطورين. أولاً وقبل كل شيء ، تم تصميم JSX كشكل من أشكال "HTML الديناميكي" الذي يمكن تضمينه في كود Javascript الموجود. لا غنى عنه لمنصات الويب المستندة إلى JS مثل React من حيث أنه يمكّن مطوري الويب من التفاعل بشكل نظيف وفعال مع DOM دون الحاجة إلى المصارعة مع الطريقة الأصلية المروعة (أو طريقة jQuery الوحيدة الأفضل قليلاً). أيضًا ، بحكم طبيعتها ، تشجع JSX تطوير واجهة المستخدم التي يمكن فصلها بسهولة عن البيانات الأساسية ، مما يعزز بنية مشروع جيدة التنظيم. في تلك البيئة ، تعد JSX أداة لتمكين إنتاجية أكبر ، وأشعر أنه سيكون من المستحيل عمليًا مناقشة ذلك.

إن كيفية ارتباط هذه الفقرة بـ React-Native هي أنها ، على الرغم من كونها منصة تطوير للأجهزة المحمولة ، إلا أنها تنحدر مباشرةً من React. على هذا النحو ، لا تزال جميع التركيبات والنماذج تقريبًا يتم إنشاؤها في الأصل مع وضع تطوير الويب في الاعتبار. هذا عن طريق التصميم - تتمثل ميزة RN بأكملها في أنه يمكنك "إنشاء تطبيقات جوال عبر الأنظمة الأساسية باستخدام React" ، لذلك من المفترض أن تشعر وكأنها تطوير ويب عند استخدامها. غالبًا ما تتم كتابة تطبيقات RN في Javascript ، لذا فإن تضمين JSX يعد أمرًا طبيعيًا. تساعد JSX في تطوير RN تقريبًا لجميع الأسباب نفسها التي تساعد في تطوير الويب. (أعتقد حقًا أن هذا سبب كبير ، في RN على الأقل ، يتم استخدام نهج JSX بشكل متكرر أكثر من النهج الأصلي. RN نفسها _ تشعر _ مثل نظام أساسي للويب ، لذا فإن النهج الأكثر طبيعية للويب هو حتمًا لتصبح المسيطرة.)

من ناحية أخرى ، لا يوجد لدى Flutter فلسفة تصميم من هذا القبيل. الغرض منه هو أن يكون حلاً أصليًا متعدد الأنظمة الأساسية ، وعلى الرغم من أنه ينص على أنه مستوحى من React-Native ، إلا أنه يشبه إلى حد كبير تطبيق سطح المكتب أو تطبيق الهاتف المحمول أكثر من تطبيق الويب. يتم تشغيله أيضًا باستخدام Dart وليس Javascript ، والذي يعتبر من وجهة نظر دمج شيء مثل JSX أحد الاعتبارات الرئيسية. على سبيل المثال ، في حين أن وظائف JS DOM يمكن أن تكون مطولة بشكل مرعب (بسبب تصميم الوظيفة ولغة JS نفسها) ، فإن Dart كلغة تسهل أكثر بكثير من كود تعريف واجهة المستخدم النظيفة بينما يقوم Flutter في معظم الأحيان بعمل جيد إبقاء مُنشئي واجهة المستخدم موجزة. بالنسبة إلى لغة أخرى ( كما أشار sandangel ) ، فإن Dart هي لغة مكتوبة بشكل ثابت ، لذا فإن طبيعة JSX المصممة للغة مكتوبة ديناميكيًا مثل JS ستواجه عقبات في الحالات التي تتطلب ، على سبيل المثال ، مُنشئ واجهة المستخدم القطعة من نوع معين ، الحل الوحيد الذي يضيف فقط إلى الإسهاب. على المستوى الشخصي ، يبدو الأمر وكأنه حل ، بمرور الوقت ، سيؤدي حتمًا إلى تضخم DSL وصعوبة صيانته لأنه يجب أن يراعي عددًا متزايدًا من حالات الاستخدام المتأصلة في نظام لم يكن من المفترض أن يكون يستعمل ل.

على هذا النحو ، لا أرى حقًا كيف ستفيد JSX / DSX في إنتاجية تطوير Flutter بما يتجاوز مجرد كونها مسألة تفضيل شخصي. كلا الصيغتين بشكل عام متكافئتان تقريبًا في الإسهاب ، وحيثما يفقد المرء الإسهاب في حالات معينة فإنه يعوض عنه في الوضوح (علامات إغلاق XML ، على سبيل المثال). يتلخص الأمر إلى حد كبير في ما إذا كان شخص ما قادمًا إلى Flutter من خلفية موجهة للويب (React / RN ، Angular ، إلخ) أو من خلفية أصلية (Java / Kotlin / Swift ، WPF / UWP ، وما إلى ذلك) التي ستحدد أي منها النهج الذي يفضلونه. حتى في هذا الموضوع وحده ، هناك الكثير من قصص المستخدمين التي تقول إنهم كانوا متشككين للغاية من JSX في البداية ولكن بعد استخدامه لبضعة أشهر غيروا رأيهم إلى "لا يمكنني الاستغناء عنه". (على الرغم من أن الجزء الساخر مني يريد أن أشير إلى أن نفس الشيء يمكن أن يحدث لهم جيدًا بالنسبة لنهج Dart الأصلي إذا أعطوه فرصة.)

بعد كل ما قيل ، لا يمكنني حقًا أن أرى نفسي أوافق على أن DSX يجب أن يتم دعمه رسميًا من قبل فريق Flutter كبديل لمنشئي واجهة المستخدم الأصليين. على الرغم من أنه جيد تمامًا كحل تابع لجهة خارجية (وجميع الدعائم إلى cbazza لتنفيذه فعليًا) ، إلا أنه لا يتناسب حقًا مع الطبيعة الأساسية لـ Flutter كمنصة غير قائمة على تكنولوجيا الويب. على هذا النحو ، المزيد من القوة لأي شخص يريد استخدام DSX في مشاريعه الخاصة ، لكنني أؤيد عقلية أن هناك الكثير من الأشياء الأخرى الأكثر أهمية التي يمكن لفريق Flutter وينبغي أن يقضي وقته فيها.

الآن مع قول ذلك ، على الرغم من أنني لا أتفق حقًا مع دعم DSX رسميًا ، أعتقد أنه يجب أن يكون هناك تنسيق رسمي لواجهة المستخدم من نوع ما. كما أشار birkir ، فإن كل منصة رئيسية رئيسية لواجهة المستخدم تقريبًا ، سواء أكانت سطح مكتب أم جوال ، لها تنسيق واجهة مستخدم بالإضافة إلى النهج المستند إلى الكود المباشر (تتم معالجة معظمها مسبقًا في النظام المستند إلى الشفرة على أي حال). لطالما كان وجود ملفات واجهة مستخدم منفصلة عن ملفات المنطق هو الطريقة الموصى بها لاحتضان نمط MVVM (والذي ، بالمناسبة ، هو أحد الأشياء التي لطالما فركتني بطريقة خاطئة حول JSX). ما أود قوله ، إذن ، هو أن Flutter لديها شيء مشابه - بدلاً من تنسيق UI DSL المضمّن ، يجب أن يكون لها تنسيق واجهة مستخدم منفصل يهدف إلى الانتقال إلى ملفه الخاص بعيدًا عن رمز Dart.

كجزء من هذا الخط من التفكير ، قمت بالفعل ببعض الأعمال في نهاية الأسبوع الماضي على طول تلك النهاية. إذا كان من الممكن السماح لي بالتردد للحظة ، فقد قمت بتطوير مشروع قمت بصياغة "FLUI" وهو محاولتي لإظهار الشكل الذي قد يبدو عليه هذا التنسيق . بدلاً من استخدام DSL موجود (أو نسخة معدلة) ، قمت بتطوير واحدة جديدة تمامًا تستلهم من YAML وحاولت قصارى جهدي للبقاء على مقربة من "الإحساس" بتخطيط نهج Flutter-constructor-approach. صحيح ، إنه تطبيق مبكر جدًا ، لذلك لا أتوقع حقًا عدم وجود عدد كبير من المشكلات ، لكنني قمت بتضمين مصدر البرنامج النصي للمعالج (مكتوب بلغة C # /. NET Standard) حتى يتمكن الأشخاص من اللعب معها إذا كانوا يريدون ذلك. :)

بصفتي مستخدمًا لـ React / RN ومستخدم Flutter ، فأنا أختلف بشدة مع فكرة "DSX".

لن يجلب DSX شيئًا . يتم استخدام JSX في التفاعل لأن بناء جملة JS مروع. ولكن في حالة Flutter ، فإن إنشاء عناصر واجهة المستخدم أمر سهل للغاية.

الكلاسيكية:

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

إنه بالفعل خارج الصندوق قابل للقراءة ، وسهل الكتابة ، ومتوافق مع النوع / العام ، وبدون أي تكرار غير ضروري.

الشكوى الوحيدة التي من المحتمل أن تكون لديك مع بناء الجملة الحالي هي "من الصعب معرفة مكان قوس إغلاق عنصر واجهة مستخدم"

ولكن مرة أخرى ، يحل المكون الإضافي dart لـ IDEs المدعومة رسميًا هذه المشكلة. لذلك عندما نفتح الكود من قبل في vscode ، سنرى

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

بالنسبة إلى "من الصعب تمييز الشفرة غير الرسمية عن رمز واجهة المستخدم" ، تنطبق قواعد التفاعل على الرفرفة أيضًا:

يجب أن تكون الأدوات إما غبية أو ذكية. القطعة الذكية ليس لديها منطق واجهة المستخدم. لا تحتوي الأدوات الذكية إلا على منطق واجهة المستخدم.

إذا اتبعت هذا النمط ، فلا يجب أن تقع في موقف تفشل فيه في التمييز بين واجهة المستخدم والبقية.
هذا صحيح أكثر عند اتباع شيء مثل نمط BLoC ؛ التي تفرض بشدة الفصل بين الأعمال وواجهة المستخدم.

يتم استخدام 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 كتب مرتين

JSX:

• 104 حرفًا ، مع قوسين ، 3 أقواس ، 1 : ، 4 <> و 5 مسافات
• Container و Text تمت كتابته مرتين

سهم:

• 99 حرفًا ، بقوسين ، 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(),
);

بناة (لا يدعم dart نوع الاتحاد لذا لا يمكن أن يكون children أداة ووظيفة معًا)

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

تضمين التغريدة

كما ذكرنا عدة مرات من قبل ، فإن DSX ببساطة مختلفة
بناء الجملة وهي مجموعة شاملة من Dart ، لذلك كل ما يمكنك القيام به
دارت يمكنك أن تفعل ذلك داخل DSX. يمكنك أيضًا مزج ومطابقة كليهما
النحو الذي تراه مناسبًا. من الواضح أنك لم تهتم حتى بالتحقق
ما هي بعض ميزات DSX التي تم إجراؤها لدعمها
سهم:
https://spark-heroku-dsx.herokuapp.com/index.html

-1 ---------------------------------------
في دارت:

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

OR

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

في DSX:

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

OR

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

-2 ---------------------------------------
في دارت:

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

في DSX:

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

-3 ---------------------------------------
في دارت:

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

في DSX:

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

  }}
  child={child}
/>

-4 ---------------------------------------
في دارت:

Text("foo")

في DSX:

<Text ["foo"]/>

-5 ---------------------------------------
في دارت:

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

في DSX:

<Positioned.fill>
  <Container/>
</Positioned.fill>

-6 ---------------------------------------
في دارت:

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

في DSX:

<Builder
  builder={(context) => <Container/>}
/>

لكن حجة الحصول على تحويل أسهل من رد فعل إلى رفرفة غير صالحة. نظرًا لأن JSX يختلف اختلافًا جذريًا عن النموذج الأولي الخاص بك:

<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

ولا يوجد أي من الأمثلة الخاصة بك هنا أو من الرابط الخاص بك في الواقع يبسط الكود أو يحسن قابلية القراءة

بقدر ما أستطيع أن أتعلق بشعورك بفقدان JSX (حصل على نفس الشيء عند بدء الرفرفة) ، بعد بعض الخبرة ، فإن بناء الجملة الأصلي يبدو جيدًا في الواقع

كملاحظة جانبية ، هناك حل أفضل بكثير لفصل مخاوفك. هذا ملف قالب
يمكن أن يكون لديك ملف xml / yaml بجوار عنصر واجهة المستخدم الخاص بك. ثم استخدم أداة إنشاء التعليمات البرمجية الرائعة التي توفرها dart.

أفضل:

// 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} />

والذي يستخدم بعد ذلك رمزًا مخصصًا لتوليد ملف dart التالي:

part of 'main.dart';

Widget $myStateStateTemplate({ThemeData theme}) {
  return Container(
    color: theme.cardColor,
  );
}

والنتيجة النهائية أفضل من "DSX" لفصل واجهة المستخدم / المنطق. إنه أفضل لمولدات واجهة المستخدم المحتملة أيضًا. وهو أسهل بكثير في التنفيذ باستخدام 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}/>}
/>

حسنًا ، يبدو أنك تخلط بين "فصل الاهتمام" و "فصل التكنولوجيا". هذه الأشياء مختلفة جدا. أنت تفصل بين كود dart و markup code في ملفات مختلفة ، وهو ببساطة "فصل للتكنولوجيا" ولا يوفر أيًا من مزايا "فصل الاهتمامات". هناك قلق هنا من وجود مكون / عنصر واجهة مستخدم يقوم بتغليف الكود القابل لإعادة الاستخدام بشكل نظيف ، ولا يهم أنه داخل هذا المكون / عنصر واجهة المستخدم يستخدم تقنيات مختلفة.

كما أن فصل التقنيات على النحو الذي توصي به هو أدنى من JSX / DSX الذي يستخدم اللغة المضيفة لجميع التركيبات الضرورية (للحلقات ، واستدعاءات الوظائف ، وعبارات if ، وما إلى ذلك).

بعد نشر الكثير من التعليمات البرمجية والأمثلة هنا ( خاصة ) ، توصلت إلى استنتاج مفاده أن JSX تضيف قيمة أكبر إلى JS على عكس DSX و Dart. لكن هناك ميزة واحدة مهمة جدًا من وجهة نظري: علامات الإغلاق. مثل:

<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 ، وما إلى ذلك).

غير صحيح. يمكنك عمل if وأشياء داخل ملف القالب الخاص بك. انظر إلى قوالب cshtml أو الزوايا.

الشيء هو ملف قالب ، طالما أن لديك بالفعل محللًا له ، يمكن تنفيذه للرفرفة في أقل من أسبوع يعمل بشكل كامل.
سواء كان ذلك yaml أو xml أو cshtml أو html مع التوجيهات.

بينما يتطلب DSX الكثير من العمل.

Bessonov أضافوا مؤخرًا تعليقات افتراضية على IDEs المدعومة لمحاكاة علامة الإغلاق.

لذلك في vscode الخاص بك سترى ما يلي:

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

فوائد إغلاق العلامات. دون الحاجة إلى كتابتها

تضمين التغريدة

لقد أضافوا مؤخرًا تعليقات افتراضية على IDEs المدعومة لمحاكاة علامة الإغلاق.

نعم ، لقد رأيت ذلك في التعليق المقتبس منه. لكنها ليست هي نفسها. هذا يقدم تحول محاذاة ويزعج تدفق القراءة. وهذا لا يساعدني في IDEs ومعالجات النصوص الأخرى.

الشيء هو ملف قالب

قوالب IMHO تعاني من متلازمة المعاهد الوطنية للصحة. أنا لا أقول أن هذا النهج لخلط PHP و HTML هو الطريقة الصحيحة للقيام بذلك. لكن رد فعل يظهر مع JSX كيف يمكن القيام بذلك بشكل أفضل.

تضمين التغريدة

لقد فاتتك عبارة "ولكن بعد ذلك حجة الحصول على تحويل أسهل من رد الفعل إلى الرفرفة غير صالحة."

لا ، لم يفوتني التعليق على الإطلاق ، ليس من المنطقي أن تخبرني أن الأشخاص القادمين من JSX سيجدون أن DSX معقد للغاية.

نصف الحجج لـ DSX ...

هناك العديد من الأسباب لاختيار DSX ولكن مع البدائل ، سيختار الأشخاص ما يفضلونه لأي سبب من الأسباب.

غير صحيح. هل يمكن أن تفعل إذا وأشياء داخل ملف القالب الخاص بك. انظر إلى قوالب cshtml أو الزاوية.

الشيء هو ملف قالب ، طالما أن لديك بالفعل محللًا له ، يمكن تنفيذه للرفرفة في أقل من أسبوع يعمل بشكل كامل.
سواء كان ذلك yaml أو xml أو cshtml أو html مع التوجيهات.

بينما يتطلب DSX الكثير من العمل.

على العكس تمامًا ، لا ينفذ DSX سوى تحويلين xml ويكسب كل شيء آخر مجانًا من لغة الاستضافة. تخيل الجهد المبذول لإعادة تطبيق قوة Dart داخل لغتك النموذجية الجديدة. لا شكرا ، سآخذ دارت.

لا ، لم يفوتني التعليق على الإطلاق ، ليس من المنطقي أن تخبرني أن الأشخاص القادمين من JSX سيجدون أن DSX معقد للغاية.

الأمر نفسه ينطبق على تنفيذ السهام الحالي.

على أي حال ، لا أعتقد أنه يمكننا إقناع بعضنا البعض هنا. لذلك سأقوم فقط بإدراج بعض الأسباب التي تجعلني لا أحب JSX في الرفرفة ثم "انتظر وشاهد".

1. يختلف إنشاء الأداة عن React

في رد الفعل ، إنها المكتبة التي تتعامل مع إنشاء المكونات. JSX جيد لأنه يقول "لا تهتم بكيفية عمل الأشياء. نحن نقوم بالأشياء من أجلك".

في الرفرفة ليس هذا هو الحال. نقوم يدويًا بإنشاء مثيل عنصر واجهة مستخدم جديد كل مكالمة بناء. من المهم حقًا فهم هذا الأمر ، وستجعله JSX أقل وضوحًا.

واستمرارًا لهذا المنطق:

2. قد تعتقد الشعوب أن <Foo /> يفعل شيئًا مميزًا لا يفعله new Foo()

<Foo /> بطريقة تبدو مميزة. يبدو أنه يفعل شيئًا غريبًا مضمّنًا في الإطار. وهذا صحيح في رد الفعل ، حيث يتم لف المكونات في React.Element .
يترجم هذا في التفاعل إلى <Foo /> ! = new Foo() وليس لديك وصول مباشر إلى Foo .

هذا لا ينطبق على الرفرفة وقد يسبب الارتباك.

ايضا :

<Foo>
  <Bar />
</Foo>

في رد الفعل ، إذا لم يستخدم Foo طفله مطلقًا ، فلن يتم إنشاء مثيل لـ Bar أبدًا. ويتم إنشاء مثيل لـ $ # $ 10 Foo # $ بعد إرجاع طريقة render .
بينما في الرفرفة هذا هو عكس ذلك. يتم إنشاء كلا من Bar و Foo على الفور

من المحتمل أن يؤدي هذا إلى قيام مطوري React بإنشاء كود رفرفة غير محسّن.

3. بشكل عام دارت / رفرفة ليس JS / رد فعل

إذا أضفنا JSX في dart ، فيمكنني بالفعل رؤية المشكلات المتعلقة باتحاد النوع أو أن أكون قادرًا على القيام بذلك
return foo && <Component /> أو العرض غير المتزامن القادم في التفاعل.
مبرر بـ "لدينا JSX بالفعل لذا يمكننا الحصول عليه أيضًا!"

أفضل بناء جملة خاص أو عدم وجود بناء جملة على الإطلاق ، من أجل عدم الاضطرار إلى تنفيذ أحدث ميزة JSX / رد فعل في dart

4. JSX يجعل بعض التفاصيل الدقيقة غير واضحة

مثال صغير ، Scaffold يتطلب appbar a PrefferedSizeWidget .
إذا أنشأنا Scaffold باستخدام JSX ، فسيتوقع الناس أنه يمكنك استبدال أي JSX بأخرى. وهذا غير صحيح

أعني ، إنه يجعل من غير الواضح تمامًا سبب قيامنا بذلك

<Scaffold
  appbar={<AppBar />}
/>

لكن لا

<Scaffold
  appbar={<Container />}
/>

تضمين التغريدة

على أي حال ، لا أعتقد أنه يمكننا إقناع بعضنا البعض هنا. لذلك سأقوم فقط بإدراج بعض الأسباب التي تجعلني لا أحب JSX في الرفرفة ثم "انتظر وشاهد".

أنا لا أتفق مع الكثير مما قلته ولكني أقدر جهودك لأنك تأخذ الوقت الكافي للتفكير بعمق في هذه القضية.

1. يختلف إنشاء عنصر واجهة المستخدم عن React

بالنسبة لي لا يهم لأن هذا مجرد تفاصيل تنفيذ ، من الناحية المفاهيمية بمجرد رؤية بعض XML ، في React هو مكون ، في Flutter هو عنصر واجهة مستخدم.

1. قد تعتقد الشعوب يفعل شيئًا مميزًا لا يفعله Foo () الجديد

أعتقد أن الناس سيتعلمون بسرعة كبيرة أن Dart / DSX ليس Javascript / JSX.

1. بشكل عام Dart / الرفرفة ليس JS / يتفاعل

نعم ، لقد اتفقنا أخيرًا على شيء ما ولكن على الرغم من اختلافهما ، فإن الخيط المشترك هو أنها أطر عمل تعريفية لواجهة المستخدم وأعتقد أن هياكل الشجرة التعريفية يتم التعامل معها بشكل جيد مع JSX / DSX. إنها تبقيك على طريقة تفكير البرمجة التصريحية.

إذا أضفنا JSX في dart ، فيمكنني بالفعل رؤية المشكلات المتعلقة باتحاد النوع أو أن أكون قادرًا على القيام بـ return foo && <Component /> أو العرض غير المتزامن القادم في رد الفعل.
مبرر بـ "لدينا JSX بالفعل لذا يمكننا الحصول عليه أيضًا!"

نحن لا نضيف JSX في Dart ، بل نضيف DSX ، إنه مختلف ولكن له أوجه تشابه مع JSX والألفة شيء ضخم.

أنا أفضل بناء جملة خاص أو عدم وجود بناء جملة على الإطلاق ، من أجل عدم الاضطرار إلى تنفيذ أحدث ميزة JSX / رد فعل في dart.

إذن بهذا المنطق لماذا تستخدم دارت؟ يبدو مشابهًا جدًا لـ Java ومع ذلك فهو مختلف عن Java ؛ حسنًا ، دعنا نتخلص من كل هذه الكلمات المفتاحية والمفاهيم الخاصة بجافا ونخرج بشيء مشابه بشكل غامض لإيرلاند لا يمكنك برمجته إلا بيد واحدة أثناء القيام بحركة يوغا مملحة على قمة جبل إيفرست ؛)

1. يجعل JSX بعض تفاصيل السهام غير واضحة

ليس حقًا ، إذا قمت بتوصيل عناصر واجهة مستخدم لا تضاهى ، فسيقوم مترجم Dart ببث رسائل خطأ تمامًا كما لو قمت بذلك في Dart عادي. لا أستطيع التأكيد بما فيه الكفاية على أن DSX هو ببساطة سكر نحوي رقيق ، ولا يوجد سحر ، بل مجرد اختلاف في تركيب نفس الشيء.

cbazza لقد أمضيت ساعات في قراءة مشاركاتك وأنا أقدر حقًا جهودك في هذه المسألة. لكنني أعتقد أنه (نوعًا) من السهل إنهاء الجدل. تذكر أن التدفق كان الحل الرسمي لإدارة الدولة للرد ولكن الآن الجميع يستخدم إعادة؟ وما عدد libs التنقل المتوفرة للرد الفعل الأصلي؟ ما عليك سوى إنشاء مستودع DSX ودع مطوري التفاعل يقفزون.

تضمين التغريدة

لم أشاهد صيغة part / part of في Dart من قبل ، وأواجه مشكلة في العثور على أي وثائق لها. هل هو شيء تدعمه Dart / Flutter رسميًا؟ أحب استخدام شيء من هذا القبيل في FLUI.

تضمين التغريدة

أنت تستمر في الدوران في دوائر مع تبرير DSX. DSX ليس JSX. DSX يشبه JSX. من المفترض أن يكون DSX بناء جملة مألوفًا لمطوري React. DSX هو مجرد التفكير النحوي السكر لدارت. سيتعلم الناس أن DSX ليس JSX. (وما إلى ذلك وهلم جرا.)

بينما أحصل على النقطة التي تحاول توضيحها مع كل هذه التفسيرات ، أعتقد أن حقيقة أنه يجب عليك الاستمرار في جعلها تكشف عن مشكلة كبيرة تتعلق بطبيعة DSX بشكل عام ، وهي نقطة أثارها rouselGit أيضًا. حتى عندما تستمر في القول أن DSX ليس هو JSX ، فإن الأشخاص الذين يجدونها سيعتقدون أنها كذلك ، وهذه مشكلة. يأتي JSX والأشخاص الذين يستخدمونه من نظام بيئي مختلف جدًا من الناحية المفاهيمية على المستويات الأساسية من Dart / Flutter. على هذا النحو ، فإن تطوير ميزة "الألفة" ليس بالضرورة أمرًا جيدًا. أحد الأسباب الأكثر وضوحًا لذلك ، كما تمت الإشارة إليه ، سيحاول الناس شيئًا كهذا:

Widget build(BuildContext context) {
    return isDialogVisible && <Widget>...</Widget>;
}

نظرًا لأنهم يأتون من Javascript / JSX ، فإنهم يتوقعون أن تعمل هذه الصيغة في DSX. عندما لا يحدث ذلك ، يصبح نقطة تنافر معرفي قد يضر في الواقع باهتمامهم ليس فقط في DSX ولكن في Flutter ككل. تكون الألفة مفيدة عندما يتم استخدامها كوسيلة لتيسير الناس على شيء جديد ، ولكن يمكن أن يكون ذلك بمثابة سيف ذو حدين - عندما تكون 90٪ من الميزات متشابهة ، فإن الـ 10٪ المتبقية يمكن أن تعمل فقط على الإحباط والإزعاج.

هناك مشكلة أخرى في DSX وهي أنه من غير المحتمل أن تكون ميزة متكاملة بسلاسة في أي وقت قريب ، بغض النظر عما إذا كانت مكونًا إضافيًا تابعًا لجهة خارجية أو إذا تم اعتمادها رسميًا بواسطة Flutter. كما قلت بنفسك ، لكي تعمل حقًا مع عملية تصحيح أخطاء Flutter ونشرها ، فإنها تحتاج إلى دعم رسمي ليس فقط من فريق Flutter ولكن أيضًا من فريق Dart. إذا تعذر ذلك ، بدون دعم المعالجة المسبقة والأدوات ، فإن الطريقة الوحيدة التي سيعمل بها DSX هي باستخدام أدوات التحويل اليدوي الخارجية ، وهي مجرد خطوة أخرى (من المحتمل أن تكون طويلة) يتعين على المطورين اتباعها.

أثناء كتابة هذا ، حدث شيء آخر بالنسبة لي. كان هناك العديد من الأشخاص المؤيدين لـ JSX في هذا الموضوع الذين أشادوا بـ JSX ، قائلين إن نهج "فصل الاهتمامات" لتصميم واجهة المستخدم هو حقًا الطريقة الوحيدة التي سيفكرون بها في تطوير واجهات المستخدم مرة أخرى. إذا كان الأمر كذلك ، فلماذا يعتبر React الإطار الوحيد الذي يستخدمه بحضور في السوق؟ تم تعليق كل من أطر تطبيقات الأجهزة المحمولة الأصلية وعبر الأنظمة الأساسية مع لوحات العمل الخاصة بهم ، وملفات XML الخاصة بهم ، وملفات XAML الخاصة بهم ، وغير ذلك من تعريفات واجهة المستخدم DST. حتى أطر JS الشائعة الأخرى مثل Angular و Vue الصاعدة لا تزال تقوم بمقاربة "فصل التقنيات". يتحدث مطورو React مثل JSX هي طريقة المستقبل ، لكني لم أرها تظهر في أي مكان آخر بخلاف React في إطار عمل حصل على أي تأثير حقيقي.

تضمين التغريدة

part / part of هي إحدى ميزات dart الحالية. بطريقة ما ينضم إلى ملفين في ملف واحد. عادة ما تستخدم لتوليد الكود.

هناك عدد قليل من سيناريوهات الحالات الحقيقية التي تستخدم مثل هذه التقنية. مثل json_serializable الذي يولد طريقة toJSON fromJSON ومصنع $ # $ 4 $ # $ للفئات بناءً على خصائصهم.

part / part of لا تفعل أي شيء بمفردها. الجزء المثير للاهتمام هو عندما تقوم بدمجه مع شيء مثل source_gen .

تضمين التغريدة

لا أعتقد أن وضع التعليمات البرمجية على الريبو من شأنه أن يحل مشكلتي لأن المشكلة الحالية تتعلق بدمج DSX بشكل صحيح مع أدوات Flutter لتوفير تجربة مطور رائعة مع مصحح الأخطاء والإكمال التلقائي وما إلى ذلك أثناء العمل على ملف dsx.

إن إخبار المستخدمين بأنه يمكنهم استخدام DSX ولكن لا يمكنهم استخدام مصحح الأخطاء أو الاستمتاع بالإكمال التلقائي هو أمر غير مبدئي بالنسبة لي. إذا كان أي شخص يريد المساعدة ، فما أحتاجه هو اكتشاف طريقة لإضافة دعم كامل للمعالجة المسبقة (مع خريطة المصدر) إلى Dart Tools و VS Code Dart plug in. بمجرد أن تدعم الأدوات DSX أو أي لغة ترانزيت أخرى (أي لغة هي مجموعة شاملة من Dart ولكنها تجمع كل شيء وصولاً إلى Dart) ستعمل فقط.

تضمين التغريدة

لست بحاجة إلى تبرير أي شيء ، فأنا واثق جدًا من أن DSX سيكون ناجحًا وهناك ما يقرب من 100 شخص مهتمون به على هذه التذكرة وحدها.

إذا تعذر ذلك ، بدون دعم المعالجة المسبقة والأدوات ، فإن الطريقة الوحيدة التي سيعمل بها DSX هي باستخدام أدوات التحويل اليدوي الخارجية ، وهي مجرد خطوة أخرى (من المحتمل أن تكون طويلة) يتعين على المطورين اتباعها.

DSX transpiler سريع للغاية ويمكنه تحويل ملفات .dsx إلى ملفات dart أسرع مما يمكنك وميضه ، لذا فإن السرعة ليست مشكلة ؛ مجرد محاولة الحصول على ميزة التكافؤ لجعل استخدام DSX أمرًا لا يحتاج إلى تفكير.

إذا كان الأمر كذلك ، فلماذا يعتبر React الإطار الوحيد الذي يستخدمه بحضور في السوق؟ تم تعليق كل من أطر تطبيقات الأجهزة المحمولة الأصلية وعبر الأنظمة الأساسية مع لوحات العمل الخاصة بهم ، وملفات XML الخاصة بهم ، وملفات XAML الخاصة بهم ، وغير ذلك من تعريفات واجهة المستخدم DST.

ما عليك سوى وضع جدول زمني وسترى تطور تطوير واجهة المستخدم. بدأ تطوير Android و iOS عبر طرقهما الحالية منذ أكثر من 10 سنوات ، لذا فهو يستخدم تقنيات عمرها 10 سنوات (تقنيات ضرورية تمامًا). بدأت تقنيات تطوير واجهة المستخدم التفاعلية (التصريحية) في الظهور على الويب منذ حوالي 8 سنوات. ظهر React منذ 5 سنوات وكان أول إطار تفاعلي يجمع التقنيات بسلاسة مع JSX. يعد Vue الآن أحدث إطار عمل تفاعلي يدعم تقنيات "فصل التقنيات" القديمة ولكنه يدعم أيضًا JSX. يعد Flutter هو الأحدث على الهاتف المحمول ويستخدم تقنيات إطار العمل التفاعلي مثل React ويمكنه الاستفادة من DSX تمامًا كما يستفيد Vue من JSX. يقتل Vue Angular لأنه يوفر خيارًا للمطورين وليس مفرطًا في الرأي.

تكمن مشكلة ملفات القوالب المنفصلة في أن تركيبات البرمجة الضرورية هناك (إذا ، للحلقة ، إلخ) ضعيفة جدًا مقارنة بما هو متاح في لغة البرمجة المستخدمة لمنطق الأعمال. من الواضح أن الجمع بين 2 بالطريقة التي تعمل بها JSX ، بالنسبة لي ، هو المستقبل.

يتحدث مطورو React مثل JSX هو طريق المستقبل ،

أنه !!!

لكني لم أره يظهر في أي مكان آخر بخلاف React في إطار عمل حصل على أي تأثير حقيقي.

يستخدم Vue JSX

تضمين التغريدة

لست بحاجة إلى تبرير أي شيء ، فأنا واثق جدًا من أن DSX سيكون ناجحًا وهناك ما يقرب من 100 شخص مهتمون به على هذه التذكرة وحدها.

أنا لا أقول أنك بحاجة إلى تبرير أي شيء. عندما كنت تصر على أن يلتقط فريق Flutter هذا الاقتراح وينفذه بأنفسهم ، نعم ، كنت سأقول أن لديك قدرًا لا بأس به من التبرير للقيام به. الآن بعد أن حاولت أن تفعل ذلك بنفسك ، يمكنك أن تفعل ما تريد لأي تبرير تعتقد أنه كافٍ ، والمزيد من القوة لك. أنا فقط أذكر الأسباب التي أرى أنها قد لا تكون سهلة أو شائعة كما تعتقد ، وأنا أضع الكرة في ملعبك لتحديهم.

DSX transpiler سريع للغاية ويمكنه تحويل ملفات .dsx إلى ملفات dart أسرع مما يمكنك وميضه ، لذا فإن السرعة ليست مشكلة ؛ مجرد محاولة الحصول على ميزة التكافؤ لجعل استخدام DSX أمرًا لا يحتاج إلى تفكير.

أفترض ، في هذه المرحلة ، أنك اختبرتها حتى الآن على واجهات المستخدم والتطبيقات الصغيرة الحجم. ماذا عن الأشياء غير التافهة؟ ماذا عن الحالات التي تقع ضمن حالات الحافة؟ أيضًا ، الوقت الفعلي الذي تستغرقه العملية ليس هو الجزء الوحيد ذي الصلة - فقط حقيقة أن المطور يجب أن يمر بقائمة تحقق أخرى للإجراءات اليدوية قبل أن يتمكنوا من البناء يكفي لإيقاف العديد من الأشخاص.

لا يزال يتعين عليك أيضًا إصدار الكود المصدري للمشروع بالفعل ، لذلك لم يتمكن أي شخص من متابعة العملية الخاصة بك ، والتحقق مرة أخرى من نتائجك ، واقتراح تحسينات. في هذه المرحلة ، كل ما يمكن لأي شخص فعله حقًا هو أن يأخذك إلى كلمتك بأنها مريحة ورائعة في نفس الوقت.

يستخدم Vue JSX

لقد كنت أستخدم Vue للاقتراب من عام الآن ، وفي ذلك الوقت مررت بعدد كبير من مستودعات المشروعات مفتوحة المصدر لمعرفة كيفية إنجاز الأشياء المختلفة. على الرغم من أنني لا أعتبر نفسي سيد Vue بأي حال من الأحوال ، فإن ما سأقوله هو أنه لم يسبق لي أن رأيت استخدام JSX فعليًا في أي واحد منهم - يبدو أن الناس يفضلون بشكل كبير نهج .vue (نموذج) -script-Styling) على طريقة العرض + JSX. لم أكن أعرف حتى أن Vue دعمت JSX (عبر ملحق بابل على الأقل) إلا بعد ردك ، قمت ببعض التنقيب في وثائق Vue واكتشفت مقتطفًا صغيرًا من المعلومات حوله في قسم وظيفة العرض.

لكن هذا لا علاقة له بنقطتي العامة. لا يزال Vue إطار عمل جافا سكريبت. من المؤكد أن الرفرفة ليست كذلك. على هذا النحو ، هناك العديد من الأسباب التي تجعل JSX هو أحدث شيء في بيئة تتمحور حول Javascript والتي لن تترجم إلى Dart + Flutter ، وقد تمت تغطية العديد منها بالفعل في هذا الموضوع.

أنه !!!

حتى أراها تتطور في بيئة تطوير غير جافا سكريبت ، سأعارضها بكل احترام.

يستخدم Vue JSX

تحديد Vue لديه مجموعة واسعة من الاستخدامات. JSX فقط "هناك". لكنها ليست البنية السائدة
يمكنك توصيل JSX بـ Angular إذا أردت ذلك. على الرغم من أن لا أحد يفعل

يتحدث مطورو React مثل JSX هو طريق المستقبل ،
أنه !!!

مرشح كبير للمستقبل هو مكونات الويب. ويتم استخدامها مباشرة في html على غرار ما تجده في Angular أو الشكل الأكثر شيوعًا لـ Vue

تضمين التغريدة

مجرد حقيقة أن المطور يجب أن يمر بقائمة تحقق أخرى للإجراءات اليدوية قبل أن يتمكنوا من البناء يكفي لإيقاف العديد من الأشخاص.

من قال أي شيء عن الإجراءات اليدوية؟ ألم أوضح لنفسي أنني أحاول الحصول على تكامل IDE سلس كامل (أفضل تجربة مستخدم ممكنة للمطورين).

لا يزال يتعين عليك أيضًا إصدار الكود المصدري للمشروع بالفعل ، لذلك لم يتمكن أي شخص من متابعة العملية الخاصة بك ، والتحقق مرة أخرى من نتائجك ، واقتراح تحسينات.

ما علاقة ذلك بأشخاص يستخدمون DSX؟ لقد استخدمت JSX لأكثر من عامين ولم أستطع الاهتمام كثيرًا بشفرة المصدر الخاصة به. هل تحتاج إلى إلقاء نظرة على الكود المصدري لمترجم Dart لتتمكن من البرمجة في Dart؟

ما سأقوله هو أنه لم يسبق لي أن رأيت استخدام JSX فعليًا في أي واحد منهم - يبدو أن الناس يفضلون بشكل كبير نهج .vue (تصميم النص النموذجي) على أسلوب العرض + JSX.

JSX هي إضافة جديدة ، لذا سيستغرق الأمر وقتًا للانتشار ، لكن النقطة المهمة للحصول عليها هي أن Vue يقبل طرقًا أخرى دون إجبار المطورين على استخدام "الطريقة الصحيحة والطريقة الوحيدة" التي يجب أن تتم بها الأشياء في Vue.

لا يزال Vue إطار عمل جافا سكريبت. من المؤكد أن الرفرفة ليست كذلك.

Riiiiight ، لذا بدلاً من JSX تستخدم DSX مع Flutter.

تضمين التغريدة

مرشح كبير للمستقبل هو مكونات الويب.

مكونات الويب هي zoobies ، ميتة لكنها ما زالت تسير ؛ فهي منتشرة مثل حيوان الكنغر في كندا. يمكنني الاستمرار لعدة أيام ولكن لتجنب الاستطراد ...
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/

تضمين التغريدة

من قال أي شيء عن الإجراءات اليدوية؟ ألم أوضح لنفسي أنني أحاول الحصول على تكامل IDE سلس كامل (أفضل تجربة مستخدم ممكنة للمطورين).

لقد قلت أيضًا أنك بحاجة إلى دعم المعالجة المسبقة من فريق Flutter / Dart من أجل القيام بذلك. هل أنا مخطئ في ذلك؟

ما علاقة ذلك بأشخاص يستخدمون DSX؟ لقد استخدمت JSX لأكثر من عامين ولم أستطع الاهتمام كثيرًا بشفرة المصدر الخاصة به.

تم تطوير JSX بواسطة Facebook من أجل React ، وتم وضعه من خلال عملية اقتراح / تصميم / تنفيذ / تكرار صارمة ، ثم تم إصدارها في العالم قبل سنوات من حصولك عليها. لقد تم اختباره بدقة وإثباته مرارًا وتكرارًا في بيئات العالم الحقيقي. إنها تقنية ناضجة. لا يوجد سبب للمطالبة برؤية ورقة مواصفات لشيء من هذا القبيل.

DSX ، من ناحية أخرى ، يتم تطويره اليوم من قبلك وحفنة من الناس. لقد تبلورت ببلاغة حول ما يمكن أن تفعله وستكون قادرًا على القيام به ، ولكن كل ما نراه في الواقع هو مجموعة صغيرة من مقتطفات الشفرة المصممة لهذا الغرض وكلمتك التي تم إنشاؤها بواسطة جهاز التحويل. الأشخاص الذين يرغبون في تجربته ويقترحون تغييرات أو تحسينات محتملة غير قادرين على القيام بذلك ، لذلك ليس لديهم سبب لدعم جهودك بخلاف "Yay JSX!".

أنا لا أتهمك بالكذب أو أي شيء آخر ، أنا أقول فقط أن JSX اكتسبت مستوى من الثقة لم يحصل عليه DSX ، فكيف ستدير بعض الرؤوس إذا لم تدع الناس يتلاعبون بها؟

JSX هي إضافة جديدة ، لذا سيستغرق الأمر وقتًا للانتشار ، لكن النقطة المهمة للحصول عليها هي أن Vue يقبل طرقًا أخرى دون إجبار المطورين على استخدام "الطريقة الصحيحة والطريقة الوحيدة" التي يجب أن تتم بها الأشياء في Vue.

كانت JSX في Vue منذ ما يقرب من عامين حتى الآن. وعلى عكس Vue نفسها ، فإن JSX هي تقنية موجودة مسبقًا لا تحتاج إلى مقدمة ، خاصة للأشخاص المألوفين في React. إذا كانت JSX ستأخذ عالم Vue.js بعاصفة ، فلا يسعني إلا أن أشعر أنها كانت ستفعل ذلك الآن. (خاصة إذا كان هناك أي مؤشر على أن العديد من الأشخاص يطالبون بـ JSX في Flutter كما تدعي.)

Riiiiight ، لذا بدلاً من JSX تستخدم DSX مع Flutter.

JSX و DSX هما نفس المفهوم النحوي. تكمن المشكلة في أنه حيث تم بناء JSX على لغة ديناميكية ضعيفة الكتابة مثل JavaScript ، فإن DSX مبني على لغة ثابتة مكتوبة بقوة مثل Dart. هذا يعني أن هناك الكثير من المشاكل التي سيتعين على DSX أن تأخذها في الحسبان والتي لم يكن على JSX أن تفعلها إذا كان سيكون أي شيء آخر غير تطبيق "JSX for Flutter" المتخصص ، وسيتطلب الأمر بعض التعديلات الخادعة لجعل DSX يعمل حقًا دون جعله منتفخًا جدًا بحيث يتعذر عليه تبرير الادعاء بأنه أكثر إيجازًا من الناحية المرئية.

وللتعامل مع "DSX هو مجرد Dart ، إذا لم يستطع DSX فعل شيء ما ، فما عليك سوى استخدام Dart" دحض ، فسيكون رد الطعن المضاد الخاص بي إذا اضطررت إلى العودة إلى Dart كلما واجهت سيناريو لم يفعله DSX t التعامل ، فلماذا لا أستخدم Dart طوال الوقت؟

ولمعالجة الطعن في هذه القراءة "يمكنك إذا أردت ، أن DSX مجرد خيار" ، فأنت تبيع نفسك على المكشوف حقًا. حتى لو كان حقًا مجرد "خيار" ، فإنه لا يزال بحاجة إلى تقديم شيء ما على الطاولة يقنع الناس باستخدامه. لقد قلت بنفسك أن DSX ليس JSX ، لذا فإن الأشخاص الذين يريدون JSX فقط لن يحصلوا على ما يريدون. هذا يعني أنه يجب أن تكون هناك بعض الأسباب الملموسة بخلاف "النداء الشبيه بـ JSX" للأشخاص الذين يرغبون في استخدامه.

إذا كنت تقوم فقط ببناء أداة تريد أنت بنفسك استخدامها ، فكل هذا هو موضع نقاش ويمكنك أن تذهب بجنون. ولكن إذا كنت تقوم بالفعل ببناء شيء ما تنوي أن يستخدمه الآخرون ، فأنت بحاجة إلى وضعه في شكل صلب لماذا تعتقد أنه يجب عليهم ذلك.

مكونات الويب هي zoobies ، ميتة لكنها ما زالت تسير ؛ فهي منتشرة مثل حيوان الكنغر في كندا. يمكنني الاستمرار لعدة أيام ولكن لتجنب الاستطراد ...

خارج الموضوع إلى حد ما ، لكني أود أن أشير إلى أن مكونات الويب هي حقًا نظرة واعدة على المستقبل ، حتى لو كان الدعم المقدم لها يضاف بشكل أبطأ من القطران. فكر في الأمر بهذه الطريقة: تقوم React بما تفعله لأنها تنفذ بشكل أساسي فكرة مكونات الويب في Javascript-only. تخيل إلى أي مدى سيكون الأمر أفضل إذا كانت هذه الميزات مدعومة من قبل المتصفح واستفادت من الأداء غير المكوّن من وضع الحماية وعدم الاضطرار إلى العمل من خلال معالجة DOM؟ (قد يستغرق الأمر 20 عامًا أخرى قبل أن نكتشف ذلك ، ولكن لا يزال ...)

تضمين التغريدة

آسف يا صاح ، ليس لدي الوقت لأجادل إلى ما لا نهاية وأكرر ما قلته من قبل مرارًا وتكرارًا ؛ لن ننتهي بالاتفاق على أي حال ، لذا حظًا سعيدًا مع FLUI الخاص بك.

لقد تبلورت ببلاغة حول ما يمكن أن تفعله وستكون قادرًا على القيام به ، ولكن كل ما رأيناه بالفعل هو حفنة صغيرة من مقتطفات الشفرة المصممة لهذا الغرض وكلمتك التي تم إنشاؤها بواسطة المترجمة.

تم تشغيل ناقل DSX عبر الإنترنت منذ فبراير 2018 ويمكن لأي شخص استخدامه لذلك ليست هناك حاجة لأخذ كلامي لأي شيء. اضغط على "ترجمة" ويقوم بتجميع ما هو مكتوب على اللوحة اليسرى ويضع النتائج على اللوحة اليمنى. افتح مصحح الأخطاء وسترى AST مكتوبًا.
https://spark-heroku-dsx.herokuapp.com/index.html

تكمن المشكلة في أنه حيث تم بناء JSX على لغة ديناميكية ضعيفة الكتابة مثل JavaScript ، فإن DSX مبني على لغة ثابتة مكتوبة بقوة مثل Dart.

لا يوجد فرق كبير على الإطلاق ، مثل مفهوم OOP (البرمجة الشيئية) وبناء الجملة لـ "الفصول الدراسية". يكاد يكون متطابقًا في Javascript أو Dart المكتوبة ؛ يمكن قول الشيء نفسه عن عبارة "if" و "for" وما إلى ذلك

لا تزال بحاجة إلى إحضار شيء إلى الطاولة يقنع الناس باستخدامه.

يبدو أنها تعمل بالفعل لـ 100 شخص في هذه التذكرة ؛ وهذا أكبر بمئة مرة من استخدامي له ؛ هذا يكفيني.

تضمين التغريدة

آسف يا صاح ، ليس لدي الوقت لأجادل إلى ما لا نهاية وأكرر ما قلته من قبل مرارًا وتكرارًا ؛ لن ننتهي بالاتفاق على أي حال ، لذا حظًا سعيدًا مع FLUI الخاص بك.

أنا لا أتجادل معك فقط من أجل الجدل أو بسبب بعض التحيز العميق ضد JSX. أحاول أن أجعلك تجيب على الأسئلة التي تحتاج إلى إجابة. أنت تطور أداة يُفترض أنك تنوي استخدامها لأشخاص آخرين ، لكنك لم تقدم بعد سببًا مقنعًا _لماذا_ يجب عليهم استخدامها بخلاف الفوائد الغامضة والذاتية لـ "الألفة" و "لأنها أفضل". الأول ، كما قلت من قبل ، ليس بالضرورة أمرًا جيدًا ، والأخير هو حتى الآن ادعاء تم تقديمه دون أي دعم ملموس.

إذا كنت تريد أن تكون أداتك ناجحة ، فيجب أن تحدد ما تفعله ولماذا تفعل ذلك ، وتحتاج إلى القيام بذلك بطريقة يمكن نقلها بسهولة إلى الآخرين. هذا لا يعني أنه لا يمكنك صنع منتج حتى ينال إعجاب الجميع ، ولكن الأهداف الواضحة والموجزة ضرورية لتشكيل التصميم والتنفيذ. بخلاف ذلك ، ستنتهي فقط بأداة مساعدة بدون اتجاه والتي ستكون منتجًا متخصصًا في أحسن الأحوال وستكون محظوظًا للغاية إذا انتهى بها الأمر في رمز الإنتاج من أي نطاق.

تم تشغيل ناقل DSX عبر الإنترنت منذ فبراير 2018 ويمكن لأي شخص استخدامه لذلك ليست هناك حاجة لأخذ كلامي لأي شيء. اضغط على "ترجمة" ويقوم بتجميع ما هو مكتوب على اللوحة اليسرى ويضع النتائج على اللوحة اليمنى. افتح مصحح الأخطاء وسترى AST مكتوبًا.

لم أر حتى أن هذا الرابط كان مثالًا عمليًا. لم أستخدم herokuapp أبدًا من قبل وبدا وكأنه مجرد جوهر أو شيء من هذا القبيل ، لذلك هذا الأمر يخصني. : ص

(على الرغم من أنني سأشير إلى أن العبث في وضع الحماية عبر الإنترنت لا يماثل اختبار محول التردد في بيئة أكثر عملية.)

لا يوجد فرق كبير على الإطلاق ، مثل مفهوم OOP (البرمجة الشيئية) وبناء الجملة لـ "الفصول الدراسية". يكاد يكون متطابقًا في Javascript أو Dart المكتوبة ؛ يمكن قول الشيء نفسه عن عبارة "if" و "for" وما إلى ذلك

كان عليك بالفعل التعامل مع أحد هذه الاختلافات في الكتابة القوية للأطفال . ماذا عن سمة الكتابة القوية؟ ماذا عن الأدوات في مكتبات مختلفة تحمل الاسم نفسه؟ ماذا يحدث إذا قام شخص ما بعمل عنصر واجهة مستخدم بأكثر من حجة موضعية واحدة غير معروفة؟ ماذا يحدث إذا قمنا باستيراد مكتبتين لهما أدوات بنفس الاسم؟ ماذا يحدث في بعض السيناريوهات التي لم أفكر في ظهور النوافذ المنبثقة لعرض الاختلاف المتأصل بين أنظمة مثل Javascript و Dart؟ يجب أن أقول ، كونك متقلبًا جدًا بشأن نقطة المناقشة هذه يجعلني أشعر بالقلق بشأن طول عمر DSX في بيئة العالم الحقيقي.

يبدو أنها تعمل بالفعل لـ 100 شخص في هذه التذكرة ؛ وهذا أكبر بمئة مرة من استخدامي له ؛ هذا يكفيني.

مرة أخرى ، هذا هو 100 شخص الذين صوتوا لصالح القضية على أساس "ضع في اعتبارك بناء جملة يشبه JSX داخل رمز dart". لقد قاموا بالتصويت لأنهم يريدون _JSX_ ، وكما كنت حريصًا جدًا على الإشارة ، DSX ليس JSX. فلماذا بخلاف ذلك يريدون استخدام DSX؟ لأن إعلان واجهة المستخدم المضمنة على غرار XML هو "المستقبل"؟ مرة أخرى ، أنا فقط لا أراها.

لقد قمنا بالفعل بتغطية JSX في Vue لعدم حصولها على أي جر ، ولكن هناك أيضًا بديلين من React مذكوران في مقالة Web Components التي ربطتها: Inferno و Preact. بقدر ما أستطيع أن أقول ، فقد فشل كلاهما في إحداث أي نوع من الموجات على الإطلاق في عالم تطوير تطبيقات الويب المستند إلى JS ، على الرغم من دعمها في الأصل لبناء جملة يشبه JSX. أعتقد حقًا أن الناس بحاجة إلى إلقاء نظرة مطولة وفاحصة على - بالضبط لماذا - الأشخاص مثل JSX في React ، لأنه بكل المقاييس لا يبدو أن ذلك بسبب JSX نفسها. إذا كان بالإمكان الإجابة على هذا السؤال ، فيمكننا المضي قدمًا نحو الابتكارات "المستقبلية" بدلاً من مجرد التأكيد على ميزة واحدة من تلك المكتبة التي أحببناها في أي مكان آخر نعتقد أنه يجب أن يكون شخصيًا.

التفكير في مقدار الطاقة التي تم استثمارها فقط في هذه المناقشة وما يمكن فعله لتحسين الإطار الحالي يجعلني أشعر بالحزن بدلاً من ذلك.

تضمين التغريدة

تكمن المشكلة في أنه حيث تم بناء JSX على لغة ديناميكية ضعيفة الكتابة مثل JavaScript ، فإن DSX مبني على لغة ثابتة مكتوبة بقوة مثل Dart.

آسف ، لكن هذه ليست مشكلة. علاوة على ذلك ، هذا لا معنى له على الإطلاق. بجانب ذلك ، نستخدم JSX مع TypeScript.

تضمين التغريدة

escamoteur أنا معك في هذا. _ال 100. _

تضمين التغريدة

آسف ، لكن هذه ليست مشكلة. علاوة على ذلك ، هذا لا معنى له على الإطلاق. بجانب ذلك ، نستخدم JSX مع TypeScript.

لم يتم تصميم React لـ TypeScript. تم تصميمه لجافا سكريبت. تم تصميم جميع تعريفات عناصر واجهة المستخدم والسمات والخصائص وكل شيء آخر لاستخدامه في البيئة الديناميكية لجافا سكريبت ، لذا فإن نوع أمان TypeScript لا يقدم أي عوامل جديدة مع كيفية تفاعل JSX مع React. هذا مثال آخر على كيفية تصميم JSX لإعداد مختلف تمامًا عن إعداد Flutter.

تضمين التغريدة
لماذا تعتقد أنه مهم؟ JSX هي طريقة لوصف الواجهة. إنها لغة حيادية في حد ذاتها. انظر هنا . إنها ليست JavaScript. لكن حسنًا ، لماذا لا يتم ذلك باستخدام JSX؟ (بجانب عدم وجود تنفيذ لهذا (حتى الآن))

و .. كما تعلم ... يأتي التدفق من الفيس بوك أيضًا:

التدفق هو فاحص ثابت للطباعة لجافا سكريبت.

من فضلك ، توقف عن بيع الحجج المؤيدة والمعارضة للتمديدات التي لم تستخدمها أبدًا. أستخدم JSX كل يوم وأنا سعيد بها أجهزة الصراف الآلي ، على الرغم من أنني كنت متشككًا جدًا في ذلك. أستطيع أن أتخيل أن JSX تتطور في أنماط أخرى ، كما كانت مع AngularJS.

وربما يساعد هذا الموضوع في إيجاد نمط أفضل لـ Dart؟ DSX هو مجرد اقتراح واحد. انظر إلى مثال نمط البناء أعلاه أو تعديلات اللغة الأخرى المعروضة هنا. حسنًا ، ربما تكون فلوسك طريقة أفضل؟ انا لا اعرف. لكن دعونا نكتشف ذلك ونساعد بعضنا البعض لتحسين اقتراحاتهم بدلاً من مناقشة الأشياء السيئة في اقتراح شخص آخر.

أود أن أقترح إغلاق هذا الموضوع وفتح موضوع شامل جديد بمحادثة محدودة. جميع المقترحات لتحسين الطريقة وكيفية استخدام الرفرفة ومناقشة الموضوعات الخاصة بموضوعية بالحب وبدون كره.

نعم ، حجم الكراهية هنا ملحمي ، فقط ضع في اعتبارك هذا:
هناك 3587 تذكرة مفتوحة ، إذا قمت بفرزها حسب "عدم الموافقة" تحصل عليها
1 (هذا) مع 57 "رفض"
3586 (تذاكر أخرى) مع "رفض" واحد أو أقل

تضمين التغريدة

لماذا تعتقد أنه مهم؟ JSX هي طريقة لوصف الواجهة. إنها لغة حيادية في حد ذاتها. انظر هنا. إنها ليست JavaScript. لكن حسنًا ، لماذا لا يتم ذلك باستخدام JSX؟ (بجانب عدم وجود تنفيذ لهذا (حتى الآن))

إنها طريقة لوصف واجهة المستخدم _in Javascript_ (ومن هنا جاء جزء "JS" من الاسم). ولا ، نظرًا لأنه DSL مضمّن ، فهو _not_ حيادي اللغة. وحتى لو كان الأمر كذلك ، فلا يزال هذا لا يجعله "الخيار الأفضل" ، نظرًا لوجود الكثير من DSLs المحايدة للغة حقًا والتي ستكون غير مناسبة بشكل محزن لإعلانات واجهة المستخدم.

و .. كما تعلم ... يأتي التدفق من الفيس بوك أيضًا:

يشبه التدفق تمامًا TypeScript: نظام فحص ثابت لنوع Javascript. إنها ليست أداة React ، ولم يتم تصميم React لاستخدامها معها. React هي أولاً وقبل كل شيء مكتبة Javascript ، وقد تم تصميم JSX لاستخدامها مع React. مهما كانت الأدوات والمرافق الثانوية التي يتم إدخالها في تطوير React فهي في النهاية غير ذات صلة بقابلية التشغيل البيني React + JSX.

من فضلك ، توقف عن بيع الحجج المؤيدة والمعارضة للتمديدات التي لم تستخدمها أبدًا. أستخدم JSX كل يوم وأنا سعيد بها أجهزة الصراف الآلي ، على الرغم من أنني كنت متشككًا جدًا في ذلك. أستطيع أن أتخيل أن JSX تتطور في أنماط أخرى ، كما كانت مع AngularJS.

لقد استخدمت JSX ، وعلى الرغم من أن لدي آراء شخصية حولها ، فقد تركت هذه الآراء بشكل متعمد خارج هذه المناقشة. في الواقع ، لو قرأت تعليقاتي السابقة ، ستعرف أنني قد أشادت بـ JSX لإحداث ثورة في تطوير واجهة المستخدم في React. بخلاف بعض التعليقات العرضية بشكل معتدل التي أدليت بها حول اختراق السوق لـ JSX ككل ، كانت حججي على وجه التحديد حول JSX _in Flutter_. وحول هذا الموضوع ، لا يوجد أساس عملي لتحديد فعالية DSX ، لذلك كل ما يمكننا فعله هو فحص كيفية تنفيذ JSX في أماكن أخرى ، وهذا الفحص لا يبشر بالخير.

ما لم تكن ، بالطبع ، تستخدم DSX كل يوم أيضًا ويمكن أن تطلعنا على المزايا العملية لاستخدام DSX في Flutter؟

وربما يساعد هذا الموضوع في إيجاد نمط أفضل لـ Dart؟ DSX هو مجرد اقتراح واحد. انظر إلى مثال نمط البناء أعلاه أو تعديلات اللغة الأخرى المعروضة هنا. حسنًا ، ربما تكون فلوسك طريقة أفضل؟ انا لا اعرف. لكن دعنا نكتشف ذلك ونساعد بعضنا البعض لتحسين اقتراحاتهم بدلاً من مناقشة الأشياء السيئة في اقتراح شخص آخر.

_ هذا ما أفعله. _ يتم اقتراح DSX كحل لواجهة المستخدم للأشخاص المطلعين على JSX. هناك عناصر تصميم رئيسية في JSX كان من المفترض استخدامها في بيئة مختلفة تمامًا عن Dart و Flutter. _تحتاج هذه الاختلافات إلى المعالجة حتى يكون DSX ناجحًا. _ أنا لست مطورًا. أحاول تعزيز المناقشة البناءة وطرح الأسئلة المهمة. ومع ذلك ، فإن جميع الردود التي تلقيتها كانت بمثابة حشو شخصي ("JSX جيد لأنه المستقبل ، وهو المستقبل لأنه جيد") ، والتلويح اليدوي الرافض لنقاط التصميم الحاسمة ("لا يحتاج DSX إلى مراعاة بالنسبة للاختلافات بين JS و Dart لأنه لا يوجد أي منها ") ، أو مجرد عدائي واضح (" من الواضح أنك لا تحب JSX لذا توقف عن الحديث عن DSX ").

أنت لا تصنع منتجًا ناجحًا بمدح خالص. كما يجب عليها أن تقف في وجه النقد وتحاسبه أيضًا. يظهر الناس ويقولون "OMG نعم ، من فضلك ، اجعل DSX" ، أثناء الارتقاء ، ليس مفيدًا. كان هناك العديد من الأشخاص خلال هذا الخيط الذين أثاروا انتقادات صحيحة تمامًا لـ DSX ، سواء من خلال تصميمها الأولي أو مع المفهوم ككل. وبالنسبة للجزء الأكبر ، لا يزال يتعين معالجة العديد من هذه الانتقادات بشكل مباشر ، مع كون الموقف العام رافضًا.

خوفي الوحيد هو أن كل هذا الحب غير المشروط لـ JSX يمنع الناس من مشاهدة DSX بموضوعية. لقد فهمت لماذا تريدون شيئًا مثل JSX في Flutter ، ويمكنني أن أتحدث - رأيي أن Flutter يحتاج إلى واجهة مستخدم مخصصة DSL هو ما يقودني إلى إنشاء FLUI. ولكن إذا كان الأشخاص الوحيدون المسموح لهم بالتحدث عن DSX هم الأشخاص الذين ليس لديهم سوى الأشياء الجيدة ليقولوها عنها ، فسوف تفشل.

هل يمكننا إعادة مناقشة هذا الموضوع؟
في الواقع ، لا أرى أي سبب لإبقاء هذه المشكلة مفتوحة.

ذكر فريق دارت أن لديهم أولويات أخرى. وتطوع فريق JSX المحترف لتنفيذ DSX الخاص بهم

ربما يجب أن يكون لدينا عدد قليل من المستودعات مفتوحة المصدر تقترح حلولًا مختلفة (حتى بالكاد تعمل). مثل DSX أو القوالب.
ثم ضع في اعتبارك إعادة التوجيه من الملف التمهيدي لـ Flutter أو awesome_flutter إلى هذه المستودعات. وإذا كان هناك أي شيء يحظر تطبيق DSX ، فقم بإنشاء مشكلة أخرى مع التفاصيل.

ثم دع المجتمع يقوم بعمله.

اتركه مفتوحًا كما هو لأن الأشخاص سيستمرون في فتح تذاكر جديدة يطلبون فيها JSX (كما حدث بالفعل مرتين من قبل).

اتركه مفتوحًا كما هو لأن الأشخاص سيستمرون في فتح تذاكر جديدة يطلبون فيها JSX (كما حدث بالفعل مرتين من قبل).

الفرق هنا هو أننا سنتمكن الآن من الإجابة بما يلي:

"لا نخطط لتنفيذ هذا في dart / flutter في الوقت الحالي. ولكن يمكنك إلقاء نظرة على بدائل المجتمع [هنا] و [هناك] أو قراءة [هذه المشكلة]"

وأغلق المشكلة باعتبارها مكررة.

مكان واحد للتعليقات والتصويت وهو هنا. لن يتم إلغاء طلب وظيفة تشبه JSX ويتم فتح التذكرة لأنها تحتاج إلى دعم أدوات Flutter (مترجم و VS Code IDE) ولقد قمت بتحديث طلب التذكرة بهذه المعلومات (التعليق الأول). إذا بدأ عدد هائل من الأشخاص في طلب ذلك ، فسيمنح فريق Flutter حافزًا لوضع الموارد فيه.

يبدو أن معظم الجدل هنا ليس حول JSX في هذه المرحلة ، ولكن DSX. أقترح تقسيم مناقشة DSX إلى سلسلة محادثات خاصة بها وترك هذا الأمر عامًا لـ JSX.

في النهاية ، تعد DSX مجرد طريقة واحدة لتقريب شيء ما من JSX ، لذلك لا ينبغي أن نمزج هذين النقاشين في سلسلة واحدة بغض النظر.

لا يوجد شيء كبير لهذا ، أعتقد حقًا أن لغة واحدة فقط هي مكسب كبير ، وسيأتي بناء جملة jsx مع المزيد من الأشياء مثل فصل xml عن js ، وما إلى ذلك ... ليس جيدًا.

هذا رأيي.

هذه هي القضية الأطول والتي لا طائل من ورائها التي رأيتها على Github.

تضمين التغريدة
DSX + 1

BarryYan ، شكرا لك

يرجى تجنب هذا النوع من التعليق ، سواء كان "+1" أو "شكرا".
هذا يرسل بريدًا إلكترونيًا إلى جميع المشتركين من أجل لا شيء مثير للاهتمام.

يرجى تجنب هذا النوع من التعليق ، سواء كان "+1" أو "شكرا".
هذا يرسل بريدًا إلكترونيًا إلى جميع المشتركين من أجل لا شيء مثير للاهتمام.

لا شيء يثير اهتمامك !!!
يرجى تجنب إخبار الناس بما يمكنهم قوله أو فعله والتركيز فقط على ما يمكنك قوله أو فعله.

تضمين التغريدة

يا صاح ، إنها آداب أساسية. أي رسالة جديدة في هذا الموضوع ترسل إلى جميع المشتركين فيها عبر البريد الإلكتروني ، لذلك من الوقاحة نشر تعليق لا يساهم في المناقشة لأنه يزعج الناس بدون سبب. يمكن نقل ردود الفعل الأساسية مثل "+1" و "شكرًا" برد فعل بسيط بإبهام لأعلى ، لذا افعل ذلك.

ومع ذلك ، إذا كان هذا الموضوع قد تطور بالفعل إلى الجدل حول ما إذا كان يجب على شخص ما نشر رسالة "+1" أم لا ، فهذه علامة حمراء كبيرة مفادها أن جميع المناقشات البناءة قد ماتت رسميًا ، ويجب إغلاقها بالفعل (ربما بشكل دائم هذا الوقت).

almoshafs

لقد فهمت ذلك ولكن أثناء تواجدك فيه ربما يجب عليك أيضًا التفكير في قواعد السلوك الأساسية أثناء تفجير هذا الموضوع برواياتك (الكتابة الطويلة والخيالية).

يرجى التوقف عن نشر FUD (الخوف من الشك والشك) مع وابل الرش والصلاة من الأسئلة التي لا معنى لها (كما تعلم ، قم بإلقاء الكثير من الهراء على الحائط ومعرفة ما إذا كان هناك أي شيء عالق) والمطالب.

بعد كل كتاباتك ، لم تقم بإضافة أي قيمة إلى DSX ، لذلك ليس لدي اهتمام بإجراء مناقشة معك حول هذا الموضوع. دافعك واضح ، على الرغم من ذلك ، قم بالترويج لـ FLUI أثناء تفجير DSX.

أخبرني شيئًا ، هل لديك إجابات لأسئلتك الخاصة عندما يتم تطبيقها على FLUI؟ دعونا نناقش FLUI قليلاً ، فهل نحن؟

تضمين التغريدة

لقد فهمت ذلك ولكن أثناء تواجدك فيه ربما يجب عليك أيضًا التفكير في قواعد السلوك الأساسية أثناء تفجير هذا الموضوع برواياتك (الكتابة الطويلة والخيالية).

حقيقة أنك تشير إلى ردودي بأنني بذلت الكثير من الوقت والجهد لكي أكون مدروسة جيدًا وغير متحيزة حيث يمكنني أن أجعلها على أنها "كتابة طويلة وخيالية" توضح الكثير عن شخصيتك وكيف تتعامل معها هذه المناقشة. أحاول تعزيز المناقشة فيما يتعلق بالقضايا الحقيقية للغاية التي تحيط بأي تطبيق لـ JSX في Flutter ، بينما أنت تهاجم أي شخص لديه أي شكل من أشكال الرأي المخالف. من منا هو الجاني الأكبر للآداب الأساسية؟

يرجى التوقف عن نشر FUD (الخوف من الشك والشك) مع وابل الرش والصلاة من الأسئلة التي لا معنى لها (كما تعلم ، قم بإلقاء الكثير من الهراء على الحائط ومعرفة ما إذا كان هناك أي شيء عالق) والمطالب.

الشيء الوحيد الذي "أطالب به" هو أنك تعالج العديد من القضايا التي أثارها العديد من الأشخاص بخصوص DSX بأكثر من موجة عداء أو عداء مفتوح. بالنسبة إلى شخص يقترح تغييرًا / إضافة كبيرة إلى مجموعة ميزات Flutter ، أشعر أن هذا ليس توقعًا غير معقول.

بعد كل كتاباتك ، لم تقم بإضافة أي قيمة إلى DSX ، لذلك ليس لدي اهتمام بإجراء مناقشة معك حول هذا الموضوع. دافعك واضح ، على الرغم من ذلك ، قم بالترويج لـ FLUI أثناء تفجير DSX.

أطلب منكم الدفاع عن موقفكم. لقد قلت مرارًا وتكرارًا أن JSX / DSX هو الأفضل / المستقبل ، لكنك لم تشرح بعد كيف ولماذا. أعرب العديد من الأشخاص عن مخاوفهم بشأن DSX ، ولكن بدلاً من معالجتها ، فإنك تلجأ إليها بالاختباء وراء الحجة المضادة "إذا لم تعجبك ، فلا تستخدمها". إن "الدافع" الخاص بي هو دفعك للإجابة على الأسئلة التي يجب طرحها بخصوص _ أي _ مشروع تقني ، أولاً وقبل كل شيء لماذا يجب على الأشخاص استخدامه بدلاً من البدائل. (وكما أوضحت من قبل ، فإن الألفة ليست سببًا جيدًا بما يكفي).

بقدر ما يتعلق الأمر بـ FLUI ، كل ما أفعله هو اقتراح حل بديل للمشكلة الكلية (بناء جملة تعريف واجهة المستخدم لـ Flutter) بينما أطلب من الناس أن يفعلوا الشيء نفسه مع DSX - تقديم نقد صادق وبناء. أنا لا أقول أن FLUI أفضل من الناحية الموضوعية من DSX - أقترح بديلاً يتكون من نهج مختلف لتطوير واجهة المستخدم وأطلب من الناس تكوين آرائهم الخاصة.

(أود أيضًا أن أشير إلى أنه بخلاف ذكري الأولي حيث كنت أقترح نهجًا بديلاً محتملاً لتمثيل واجهة المستخدم الرسومية ، فإن المرات الوحيدة التي تحدثت فيها عن FLUI هي عندما طرحتها. فكيف يتم ذلك من المنطقي أن يكون دافعي الخفي هو الترويج لها عندما تتحدث عنها أكثر مما أنا عليه الآن؟)

أخبرني شيئًا ، هل لديك إجابات لأسئلتك الخاصة عندما يتم تطبيقها على FLUI؟ دعونا نناقش FLUI قليلاً ، فهل نحن؟

FLUI ليس DSX - ليس من الضروري الإجابة على كل الأسئلة التي طرحتها عليك بخصوص DSX لأن العديد منها خاص بتصميم DSX. هذا لا يعني أنه ليس لديه مجموعة الأسئلة الخاصة به التي تحتاج إلى إجابة ، ومع ذلك ، لا ، ليس لدي كل هذه الإجابات. هذا _لماذا_ أقدر المناقشة النقدية - لن تقف FLUI / DSX أمام محكمة الرأي العام ما لم يتمكنوا من النجاة من التعرض للجروح عدة مرات. لكن ليس هذا هو المكان المناسب لمناقشة FLUI. إذا كنت ترغب في مناقشة FLUI مطولًا ، فإن المشروع له لوحة مشكلات خاصة به ، لذلك لا تتردد في النشر هناك.

بدلاً من الرد على النقد ، كنت بدلاً من ذلك دفاعيًا ومراوغًا ، لدرجة أنك مسؤول بشكل مباشر عن مناسبتين منفصلتين (تقترب من ثلاثة) حيث كان يجب إغلاق هذا الخيط مؤقتًا بسبب سخونة الأمور. لذا سأخرج من "آداب السلوك" وأقول هذا مرة واحدة: ارفع غرورك ، وتوقف عن تفسير الانتقادات على أنها هجمات شخصية ، وأجب عن الأسئلة المهمة. إما ذلك ، أو عقد السلام مع DSX أبدًا.

andrewackerman عمل جيد 👍
+ 1

تضمين التغريدة

أحسنت

يا صاح ، هل تحصل على مجاملة من jstansbe الذي ينقل معلومات أكثر بكثير من الإبهام لأعلى وأنت تتجاهل المجاملة؟

من الواضح أنك لم تأخذ تلميحي بالتفصيل ولكن لا تتوصل إلى استنتاجات حول شخصيتي لأنك لا تعرفني على الإطلاق.

حقيقة أنك تشير إلى ردودي أنني بذلت الكثير من الوقت والجهد لأكون مدروسة جيدًا وغير منحازة بقدر ما أستطيع أن أجعلها

إنني أقدر وأقرأ كل `` كتاباتك الطويلة '' ، والإجابة على كل شيء: مستحيل ، لكن عندما أجيب بشكل صحيح ، فأنت لا تفهم إجابتي وتخلص إلى أنني أرفض.

من الواضح بالنسبة لي أنك لست خبيرًا جدًا في JSX ، فأنت لا تفهم حقًا كيف يعمل. لذا بدلاً من المضاعفة ، امتلكها وسأشرحها بمزيد من التفصيل. على سبيل المثال ، يقوم JSX و DSX بإجراء التحولين التاليين فقط (تم ذكرهما عدة مرات من قبل):

(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" ، وما إلى ذلك. ينتهي بك الأمر ببناء لغة برمجة تعريفية داخل الترميز لا يمكن أن تكون أبدًا بنفس قوة لغة الترميز. لغة البرمجة الرئيسية. لذلك من خلال إدخال الترميز في لغة البرمجة لديك أفضل ما في العالمين وهذه هي قوة JSX / DSX.

لاحظ أعلاه في (2) أن التحويل الثابت <Widget> وهذا ليس هو الحال دائمًا ، لذلك يمكنك الآن تحديد ذلك إذا لزم الأمر كما تمت مناقشته من قبل. انظر إلى التحولات والآن جميع الرموز تأتي من المصدر أو يمكن تحديدها حتى لا يكون هناك بعض المشاكل السحرية الرئيسية في المستقبل.

بينما تنتقد أي شخص بأي شكل من أشكال الرأي المخالف.

هذا ليس صحيحًا ، يمكن أن يكون لديك رأي مخالف ولكن لا يمكنك الادعاء بأن شيئًا صحيحًا عندما يمكنني إثبات خلاف ذلك.

بالنسبة إلى شخص يقترح تغييرًا / إضافة كبيرة إلى مجموعة ميزات Flutter ، أشعر أن هذا ليس توقعًا غير معقول.

ولكن هذا هو الشيء ، أردت أن يقوم فريق Flutter بتنفيذ DSX ولكن بعد ذلك قمت بذلك ، لذا فإن ما يحتاجون إلى تنفيذه هو أشياء عامة لا تعتمد على DSX و DSX ليست المستفيد الوحيد. يدعم محرك المتصفح js خرائط المصدر التي مكّنت نظامًا بيئيًا للغات جديدة في المتصفح تم تحويله إلى js ؛ انها مكنت من خلق دارت !!! والعديد من الآخرين (Coffeescript ، و Typescript ، و Reason ، إلخ). يمكن لـ Dart أن تفعل الشيء نفسه الآن وتستفيد من النظام البيئي الذي تساعده في إحضاره ، ترتفع جميع القوارب.

أنا أطلب منك الدفاع عن موقفك.

لقد قمت بذلك بالفعل عدة مرات والاستنتاج هو أن Plain Dart أو DSX يعود إلى تفضيلات المستخدم ؛ والمهم هو توفير خيار بدلاً من إجبار الناس في اتجاه واحد.

أولاً وقبل كل شيء لماذا يجب على الناس استخدامه بدلاً من البدائل.

سأستخدم DSX لأنني أفضله ، مثل المسافات أو علامات التبويب ، اكتب التعريف قبل أو بعد اسم المتغير. لا جدوى من القتال من أجل ذلك ، فقط تقبل أن الناس لديهم تفضيلات مختلفة ؛ يوجد أكثر من محرر برمجة ، أليس كذلك؟

الألفة ليست سببا كافيا وجيها

فقط رأيك ، لماذا نستخدم عبارات "if" في كل لغة تقريبًا ، لـ "بيان" ، "فئة" ، والآن "asyn / await".

لكن ليس هذا هو المكان المناسب لمناقشة FLUI. إذا كنت ترغب في مناقشة FLUI مطولًا ، فإن المشروع له لوحة مشكلات خاصة به ، لذلك لا تتردد في النشر هناك.

جيد جدا ، لقد اكتسبت احترامي الآن.

أنت مسؤول بشكل مباشر عن مناسبتين منفصلتين (تقترب من ثلاثة) حيث كان يجب إغلاق هذا الخيط مؤقتًا بسبب سخونة الأشياء.

الشيء حتى إذا تم إغلاقه مرة أخرى ، فلن يمنع الناس من طلب إمكانات شبيهة بـ JSX.

رفِف غرورك ، وتوقف عن تفسير الانتقادات على أنها هجمات شخصية ، وأجب عن الأسئلة المهمة.

ليس لدي غرور ولكن لدي مزاج قصير لذلك لا يوجد خطأ عندما يزعجني شخص ما (يخرج على الفور). لا يسيء إليك ولكن أسئلتك لم تكن مهمة.

إما ذلك ، أو عقد السلام مع DSX أبدًا.

أنت لست المقياس المستخدم لقياس النجاح ولا تعرف ما الذي أفعله.

يا صاح ، هل تحصل على مجاملة من jstansbe الذي ينقل معلومات أكثر بكثير من الإبهام لأعلى وأنت تتجاهل المجاملة؟

من الواضح أنك لم تلتقط السخرية الكامنة في تعليقه. (لقد فعل حرفيًا كل ما قلته ألا أفعله.) في حين أنه كان شيئًا ممتعًا من التصيد الذي يمكنني تقديره ، إلا أنه ليس مناسبًا هنا. وإذا كان صادقًا ، بالصدفة ، فأنا أعتذر عن خبثتي ، لكن وجهة نظري لا تزال قائمة - هذا النوع من التعليق _لا يزال_ غير مناسب هنا.

من الواضح لي أنك لست خبيرًا جدًا في JSX ...

هل كان إخلاء المسؤولية الخاص بي في تعليقي الأول على هذا الموضوع قد أفادك؟

... أنت لا تفهم حقًا كيف يعمل.

أنت تساوي أنني لا أملك خبرة كبيرة مع JSX وأنا لا أعرف كيف يعمل على الإطلاق؟ على الرغم من أنني لم أعمل مطلقًا في أي مشروع React جاد ، فقد أنجزت نصيبي العادل من الترقيع. أنا أفهم جيدًا كيف _يعمل_.

يتم التعامل مع كل شيء آخر بواسطة اللغة المضيفة ، على سبيل المثال: كيف تتعامل مع استيراد المكونات التي تحمل نفس الاسم؟ الجواب: لغة المضيف.

وهذا منطقي في حالة تمييز لغة الترميز واللغة المضيفة. باستخدام JSX ، تم تصميم لغة الترميز على أنها _ امتداد_ للغة المضيفة. على هذا النحو ، تم تصميم JSX على أنه امتداد لـ JS ، وهذا هو السبب في أنها تعمل بشكل جيد. DSX هو تطبيق لـ JSX لـ Dart.

ألا ترى المشكلة هناك؟ لغة ترميزية مصممة على أنها امتداد للغة واحدة يتم تزويرها في لغة مختلفة أساسيًا. لا مفر من وجود عدد كبير من المشكلات وحالات الحافة والاعتبارات.

ترى ما إذا كنت تفصل بين الترميز والبرمجة في ملفات منفصلة ، تبدأ في تكرار البرمجة داخل الترميز باستخدام تركيبات بسيطة لـ "if" ، وما إلى ذلك. ينتهي بك الأمر ببناء لغة برمجة تعريفية داخل الترميز لا يمكن أن تكون أبدًا بنفس قوة لغة الترميز. لغة البرمجة الرئيسية.

أولاً ، الفكرة الكاملة وراء فصل الترميز والبرمجة هي أنه إذا كنت تقوم بذلك بشكل صحيح ، فهناك فصل واضح بين الاثنين مما ينتج عنه _لا_ تكرار.

ثانيًا ، إذا كنت تفعل شيئًا أكثر تعقيدًا من if s و for s في كود واجهة المستخدم (وهي بنيات يمكن التعامل معها بسهولة في العديد من حلول الترميز) ، فأنا أزعم ذلك إنها علامة على وجود خطأ ما في التصميم الخاص بك على أي حال. وفقًا لمبادئ تصميم MVC / MVVM ، إذا كنت تدمج منطقًا معقدًا في تصميمات واجهة المستخدم الخاصة بك ، فهذه علامة محتملة على وجود شفرة كريهة الرائحة ويجب عليك التفكير بجدية في إعادة التصميم على أي حال.

(هذا لا يعني أنك لا تستطيع أن تكتب واجهة مستخدم تعريفية بأسلوب MVVM باستخدام JSX ، ولكنها مجرد شيء يدعو إلى المتاعب لتحقيق مكاسب موضوعية قليلة. لماذا تستخدم شيئًا يمكنك فيه كتابة رمز متوافق مع المعايير عندما يمكنك استخدامه شيء يجعل من الصعب كتابة رمز _ليس كذلك؟)

هذا ليس صحيحًا ، يمكن أن يكون لديك رأي مخالف ولكن لا يمكنك الادعاء بأن شيئًا صحيحًا عندما يمكنني إثبات خلاف ذلك.

أنت لم "تثبت" أي شيء. لقد قدمت مجموعة من الادعاءات الذاتية التي لم يتم دعمها بأي منطق إثبات. (على الرغم من أن هذا المنشور الأخير يُعد تحسنًا كبيرًا في رصيدك.)

ولكن هذا هو الشيء ، أردت أن يقوم فريق Flutter بتنفيذ DSX ولكن بعد ذلك قمت بذلك ، لذا فإن ما يحتاجون إلى تنفيذه هو أشياء عامة لا تعتمد على DSX و DSX ليست المستفيد الوحيد.

أنت لا تزال تطلب منهم القيام بأشياء غير تافهة ، لذا فإن المسؤولية تقع على عاتقك لإقناعهم وبقيةنا لماذا يجب عليهم ذلك ولماذا من المهم جدًا أن يدفعوا أشياء أخرى إلى قائمة المهام الخاصة بهم.

يدعم محرك المتصفح js خرائط المصدر التي مكّنت نظامًا بيئيًا للغات جديدة في المتصفح تم تحويله إلى js ؛ انها مكنت من خلق دارت !!!

من طبيعة JS نفسها أن مثل هذا الشيء يمكن تنفيذه بسهولة (بشكل نسبي) ، لدرجة أن Dart بعيدة كل البعد عن اللغة الوحيدة التي تحتوي على مترجم إلى JS. كما أشرت عدة مرات ، فإن Dart ليس JS. إنها ثابتة ومكتوبة بقوة ، مما يعني أن الكثير من الأشياء التي سيكون من السهل القيام بها في JS معقدة للغاية في Dart.

سأستخدم DSX لأنني أفضله ، مثل المسافات أو علامات التبويب ، اكتب التعريف قبل أو بعد اسم المتغير. لا جدوى من القتال من أجل ذلك ، فقط تقبل أن الناس لديهم تفضيلات مختلفة ؛ يوجد أكثر من محرر برمجة ، أليس كذلك؟

من خلال هذا المنطق ، يجب أن أقوم بعمل حل لواجهة المستخدم تحدد فيه التركيبات باستخدام طريقة برايل ذات التشفير السداسي. أعني ، إذا كان كل ما يهم حقًا هو التفضيل الشخصي ، فكل ما أريد قوله للدفاع عن وجوده هو أن "بعض الناس يفضلونه" ، أليس كذلك؟

أنت تطور أداة تنوي أن يستخدمها الآخرون ، لذا فأنت بحاجة إلى تفكير يتجاوز عبارة "قد يحبها بعض الأشخاص" لتجعل نفسك مقنعًا. إذا لم تتمكن من صياغتها في كلمات _لماذا_ يجب عليهم استخدامها بدلاً من شيء آخر ، فما الذي يجعلك تعتقد أنهم سيفعلون ذلك؟ وما الذي يحفزك على التأكد من أنهم سيفعلون ذلك عند تصميم مجموعة ميزات DSX؟

فقط رأيك ، لماذا نستخدم عبارات "if" في كل لغة تقريبًا ، لـ "بيان" و "فئة" والآن "غير متزامن / انتظار".

أولاً ، أصبحت هذه الكلمات الرئيسية (بصرف النظر عن async/await ) معجم برمجة شائعًا بسبب الشعبية الهائلة للغات مثل C و BASIC على مدار عدة عقود. كما ذكرت من قبل ، JSX بعيد عن إثبات طول عمرها - لقد كانت موجودة منذ 5 سنوات ولم تشهد بعد أي استخدام مهم خارج React على الرغم من توفر الخيار.

ثانيًا ، هناك فرق كبير بين الألفة والتقاليد. if ، while ، for ، struct ، class ، enum ، try/catch/finally ، async/await ... هذه كلها طرق رائعة لتمثيل المفهوم شفهيًا. هناك أسباب للدفاع عن استخدام هذه الكلمات الرئيسية بخلاف كونها مجرد ما يعرفه الناس - فهي منطقية من الناحية المفاهيمية. (بالطبع ، هذا لا يعني أنها ثوابت. بعض اللغات تفعل if ... then . البعض يفعل if ... elif بينما البعض الآخر يفعل if ... else if والبعض الآخر يفعل if...endif . البعض يفعل foreach ، والبعض الآخر يفعل from . وهكذا دواليك.)

وفي الوقت نفسه ، فإن حجة استخدام JSX لأنها "مألوفة" لا تناسب نفس الفئة. JSX هي إحدى طرق تمثيل واجهة المستخدم التعريفية ، ولكنها ليست الوحيدة أو الأكثر شيوعًا. علاوة على ذلك ، فقد تم تصميمه ليتم استخدامه في نوع واحد من البيئة ، لذا فإن استخدامه في بيئة أخرى يمكن أن يحول الألفة إلى شيء سيء - فالألفة تدفعهم إلى توقع أنها تعمل بشكل أو بآخر تمامًا بالطريقة نفسها التي تعمل بها في مكان آخر ، لذلك إذا كان الأمر كذلك لا يؤدي ذلك بعد ذلك إلى انفصال عقلي وهو شيء تريد تجنبه.

الشيء حتى إذا تم إغلاقه مرة أخرى ، فلن يمنع الناس من طلب إمكانات شبيهة بـ JSX.

يطلبون ذلك على أي حال ، ويتم إعادة توجيه المشكلة هنا على الرغم من ذلك. لا أرى كيف سيؤدي إغلاق الموضوع إلى تغيير ذلك.

أنت لست المقياس المستخدم لقياس النجاح ولا تعرف ما الذي أفعله.

اقرأ أي كتاب عن تصميم المنتج. يدور الفصل الأول دائمًا حول إنشاء بيان أو بيان أو شعار أو أي شيء ملموس ويمكن التعبير عنه بلغة إنجليزية بسيطة يصف ماهية المنتج ولماذا يجب أن يهتم الناس به. هناك سبب لكون النصيحة الأكثر شيوعًا التي يتم تقديمها لرواد الأعمال الهواة هي تقديم "عرض ترويجي" ، وهو شيء ينقل المنتج بشكل واضح وموجز والسحب في 30 ثانية أو أقل. إذا كنت لا تستطيع أن تشرح بإيجاز لماذا يجب على الناس استخدام منتجك ، فهذه علامة على أنه يعاني من أزمة هوية. إذا لم يستطع الشخص الذي يصمم المنتج الاستجابة بشكل كافٍ للنقد ، فهذا يعطي انطباعًا بعدم الثقة في منتجه. كلا هذين الأمرين يمثلان إشارات حمراء كبيرة للمستثمرين.

في هذه الحالة ، المنتج هو DSX ، والمستثمرون يفكرون في استخدامه. الأشخاص الوحيدون الذين تدعمك هم الأشخاص الذين يبدو أنهم سيشجعون دون قيد أو شرط لأي شيء مع "JSX" في الوصف. كل شخص آخر في هذا الموضوع رأيته يتساءل عما تفعله قد ابتعد على ما يبدو غير مقتنع باتباع إجابتك.

أنت حاليًا تجلس عند معدل تحويل 0٪ أو بالقرب منه ، وهذا هو المكان الذي أتيت منه عندما أقول إنك لم ترد بعد بشكل كافٍ على النقد. ربما لا تهتم ، ولكن إذا كنت تنوي بجدية أن يكون DSX مكونًا إضافيًا لترميز إعلان واجهة المستخدم ويمكن استخدامه في مشاريع العالم الحقيقي ، فقد ترغب في البدء.

لكن مرة أخرى ، ربما تكون استثناءً.

حسنًا ، لقد تجاوزت هذه المحادثة أنواع المناقشات التي نعتبرها مقبولة في مجتمع Flutter ، ولذا سأقوم بإغلاق هذا الموضوع وإغلاق الخطأ. يرجى النظر في قراءة https://flutter.io/design-principles/#conflict -resolution لمزيد من التفاصيل حول كيفية تصرفنا هنا.

ستكون الخطوة التالية إذا أراد أي شخص المساهمة في رمز لمعالجة هذه المشكلة هو التوصل إلى تصميم لكيفية إنشاء تكامل النظام بحيث يمكننا إنشاء رمز مع Gradle و Xcode وإعادة التحميل السريع والتكامل مع التطبيقات الحالية. إذا كان أي شخص مهتمًا بالعمل على هذا ، فيرجى عدم التردد في التواصل معي. وإلا أتوقع أن هذا شيء سنعمل عليه في أوائل العام المقبل. بمجرد أن يكون لدينا آلية للقيام بذلك ، سيكون من السهل دمج حلول مثل DSX في نظام Flutter البيئي. قد نجد حلولًا يجب دمجها افتراضيًا. في غضون ذلك ، نعمل أيضًا على إدخال تحسينات على بنية Dart لمعرفة ما إذا كان بإمكاننا تسهيل كتابة تعبيرات واجهة المستخدم.

أود أن أطلب من الناس عدم فتح أخطاء جديدة حول هذا الموضوع ما لم يكن هناك شيء بناء وجديد للغاية يستحق التطرق إليه.