Flutter: اعتبر شبيهة بـ JSX على أنها React Native

لقد تم السؤال عن هذا لفترة طويلة:
https://github.com/flutter/flutter/issues/11609
تم تطوير النموذج الأولي الوظيفي:
https://spark-heroku-dsx.herokuapp.com/index.html
وهذا يدل على البديل وبعض الفوائد ...

المشكلة الحالية في DSX تتعلق بالتكامل الصحيح مع أدوات Flutter لتوفير تجربة مطور رائعة مع مصحح الأخطاء والإكمال التلقائي وما إلى ذلك ، والعمل على ملفات .dsx.

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

إذا كنت تستطيع وتريد المساعدة ، أعلمني بذلك.

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

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

أستخدم Android Studio. أنا لا أرى حتى علامة إغلاق افتراضية. على الرغم من أن لدينا علامة إغلاق افتراضية ، إلا أنها أكثر تعقيدًا من HTML التي يكرهها الجميع. Dart هي مجرد لغة برمجة. لا يفهم الأشخاص في Google أهمية التبسيط.

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

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

لا أرى كيف يختلف هذا عن JSX ... فكلما كبرت الشجرة ، يمكنك تقسيم الأشجار الفرعية الصغيرة بكليهما.

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

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

هذا هو نسخة مزدوجة من قفل مغلق # 11609
sethladd ؟

معذرةً ، يجب أن تشاهد "علامات الإغلاق الافتراضية" في IntelliJ و Android Studio.

ccdevoncarew للتحقق من الإصدار الذي تم تشغيله ، أو ما إذا كان المستخدم بحاجة إلى الاشتراك؟

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

هذا لا يخدع # 11609 لكني أود أن يضيفdevoncarew أو @ mit-mit ملاحظة حول كيفية تشغيل "علامات الإغلاق الافتراضية" ، إن أمكن.

شكرا!

JonathanSum ، التسميات الختامية غير متوفرة في Android Studio 3.0 للأسف. ستحتاج على الأقل إلى IntelliJ 2017.3 أو Android Studio 3.1. Android Studio 3.1 حاليًا في مرحلة الإصدار المرشح ، ونخطط لإصدار مكون إضافي flutter مع دعم له غدًا.

بصرف النظر عن المحادثة حول بناء جملة مثل JSX ، نريد العمل من أجل تسهيل كتابة كود واجهة المستخدم في Dart ، في كل من IntelliJ / Android Studio و VS Code. هذا في البداية هو عمل تسمية الإغلاق ، ولكن أيضًا عرض Flutter Outline الأخير. يُظهر ذلك بنية طريقة الإنشاء () في عرض مخطط تفصيلي ، ويسمح لك بالتنقل في عناصر واجهة المستخدم ورؤية العلاقات بين الوالدين / الأطفال بسهولة أكبر. هذا متوفر حاليًا في IntelliJ - نتوقع أن نتمكن من تقديمه إلى VS Code أيضًا.

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

sethladd - من فضلك لا تغلق هذا الموضوع ؛ أعتقد أن مناقشة المجتمع للمزايا والعيوب على طرق التخطيط البديلة أمر مفيد. كنت سأشارك في # 11609 لو لم يتم قفلها.

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

في NativeScript ، لدينا بالفعل الملفات التالية:

• screen.js / screen.ts (يتم تحويل ts إلى .js إذا كنت تفضل الكتابة المطبوعة). هذا هو المنطق الرئيسي للشاشة التي تعرضها.
• screen.css (أو screen.android.css و / أو screen.ios.css ) وهو إصدار محدود من CSS ولكنه يدعم أشياء مثل الطول والعرض واللون والخلفية وما إلى ذلك. هناك حاجة إلى ملف css واحد فقط ، ولكن في بعض الأحيان إذا كنت تفعل شيئًا غريبًا ، يمكنك فصل css عن android و ios. إنه يحتوي على دعم كامل للفئات والعناصر والمعرف لذا يمكنني أن أفعل TextArea.Login #Password وسيقتصر في الواقع على سلسلة العناصر المحددة.
• screen.xml (مرة أخرى أو screen.android.xml و / أو screen.ios.xml ) - هذا هو تخطيط الشاشة. يمكنك ترميز التخطيط في JS إذا كنت تريد (بشكل أساسي مثل الرفرفة) ؛ لكن XML أسهل بكثير. مثال:

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

الشيء المثير للاهتمام هو أن ActionBar هو مكون محدد للصفحة فقط (أي أنه خاص بالصفحة فقط) ؛ لذا فإن ما يحدث هو صفحة مشاهدة محلل XML ؛ يقوم بإنشاء عنصر صفحة جديد ؛ ثم يقوم بإنشاء مكون ActionBar والذي يقوم بتشغيل وظيفة builderChild على مكون الصفحة ؛ يتجاوز مكون الصفحة الباني الافتراضي ويبحث لمعرفة ما إذا كان الطفل هو ActionBar ؛ اذا كانت؛ ثم يقوم بتعيينها داخليًا إلى المتغير المناسب ؛ وبخلاف ذلك ، يتم تمرير الباقي من خلال الوالد / المشرف الذي يقوم بعد ذلك بتعيينه للمكونات "الفرعية" أو "الفرعية" تلقائيًا. نظام البناء متعدد الاستخدامات بشكل لا يصدق حيث يمكن لكل مكون استخدام وظيفة Builderchild الخاصة بالوالد أو تجاوزها للقيام بالعناصر الإضافية مثل support <Label>Hi</Label> وتعيين ذلك إلى قيمة Text تلقائيًا. هذا يجعل التخطيط والتشغيل أمرًا سهلاً للغاية بدون أي تعليمات برمجية.

نظرًا لأن معظم المحررين يتمتعون بقدرة جيدة على تحرير XML ، يتم تلوينه تلقائيًا ومع تعريف xsd المناسب ، يقوم intellij (& vscode) بفحص تلقائي ودعم محدود للسياق.

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

الشيء الجميل في هذا ؛ هل يسمح لمطوري الويب بالقفز مباشرة مع إعادة تدريب قليلة جدًا (إن وجدت). حقيقة؛ بسبب العارض المرن وكونه يعتمد على JS - يدعم NativeScript بالفعل Angular و Vue - بحيث يمكنك بالفعل مشاركة ما يقرب من 95 ٪ من قاعدة الشفرة بين الويب وتطبيق الهاتف المحمول الخاص بك إذا كنت تستخدم Angular أو Vue. نظرًا لأنه يستخدم مكونات نظام التشغيل الأصلي مثل رد فعل أصلي (وليس عرض ويب مثل كوردوفا) ؛ إنه حقًا نظام مناسب عبر الأنظمة الأساسية (وهذا أفضل من برنامج imho من React Native). ومع ذلك ، يمكنني أن أرى أين توجد بعض نقاط القوة التي يتمتع بها Flutter والتي تجعله أداة تكميلية جيدة لبعض تطوير الأجهزة المحمولة حيث إنها بعض التطبيقات التي يكون NativeScript أسوأ فيها وبعضها لا يزال أفضل بكثير ويستند إلى الردود على بلدي قضايا من إيان ؛ ستبقى الأداة الأفضل إلى حد كبير في تلك المناطق.

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

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

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

zoechi - في الواقع أعتقد أن أي نقاش حول ميزة جديدة يجب أن يكون هنا. يجب الحفاظ على السجل بحيث عندما يأتي John Doe بعد شهر من الآن ويبحث عن ميزة XYZ ، يمكنه: +1: ميزة موجودة و / أو المساهمة فيها.

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

تم قفل الخيط لأن فريق Flutter لا يهتم بالقيام بذلك ويريدون فقط من الناس أن يتوقفوا عن الحديث عنه.

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

في الواقع ، إذا كانت NativeScript بهذه الجودة ، فلماذا تهتم باستخدام Flutter على الإطلاق بدلاً من محاولة جعل Flutter NativeScript مثل.
أنا قادم من منصة تستند إلى XML (Xamarin Forms) وأعتقد في البداية أنه قد يكون من الصعب تصميم التعليمات البرمجية ولكن هذا ليس هو الحال.
على العكس من ذلك ، من السهل جدًا تقسيم التصميم الخاص بك إلى فئات منفصلة يسهل صيانتها.

يتم تصميم JSX في التعليمات البرمجية !!!

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

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

حسنًا ، لنتحدث عن تصميم DSX الخاص بي والذي يمكن مشاهدته هنا:
https://spark-heroku-dsx.herokuapp.com/index.html

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

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

أنا وافد جديد إلى Flutter ، ولدي بعض الخبرة فقط مع Android و Java ، ويجب أن أقول إنني أجد ما يقدمه Flutter أفضل بكثير مما هو مقترح هنا. أميل إلى العثور على أن XML قبيح وغير عملي. من الأجمل بكثير أن يكون لديك شخصية ختامية فردية ، بدلاً من بحر منهذا يجعل الكود الخاص بي أطول بمقدار 5 أضعاف ، وهو كراهية لي عند تحرير Android XML ، وعلامات الإغلاق الافتراضية فقط التي تستخدمها الغالبية العظمى من IDEs التي يستخدمها الأشخاص. هذا مفيد بشكل لا يصدق عند تصميم هياكل أطول. لا تفوق لغة XML المتداخلة الأنيقة على بقية العيوب ، في رأيي ، خاصةً عندما يقوم "child: / children" بعمل جيد تقريبًا. Dart نظيف بشكل لا يصدق ، وهذا سبب يعجبني كثيرًا. سأكون محبطًا بشكل لا يصدق إذا تم تدمير هذا.

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

بعض الملاحظات من DSX مقابل مقتطفات Dart التي تم إنشاؤها:

1. شخصي: لا أرى أي مكاسب كبيرة في قابلية القراءة. الإسهاب مشابه - إن لم يكن قليلاً. يوفر المكون الإضافي Dart IDE علامات الإغلاق التلقائي ، والتي تعكس علامات إغلاق العلامات التعريفية. إذا كان JSX مصممًا في رمز ، فأنا لا أرى كيف أن عناصر واجهة المستخدم في Dart ليست كذلك.

2. خصائص متعددة في <vars>

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

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

بالنسبة إلى Text ، يبدو أن معظم ما أحتاجه لإعادة استخدامه محدد TextStyle ، بدلاً من مزيج من عدة خصائص. ربما يمكنك العثور على مثال آخر غير Text حيث لم يكن الأمر كذلك.

بالنظر إلى TextStyle ، أجد النسخة الحالية + الثابتة () رائعة لإعادة الاستخدام والتأليف في Dart:

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

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

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

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

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

في أي من هذه الحالات ، سأحتاج إلى إنشاء Container باستخدام أداة أخرى: Material ، Padding ، Center إلخ. لذا إذا كان عليّ إنشاء أداة "حاوية" مخصصة قابلة لإعادة الاستخدام على أي حال ، لا أرى الكثير من المكاسب لامتلاك نمط <vars> خارجي من شأنه أن يحدد فقط خصائص عنصر واجهة مستخدم واحد في التسلسل الهرمي لعناصر واجهة المستخدم القابلة لإعادة الاستخدام.

لا أرى "كل شيء عبارة عن عنصر واجهة مستخدم" في Flutter يعمل بشكل جيد مع أنماط "خصائص متعددة".

1. لم يتم تمييزه في أمثلة DSX الحالية: كيف يمكنك ترميز واجهة باستخدام عناصر واجهة مستخدم ديناميكية؟ المعنى: كيفية إظهار أو عدم إظهار بعض الأدوات حسب الحالة.

عند القيام بالتصميم في Dart ، من السهل والمريح إضافة أو عدم إضافة أداة معينة إلى children .
من الملائم جدًا أيضًا التفاف عنصر واجهة مستخدم ديناميكيًا بأخرى. يجعل وظيفة build () بطلاقة وسهلة الفهم.

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

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

    children.add(wb);

@ SirComputer1 ، يُعد اقتراح DSX إضافة ، والطريقة الحالية لا تتغير ، لذا إذا لم تعجبك ، فلا تستخدمها ، فاستمر كما أنت اليوم.

تم تنفيذ الشيء <var> للعرض التوضيحي فقط لأنني لم أرغب في تحليل Dart بالكامل. لن يتضمن الحل النهائي <var> ولكنه سيستخدم أي متغير dart. كما تم عمل العلامة "@" فقط للعرض التوضيحي لتسهيل عملية التحليل. الحل النهائي لن يشمل ذلك.

لا تنس أن أي شيء آخر في الملف هو رمز Dart العادي ، لذا يمكنك استخدامه لأي شيء آخر.

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

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

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

    children.add(wb);

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

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

escamoteur - لا أميل إلى استخدام المطرقة كمحرك لولبي. أقوم بتقييم التقنيات المختلفة واستخدام التقنية المناسبة لحالة الاستخدام المناسبة. هذا لا يعني أنه يمكن تغيير الأشياء الخاصة بهم للأفضل في كل من الأنظمة الأساسية. : ابتسامة عريضة:

علي سبيل المثال؛ تكامل ملحقات الطرف الثالث. NativeScript هو ملك حقًا على كل منصة مشتركة أخرى. لا شيء آخر يقترب من NativeScript حتى عن بعد ؛ وتكامل الطرف الثالث. لدي عميل يسأل عن استخدام https://github.com/vipulasri/Timeline-View . رفرفة مستحيل عمليا. أعطني NativeScript بضع ساعات وستعمل تمامًا مثل أي عنصر تحكم NS آخر ربما حتى مع ربط البيانات العامل بشكل كامل. على الجانب الآخر ، يحتوي الرفرفة على بعض نقاط القوة الجادة حيث أعلام NS ...

استخدم الأداة المناسبة لهذا المنصب. : ابتسامة عريضة:

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

لقد فكرت بالفعل في إضافة عارض قائم على XML إلى Flutter باعتباره POC ؛ لكن لم يكن لدي وقت الفراغ. أردت فقط المساهمة في المحادثة وأقول إنني أرغب في رؤية هذا يتقدم إلى الأمام ؛ لكنني في الواقع لا أتوقع أن يعمل الفريق الأساسي على ذلك. أعتقد أن تنسيق NS XML يمكن أن يتم كمشاريع مجتمعية حيث يكون أولئك الذين يهتمون منا (على سبيل المثال أنا: ابتسامة عريضة :) على استعداد للقيام بالعمل عليها. ومع ذلك ، فإن شاغلي الأكبر sethladd - هو إذا قضيت الكثير من الوقت على رقعة ؛ هل سيتم رفضه لأن شخصًا ما في الفريق الأساسي يعارض هذه القدرة تمامًا. هذا ما أود أن أتحدث عنه أولاً قبل أن أقضي أي وقت في هذا ...

NathanaelA منظور رائع !!!!!!! وانظر لقد استخدمت الكثير من علامات التعجب ؛-) لقد سمرتها حرفيًا على الرأس.

نعم ، يمكنني عمل DSX ولكني بحاجة إلى طريقة لدمجها في نظام بناء Flutter الحالي ، لذا أحتاج إلى التزام من فريق Flutter الحالي قبل المضي قدمًا. يعد تكامل IDE أمرًا تافهًا تقريبًا في VS Code ولكنه ليس كثيرًا مع Intellij (ما لم يكن لدى Google إمكانية الوصول إلى دعم Intellij JSX).

zoech ، لا! أعتقد أن هذه مشكلة. أتذكر تطوير تطبيق android باستخدام Java أصلي و XML. ما زلنا نستخدم XML لجزء لغة واجهة المستخدم. أعتقد أن استخدام Dart للمنطق وواجهة المستخدم أمر غريب نوعًا ما ، وهذه المشكلة واضحة نوعًا ما. علاوة على ذلك ، آمل فقط أن تضيف Google فكرة واجهة المستخدم الخاصة بـ React إلى الرفرفة. جزء واجهة المستخدم في React قوي جدًا وموجز.

JonathanSum لقد رأيت العديد من التعليقات حول هذا الموضوع.
بالنسبة لي ، لا يزال يبدو وكأنه شيء يريده الناس لأنهم يترددون في تغيير عاداتهم ، وليس لأنها تعود بالنفع على النظام الأساسي.

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

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

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

بالنسبة لي لا يزال يبدو وكأنه شيء يريده الناس لأنهم يترددون في تغيير عاداتهم

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

@ yuu2lee4

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

سؤال ممتاز. نظرًا لأنني أقوم بجميع الأعمال على DSX ، والتي تشبه JSX تمامًا ، وأرسل لي Hixie شخصيًا رسالة بريد إلكتروني متحمسًا بشأن التقدم ، لا أرى سبب عدم دعمه ، ولا أرى سبب عدم مد يد المساعدة وأقول 'ماذا يمكنني أن أفعل لمساعدتك؟ ما الذي يمنعك من القيام بذلك؟

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

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

Hixie أرسل لي شخصيًا بريدًا إلكترونيًا متحمسًا للتقدم ..

فلماذا لا تستمر ويجب على الأشخاص الآخرين الذين يمكنهم المساعدة أيضًا الانضمام والمساعدة؟ إذا كنا لا نريد أن يظهر هذا مثل الخيط الآخر ... أعتقد أننا يجب أن نناقش ما هي الكتل ، وكيف نتعامل معها وكيف نجعلها تعمل ونضعها هناك ... و أعتقد أيضًا أن فريق الرفرفة والسهام قد بدأ بطريقة ما بعض العمل على تقليل الطبيعة المطولة لكتابة واجهة المستخدم ...
ربما لا يكون الفريق قادرًا على الانضمام الآن ، لكنني أعتقد أنه إذا كانت قضيته جديرة بالاهتمام والتي أعتقد أنها كذلك بالنسبة لي ، فأنا على ما يرام ، أيًا كان النهج ... أنت تفعله وأخرجه ... مثل ما فعله هذا الرجل http://mutisya.com/ في الأيام الأولى على الرغم من أنني لا أعرف حالتها ... أعرف أيضًا أن NathanaelA يمكنه المساعدة لأنه ساهم ببعض أشياء وأدوات مذهلة حقًا لـ Nativescript ... دعنا نخرجها لإعطاء المزيد من الخيارات للمطورين ...

تضمين التغريدة
سبب عدم استثمار المزيد من الوقت في هذا الأمر مثل NathanaelA قال:

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

حسنًا ، هذا ما لدي:
(أ) معالج مسبق يأخذ ملفات * .dsx ويخرج * .dart الملفات.

هذا ما أحتاجه:
(1) شخص ما لرعاية تكامل "VS Code". من استقصائي يبدو بسيطًا.
(2) شخص ما لمعرفة كيفية إضافة قدرة ما قبل المعالج إلى نظام بناء Flutter بحيث يعمل التصحيح بشكل صحيح. أعني أن التنقل في التعليمات البرمجية سيكون على ملفات * .dsx عبر شيء مثل sourcemap ، إلخ.

بمجرد الانتهاء من العنصرين المذكورين أعلاه ، يكون لدينا نظام أولي شامل لتدحرج الكرة. أي من الأشخاص يود ذلك؟

لذلك كما ترى أعلاه ، تتطلب (1) و (2) تغييرات في رمز Flutter يمكن لفريق Flutter رفضها ، لذلك بدون دعم / التزام ، تتوقف هذه الميزة.

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

(2) أعتقد أن أفضل رهان هو الاتصال بفريق Dart ، ربما عبر [email protected] أو متعقب المشكلة؟ أعتقد أن أحد أهداف Dart 2 كان إنشاء بنية تحتية لمزيد من التجارب مع اللغة والسماح للمجتمع بإنشاء تجارب مثل DSX. ربما يستطيع @ anders-sandholm @ mit-mit أو mraleph توجيهك في الاتجاه الصحيح.

sethladd شكرًا للاستجابة السريعة ويمكنك أيضًا نسخ الأشخاص المرجعيين وربما
فريق دارت لهذا الموضوع أيضا
cbazza ، هل يمكنك القفز للحصول على هذا الخطاب مع الشخص المسؤول المدرج في القائمة.
فيما يتعلق بتكامل "VS Code" ، أنا متأكد من أننا سنحصل على 2 بعيدًا عن الطريق ، ربما يكون DanTup مهتمًا بالمساعدة

فقط بعض الأفكار

حسنًا ، هذا ما لدي:
(أ) معالج مسبق يأخذ ملفات * .dsx ويخرج * .dart الملفات.

ربما يكون هذا هو كل ما تحتاجه للبدء ، ذلك ومراقب الملفات لإعادة البناء على التغييرات - راجع FileSystemEntity . التحدي هو أن القواعد النحوية هذه .dx هي مجموعة شاملة من dartlang ، لذلك سيكون عليك تحليل كل Dart أيضًا. سيكون هذا صعبًا لأنه على عكس JavaScript ، يتم استخدام < و > في أماكن أكثر. أعتقد أن محلل Dart مكتوب بالفعل في Dart ، وفي مكان ما داخل sdk repo ، لكني لا أعرف أين

1. بالنسبة لتكامل vscode و Intellij ، فهو ليس نظام بناء flutter ، إنه محلل dart الذي تريده. أعتقد أنه يمكنك إنشاء مكون إضافي لهذا الذي من شأنه أن يستهلك dx ، وينقله إلى dart ، ثم يعيد النتائج إلى الملف الأصلي. هذه هي الطريقة التي يعمل بها المكون الإضافي للمحلل الزاوي لتوفير أشياء مثل الإكمال التلقائي لملفات html.

2. تريد بناء عداء ، هذه حزمة أكثر تعقيدًا لعمل a .

تضمين التغريدة
ممتاز لذا أعتقد أنك تأخذ (1) و (2) حتى أتمكن من التركيز على محول التردد؟

تضمين التغريدة
أعلم أن تحليل السهام الكامل سيكون معقدًا وليس ضروريًا حقًا في الوقت الحالي لأنه يمكنني دائمًا استخدام علاماتي للإصدار الأول (https://spark-heroku-dsx.herokuapp.com/index.html)

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

re: IDE و debugger ، ويفترض أنه من خلال تنفيذ هذه الميزة داخل البنية التحتية Dart 2 و "الواجهة الأمامية المشتركة" ، يجب أن تكون قادرًا على تمكين المستويات الأعلى من المكدس لتكون على دراية بـ DSX. أوصي بالعمل مع فريق Dart وتعلم كيفية استكشاف الأجزاء المختلفة للواجهة الأمامية المشتركة وواجهات برمجة التطبيقات الخاصة بها.

MichaelSowah لقد قمت بعمل CC للناس من Dart في https://github.com/flutter/flutter/issues/15922#issuecomment -376960770

NathanaelA هل أنت مهتم بالانضمام إلى (1) و (2) منذ الآن لدينا دعم واضح من الفريق

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

NathanaelA ليس هناك اندفاع أو أي شيء لذا أنت جيد :-)

إذا كان DSX هو ببساطة Dart + Virtual closing tag ، فلا فائدة حقيقية. تتمثل إحدى فوائد dart في أنه يمكننا استخدام الوظائف والمتغيرات لإنشاء جزء من عنصر واجهة المستخدم وزيادة إمكانية القراءة.

أيضًا مع DSX والمعالج المسبق ، سنفقد قدرة إعادة التحميل السريع دون الثانية ، أليس كذلك cbazza ؟

كلا ، DSX يشبه JSX ويختلف تمامًا عن "علامة الإغلاق الافتراضية Dart +" وهو ما يمكنك فعله اليوم باستخدام شجرة عناصر واجهة المستخدم Dart و IDE فقط.

يتم وصف DSX هنا:
https://spark-heroku-dsx.herokuapp.com/index.html

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

لا ، لن تفقد أي شيء ، لا شيء يتغير بالنسبة للملف العادي * .dart الذي تقوم بإنشائه ، لا يزال لديك إعادة تحميل سريع لمدة أقل من الثانية.
الآن إذا كان لديك ملف * .dsx ، فسيتم تحويله أولاً إلى * .dart وستكون هذه العملية أسرع مما يمكنني وميضه !!! لذلك سيكون غير ملحوظ لمستخدمي DSX.

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

JonathanSum هل جربت الإصدار الأخير من Android Studio (3.1) مع إغلاق التسميات؟

@ 14n نعم ، أرى علامات الإغلاق الافتراضية والتعليقات.

يمكن أن يكون من الصعب قراءة شجرة عناصر واجهة مستخدم كبيرة تشبه XML مثل أي شيء كبير آخر ، سواء كان Dart أو JSON أو YAML أو JSX. لا يبدو أن JSX نفسها تحل مشكلة قابلية القراءة.

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

رأي شخصي حول تنسيق DSX المقترح:

1. بصريا لا فائدة حقيقية ومرة ​​أخرى - قراءة شجرة XML الكبيرة يمكن أن تكون مؤلمة ، لذلك لا يبدو أنها تحل المشكلة. تعزيز ممارسات الكود النظيف ، على سبيل المثال ، من شأنه أن يعالج بالفعل مخاوف قابلية القراءة ، ولكن يمكن تطبيق هذه الممارسات (تقريبًا) على أي بناء جملة.
2. يتطلب تعلم DSL / بناء جملة آخر. أنا حقًا - حقًا - حقًا أحب أن أعرف بنية واحدة فقط - Dart - لفعل كل شيء - التخطيط والأنماط والرسوم المتحركة والمنطق. إنه أكثر ملاءمة لكل من الوافدين الجدد والمطورين ذوي الخبرة مقارنة بما حدث للويب باستخدام html / js / jsx / ts / coffee / css / sass / scss. في الواقع ، أنا أعتبر هذا فائدة كبيرة لـ Flutter على المنصات الأخرى.

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

من فضلك توقف عن محاولة جعل Flutter مثل "الشيء الجديد الساخن". إنه الشيء الجديد الساخن من تلقاء نفسه ، دعه يستكشف نماذج جديدة.

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

أفكاري في هذه المرآة ما قالتهpulyaevskiy في https://github.com/flutter/flutter/issues/15922#issuecomment -377666972. يمكن عادةً تنظيم جميع الأمثلة التي رأيتها والتي لا يمكن قراءتها في الكود الحالي وأعتقد أنه قد يكون هناك المزيد من التغييرات الطفيفة التي يمكن إجراؤها على Dart (على غرار إزالة new / const) التي يمكن أن تحسنها بشكل أكبر . يبدو أن الاحتفاظ بمجموعة كاملة أخرى من الملفات مع بناء جملة مختلف ومجموعة جديدة كاملة من التعليمات البرمجية للأدوات يبدو وكأنه تكلفة عالية لما أعتقد أنه مكسب صغير نسبيًا (FWIW ، أفضل أيضًا React بدون JSX).

لا أعرف ما إذا كانت قابلة للتطبيق تمامًا هنا نظرًا لأن dsx المقترح يسمح برمز Dart العادي أيضًا ، ولكن في كل مرة أسمع فيها شخصًا يتحدث عن بناء جملة جديد ، يتم تذكير هذا المنشور الرائع بواسطة Gilad A DOMain of Shadows . هذه الأشياء دائمًا ما تكون أكثر تعقيدًا مما يعتقده الناس. الأمر ليس بهذه البساطة مثل تحويل الشفرة فقط لأن الناس يتوقعون أخطاء في الوقت الفعلي ، وإكمال التعليمات البرمجية ، وإعادة البناء ، وتلميحات الأدوات ، وما إلى ذلك - إنها مهمة كبيرة.

بدلاً من مترجم يعمل ، سأكون مهتمًا أكثر برؤية مقارنة ثلاثية بين بعض التعليمات البرمجية التي تعتبر صعبة القراءة ، وكيف ستبدو في بناء الجملة المقترح ، وكيف ستبدو إذا كان بإمكانك إجراء أي تغييرات على بناء جملة Dart الحالي دون استبدال جميع الأقواس. على سبيل المثال ، هناك شيء أحبه في React وهو أن الأطفال يتم تمريرهم كـ varargs كمعامل أخير - أعتقد أن child و children يضيف الكثير من الضوضاء في Flutter - ربما هناك مجال للتحسين هناك . هناك أيضًا بعض المناقشات حول ما إذا كان تغيير التنسيق أو تمييز أسماء فئة عنصر واجهة المستخدم قد يساعد. يبدو أن أداة إعادة بناء Extract Widget في طريقها لتحطيم أساليب البناء الكبيرة بسهولة. وبالطبع ، يحتوي IntelliJ على عرض Flutter Outline الذي يتيح لك رؤية الرمز في شجرة ويظل التحديد متزامنًا مع موضع المؤشر في المحرر (وآمل حقًا الحصول على شيء مشابه في VS Code ، على الرغم من حظره من خلال بعض ميزات VS Code مثل هذه ، فلا تتردد في 👍 it!).

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

تضمين التغريدة
شكرا لك على القيادة.
أحب أن أسمع رد من @ anders-sandholm @ mit-mit أو mraleph على
كيفية العمل مع البنية التحتية Dart 2 و "الواجهة الأمامية المشتركة".
سأبحث في ذلك معNathanaelA.

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

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

نعم ، أنت محق. لقد تم تطبيق تعليقي "التافه والبسيط مثل فطيرة التنفيذ" فقط على جعل المحرر يتعرف على صيغة dsx. لقد بحثت في Intellij وهم يحتاجون إلى محلل لغة كامل لذلك (وهذا معقد) ، في حين أن VS Code كان أسهل بكثير مع ملفات بناء الجملة ولاحظت أيضًا أن ملفات بناء الجملة Typescript / Javascript تدعم بالفعل JSX (و DSX لديها فقط تغييرات طفيفة من JSX).

من المؤكد أننا سننبهك للحصول على المساعدة / التوجيه لبدء تجربتنا.

باختصار ، لدي:
(أ) معالج مسبق يأخذ ملفات * .dsx ويخرج * .dart الملفات.
https://spark-heroku-dsx.herokuapp.com/index.html

أحتاج إلى مساعدة في:
(1) شخص ما لرعاية تكامل "VS Code".
(2) شخص ما لمعرفة كيفية إضافة قدرة ما قبل المعالج إلى نظام بناء Flutter بحيث يعمل التصحيح بشكل صحيح. أعني أن التنقل في التعليمات البرمجية سيكون على ملفات * .dsx عبر شيء مثل sourcemap ، إلخ.

NathanaelA سوف تساعد في (2).

لذلك ما زلت أبحث عن أشخاص يمكنني مساعدتهم في (1)
أي من الأشخاص يود ذلك؟ birkir @ yuriy - manifoldtehfailsafealexkrolicksanketsahusoft

DanTup - لست محترفًا في JSX ، لكن يمكنني التحدث تجاه تنسيق NativeScript XML. أستطيع أن أفعل:

يمكن إضافة أي خاصية تدعمها الفئة StackLayout إلى XML. لذا فهي علاقة رأس برأس. التي تقضي على الكثير من الخداع الإضافي: فلنلقِ نظرة على عرض Flutter:
https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/gallery/home.dart#L39 -L63

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

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

NathanaelA ماذا يحدث إذا احتجت إلى فعل شيء أكثر ديناميكية ، مثل الاتصال بـ map ؟ إليك بعض التعليمات البرمجية من نفس الملف:

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

كيف سيبدو children: _kBackgroundLayers.map(...) في بناء الجملة هذا؟

تحدد JSX / DSX تحويل العلامة فقط على النحو التالي:

في:
<A property="a"/>
خارج:
new A(property: a)

في:

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

خارج:

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

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

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

ضع الكود أعلاه في ملف Javascript واعرضه باستخدام VS Code / Intellij. لاحظ +/- (الجانب الأيسر من السطر) الذي يمكنك استخدامه لفتح وطي عقد XML لجعل الشجرة أصغر / أكبر.

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

JonathanSum آسف عندما يتم توجيهك هنا ، ولكن من تعتقد نفسك؟ لا توجد مشكلة عامة فقط شيء لا تحبه.
هل سبق لك أن كتبت تطبيقًا واحدًا باستخدام Flutter؟
تبدو الأمثلة المذكورة أعلاه لخلط Dart مع XML أسوأ بكثير من مجرد Dart. لا شيء لكسبه هنا.
لقد جئت من نماذج Xamarin التي تستخدم xaml وقد أحببتها حقًا. لكن بدلاً من الشكوى من سبب عدم دعم Flutter لـ Xaml ، انغمست فيه وبدأت في التكيف والتعلم.
واجه الأمر إذا كنت تريد العمل كما هو الحال في React ، فاستخدم Reactive بدلاً من إزعاج الجميع هنا.

هنا نفس كتلة الكود المذكورة أعلاه ، ولكن في Dart النقي ومعاد بنائها لتجنب التداخل العميق.
هل أنت مهتم بأي أجزاء من المقتطف أدناه يصعب قراءتها و / أو فهمها؟

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

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

في الواقع ، أنا شخصياً سأجعلها تبدو أقرب إلى شيء مثل هذا:

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

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

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

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

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

مرة أخرى ، يبدو أننا نخلط بين مشكلتين مختلفتين هنا:

1. يكره بناء جملة Dart وتحتاج إلى بناء جملة يشبه XML / JSX
2. قراءة كود Flutter.

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

ولكن ما ستضيفه بالتأكيد هو خطوة بناء / تحويل إضافية مع خرائط المصدر وشركاه ، والكثير من العمل لدعم هذه البنية التحتية في IDEs و Dart SDK (محلل ، مصحح أخطاء ، إلخ).

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

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

Hixie آسف لأنني فقدت أعصابي ولكني أعتقد أن Flutter في حالة جيدة كما هي وأن مطوري Flutter لديهم ما يكفي للقيام به دون مطالب كهذه

escmoteur - أعتقد أن هذا هو السبب في أنني قلت على وجه التحديد جهد "المجتمع". لا أعتقد أن هذا يحتاج إلى إشراك فريق flutter الأساسي بخلاف استعدادهم لقبول التصحيحات ... التي يبدو أن Seth قالها إننا قادرون على المضي قدمًا. إذا لم تكن مهتمًا بهذه الميزة ؛ ثم لا تستخدمه ...: ابتسامة عريضة:

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

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

من فضلك توقف عن محاولة جعل Flutter مثل "الشيء الجديد الساخن". إنه الشيء الجديد الساخن من تلقاء نفسه ، دعه يستكشف نماذج جديدة.

يمكنك الذهاب للتحقق منها.
https://facebook.github.io/react-native/
التفكير في رد الفعل:
https://reactjs.org/docs/design-principles.html
رفرفة:
https://flutter.io/tutorials/animation/

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

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

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

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

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

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

الأهم من ذلك ، أعتقد أن الطريقة التي يبني بها React-Native تتبع ما يقوم البشر ببناء الأشياء بشكل طبيعي.

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

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

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

علاوة على ذلك ، تركز معظم أطر عمل واجهة المستخدم التي نستخدمها في هذه السنوات على طريقة React هذه كمعيار ،

Argumentum ad populum.

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

نعم ، لأن إعادة التحميل الساخن ليست ميزة سهلة للغاية لتحقيقها بالطريقة التي قام بها Flutter. أود أن أزعم أن دورة التطوير التي تمكن Flutter من تحقيقها ، حتى في 30-40٪ من تغييرات الكود ، مثيرة للإعجاب حقًا ، ولن تتباطأ إلا من خلال طبقات التحويل.

ومع ذلك ، فإن المستقبل مثل مجرد الفوضى والفوضى.

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

هذا هو سبب انخفاض منحنى التعلم ووقت إدارته. من فضلك لا تقارن XML أو حتى Xamarin مع React Native.

عادل بما يكفي - استخدم React Native بعد ذلك. يقوم المطورون هناك بعمل رائع بنموذجهم.

عديمي الجنسية يتصلون بالحالة وخلق الحالة في عديمي الجنسية

لما؟ رقم هذا مجرد خطأ واضح - ما هي وجهة نظرك هنا؟

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

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

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

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

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

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

ما أود معرفته هو سبب اهتمامك بـ Flutter على الإطلاق؟ بالنسبة لي ، فإن React هو أمر محظور بسبب JS

الكثير للتعليق ، القليل من الوقت ، ربما ينبغي علي التركيز ...

escamoteur ماذا تقصد بالضبط ب:

بالنسبة لي ، فإن React هو أمر محظور بسبب JS

ES6 / 7 أو Typescript قريبين جدًا من Dart / Kotlin / Swift لدرجة أنني سأرقص بسعادة مع أي من هؤلاء السيدات :)

الشيء الذي يجذبني إلى Flutter هو دعم الرسومات والرسوم المتحركة. رسومات Direct Skia Vector المبنية على OpenGL لتجربة مستخدم فائقة السرعة بمعدل 60 إطارًا في الثانية لتنفيذ أشياء بسهولة مثل ما تراه على:
https://uimovement.com/
أنا في UX مخصص و Flutter يتيح ذلك. لقد قمت بتطبيق عناصر UX لعقود من الزمان وأحب حقًا أن أكون قادرًا على بناء ذلك باستخدام تقنيات تصريحية / تفاعلية ، ويدعم Flutter ذلك.

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

مرة أخرى ، يبدو أننا نخلط بين مشكلتين مختلفتين هنا:

• يكره بناء جملة Dart وتحتاج إلى بناء جملة يشبه XML / JSX
• قراءة كود Flutter.

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

هل هناك أشخاص هنا يعتقدون أن تنفيذ JSX سيحل قابلية القراءة؟

قد يكون لهم ، لكل منهم.

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

ولكن ما ستضيفه بالتأكيد هو خطوة بناء / تحويل إضافية مع خرائط المصدر وشركاه ، والكثير من العمل لدعم هذه البنية التحتية في IDEs و Dart SDK (محلل ، مصحح أخطاء ، إلخ).

نحن نتعامل مع هذا وقد صرح sethladd أن I believe one of the goals of Dart 2 was to create an infrastructure for more experimentation with the language and let the community create experiments like DSX.

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

أود أن أزعم أن دورة التطوير التي تمكن Flutter من تحقيقها ، حتى في 30-40٪ من تغييرات الكود ، مثيرة للإعجاب حقًا ، ولن تتباطأ إلا من خلال طبقات التحويل.

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

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

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

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

• إذا كنت مع هذه الميزة - ممتاز التعليق الأول على هذه المشكلة.
• إذا كنت تعارض هذه الميزة - لا يعجبك التعليق الأول على هذه المشكلة.

بعد ذلك ، أود توضيح عبارةsethladd ، يجب أن تقرأ _ "أحد أهداف Dart 2 كان إنشاء بنية تحتية لمزيد من التجارب مع لغة فريق Dart " _.

حتى في Dart 2 ، لا نوفر أي واجهات برمجة تطبيقات تتيح لك تغيير بنية لغة Dart بسهولة ، دون إعادة إنشاء Dart SDK (أو عناصر محرك Flutter). ما توفره Dart 2 هو بنية أساسية مشتركة للواجهة الأمامية (CFE) (موجودة في pkg/front_end في مصادر Dart SDK) - وهو محلل للغة Dart مكتوب بلغة Dart. بالنسبة لتغييرات لغة السكر النحوية البحتة مثل DSX ، يجب أن تكون قادرًا فقط على تحرير كود CFE ، وبناء Dart SDK (أو محرك Flutter) ولديك جميع الأدوات (باستثناء كود تمييز بناء الجملة المدمج في مكونات IDE الإضافية) اختر ملحق بناء الجملة الجديد. لاحظ أنه حاليًا فقط VM و dart2js يستخدمان CFE بالفعل ، ومن المقرر أن ينتقل المحلل بعد ذلك. كما ترون ، هناك عائق معين للدخول هنا.

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

فيما يلي توصياتي لمؤيدي DSX مثل الحل:

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

  • إذا وضعت اقتراحك في مستند Google ، فيمكن للأشخاص استخدام التعليقات المضمنة لمناقشة المكونات المختلفة لاقتراحك ؛
  • بدلاً من ذلك ، يمكنك إنشاء GitHub repo مع وصف تخفيض السعر لاقتراحك ، واستخدام مشكلة GitHub والعلاقات العامة لتنقيح اقتراحك ومناقشته.

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



• بعد ذلك ، إذا كان بإمكانك محاولة الحصول على تطبيق. الحاجز مرتفع هنا حتى مع البنية التحتية CFE - ولكنه أقل بكثير مما كان عليه من قبل.

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

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

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

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

فيما يتعلق بالتصويت ، تحتوي التذكرة السابقة على بعض الأرقام:
https://github.com/flutter/flutter/issues/11609

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

لا نريد حقًا تعديل لغة Dart ، ما نحتاجه هو قدرة المعالجة المسبقة من أجل تحويل DSX التجريبي الخاص بنا إلى Dart.

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

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

mraleph شكرا لك مرة أخرى.

نحن نهدف بالتأكيد إلى توفير تجربة مستخدم رائعة لمستخدمي DSX وهذا أمر مؤكد.

بعض الناس يحبون بناء جملة يشبه XML ، والبعض يكرهونه. ربما تكون إضافة صيغة شبيهة بـ jsx مبالغة للغاية. شاغلي الرئيسي حول Flutter هو قابلية القراءة. IMHO ، لا يزال هناك مجال لتحسين البنية الحالية لـ Dart و Flutter (بالنسبة لي هو كذلك بشكل أساسي حول أقواس التداخل العميقة ، child ، children ، ضوضاء الفاصلة المنقوطة ، إلخ.)
إعادة نشر رمز مثال [1] هنا ،

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

إصدار Dart 2 بـ new وفاصلة منقوطة اختيارية (رمز منsethladd) [2] ،

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

IMO ، إصدار kotlin نظيف ويبدو أفضل ، إصدار Dart 2 قريب جدًا ولا يزال لديه مجال للتحسين (إذا كان Dart يدعم طرق التمديد؟). لذلك أعتقد أن تحسين بناء جملة Dart لتقليل الإسهاب هو الاتجاه الصحيح.

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

زاوية أخرى ، أنا أحب قدرة تكوين JSX.

يعد العمل مع المكونات (عناصر واجهة المستخدم) أمرًا سهلاً للغاية ويمكن الوصول إليه ، ونقلها لأعلى ولأسفل في المحرر هو مجرد مسألة اختصار لوحة مفاتيح (Alt + UP / Alt + DOWN). هذا صحيح بشكل خاص عند نقل الأشياء داخل وخارج الحاوية أو الصف أو العمود وما إلى ذلك.

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

فيما يلي مناقشة رائعة للإيجابيات والسلبيات: https://github.com/jsforum/jsforum/issues/1

سهم	DSX

المصدر: https://github.com/flutter/flutter/blob/master/examples/platform_view/lib/main.dart

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

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

بقدر ما يتم تطبيق الأدوات ، فقد دعمت أدوات Javascript بناء الجملة غير القياسي وامتداد اللغة لفترة طويلة (Flowtype / Typescript / Babel) لذا فقد استفادت الكثير من الأدوات الخاصة بـ JSX من المحولات الموجودة. لم يختبر Afaik Dart هذا المستوى من التجزئة لذا فإن الأدوات غير موجودة بعد. لكن الآن هو الوقت المناسب للبدء في بنائه 😄

IMHO ، بناء جملة يشبه json أفضل بكثير من ~ مثل xml ~ بناء الجملة!

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

MustafaHosny اللهم امين
لا أعتقد أنه يمكن مقارنة JSX بـ XML. أعتقد أن JSX و XML هما شيئان مختلفان مثل الطائرات الأسرع من الصوت.

باستخدام JSX ، يمكنك القيام بأشياء مثل ما يلي:

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

أو

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

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

هذا هو السبب في أن React يستبدل HTML و XML ويتبنى JSX لبناء إما تطبيق iPhone أو تطبيق ويب ، أو يقول الناس إن JSX هو مجرد نسخة أكثر برودة من HTML.

• أنا لا أحب كلا من XML و HTML وأحب JSX.

• أعتقد أن أهم شيء لا يتعلق بالأداء مثل iPhone مقابل سطح المكتب.

• أهم شيء هو سهولة الاستخدام مثل iPhone مقابل سطح المكتب.

علي سبيل المثال:

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

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

أو الكتابة

< AwkwardScrollingImage/>

لكتابة مرة واحدة في كل مكان

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

~ يستخدم Flutter لغة برمجة لبناء واجهة مستخدم. ~

مرجع:

رفرفة:
https://flutter.io/tutorials/layout/
التفاعل الأصلي الذي ينشئ Android و Iphone وحتى سطح المكتب:
https://facebook.github.io/react-native/

تضمين التغريدة
أوه هذا يبدو رائعًا جدًا !!! فقط لحم ولا عظام :)
تخيل استخدام https://builderx.io/ معها (ألق نظرة على الصورة المتحركة الثانية - بناء واجهة مستخدم ثنائية الاتجاه مثل استخدام Flex للقيام :)

تضمين التغريدة
مع أدوات الإنشاء المضمنة ، ستبدو فوضوية كما هو الحال مع الطريقة الحالية ؛ تم تقديم العينات أعلاه:
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

على أي حال ، أعتقد أن الطريقة الحالية واضحة ومتسقة. إن خلط بعض أكواد dart وعلامة < في ملف dart يجعلني أشعر أن الكود محرج وغير واضح. من وجهة نظر مطور android ، يبدو الأمر وكأنه كتابة كود java / kotlin في ملف تنسيق xml :)

فقط سنتي

MustafaHosny اللهم امين ...

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

JSX ليس مثل XML. JSX أبسط وأقوى من XML.

راجع للشغل ، JSX يشبه xml ، إذا لم يكذب فريق facebook علي :)

MustafaHosny اللهم امين
JSX ليس XML لأن JSX أبسط وأقوى من XML (أقول إن JSX ليس مثل XML)

إذا قلت أنه لا توجد حجج قوية ، دعني أطرح عليك سؤالاً.
اسمحوا لي فقط أن أنهي حديثي هنا. إذا كان الناس يريدون JSX أو DSX أيا كان ، فسيكون هناك واحد مماثل في المستقبل.

• مرجع:
  https://facebook.github.io/jsx/
  This specification does not attempt to comply with any XML or HTML specification. JSX is designed as an ECMAScript feature and the similarity to XML is only for familiarity.

لا أفتقد علامات الإغلاق الحقيقية من XML على الرغم من :)
الفكرة: علامات الإغلاق المُنشأة تلقائيًا

كان من الممكن أن يحل Kotlin هذا أيضًا. ما عليك سوى إلقاء نظرة على مدى روعة تفاعل Kotlin و Anko

Kotlin-reaction ليس بهذه الروعة ، كان KSX سيكون أفضل :)

import React from 'react';

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

package hello

import react.*
import react.dom.*

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

package hello

import react.*
import react.dom.*

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

العلامات فقط لا تنتمي إلى هناك :)

لكوني في معسكر JSX / DSX / KSX ، أعتقد بالتأكيد أن العلامات تنتمي إلى الكود :)

@ saied89
هل تريد استخدام علامة لتداخل عنصر داخل عنصر آخر تمامًا مثل HTML؟ أم تريد كتابة كلمة "أطفال" أو "طفل" أو []؟ بالإضافة إلى ذلك ، توفر JSX أشياء مثل إعادة استخدام مئات من كود واجهة المستخدم عن طريق كتابة علامة واحدة فقط.

ربما يكون أحد الجوانب الأخرى هو التنسيق الافتراضي الذي يقوم به dart format . من الصعب قراءة IMHO خاصة مع الطفل الرائد: / الأطفال.

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

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

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

قد لا يكون هذا هو الحل المثالي ولكن يجب أن يوضح الاتجاه.
sethladd أي فرصة للقيام بشيء في هذا الاتجاه؟

بادئ ذي بدء ، أنا سعيد لأن هذا لم يزداد سخونة كما كانت القضية الشقيقة: ابتسم:.

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

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

وبغض النظر عن ذلك ، فإنني في الواقع أفضل بناء جملة يشبه Kotlin. خاصة إذا كان بناء الجملة المذكور يجلب بعض ميزات Kotlin إلى Dart: بريء : .

emalamela ،

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

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

لكن لسوء الحظ ، سيكون الأمر كذلك للعديد من مطوري React.

سنستفيد من كل تحديث Dart.

لا أرى كيف لا تستفيد DSX أيضًا من تحديثات Dart نظرًا لأنها مجموعة شاملة من Dart.

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

إن الجهد المبذول لتحقيق الأمان من النوع في DSX هو صفر لأن DSX هو مجرد طبقة سكر تركيبية صغيرة أعلى Dart ، لذلك يستخدم نظام Dart من النوع تمامًا كما يستخدم عبارات التحكم Dart ، وما إلى ذلك.
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

شكرا لمساهمتكcbazza !

هذا هو الشيء ، لا يوجد تبديل للسياق كما تسميه ، فقط اسأل أي مطور React متمرس.

أنا لست مطور React متمرس لذلك بالنسبة لي هو تبديل السياق. تمامًا كما هو الحال في Android ، عليك القفز من Java / Kotlin إلى XML ، على الرغم من أن القفزة أكبر هناك. لغة واحدة ، ونفس الأدوات ، ونفقات أقل.

يعد فصل بناء الجملة أيضًا ميزة رائعة لأنه عندما تنظر إلى الكود ، يمكنك بسهولة رؤية ما هو تعريفي وما هو ضروري.

الطريقة التي هو عليها الآن هي معلنة تماما في رأيي.

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

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

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

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

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

لأن React بها فجوات يمكن أن يملأها Flutter ، ثم تنشئ شيئًا أفضل من React لأنه يصلح عيوب React بأداء Dart ورسومات GPU المسرَّعة ، مع الحفاظ على أفضل أجزاء React بالإضافة إلى معرفتها.

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

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

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

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

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

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

تضمين التغريدة
اسمع ، أنا أعلم أنك صوتت ضد ردود cbazza.
ولكن هل يمكنك قضاء 15 ثانية للنظر في هذا قبل التصويت على ردي؟

قبل أن تفكر في DSX.
ألقِ نظرة أدناه ، إنها مجرد JSX.

بعد إنشاء شريط تنقل وجسم ، يمكنك فقط استيراد الرمز الشريطي للتنقل من الرمز الشريطي للتنقل.

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

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

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

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

ربما يكره شخص ما JSX لأنها من Facebook ، لكنها في الواقع من شركة ألعاب يابانية صغيرة.

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

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

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

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

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

لا تتطلب React استخدام JSX ، لكن معظم الناس يجدونها مفيدة كأداة مساعدة مرئية عند العمل مع واجهة المستخدم داخل كود JavaScript. كما يسمح لـ React بإظهار المزيد من رسائل الخطأ والتحذير المفيدة.

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

woodstream نوع الأشخاص الذين يتوقون لاستخدام JSX هم بالفعل معجبون بـ React fanboys. إنهم يستخدمون بالفعل React Native. يلبي Flutter نوعًا مختلفًا تمامًا من المطورين.

تحرير : أعترف أن استخدامي لـ fanboy كان خاطئًا هنا.

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

هذا النوع من الأشخاص الذين يتوقون لاستخدام JSX هم بالفعل معجبون بـ React. إنهم يستخدمون بالفعل React Native. يلبي Flutter نوعًا مختلفًا تمامًا من المطورين.

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

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

@ anders-sandholm أتفق مع escamoteur حول الحاجة إلى تحسين رؤية شجرة عناصر واجهة المستخدم. كنت سأفعل مثاله كالتالي:

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

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

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

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

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

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

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

فقط بعض التوضيحات الطفيفة ...

ومع ذلك ، كما ذكرنا سابقًا ، كان لدى Facebook سبب لاستخدام JSX نظرًا لكيفية كتابة JavaScript (على سبيل المثال ، لا توجد معلمات مُنشئ مُسماة) وهذا ليس هو الحال مع Dart.

في الواقع منذ ES2015 / ES6 ، قام JS بتسمية المعلمات ؛ يمكنك فقط استخدام "de-Structuring" لذلك :)
هنا مثال:

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


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

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

كما أن سلامة نوع Dart المضافة لطيفة بالفعل!

تحصل على نفس النوع من الأمان مع DSX ، وهو أمر رائع حقًا.

نظرًا لأن هذه نسخة مكررة من https://github.com/flutter/flutter/issues/11609 التي تم الإبلاغ عنها سابقًا ، فسوف أغلق هذا لصالح ذلك.

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

<like><this /></like>

يرجى التحلي بالمرونة الكافية لإعطاء الرفرفة فرصة للطيران!

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

نحن لسنا بحاجة إلى القيام بذلك مثل رد فعل أصلي أو html ، فقط استخدم xml بسيط

و maybeeee ... xml جزءا لا يتجزأ من dart! ؛ ص

في الثلاثاء ، 28 أغسطس 2018 الساعة 21:29 ، كتب Touseef [email protected] :

نحن لسنا بحاجة إلى القيام بذلك مثل رد فعل أصلي أو html ، فقط استخدم xml بسيط

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/flutter/flutter/issues/15922#issuecomment-416550338 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AC8aNdVb_NV8c8JH4t36OS1OOvX6kY58ks5uVSmjgaJpZM4S6HPa
.

-
توني بولينيلي

بالنسبة لي ، فإن الوظيفة الشبيهة بـ JSX هي المستقبل وستصبح بناءًا قياسيًا لأطر تعريفية مثل React و Vue & Flutter.

لا نحتاج إلى تضمين xml في dart إذا كان بإمكاننا فقط الحصول على ملفين منفصلين لواجهة المستخدم والمنطق ، فيمكننا بسهولة اتباع mvvm أو mvc أو أي نمط آخر مرغوب فيه.

لقد قلتها في الموضوع الآخر ولكن:

إذا كنت تريد JSX حقًا ، فإن المبتدئ الجيد يستخدم إنشاء الكود. انتقل باستخدام ملف .html أو .xml وأنشئ أدوات من هذه.

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

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

إذا قدم flutter و xml / jsx / أطلق عليه ما تريده بطريقة إنشاء واجهة المستخدم ، فسأبدأ في استخدامه لتطبيقات مستوى الإنتاج بنبض القلب!

أوافق leossmith tht هو الشيء الوحيد الذي يمثل عقبة أمام تطبيقات مستوى الإنتاج.

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

• يساعد جعل الكلمات الرئيسية new و const اختيارية.
• علامات الإغلاق الافتراضية في IDE
• dartfmt يساعد أيضا

أفضل الاحتفاظ بكل شيء بلغة واحدة يتم فحصها بنوع واحد

هذا بالضبط ما يفعله DSX / JSX ، اللغة هي Dart لـ DSX ، Javascript لـ JSX !!!

أشعر أن النهج الأفضل هو الاستمرار في تحسين لغة Dart بغرض ترميز أشجار واجهة المستخدم التوضيحية المتداخلة بعمق.

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

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

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

cbazza أنت تطرح نقطة جيدة. JSX هو مجرد تحسين لجافا سكريبت.

لذلك دعونا أولاً نفصل بوضوح بين شيئين:

1. DSL خارجي لتعريف واجهة المستخدم. أنا 100٪ ضد هذا. لطالما اعتقدت أن هذا يخلق مشاكل أكثر مما يحلها. لقد كتبت منشور مدونة يجادل في هذه النقطة. حصلت على 58 ألف مشاهدة والمثير للدهشة ، عدم وجود آراء مخالفة تقريبًا: 80٪ من الترميز الخاص بي يفعل ذلك (أو لماذا ماتت القوالب)
2. تحسينات اللغة. لتسهيل إنشاء وتصور هياكل شجرة واجهة المستخدم المتداخلة بعمق. في هذا الصدد ، نتفق كلانا على أن هناك متسعًا للتحسين.

لكننا نختلف قليلاً في النهج. هناك سببان يجعل JSX أكثر منطقية لـ React:

1. بنية البيانات: على الويب ، تتطابق JSX تمامًا مع الشيء الذي يتم إنشاؤه (عُقد HTML DOM). في الرفرفة ، نقوم بإنشاء نماذج القطعة.
2. الألفة: اعتاد الناس على النظر إلى كود html. لكن اقتراح DSX ينحرف عن JSX / XML بما يكفي لإبطال هذه النقطة.

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

1. يحتوي XML على علامات نهاية. هذا ممكن مع أو بدون بناء جملة xml-ish. كان Visual Basic في التسعينيات (فكر في End If). ولغات أخرى. يوفر IDE "علامات نهاية افتراضية" ولكن هذا نوع من التخطيط. أفضل دعم اللغة.
2. لغة XML لها معاملة خاصة للأطفال. الصفات مميزة عن الأطفال. لكنني أزعم أن هذا سيف ذو حدين. هناك بعض الحالات التي يكون فيها Dart في الواقع أكثر وضوحًا وتعبيرًا عن XML في هذا الصدد. على سبيل المثال ، أدوات الحاوية مع نماذج محتوى فرعية مختلفة:

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

اقتراح ديف لمشكلة علامة النهاية

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

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

اقتراح ديف لمشكلة الأطفال المتداخلة

تسمح بعض اللغات (مثل kotlin) بمعاملة خاصة لـ args من نوع lambda. إنها تسمح لك بوضع حجة لامدا خارج الأقواس. راجع تمرير لامدا للمعامل الأخير .

أقترح شيئًا مشابهًا لـ Dart ، ولكن كحجة من النوع List ، ليس لـ lambdas. أقترح صياغة خاصة لتمرير قائمة من النوع الذي يسمى "الأطفال":

""
//بدلا من هذا:
فو (أ: 1 ، ب: 10 ، ج: 44 ، أطفال: [...])

//نحن نفعل هذا:
فو (أ: 1 ، ب: 10 ، ج: 44) [

]

بالنسبة للمُنشئين / الوظائف التي تأخذ طفلًا واحدًا أو طفلين (مثل الأعلى والأسفل) ، اتركها كما هي ، بدون تغيير.

أفضل الاحتفاظ بكل شيء بلغة واحدة يتم فحصها بنوع واحد

هذا بالضبط ما يفعله DSX / JSX ، اللغة هي Dart لـ DSX ، Javascript لـ JSX !!!

أشعر أن النهج الأفضل هو الاستمرار في تحسين لغة Dart بغرض ترميز أشجار واجهة المستخدم التوضيحية المتداخلة بعمق.

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

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

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

StokeMasterJack - يبدو اقتراحك لمشكلة علامة النهاية هو نفسه اقتراحي منذ بعض الوقت.
الفكرة: علامات الإغلاق المُنشأة تلقائيًا

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

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

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

(متأكد من أن Android Studio له نفس الشيء)

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

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

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

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

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

هناك عدد غير قليل من خيارات إعادة البناء ، بما في ذلك:

• التفاف في القطعة الجديدة
• إزالة القطعة
• القطعة مبادلة مع الطفل
• القطعة مبادلة مع الوالدين

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

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

rousselGit - خيارات إعادة البناء التي لديك تبدو مفيدة. لا أراها على Android Studio 3.2.
اعتقدت أن Android Studio سيوفر أفضل الميزات لتطوير Flutter.

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

هذه لقطة شاشة من Android Studio:

تم تفعيله كحل سريع Option+Enter (macOS).
أنا أستخدمها طوال الوقت ، مفيدة للغاية.

حول الموضوع: يبدو أن فريق Flutter يستكشف خيارات "واجهة المستخدم كرمز" وقد نحصل على المزيد من التحسينات في هذا المجال عاجلاً أم آجلاً. على الرغم من أن أفكار StokeMasterJack تبدو مثيرة للاهتمام.

Rockvole العقول العظيمة تفكر على حد سواء!

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

رد لطيف !!!

هناك سببان يجعل JSX أكثر منطقية لـ React:

1. بنية البيانات: على الويب ، تتطابق JSX تمامًا مع الشيء الذي يتم إنشاؤه (عُقد HTML DOM). في الرفرفة ، نقوم بإنشاء نماذج القطعة.

لا تكمن قوة JSX في إنشاء عقد HTML / DOM ، بل في إدارة التسلسلات الهرمية للمكونات ؛ لا تحتوي React Native على عقد HTML / DOM ، أليس كذلك؟

1. الألفة: اعتاد الناس على النظر إلى كود html. لكن اقتراح DSX ينحرف عن JSX / XML بما يكفي لإبطال هذه النقطة.

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

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

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

أود استخدام صيغة تشبه JSX فقط للحصول على تدوين وسم النهاية

جيد ان تعلم ؛)

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

لا أريد أن أكتب علامات ختامية.

ليس عليك يقوم WebStorm ، على سبيل المثال ، بإنشاء علامة الإغلاق تلقائيًا ، كما أنه يعيد تسمية علامات الفتح أو الإغلاق أثناء قيامك بتحرير العلامة الأخرى. وظيفة محرر رائعة حقًا يجب على الآخرين اتباعها (بالنظر إليك "رمز VS").

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

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

ليس عليك WebStorm على سبيل المثال يولد السيارات

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

آمل أن تقدر أن تجربتك لا تعكس تجربة أي شخص آخر

بالتأكيد ! أردت فقط أن أشير إلى أنه قد يكون قلة خبرة بالأدوات أكثر من نقص حقيقي

اذهب إلى github لقراءة كود الآخرين وستلاحظ أن القراءة مؤلمة ، [...]

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

pulyaevskiy - شكرًا على النصيحة المفيدة ، الإصلاح السريع في Linux هو Alt-Enter. ليست ميزة سهلة الاكتشاف ، لقد بحثت في خيارات القائمة العلوية ولكن يبدو أنها لا توجد في أي مكان باستثناء الضغط السحري :)

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

هل تظهر هذه العلامات الافتراضية في ملف المصدر في جيثب على سبيل المثال؟

لا أرى تمامًا كيف ترتبط حججك هنا بالموضوع.

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

المشكلة التي ذكرتها تأتي من الممارسات السيئة ، وليس من النحو السيئ.

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

هذا مثال رهيب woodstream

تحديث : فقط لتوضيح وجهة نظري وليس مجرد هجاء الكلمات دون أي حجج. مكافئ DSX هو نفس الطول ... هذا لا علاقة له بعدد الأسطر أو HTML.

class MusicImage extends StatelessWidget {

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

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

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

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

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

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

أعتقد أن أحد الأسباب الرئيسية التي تدفع الناس ضد هذا هو أنهم لا يستطيعون تخيلهم يستخدمونه. الحقيقة هي أنك لست مضطرًا إلى فعل ذلك ، تمامًا كما يستخدم الأشخاص (مقارنةً بالتفاعل) React.createElement(Component, {}, null) مقابل <Component /> إذا تم تنفيذ ذلك ، فسيؤدي ذلك إلى جذب الأشخاص لاستخدام Flutter في الأول المكان ، وهذا ما نريده حقًا. مجتمع كبير مخصص لـ Flutter بدعم من بعضهم البعض. إذا لم يكن هذا هو نوع بناء الجملة الذي ستستخدمه ، حسنًا. لكن الأطنان يفضلون تدوينًا يشبه JSX بدلاً من الطريقة الحالية.

أنا شخصياً أعتقد أن SGML ومشتقاته مجرد قبيحة. إذا كنا نقوم بعمل DSL ، فلماذا لا نستخدم صيغة تشبه لغة QML؟

أعتقد أيضًا أن بعض نقاط pro-DSX تخلط بين ميزات جافا سكريبت كلغة (لا تمتلكها Dart كلغة) وميزات JSX باعتبارها DSL. على سبيل المثال،

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

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

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

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

يمكن أن تكسب Dart كلغة عامل الانتشار (IMO غير مرجح إلى حد ما)

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

mraleph كنت أتحدث عن عامل الانتشار المستخدم على وجه التحديد في مكالمات الوظيفة / المُنشئ ومع الكائنات ، وليس فقط مع القوائم أو الخرائط - وهذا ما أعتقد أنه غير محتمل. آسف إذا لم يكن ذلك واضحًا!

(أنا على دراية بهذا الاقتراح بشكل غامض ، ولكن آخر مرة قمت بفحصه ، لا يمكنك فقط نشر Dart Size(10, 10) بالطريقة التي يمكنك بها نشر / إتلاف Javascript Size { width: 10, height: 10 } ، أو نشر قائمة / خريطة الوسيطات في استدعاء دالة عادي (لا تستخدم Function.apply ، والذي من شأنه التضحية بنوع الأمان))

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

أنا شخصياً أعتقد أن SGML ومشتقاته مجرد قبيحة. إذا كنا نقوم بعمل DSL ، فلماذا لا نستخدم صيغة تشبه لغة QML؟

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

يجلب JSX / DSX ترميزًا إلى لغة Javascript / Dart المضيفة بطريقة تعزز اللغة المضيفة وتمكّن كل لغة البرمجة على الترميز. أشياء بسيطة جدا وقوية.

هذه ليست ميزة يمنحها DSX بطريقة سحرية ، هذه ميزة تمتلكها JSX لأن جافا سكريبت بها.

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

تعمل عمليات ناقل DSX عبر الإنترنت على انتشار المشغل على ما يرام ، تحقق من ذلك:
https://spark-heroku-dsx.herokuapp.com/index.html

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

توقف عن التفكير في ماهية Dart الحالية وركز على ما يمكن أن يكون من خلال أخذ أفضل الأفكار من جميع اللغات الأخرى الموجودة هناك.

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

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

من الجيد أن نرى أن الأشخاص الذين يستخدمون لغة Dart يأخذون أفضل الأفكار من لغات أخرى مثل Python (قائمة وفهم القاموس).

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

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

والعكس صحيح. لماذا هذا النحو وليس أي بناء آخر ، خاصة عندما لا يكون له علاقة قوية مع اللغة؟ (مع Android SDK ، كانت لـ Java و XML علاقة لسنوات. كما هو الحال مع Javascript و HTML ، والتي تشبهها JSX بشدة. DSX كما هو مقترح سيجلب بناء جملة SGML بناءً على معنى اللغات الأخرى ولكن ليس بالضرورة لـ _Dart_).

يجلب JSX / DSX ترميزًا إلى لغة Javascript / Dart المضيفة بطريقة تعزز اللغة المضيفة وتمكّن كل لغة البرمجة على الترميز. أشياء بسيطة جدا وقوية.

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

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

تعمل عمليات ناقل DSX عبر الإنترنت على انتشار المشغل على ما يرام ، تحقق من ذلك:
https://spark-heroku-dsx.herokuapp.com/index.html

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

توقف عن التفكير في ماهية Dart الحالية وركز على ما يمكن أن يكون من خلال أخذ أفضل الأفكار من جميع اللغات الأخرى الموجودة هناك.

بالتأكيد. ولكن من بين اللغات المتاحة التي يمكن لـ Dart رفعها ، فإن JS شخصيًا ليس على رأس القائمة - أعتقد بصراحة أن محاولة أن أكون مثل JS (من أجل إمكانية التشغيل البيني) قد أعاقت Dart في أيامها الأولى.

سأحب واجهة مستخدم DSL بالتأكيد. ولكن يجب أن يكون DSL اصطلاحيًا لـ _Dart_ ، وليس رفع الجملة من لغة مختلفة لغويًا بسبب الشعبية وحدها.

وأود أيضًا أن يتوقف الأشخاص عن الخلط بين ما يفعله جافا سكريبت وما يفعله JSX DSL ، لأن بعض الفوائد المذكورة هي في الواقع طلبات ميزات على مستوى اللغة مقنعة. للاستمرار مع عامل الانتشار ، إذا كانت Dart كلغة تدعم بالفعل النطاق الكامل للمشغل كما هو في JS ، فأنا لا أرى كيف يُفضل قراءة $ return <SomeWidget {...someArgs, arg: newValue } />; أكثر من return SomeWidget(...someArgs, arg: newValue); أو يشبه QML return SomeWidget { ...someArgs, arg: newValue }; ما لم يكن لدى أحدهم بعض المرفقات لـ SGML.

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

لماذا هذا النحو وليس أي بناء آخر ، خاصة عندما لا يكون له علاقة قوية مع اللغة؟ (مع Android SDK ، كانت لـ Java و XML علاقة لسنوات. كما هو الحال مع Javascript و HTML ، والتي تشبهها JSX بشدة. DSX كما هو مقترح سيجلب بناء جملة SGML استنادًا إلى أنه يجعله منطقيًا للغات الأخرى ولكن ليس بالضرورة لـ Dart).

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

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

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

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

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

كانت نيتي بالانتشار على DSX مجرد نشر السمات وليس تطبيق JS الكامل للانتشار. إنه يعمل بشكل جيد على ما هو عليه ولا يحتوي على مشكلات آمنة من النوع على الإطلاق. التحقق من النوع / التصحيح يحدث عندما يجمع Dart ما يولده DSX.

شلت دارت في أيامها الأولى.

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

سأحب واجهة مستخدم DSL بالتأكيد. ولكن يجب أن يكون DSL اصطلاحيًا لـ Dart ، وليس رفع الجملة من لغة مختلفة لغويًا بسبب الشعبية وحدها.

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

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

مرة أخرى هذا غير ذي صلة.

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

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

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

هذا يبدو مثيرًا للانقسام إلى حد ما ويحق لي إلى حد ما. لماذا يجب أن يتمتع Flutter بدعم من الدرجة الأولى لبناء جملة React على وجه التحديد؟ لماذا لا ملفات مكون Vue ، أو بناء جملة Xamarin.Forms؟ لماذا يجب أن تستند واجهة المستخدم DSL (الرسمية) لـ Flutter إلى ما تتوقعه وتريده مجموعة معينة من الأشخاص الذين يستخدمون إطار عمل مختلفًا بلغة مختلفة؟ إذا كنت تريد أداة مجتمع خاصة لمطوري React / JS ، فسيكون ذلك شيئًا واحدًا. لكن طلب إطار العمل نفسه لتضمينه فقط لتلبية احتياجاتكم جميعًا هو أمر قليل جدًا IMO.

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

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

كانت نيتي بالانتشار على DSX مجرد نشر السمات وليس تطبيق JS الكامل للانتشار. إنه يعمل بشكل جيد على ما هو عليه ولا يحتوي على مشكلات آمنة من النوع على الإطلاق. التحقق من النوع / التصحيح يحدث عندما يجمع Dart ما يولده DSX.

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

لتوضيح ما أعنيه ، يمكنك القيام بذلك في JS:

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

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

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

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

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

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

ولكن مع Dart و transpiler الخاص بك الذي يتطلب hashmaps من الحجج:

class MyCustomSize {
  int length, width, height;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تعديل آخر: قد يكون طلب DSL ، واقتراح JSX بمثابة إلهام محتمل للنحو / بناء الجملة ، والانفتاح على الاقتراحات الأخرى أمرًا واحدًا. إن الإصرار على DSX هو الذي يفركني (وأظن أن الكثيرين علقوا) على خطأ.

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

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

الشيء الوحيد الذي أطلبه من فريق Dart / Flutter هو ما قلته من قبل:

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

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

أود أن أقول أنك تبحث عن أشياء مثل https://github.com/dart-lang/build و dartanalyzer.
من المحتمل أن تفوتك قطعة أو اثنتين (مثل القدرة على إنشاء مكونات إضافية للمحلل كاعتماد على الحانة) ، لكنني متأكد تمامًا من أن فريق Dart على ما يرام في المساعدة في ذلك.

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

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

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

cbazza النقطة هي أن جزءًا مما يجعل عامل الانتشار مفيدًا جدًا في JS / JSX هو أنك لست مضطرًا إلى فرض قيود مثل "يمكنك فقط استخدام hashmap" أو "يجب معرفة جميع الحجج الخاصة بك في وقت الترجمة" أو "لا يمكنك التفاعل مع الوسائط / الدعائم التي تريد تمريرها إلى عنصر واجهة مستخدم بنفس الطريقة التي يمكنك من خلالها التفاعل مع كل شيء آخر" (لاحظ أنك لم تقترح أي شيء للتعامل مع الحالة التي يكون فيها الشيء مع الخصائص الحاجة هي في الواقع كائن ، وليست خريطة حرفية) -0 كل شيء جيدًا وجيد عندما يكون مثالًا بسيطًا ، ولكن هذا النوع من الأشياء سيصبح محبطًا للغاية _ سريع_ في أي مشروع متوسط ​​الحجم. أعني ، في أي نقطة يتوقف المرء عن تكديس الحلول والتسويات والتعليقات التوضيحية ، يتراجع خطوة إلى الوراء ويتساءل عما إذا كان الامتداد مناسبًا بالفعل للغة كما هي؟

لقد حققت JSX مثل هذا النجاح (مقارنة بمعظم القوالب) لأنها لا تجبرك على البرمجة بطريقة معينة (أو بالأحرى ، لا يجبرك على كتابة التعليمات البرمجية بشكل مختلف عما كنت ستكتبه في Javascript على أي حال). إنه غير مؤلم تمامًا للاستخدام مع _any_ JavaScript ؛ هذا ما أعنيه بإنشاء DSL يناسب اللغة بالفعل. إنه شيء مشابه مع Redux. يعد الإحياء في قاعدة بيانات JS أمرًا رائعًا (عندما يتم استخدامه بشكل صحيح) ؛ من ناحية أخرى ، كل أمثلة Flutter التي رأيتها باستخدام Redux على نطاق واسع وبصراحة تبدو مؤلمة مقارنة باستخدام نمط Streams / BLoC. هذا لا يعني أنه لا توجد أشياء تتداخل مع النجاح الكبير: يطبق React's Context و Flutter's InheritedWidget مفهومًا شائعًا يلبي بشكل جيد نقاط القوة في كليهما. أنا لست مقتنعًا بأن JSX هو حاليًا أحد هذه الأشياء - باستثناء العديد من التغييرات على مستوى اللغة ، يبدو بصراحة أن DSX سيكون من الصعب تطوير _و_ ألمًا لاستخدامه في أي شيء أكثر من مجرد أمثلة تافهة ، في حين أنه من المحتمل أن يكتب المرء محول JSX كامل الميزات من البداية في عطلة نهاية أسبوع كسولة نظرًا لمدى سهولة التعيين إلى JS.

كما أنني كنت عدوانيًا بعض الشيء في وقت سابق وأعتذر.

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

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

مجموعات انتشار
https://github.com/dart-lang/language/issues/47

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

cbazaa أقوم بتقييم استخدام React Native أو Flutter. يميل نحو Flutter لأن كل شيء مجرد Dart حتى يتمكن المترجم من التحقق من أخطاء واجهة المستخدم المطبعية. انظر أيضًا: https://medium.com/flutter-io/out-of-depth-with-flutter-f683c29305a8

هل رصدت JSX الأخطاء الإملائية الخاصة بي أيضًا؟ أنا أستخدم TypeScript.

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

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

هل رصدت JSX الأخطاء الإملائية الخاصة بي أيضًا؟ أنا أستخدم TypeScript.

نعم ، يتم اكتشاف بعض الأخطاء المطبعية في JSX في وقت الترجمة (اسم المكون على سبيل المثال) ولكن ليس أسماء الخصائص (التي سيتم اكتشافها في وقت التشغيل) عند استخدام JS / ES6 ؛ ولكن نظرًا لأنك تستخدم TypeScript ، فإن نظام الكتابة يمسك جميع أخطاء JSX المطبعية في وقت الترجمة:
https://www.typescriptlang.org/docs/handbook/jsx.html

cbazza هو dsx مفتوح المصدر؟

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

بصفتي مستهلكًا لـ React + TypeScript و Flutter ، يمكنني أن أقدم نفسي كمختبِر. هتافات

هل سيكون لدينا مصدر dsx؟ سيكون رائعا جدا!

أنا أحيي جهود cbazza لكنني لن أستخدم DSX في Flutter. سعيد باختباره ، على الرغم من ذلك.

تتعقب المشكلة رقم 27141 إضافة دعم إنشاء الكود إلى نظام الإنشاء. سيتم ذلك من خلال https://github.com/dart-lang/build Builder . من الناحية النظرية ، يجب أن يكون من السهل جدًا توصيل مترجم dsx / ناقل عندما تكون هذه الميزة جاهزة.

بعد قضيتين ، قابلت فريقًا عنيدًا كهذا للمرة الأولى.

هذه ليست مناقشة لـ JSX ، لكنها مناقشة للجحيم المتداخلة

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

أعتقد أن ميزة JSX واضحة ، لكن فريق Flutter يحاول تجاهلها.

JSX لا يحل مشكلة التداخل. رد فعل تواجه نفس المشكلة

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

أعتقد أنه يجب علينا معرفة سبب ظهور JSX. هذا لأن الوظيفة h/createElement مكتوبة بشكل سيئ وأن الكود غير مقروء بشكل جيد. بشكل غير متوقع ، تمت كتابة الرفرفة الآن 10000 مرة أسوأ من وظيفة h/createElement ، والتي يمكن رؤيتها من العين

ظهرت JSX لأن React ، في جوهرها ، مزيج من Javascript و HTML. بناء جملة XML مع الاستيفاء / الحقن لـ Javascript ينشئ JSX بشكل طبيعي.

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

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

أعتقد أن هناك طرقًا لتحسين مشكلة التداخل ، ولكن JSX ليس هو الحل.

بعض الافكار:

1. قم بتطوير دليل نمط داخلي يتطلب من الأشخاص تقسيم أشجار الرفرفة الضخمة إلى مكونات أصغر.

2. احصل على dartfmt للتعرف رسميًا على أن Flutter لديه مجموعة فريدة من احتياجات التنسيق مقارنة بحزم Dart والعمل مع فريق Flutter / Dart للتوصل إلى حل معقول. @سخي

3. استخدم إنشاء الكود مثل حزمةrousselGit @stateless لتسهيل الأمر على المطورين للقيام بالرقم 1

لكي نكون منصفين ، فإن مشكلة التداخل تنشأ في الغالب عندما لا ترغب في كسر الكود الخاص بنا.

تم تصميم الأدوات لتقسيمها إلى العديد من القطع الأصغر.
استخدام وإساءة استخدام أداة إعادة بناء الأصول extract widget .

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

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

ظهرت JSX لأن React ، في جوهرها ، مزيج من Javascript و HTML. بناء جملة XML مع الاستيفاء / الحقن لـ Javascript ينشئ JSX بشكل طبيعي.

كيف تفسر حقيقة أن React Native تستخدم JSX ولا علاقة لها بـ HTML؟

كيف تفسر حقيقة أن React Native تستخدم JSX ولا علاقة لها بـ HTML؟

لأنه يستخدم React. ربما لم يرغبوا في إعادة اختراع بناء الجملة

لأنه يستخدم React. ربما لم يرغبوا في إعادة اختراع بناء الجملة

لذا فإن JSX ليس في الحقيقة مزج جافا سكريبت و HTML كما تنص lukepighetti ولكنه بالأحرى XML-like syntax extension to ECMAScript without any defined semantics... who's purpose is to define a concise and familiar syntax for defining tree structures with attributes.
يتم توضيح كل ذلك في المواصفات: https://facebook.github.io/jsx/

كما أفهمها ، تم إصدار React لأول مرة كـ react + react-dom مع مترجم jsx ، لذلك كان مزيج HTML + JavaScript طبيعيًا. بعد ذلك ، تم استخدام react لدفع عارضين آخرين مثل react-native ، react-vr ، react-pdf ، إلخ. معقول وحساس لتاريخ ونسب React. مواصفات 2019 هي المواصفات اعتبارًا من 2019 ولا تتناول تاريخ React.

أنا موافق

لكن بالنسبة لي هناك مشكلة أكبر. يعمل Vue و React بشكل مشابه في هذا الجانب.
تحتوي React على createElement و Vue لها وظيفة h .

لا نقوم أبدًا بإنشاء مثيل للمكونات يدويًا في كل من React و Vue. إنه الإطار الذي يعتني به.

الرفرفة تتصرف بشكل مختلف. نحن نتعامل بشكل مباشر مع مثيل الأداة.

على هذا النحو في عالم Flutter ، فإن <Foo /> يعني فقط new Foo()

ولكن في هذه الحالة ، فإن JSX لا علاقة لها تمامًا بـ Widgets. نحن فقط نغير بناء الجملة الخاص بكيفية إنشاء مثيل للفئات في لعبة dart.

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

تضمين التغريدة
react-pdf ليس عارض تفاعل آخر ، يجب أن تفكر في react-canvas .
إذن ، react ! = react-dom ! = react-native . حزمة react مسؤولة عن إدارة التسلسلات الهرمية للمكونات بمساعدة JSX لذلك react لا تهتم إذا كانت تولد react-dom ، react-native ، react-canvas ، لذا فإن react لا يتعلق حقًا بتنسيق HTML.

مواصفات 2019 هي المواصفات اعتبارًا من 2019 ولا تتناول تاريخ React.

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

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

نحن فقط نغير بناء الجملة الخاص بكيفية إنشاء مثيل للفئات في لعبة dart.

بالنسبة لحالة DSX مع Flutter ، هذا بالضبط ما يفعله المرشح.

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

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

مرحبًا ، أعتقد أنه قد يكون لديك سوء فهم لرسالتي. يقوم react بتشغيل برامج عرض تفاعلية أخرى مثل react-dom ، react-native ، react-pdf ، react-vr ، إلخ. Afaik ، react و react-dom تم إصدارهما في وقت واحد ، لذا فإن تراث jsx ، في رأيي ، واضح تمامًا. آمل ألا تتعمق في رسالتي لأن لدينا آراء مختلفة حول قيمة JSX في سياق Flutter. ربما يكون من الأفضل إبقائه في الموضوع وليس تقسيم الشعر.

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

ما زلت آمل أن تتمكن Google من فهم جمال JSX ، حيث كان لدينا الكثير من الأشخاص الذين يدعمون ذلك. قد يفكر فريق Google يومًا ما في DSX أو JSX من أجل إطار عمل مستوحى من React ، flutter.

مرحبًا lukepighetti ، هل استخدمت التفاعل الأصلي مع JSX لمدة شهر إلى شهرين؟ إذا كان الأمر كذلك ، يجب أن تفهم سبب بناء تطبيق باستخدام JSX AND React native (أو React ، وأنا أعلم أنهما مختلفان) أسلوب إطار العمل بسيط وجيد البنية.

لا يمكنني التحدث عن lukepighetti ، لكنني أعمل بشكل احترافي مع React لمدة عامين ، والآن أقوم ببعض Vue. لذا فأنا على دراية جيدة عندما يتعلق الأمر بـ JSX.

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

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

على سبيل المثال ، إعادة بيع ديون Foo() إلى Foo(child: Bar()) أمر سهل.
لكن إعادة هيكلة <Foo /> إلى <Foo><Bar /></Foo> ليست كذلك.

• يوفر Flutter الكثير من خيارات إعادة البناء التي تجعل التعامل مع الأقواس أسهل

• علامات الإغلاق الافتراضية التي يقدمها Flutter تعوض عن عدم وجود علامات النهاية.
  _لكنهم لا يظهرون في مراجعات الكود! _
  يفعلون في الواقع! يمكنك القيام بمراجعات التعليمات البرمجية الخاصة بك من IDE الخاص بك. انظر https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests

  • لا تترجم JSX بشكل جيد مع نموذج Flutter.

ماذا لو كانت الأداة تأخذ كلاً من child و children ؟ هل نحصل على:

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

؟

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

الشيء هو أن عددًا قليلاً جدًا من الأدوات يأخذ children . الغالبية العظمى إما child واحد ، أو مجموعة من المعلمات المسماة المخصصة (مثل Scaffold ).

مما يعني أن الغالبية العظمى من الأدوات التي تستخدم JSX ستبدو كما يلي:

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

وهو _الأسوأ_ إذن:

Container(
  child: Bar(),
)

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

كما قلت لأعلى ، أعتقد أن هناك الكثير من الخلط بين ما هي في الواقع JS / ECMAScript / ميزات الويب العامة (نشر الكائن ، والتدمير ، وإمكانية تبادل الكائنات / hashmaps ، وجميع عقد DOM * التي لها واجهة متشابهة للغاية ، ومرونة HTML في عام ، وما إلى ذلك) مع ميزات JSX. IMO السابق هو ما يجعل كتابة JSX ممتعة. بدونها ، أنت تكتب XML فقط ، ومعظم الأشخاص الذين أعرفهم والذين لديهم حق الاختيار لا يحبون كتابة XML.

* تجدر الإشارة إلى أن هذا فوق كل شيء هو معارضتي الرئيسية لمحاولة تعديل Flutter إلى XML. لا أعتقد أن هناك أي نقطة حقيقية تحاول إنكار أن JSX / React لها جذور عميقة في الويب ، وأن عناصر DOM لها معيار طويل الأمد لكل عقدة لها _سمات _ و _ أطفال. من ناحية أخرى ، لا يُلزم Flutter المطورين بتسمية فتحة عنصر واجهة مستخدم مخصصة لأدوات أخرى children أو حتى child ولا أرى سببًا يدعوها لبدء القيام بذلك.

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

ماذا لو كانت الأداة تأخذ كلاً من child و children ؟ هل نحصل على:

لماذا تحتاج الأداة إلى كل من child و children ؟ إما هذا أو ذاك。
موضوع آخر ， بعض أدوات Flutter تستخدم children ، والبعض الآخر يستخدم child ، لا أحد يعتقد أنه معقد وسهل الخلط？ children يحتوي على child ، لذا لا مهما كان عدد child لديك ， واحد أو أكثر ثم واحد ， فقط استخدم children لإنجاز المهمة.

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

JSX أمر مروع أن تكتب باليد. يتطلب الكثير من الأدوات لجعله محتملًا ،

لا يختلف معك عالم React بالكامل فحسب ، بل يختلف معك أيضًا في عالم HTML وعالم XML بأكمله.

يوفر Flutter الكثير من خيارات إعادة البناء التي تجعل التعامل مع الأقواس أسهل

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

يفعلون في الواقع! يمكنك القيام بمراجعات التعليمات البرمجية الخاصة بك من IDE الخاص بك.

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

لا تترجم JSX بشكل جيد مع نموذج Flutter.

هذا مجرد رأيك السيئ ، يمكن لأي شخص أن يرى أن DSX تضيف تحسينات على JSX تتناسب تمامًا مع Flutter.
https://spark-heroku-dsx.herokuapp.com/index.html

إذن أنت تقول أن Flutter "تتطلب الكثير من الأدوات"

لا ، قلت "أسهل" لا "يمكن تحمله".

تصادف أن أجيب على StackOverflow / Slack كثيرًا ، وأحيانًا حتى من هاتفي.
ومن الواضح أن وقتًا سيئًا عند الإجابة على سؤال متعلق بـ html - لكن Flutter جيد.

أفضل ما يمكنك فعله هو قبول أن هناك أكثر من طريقة لفعل شيء ما وأن بعض الناس يفضلون الطريقة الأخرى لفعله.

هذا يعمل في الاتجاه المعاكس. يجب أن ترى ذلك بوضوح ، المجتمع ليس معجبًا بـ JSX بنسبة 100٪. عدد الأصوات المعارِضة على كلٍّ من هذه المسألة والسابقة يثبت ذلك.

هذا مجرد رأيك السيئ ، يمكن لأي شخص أن يرى أن DSX تضيف تحسينات على JSX تتناسب تمامًا مع Flutter.

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

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

إذا كان JSX لا يعمل بشكل جيد في الرفرفة ، يمكنني قبول عدم الانضمام إلى JSX ، ولكن يجب علينا التفكير في الجحيم المتداخل.

قصة جانبية أخرى هي الفاصلة المنقوطة للغة النبال. انه حقا مزعج.

قصة جانبية أخرى هي الفاصلة المنقوطة للغة النبال. انه حقا مزعج.

يوجد طلب لهذا على dart-lang / language: https://github.com/dart-lang/language/issues/69
اذهب واعطيه 👍

يدور هذا النقاش الطويل حول القدرة على استخدام هذا:

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

بدلا من هذا:

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

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

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

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

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

مرحبًا أي شويتز.
يوجد قسم للرد.

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

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

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

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

JonathanSum هو Flutter أكثر تعقيدًا من JSX ، أم أن Flutter يختلف عن _React_ وهذا يسبب احتكاكًا منك؟ إنها مطولة في بعض الحالات ، نعم ، ويمكن القول إنها أقل قابلية للقراءة بدون علامات الإغلاق الافتراضية في IDE ، لكنني لست متأكدًا تمامًا من أن استخدام المُنشئين أكثر تعقيدًا من كتابة DSL مثل XML وما زلت غير متأكد تمامًا لماذا يعتقد الكثير من الناس أن DSL الذي يشبه XML سيكون رصاصة فضية تجعل استخدام Flutter أسهل في الفهم. لا سيما بالنظر إلى أن Flutter ليس له تاريخ سابق مع المشكلات التي تم إنشاء React / JSX لحلها - تجعل React معالجة DOM أسهل وأنظف ، وهذا أمر رائع ، ولكن ما علاقة ذلك بالضبط بـ Flutter مرة أخرى؟

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

بدون لمس الفكرة القائلة بأن React لديها فكرة "حقيقية" عن أن كل شيء مكونات لا يمتلكها Flutter ، هناك أيضًا بعض مزايا تصميم Flutter / Dart التي لا يمكن لـ React / JS التقاطها. ويمكنك قول الشيء نفسه (والعكس صحيح) لمعظم مجموعات / أطر عمل / مكتبات UI اللائقة. بشكل لا يصدق ، المشاريع المختلفة في الواقع مختلفة ؛ ربما يحصل الأشخاص الذين يأتون إلى مشروع واحد على خدمة أفضل إذا لم يبدأوا في توقع أن يكون [أدخل المشروع الذي استخدموه في الماضي]. 🙂

هناك بعض الأفكار المثيرة للاهتمام هناك https://github.com/munificent/ui-as-code

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

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

أوافق الآن على عدم إضافة JSX وعدم ممارسة ضغط إضافي على الرفرفة.

ولكن فيما يتعلق بالسهام ، فهي أقل أناقة بكثير من JS أو TS. أشعر بالعجز

على سبيل المثال ، مسار تطوير تقنية Microsoft UI هو WinForm إلى WPF ， والآن في Flutter تخلى عن WPF واستخدم WinForm بدلاً من ذلك。 استجابة لشكاوى المطور ، عمل فريق Flutter بجد لتنفيذ نافذة WinForm المرئية ومحرر الخصائص。

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

أستطيع أن أرى وظيفة تصيير لفئة التفاعل وصورة للفئة المقدمة والمشتركين في الوقت الحالي.

يمكنني رؤية ملف dart والمحتوى المعروض وسأستغرق من 5 إلى 6 دقائق لمعرفة كيفية عمله ...

يمكنني عمل فصل دراسي شبه معقد في 5 دقائق في محرر نص عادي ، لأنه بديهي

لا يمكنني فعل ذلك في الرفرفة. بدون الإكمال التلقائي لقد انتهيت من العمل كمطور. لا أحب أن أعتمد في امتداد لتطوير شيء ما -. -

ومع ذلك. سيكون من المثير للاهتمام كيف يتعامل مطورو لعبة dart مع هذه "المشكلة". في dart 2 جعلوها أكثر قابلية للقراءة. لا أعرف كيف ستعمل على تحسين قابلية القراءة في dart 3 -4 -5. لكنني أعتقد أنه ستكون هناك حاجة إلى إعادة هيكلة وظيفة بناء المكونات عاجلاً أم آجلاً.

تعديل:
نفي مايند ، فقط جربت React Native مرة أخرى ، وكرهت jsx ، نظام الدعائم ، حقيقة أن كل شيء كان ديناميكيًا كان مفهومًا مخيفًا حقًا مرة أخرى ، أعتقد أنه مجرد رأي شخصي في ذلك الوقت. اترك الرفرفة كما هي ....

لقد طلبوا DSX ، ليس فقط لأنهم يحبون JSX. يريدون Flutter.

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

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

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

قادمًا من Adobe Flex يمكنني القول أن قراءة إعلانات واجهة مستخدم Flutter تقلل الإنتاجية بشكل سيء.

تخيل إعلان واجهة مستخدم مثل MXML بقوة Flutters! لا يسعني إلا أن أحلم!

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

Hixie هل هناك أي مؤشر إلى doc من أجل codegen؟

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

يبدو لي أن codegen مخصص فقط لـ dart -> .dart ، يجب أن يكون ملف الإدخال صالحًا .dart. هذا ليس مفيدًا جدًا لملفات .dsx لأنه مجموعة شاملة من dart. ما زلت بحاجة إلى دعم التحويل البرمجي إلى .dart مع خرائط المصدر مثل ميزات التصحيح ، وما إلى ذلك.

يرجى إلقاء نظرة على SwiftUI ، الذي تم إصداره بالأمس. يبدو أن هذا هو ما يجب أن يهدف إليه Flutter ، بدلاً من الترميز الشبيه بـ React.

ستكون تعبيرات العضو الضمنية لـ Swift وحدها مذهلة للغاية

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

ولكن يمكننا تقنيًا الحصول على شيء مشابه نسبيًا بالفعل:

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

هذا رمز سهام صالح ، حيث Column _لا يزال_ فئة.

إليك أداة عديمة الحالة تعرضها:

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

  final List<Widget> children;

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

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

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

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

إذا كانت هذه الصيغة مطلوبة ، فمن الأفضل بدلاً من طريقة call ، يجب تنفيذها باستخدام currying المُنشئ.

rousselGit أشعر بالفضول بشأن جوانب SwiftUI التي تبدو سحرية بالنسبة لك - يبدو أنها امتداد مباشر جدًا لبناء جملة Swift بالنسبة لي.

على مثال الكود الخاص بهم من هنا :

• Content غير قابل للتغيير؟ هل هذا يعني أن لديهم متجر Mobx / Vue مدمج؟
• ما هذا @State ؟
• لماذا يُعد body متغيرًا؟ هل هذا جامع؟ إذا كان الأمر كذلك ، فمتى يتم استدعاء الطالب مرة أخرى؟
• هل body جزء من واجهة ، أو العديد من المتغيرات المماثلة داخل Content ؟
• ماذا يفعل هذا item in _تفعل؟ لماذا المعامل الصحيح in ليس شيئًا متكررًا ، لكن "النتيجة" بدلاً من ذلك؟
• لماذا تتم محاذاة Image مع اليسار إلى العنوان / العنوان الفرعي عندما لا يكون هناك HStack ؟

لا أستطيع أن أتذكر على وجه اليقين ، لكنني متأكد من أنه لم يكن لدي مثل هذه الأسئلة عند التقاط Flutter.

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

• إنها ليست قابلة للتغيير حقًا (بمعنى Dart أو JS) رغم ذلك؟ إنه هيكل. كما أن المتاجر ذات النمط MobX / Vue (أي الطباعة الورقية على دعم لغة محدود جدًا) ليست هي الطريقة الوحيدة للتعامل مع قابلية التغيير

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

• body خاصية محسوبة ، وهي ظاهرة بسهولة لمطوري Swift. أما عند إعادة حسابها ، فهل يخبرك Widget build(BuildContext context) بطبيعتها عندما يتم استدعاؤها مرة أخرى؟

• Content (مرة أخرى بوضوح لمطوري Swift) يمتد / ينفذ View ، وهو المكان الذي تبحث فيه عن إجابات لسؤالك (يحتوي في الواقع على صفحة مرجعية جيدة جدًا لواجهة برمجة التطبيقات).

• هذا إلى حد كبير "لماذا الكلمة الرئيسية في هذه اللغة ليست نفس الشيء مثل الكلمة الرئيسية في اللغة التي أستخدمها" ، وليس أي شيء على وجه التحديد "سحري". الكلمة الأساسية in هنا ليست هي نفسها بناء for...in - فهي تشير إلى أن جسم الإغلاق على وشك البدء. { item in ... } كتلة دالة تم تمريرها إلى المُنشئ List ؛ a ListView 's itemBuilder ، إذا صح التعبير.

• هل تسأل بشكل شرعي عن سبب احتواء طريقة العرض على قواعد التخطيط المغلفة الخاصة بها؟

على SwiftUI:

1-من الجيد رؤية الحالة معلنة في العرض وليس كملحق جانبي.

2-طرق فردية لطيفة لتعيين الأشياء بدلاً من الاضطرار إلى تمرير كل شيء على المُنشئ (تتيح الأساليب تنفيذ الإجراءات بدلاً من تمرير البيانات فقط).

3-جميل جدًا أن ترى رسومات متجهية توضيحية مختلطة مع كل شيء آخر تعريفي (مثلما اقترحت في الماضي مع عناصر واجهة تعامل SVG التوضيحية) !!!
https://developer.apple.com/tutorials/swiftui/drawing-paths-and-shapes

4-بنيات الرسوم المتحركة والانتقال بسيطة للغاية
https://developer.apple.com/tutorials/swiftui/animating-views-and-transitions

5-سحب وإفلات أدوات التصميم متزامنة مع محرر التعليمات البرمجية في كلا الاتجاهين.

هناك ثآليل مثل كل شيء آخر ولكني أفضل التركيز على ما فعلوه بشكل جيد للغاية.

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

قد يكون ذلك بسبب خلفيتك

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

بالنسبة إلى وقت إعادة الحساب ، هل يخبرك Widget (سياق BuildContext) بطبيعته عندما يتم استدعاؤه مرة أخرى؟

نقطتي هنا هي عدم وجود علاقة بين State وعملية إعادة حساب body .
يعتبر React و Flutter واضحين جدًا في هذا الشأن: setState.
Vue / Mobx "سحرية" باستخدام نفس الميزة @State .

إنه جيد حقًا ، لكن هذا نمط مختلف.

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

لا ، إنها أكثر من "صريحة" مقابل "ضمنية".
يبدو أنهم ركزوا حقًا على "القيام بأكبر قدر ممكن في أقل قدر ممكن من التعليمات البرمجية" ، حتى لو كان يخفي بعضًا من المنطق (في هذه الحالة ، المنطق ltr مقابل rtl logic)

سيطلب منك Flutter استخدام Row .

يستخدم Flutter ويعتمد على الكثير من "ميزات اللغة الفاخرة" (اقرأ: ميزات اللغة التي لا يستخدمها المتحدث و / أو لا يتفق معها). من أعلى رأسي ، المنشئات الثابتة (وأسلوب Dart في تسمية المنشئات بشكل عام) ، التحميل الزائد على المشغل ، الفئات هي واجهات ضمنية ، @covariant ، والمزج هي ميزات من شأنها جذب ردود الفعل من الارتباك إلى وضع العلامات الصريح مثل رائحة رمز اعتمادًا على خلفية المطور. ربما يمكنني الخروج بقائمة أطول مع الأخذ في الاعتبار ساعة من التفكير. وهذه ليست لائحة اتهام ضد Flutter أكثر من كونها لائحة اتهام لـ SwiftUI - لا أفهم لماذا يعتقد المرء أنه من الفضيلة كتابة برنامج بلغة معينة بحيث يمكن كتابتها بنفس الطريقة بأي لغة - ما هو نقطة لغات مختلفة إذا كان من المفترض أن نتظاهر بأن الاختلافات بينهما غير موجودة؟

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

سيطلب منك Flutter استخدام Row

أعتبر أنك لم تستخدم أبدًا ListTile ، والذي له نفس السلوك الموضح هنا ولكن مع المعلمات المسماة؟ هل يجب أن نسأل أيضًا لماذا يضع Scaffold زر قائمة "بطريقة سحرية" في يسار شريط التطبيقات عندما لم تطلب ذلك؟

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

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

بقية المناقشة خارج الموضوع قليلاً. إذا كنت تريد يمكننا متابعة هذا الجزء عن طريق البريد (يعمل بريد github الخاص بي).

لماذا هذا غير مقفل؟ هذا يتطور بالفعل بشكل سيء ، وهو بالضبط نفس المشكلة التي تم قفلها سابقًا.

لقد صنعت واحدة بسيطة هنا:
https://github.com/danialdezfouli/flutterjsx
https://www.npmjs.com/package/flutterjsx
https://www.youtube.com/watch؟v=Oj1JMSurphA

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