cc @lukechurch

@cbazza Bisakah Anda menjelaskan mengapa Anda menginginkan ini? Mungkin menunjukkan contoh seperti apa bentuknya dibandingkan dengan hari ini?

Oke, jadi contoh "Basic widgets" pada ' https://flutter.io/widgets-intro/#basic -widgets' akan terlihat seperti berikut:

import 'package:flutter/material.dart';

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

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

  final Widget title;

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

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

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

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

Bagaimana dengan sintaks ini?:

import 'package:flutter/material.dart';

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

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

  final Widget title;

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

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

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

Huumm, sedikit perbaikan tapi tidak begitu bagus...
Berikut adalah hal-hal yang dicapai dengan menggunakan XML:
(1) Tidak ada lagi barang 'anak' & 'anak-anak'
(2) alat pihak ketiga mudah untuk dimanipulasi (mengurai, menganalisis, dan membuat ulang)
(3) perhatikan bahwa peralihan antara markup dan pemrograman mudah dideteksi. Maksud saya di dalam XML Anda memiliki '{}' untuk membatasi kode dan dalam kode Anda memiliki ' Juga pisahkan semua hal 'gaya' dari struktur utama.
Saya tahu ini pada dasarnya sepenuhnya mendukung cara React tetapi Anda sudah setengah jalan di sana;)

cc @kasperl

(1) Tidak ada lagi barang 'anak' & 'anak-anak'

Saya tidak begitu mengerti mengapa itu diinginkan. "anak" dan "anak-anak" tidak istimewa. Pertimbangkan ListTile misalnya. Bagaimana Anda melakukannya? Mengapa "ikon" di IconButton, atau "rumah" di MaterialApp, sesuatu yang ingin Anda beri nama, tetapi bukan "anak" di Diperluas? Ketiganya hanyalah argumen arbitrer yang kebetulan mengambil objek Widget. Tidak ada yang ajaib tentang "anak" vs "rumah".

(2) mudah untuk dimanipulasi oleh alat pihak ketiga (mengurai, menganalisis, dan membuat ulang)

Anda dapat mengurai, menganalisis, dan membuat ulang kode Dart. Tapi saya setuju kita harus membuatnya lebih mudah. Semoga di tahun-tahun mendatang tim Dart akan menyediakan API yang lebih baik untuk ini.

(3) perhatikan bahwa peralihan antara markup dan pemrograman mudah dideteksi.

Mengapa itu diinginkan? Maksud saya, mengapa semua ini dianggap sebagai "pemrograman"? Itu semua hanya ekspresi.

Maksud saya di dalam XML Anda memiliki '{}' untuk membatasi kode dan dalam kode Anda memiliki '

Saya tidak begitu mengerti perbedaannya.

Juga pisahkan semua hal 'gaya' dari struktur utama.

Anda dapat melakukannya hari ini di Flutter jika Anda benar-benar ingin, cukup masukkan gaya ke dalam variabel seperti yang Anda lakukan dalam kasus XML.

Saya tidak begitu mengerti mengapa itu diinginkan. "anak" dan "anak-anak" tidak istimewa. Pertimbangkan ListTile misalnya. Bagaimana Anda melakukannya? Mengapa "ikon" di IconButton, atau "rumah" di MaterialApp, sesuatu yang ingin Anda beri nama, tetapi bukan "anak" di Diperluas? Ketiganya hanyalah argumen arbitrer yang kebetulan mengambil objek Widget. Tidak ada yang ajaib tentang "anak" vs "rumah".

Lebih sedikit boilerplate, Anda tidak perlu mengatakannya karena itu diwariskan dalam struktur.

Mengapa itu diinginkan? Maksud saya, mengapa semua ini dianggap sebagai "pemrograman"? Itu semua hanya ekspresi.

Ini terkait dengan (2) karena membuat hidup pembuat alat, khususnya pembuat GUI, jauh lebih mudah karena mereka tidak perlu mengurai Dart sepenuhnya; tetapi juga membuat membaca kode lebih mudah.

Saya tidak begitu mengerti perbedaannya.

Format XML sangat sederhana sehingga ketika Anda melihat '{}' Anda tahu itu sedang menghitung ekspresi dalam dart. Sama untuk kebalikannya, saat membaca kode panah dan Anda melihat ') Anda tahu bahwa hierarki objek sedang dibuat dari markup XML.

Juga di prosesor XML terakhir saya akan menghindari meneruskan objek ke atribut orang tua dan sebagai gantinya membuat tag anak seperti di bawah ini:

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

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

Lebih sedikit boilerplate, Anda tidak perlu mengatakannya karena itu diwariskan dalam struktur.

Tapi mengapa hanya untuk beberapa properti? Dan bagaimana Anda menangani kasus di mana ada dua slot anak, seperti ListItem? Sintaks XML-ish sepertinya tidak menangani ini dengan baik.

Juga saya tidak begitu yakin itu kurang boilerplate.

Membandingkan:

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

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

Sama sekali tidak jelas bagi saya bahwa sintaks XML-ish lebih bersih atau kurang boilerplatey. Ada lebih banyak tanda baca, dan beberapa duplikasi konten (misalnya di tag penutup). Dan Anda harus menambahkan beberapa nama, jadi tentu saja, Anda kehilangan "anak", tetapi Anda mendapatkan "nama" di Ikon.

Juga dengan XML bagaimana Anda menjelaskan bahwa Baris dapat mengambil nol, satu, atau lebih dari satu anak, sedangkan Center harus memiliki tepat satu anak? Apa yang akan terjadi jika seseorang melakukan ini?:

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

Ini terkait dengan (2) karena membuat hidup pembuat alat, khususnya pembuat GUI, jauh lebih mudah karena mereka tidak perlu mengurai Dart sepenuhnya;

Mereka tidak perlu sepenuhnya mengurai Dart jika kita juga memiliki API parsing Dart, bukan? Maksud saya, Anda akan mengurai apa yang ingin Anda uraikan dan meninggalkan sisanya. Saya juga tidak yakin itu sebenarnya lebih mudah untuk diurai, karena ini sebenarnya bukan XML; Lihat di bawah.

tetapi juga membuat membaca kode lebih mudah.

Saya sama sekali tidak yakin bahwa versi XMLy di sini lebih mudah dibaca. Setelah Anda membaca beberapa fungsi build, Anda akan segera terbiasa dengan sintaks konstruktor bersarang.

Format XML sangat sederhana sehingga ketika Anda melihat '{}' Anda tahu itu sedang menghitung ekspresi dalam dart.

Ini sebenarnya bukan XML, kan? Ini beberapa varian dari XML. Apakah ada aturan penguraian yang terdefinisi dengan baik untuk itu? Misalnya, apakah ini valid?

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

Bagaimana ia tahu bahwa "}" pertama bukanlah akhir dari ekspresi atribut, tanpa menguraikan Dart?

Sama untuk kebalikannya, saat membaca kode panah dan Anda melihat ') Anda tahu bahwa hierarki objek sedang dibuat dari markup XML.

Anda tahu ini hari ini ketika Anda melihat kata kunci new juga, bukan? Atau memang dalam proposal markup baru-kurang di atas ketika Anda melihat kata yang dikapitalisasi. Apakah ini benar-benar manfaat XML, atau Anda lebih akrab dengan XML daripada Dart?

Juga di prosesor XML terakhir saya akan menghindari meneruskan objek ke atribut orang tua dan sebagai gantinya membuat tag anak seperti di bawah ini:

Saya benar-benar tidak mengerti apa yang Anda usulkan di sini. Ini sama sekali bukan XML yang terbentuk dengan baik sejauh yang saya tahu. Bisakah Anda menguraikan dengan tepat apa sintaks yang Anda usulkan dan bagaimana cara kerjanya? Misalnya, konstruktor "Teks" tampaknya telah menghilang; bagaimana prosesor tahu itu?

Lihat, Anda mencampuradukkan semua yang saya katakan dan percakapan ini tidak mengarah ke mana-mana. Dalam istilah hukum Anda "Menyerang saksi".

Jika Anda benar-benar tertarik untuk mempelajari mengapa JSX panas, cukup google untuk "tutorial reaksi" dan perhatikan bahwa selama 2 tahun terakhir semua artikel di React menggunakan JSX. Cara asli membuat hierarki komponen di React (yang setara dengan cara saat ini di Flutter) tidak pernah disebutkan lagi karena JSX menjadi metode pilihan (praktik terbaik).

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

Hal menarik lainnya adalah TypeScript telah mengadopsi JSX juga:
https://www.typescriptlang.org/docs/handbook/jsx.html

Anda gagal memahami bahwa penguraian XML (dengan beberapa kode tambahan untuk melewati '{}' dengan benar) lebih sederhana daripada penguraian penuh bahasa pemrograman seperti Dart. Itu adalah fakta. Anda berasumsi bahwa pembuat alat akan menggunakan Dart pada pengembangan mereka, bukan kasusnya, Intellij kemungkinan besar menggunakan Kotlin dan Java pada IDE mereka yang mendukung Dart (mereka adalah kasus khusus karena mereka berspesialisasi dalam penguraian bahasa; semua orang akan berjuang untuk sepenuhnya mengurai Dart dari bahasa lain).

Apa yang saya suka tentang menempatkan XML di dalam bahasa lain adalah menyediakan pemisahan kognitif antara keduanya karena XML sangat berbeda dari bahasa pemrograman. Hanya menggulir file sumber Anda dapat dengan mudah melihat apa itu kode dan apa itu markup deklaratif. Tidak dapat melakukannya dengan kode panah yang berpura-pura menjadi markup.

Berhenti memilih hal-hal yang tidak sepenuhnya ditentukan. Semua keraguan Anda telah terjawab untuk itu pelajari lebih lanjut tentang bagaimana hal itu ditangani di BEJ. Saya hanya tidak punya waktu untuk ini di sini.

Saya minta maaf jika saya terdengar defensif atau agresif. Ini adalah topik yang muncul beberapa kali tetapi saya tidak pernah memiliki seseorang yang bersedia untuk benar-benar memperdebatkan kasus ini sebelumnya, jadi saya menemukan percakapan ini sangat berguna dalam mengajari saya apa alasan di balik permintaan itu. Tolong jangan anggap nada argumentatif saya sebagai meremehkan, saya sangat tertarik dengan masukan Anda di sini.

Tolong jangan merasa Anda harus membalas. Saya berkomentar di sini agar ada transparansi mengenai masalah yang harus kami selesaikan sebelum kami dapat membuat keputusan atau merancang dengan satu atau lain cara. Ini pada dasarnya hanya dialog Socrates. Partisipasi Anda dipersilakan tetapi tentu saja Anda tidak boleh merasa bahwa itu adalah tanggung jawab Anda untuk mempertahankan proposal Anda.

Saya yakin BEJ "panas". Di React, sintaks non-JSX jauh lebih buruk daripada sintaks alternatif yang diusulkan dalam masalah ini (yang terlihat seperti kode kita saat ini tetapi tanpa kata kunci "baru" dan "const"). Apa yang saya coba pahami adalah apakah alasan yang sama bahwa JSX "panas" di React berlaku untuk Flutter.

Mengenai TypeScript melakukan JSX, Pada tahun 2012 saya terlibat dalam upaya untuk menentukan E4H , dan bahkan sebelum itu ada E4X . Kedua upaya itu mati. Jadi, penting bagi saya untuk memahami apa sebenarnya yang disukai orang tentang JSX vs sintaks lainnya.

Mengurai XML tidak mudah, mengurai jenis XML-tetapi-dengan-kurung kurawal-entah bagaimana juga tidak mudah. Mengurai jenis XML-tetapi-dengan-kurung kurawal-entah bagaimana-yang-tertanam-dalam-bahasa lain bahkan lebih mudah. Namun, seberapa mudah implementasinya mungkin bukan masalah besar karena itu akan diimplementasikan sekali atau dua kali dan kemudian perpustakaan yang melakukannya akan digunakan kembali. (Saya telah banyak terlibat dalam menulis spesifikasi untuk parsing HTML dan terlibat dalam pekerjaan serupa untuk XML, dan saya telah mengimplementasikan parser untuk Dart, jadi saya memiliki ide yang cukup bagus tentang betapa sulitnya parsing bahasa markup vs bahasa pemrograman sebenarnya adalah.)

Apa yang saya suka tentang menempatkan XML di dalam bahasa lain adalah menyediakan pemisahan kognitif antara keduanya karena XML sangat berbeda dari bahasa pemrograman. Hanya menggulir file sumber Anda dapat dengan mudah melihat apa itu kode dan apa itu markup deklaratif. Tidak dapat melakukannya dengan kode panah yang berpura-pura menjadi markup.

Tetapi mengapa bermanfaat untuk dapat melakukan itu?

Cukup jelas ketika menggulir aplikasi Flutter di mana fungsi build berada (mereka adalah ekspresi bersarang raksasa). Ada apa dengan "markup deklaratif" yang penting untuk dipisahkan dari "kode"?

Berhenti memilih hal-hal yang tidak sepenuhnya ditentukan. Semua keraguan Anda telah terjawab untuk itu pelajari lebih lanjut tentang bagaimana hal itu ditangani di BEJ. Saya hanya tidak punya waktu untuk ini di sini.

Sejauh yang saya tahu, BEJ tidak menangani hal-hal yang saya tanyakan. Misalnya, React tidak memiliki konsep slot anak. Hal terdekat yang dapat saya temukan adalah sesuatu yang mereka lakukan dengan beralih kembali ke JS lalu kembali ke JSX di dalamnya, jadi Anda harus dapat mengurai bahasa pemrograman dan bahasa markup.

Apa yang saya coba pahami adalah apakah alasan yang sama bahwa JSX "panas" di React berlaku untuk Flutter.

Ya, hal yang sama persis berlaku di sini. Cara saat ini terlihat bagus bagi Anda karena itulah satu-satunya pilihan yang Anda miliki. Beri orang pilihan kedua dan hal yang sama akan terjadi.

Apakah E4X mati atau tidak tidak relevan karena tidak ada yang hidup selamanya. Saya telah sering menggunakan ActionScript dengan E4X dan berpikir bahwa Adobe melakukan pekerjaan yang sangat baik di sana. Di satu sisi Flutter hanyalah versi terbaru dari Adobe Flash dengan aplikasi Flex.

(Saya telah banyak terlibat dalam menulis spesifikasi untuk parsing HTML dan terlibat dalam pekerjaan serupa untuk XML, dan saya telah mengimplementasikan parser untuk Dart, jadi saya memiliki ide yang cukup bagus tentang betapa sulitnya parsing bahasa markup vs bahasa pemrograman sebenarnya adalah.)

Hebat sehingga Anda tahu bahwa mem-parsing bahasa markup itu sepele dibandingkan dengan mem-parsing bahasa pemrograman imperatif.

Tetapi mengapa bermanfaat untuk dapat melakukan itu?

Keterbacaan kode dan kesederhanaan yang pada gilirannya mendorong sejumlah besar manfaat lainnya.

Cukup jelas ketika menggulir aplikasi Flutter di mana fungsi build berada (mereka adalah ekspresi bersarang raksasa). Ada apa dengan "markup deklaratif" yang penting untuk dipisahkan dari "kode"?

Pada ekspresi bersarang raksasa Anda, dapatkah Anda dengan mudah melihat struktur? dapatkah struktur ini dengan mudah dimanipulasi oleh alat lain seperti pembuat GUI secara bergantian? Maksud saya seperti yang digunakan Adobe Flex Builder untuk melakukan, menyeret dan melepas widget, memasangnya di UI dan kemudian beralih ke tampilan kode dan hanya mengedit apa pun yang Anda inginkan dan kemudian beralih kembali ke mode gui dan terus memanipulasi widget. Anda tidak dapat melakukannya dengan mudah ketika programmer masuk ke dalam "ekspresi bersarang raksasa" Anda dan menulis kode panah valid yang tidak mengikuti struktur yang diharapkan oleh editor GUI. Dengan struktur XML tetap itu tidak masalah.

Sejauh yang saya tahu, BEJ tidak menangani hal-hal yang saya tanyakan. Misalnya, React tidak memiliki konsep slot anak

Ini menanganinya dengan baik, Anda hanya tidak tahu bagaimana melakukannya. Jadi ke depan, cukup berikan contoh yang dimaksud di sini dan saya akan memberi Anda apa yang menurut saya seharusnya versi BEJ.

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

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

Itu terlihat lebih panjang dari versi dart tetapi saya bisa menempatkan semuanya dalam jumlah baris yang sama. Masalahnya adalah IDE/Editor dapat memberikan '+' & '-' untuk memperluas dan menutup node XML ini.

Jadikan Flutter terlihat familier bagi pengembang Bereaksi dan Anda memiliki peluang untuk menarik banyak pengguna baru ke Flutter.

Apakah E4X mati atau tidak tidak relevan karena tidak ada yang hidup selamanya.

Apakah itu mati bukanlah masalah, itu sebabnya ia mati. Apakah itu mati karena tidak memberikan solusi yang diinginkan orang? Apakah itu mati karena masalah implementasi? Apakah itu mati karena masalah paten? Apakah itu terlalu dini? Sangat terlambat? Saya pikir penting untuk belajar pelajaran dari pengalaman masa lalu. Mengapa E4X dan E4H gagal sedangkan BEJ berhasil?

Yang menurut saya menarik adalah orang yang baru mengenal Flutter sering menanyakan dua hal: bahasa markup, dan GIF animasi. Kemudian tiga bulan kemudian, mereka masih meminta GIF animasi, tetapi tidak untuk bahasa markup. Bisa jadi ini karena bahasa markup sebenarnya tidak diperlukan setelah Anda terbiasa menulis metode build di Dart. Bisa jadi mereka masih menginginkan bahasa markup tetapi telah mengatasi kelalaian dan jadi jangan berpikir untuk bertanya lagi. Ada baiknya mencari tahu yang mana karena jika tidak, kita berisiko menghabiskan upaya untuk sesuatu yang merupakan pilihan yang salah (di kedua arah).

Pada ekspresi bersarang raksasa Anda, dapatkah Anda dengan mudah melihat struktur?

Ya, setidaknya semudah dengan XML. Secara pribadi, saya menemukan XML menjadi sangat verbose dan mengaburkan struktur. Tapi saya pikir ini lebih tentang apa yang biasa Anda lakukan.

(Kami juga bereksperimen dengan IDE yang memasukkan komentar "tag penutup" virtual untuk Anda sehingga Anda dapat melihat strukturnya tanpa harus benar-benar menulisnya.)

Hebat sehingga Anda tahu bahwa mem-parsing bahasa markup itu sepele dibandingkan dengan mem-parsing bahasa pemrograman imperatif.

Pengalaman saya adalah bahwa deklaratif vs imperatif bukanlah perbedaan yang penting dalam menentukan seberapa mudah suatu bahasa diuraikan. (Misalnya, HTML adalah "deklaratif" tetapi mungkin salah satu bahasa yang paling rumit untuk diuraikan yang pernah saya tangani.)

Keterbacaan kode dan kesederhanaan yang pada gilirannya mendorong sejumlah besar manfaat lainnya.

Jika ini adalah manfaat utama maka ini adalah sesuatu yang bisa kita uji. Kita bisa mengambil campuran insinyur yang terbiasa menulis HTML, React, kode iOS, kode Android, Flutter, aplikasi baris perintah, dan sebagainya, dan menyajikan masing-masing dengan berbagai sintaks, dan meminta mereka untuk menjelaskan apa yang mereka pikirkan UI yang dihasilkan akan terlihat seperti. Kami kemudian dapat mengukur sintaks mana yang mendapatkan hasil terbaik. @InMatrix apakah ini sesuatu yang bisa kita lihat setelah pekerjaan animasi selesai, mungkin?

dapatkah struktur ini dengan mudah dimanipulasi oleh alat lain seperti pembuat GUI secara bergantian?

Ya, setidaknya pada prinsipnya. Seharusnya relatif mudah untuk secara mekanis mengonversi ekspresi Dart ke XML atau JSON atau bahasa terstruktur apa pun yang mungkin digunakan. Ini hanya masalah mengubah sintaks, informasi sebenarnya sama. Secara pribadi saya tidak akan mengubahnya menjadi sintaks yang berbeda jika saya membuat editor GUI, saya hanya akan menguraikannya menjadi struktur data dalam memori langsung dari Dart.

Anda tidak dapat melakukannya dengan mudah ketika programmer masuk ke dalam "ekspresi bersarang raksasa" Anda dan menulis kode panah valid yang tidak mengikuti struktur yang diharapkan oleh editor GUI. Dengan struktur XML tetap itu tidak masalah.

Masalahnya, Anda dapat menempatkan "kode panah apa pun yang valid" yang sama persis dalam struktur XML seperti pada ekspresi Dart. Mereka benar-benar dapat dipertukarkan secara mekanis. Jadi saya tidak benar-benar melihat bagaimana menggunakan XML membantu dengan ini secara khusus. Misalnya bagaimana Anda mengubah ini menjadi XML?:

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

Ini menanganinya dengan baik, Anda hanya tidak tahu bagaimana melakukannya.

Maksud saya khususnya BEJ. Saya setuju bahwa sintaks yang Anda usulkan akan menjadi cara yang benar-benar valid untuk mendekati masalah.

Saya bekerja di Flex SDK Adobe, yang menggabungkan markup XML dan ActionScript, selama beberapa tahun terakhir produk tersebut ada di Adobe. Saya memahami daya tarik markup untuk mendefinisikan UI namun saya juga dapat mengingat beberapa kelemahan:

• Visual aplikasi fleksibel dapat didefinisikan dalam hal markup dan kode. Seingat saya, kode cenderung mendominasi di aplikasi dunia nyata yang besar. Keterbacaan tidak selalu merupakan manfaat untuk aplikasi yang didefinisikan sebagai gabungan markup dan kode yang kompleks.
• IDE "Flex Builder" harus mendukung aplikasi yang ditentukan oleh markup dan kode. Hal ini membuat IDE sulit untuk dibangun dan dipelihara. Pengembang cenderung melihatnya sebagai alat ActionScript.
• Mengembangkan dan memelihara "kompilator" XML adalah beban signifikan yang membuat tim insinyur sibuk penuh waktu. Menjaga kompiler dan toolkit di lockstep memperlambat evolusi SDK secara keseluruhan.

Sudah bertahun-tahun dan saya tidak bisa lagi mengingat semua detailnya. Namun kesan keseluruhan saya adalah bahwa mendefinisikan UI dengan kombinasi markup dan kode adalah yang terbaik.

Apakah itu mati bukanlah masalah, itu sebabnya ia mati. Apakah itu mati karena tidak memberikan solusi yang diinginkan orang? Apakah itu mati karena masalah implementasi? Apakah itu mati karena masalah paten? Apakah itu terlalu dini? Sangat terlambat? Saya pikir penting untuk belajar pelajaran dari pengalaman masa lalu. Mengapa E4X dan E4H gagal sedangkan BEJ berhasil?

Itu mati karena E4X hanya diimplementasikan dalam ActionScript yang hanya digunakan di dalam Adobe Flash/Flex dan Adobe mematikan proyek. Alih-alih, Adobe mengubah arah menuju standar terbuka di mana tidak ada penyedia sumber tunggal dengan kemungkinan penguncian dan ledakan ekosistem.

Yang menurut saya menarik adalah orang yang baru mengenal Flutter sering menanyakan dua hal: bahasa markup, dan GIF animasi. Kemudian tiga bulan kemudian, mereka masih meminta GIF animasi, tetapi tidak untuk bahasa markup. Bisa jadi ini karena bahasa markup sebenarnya tidak diperlukan setelah Anda terbiasa menulis metode build di Dart. Bisa jadi mereka masih menginginkan bahasa markup tetapi telah mengatasi kelalaian dan jadi jangan berpikir untuk bertanya lagi. Ada baiknya mencari tahu yang mana karena jika tidak, kita berisiko menghabiskan upaya untuk sesuatu yang merupakan pilihan yang salah (di kedua arah).

Nah, jika saya meminta Anda untuk 2 hal dan Anda tidak melakukan keduanya dalam 3 bulan dan ada alternatif untuk hal pertama, saya juga hanya akan meminta Anda untuk apa yang sama sekali tidak mungkin dilakukan mengingat respons Anda dan kinerja pengiriman sebelumnya.

(Kami juga bereksperimen dengan IDE yang memasukkan komentar "tag penutup" virtual untuk Anda sehingga Anda dapat melihat strukturnya tanpa harus benar-benar menulisnya.)

Agak lucu tapi sepertinya menempatkan tag penutup XML yang Anda sebutkan sebelumnya terlalu bertele-tele.

Jika ini adalah manfaat utama maka ini adalah sesuatu yang bisa kita uji. Kita bisa mengambil campuran insinyur yang terbiasa menulis HTML, React, kode iOS, kode Android, Flutter, aplikasi baris perintah, dan sebagainya, dan menyajikan masing-masing dengan berbagai sintaks, dan meminta mereka untuk menjelaskan apa yang mereka pikirkan UI yang dihasilkan akan terlihat seperti. Kami kemudian dapat mengukur sintaks mana yang mendapatkan hasil terbaik. @InMatrix apakah ini sesuatu yang bisa kita lihat setelah pekerjaan animasi selesai, mungkin?

Tentu Anda dapat melakukannya, saya yakin Anda akan mengetahui bahwa "Setelah Anda melakukan Bereaksi (dengan JSX), Anda tidak akan kembali". Survei pengembang React yang berpengalaman dan tanyakan apakah menurut mereka JSX buruk dan seharusnya tidak pernah dilakukan. Tunjukkan jalan Anda dan tanyakan apakah mereka ingin mengganti BEJ dengan apa yang Anda miliki. Sebelum Anda melakukannya, tutup pintu dan kunci tempat itu karena pengembang ini hanya akan mengambil barang-barang mereka dan berlari ke pintu keluar terdekat.

Masalahnya, Anda dapat menempatkan "kode panah apa pun yang valid" yang sama persis dalam struktur XML seperti pada ekspresi Dart.

Tentu, tetapi untuk pembuat GUI itu hanya blok byte yang tidak perlu disentuh dan dapat dengan mudah dilewati. Membuatnya desain/kode dapat dipertukarkan secara praktis daripada pada prinsipnya.

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

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

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

Saya menggunakan Adobe Flex Builder secara ekstensif...

Pengembang cenderung melihatnya sebagai alat ActionScript.

Ya, tetapi saya sering beralih dari tampilan desain ke tampilan kode dan sebaliknya.
Memulai layar saya akan pergi ke tampilan desain dan menggunakan drag/drop ke widget tata letak dan menghasilkan layar statis pertama. Kemudian saya akan menambahkan kode dan beberapa data statis untuk mengisi layar sehingga saya dapat menunjukkan kepada orang-orang sesuatu yang berjalan yang tampak seperti barang siap produksi. Produktivitas luar biasa. Saat pengembangan berlangsung, saya menghubungkan ujung depan ke ujung belakang dan jumlah kode ActionScript bertambah dan ya itu mendominasi kode secara keseluruhan tetapi bahkan mendekati waktu rilis, saya sering menggunakan tampilan desain untuk mengubah UI tanpa harus menggali lebih dalam. kode.

Namun kesan keseluruhan saya adalah bahwa mendefinisikan UI dengan kombinasi markup dan kode adalah yang terbaik.

Tidak di dunia sekarang ini. Bahasa imperatif telah berkembang dalam filosofi Python dan bagus untuk pengembangan. Teknik deklaratif dengan embedded markup (XML) menjadi mainstream dengan munculnya React; dan JSON menjadi format data berbasis teks yang disukai.

E4X hanya diimplementasikan di ActionScript

E4X adalah standar ECMA. Mozilla mengirimkannya untuk sementara waktu, tetapi kemudian menghapusnya (langkah yang sangat tidak biasa untuk vendor browser). Vendor browser lain tidak pernah ingin mengimplementasikannya. (Namun, mereka telah mengimplementasikan fitur ECMA baru lainnya.) Dengan E4H, vendor browser tidak pernah tertarik untuk mengimplementasikannya (meskipun sekali lagi, mereka telah mengimplementasikan banyak hal lain yang telah saya bantu ciptakan).

Nah, jika saya meminta Anda untuk 2 hal dan Anda tidak melakukan keduanya dalam 3 bulan dan ada alternatif untuk hal pertama, saya juga hanya akan meminta Anda untuk apa yang sama sekali tidak mungkin dilakukan mengingat respons Anda dan kinerja pengiriman sebelumnya.

Itu salah satu teori yang mungkin. Orang cenderung meminta banyak hal lain selain itu, dan banyak hal yang mereka minta diimplementasikan, dan ada solusi untuk GIF animasi juga, jadi saya tidak yakin ini sepenuhnya menjelaskan situasinya.

Agak lucu tapi sepertinya menempatkan tag penutup XML yang Anda sebutkan sebelumnya terlalu bertele-tele.

Memang. Ini adalah fitur IDE opsional, dan yang tidak perlu Anda tuliskan ke dalam kode, yang membuat perbedaan besar apakah verbositas menjadi masalah.

... ListView ...

Bagaimana editor GUI menangani markup ini? Saya tidak begitu mengerti bagaimana memvisualisasikan UI untuk ini.

Ini mungkin merupakan argumen balasan untuk permintaan ini, dan/atau mungkin beberapa wawasan yang perlu diingat jika Anda ingin markup. Saya memiliki perasaan yang kuat bahwa menambahkan markup membuat beberapa tantangan dengan GWT Saya tidak suka melihat API lain melaluinya.

Saya telah melihat beberapa kerangka kerja lain melalui transisi ini terkait dengan pembangunan UI. Markup seperti ini berfungsi dengan baik untuk perkakas, sejauh ini sangat cocok untuk pengembang IDE. Lebih mudah untuk memisahkan tanggung jawab siapa melakukan apa. Meskipun saya pikir itu bisa dilakukan dengan lebih baik.

GWT dimulai dengan cara ini, membangun UI dengan Java. Kemudian datanglah UiBinder, di mana Anda dapat membangun UI dalam markup xml, dengan spesifikasi. Kemudian perkakas, Eclipse Plugin, mampu menghasilkan UI dalam markup xml. Android juga melakukannya, tidak perlu bertele-tele. Jadi apa yang saya lihat terjadi, markup bekerja sangat baik untuk pengembang UI IDE. Tapi sungguh, markup adalah investasi besar yang sangat besar dalam waktu dan menambahkan alat kompleksitas untuk mentransisikannya ke program nyata. Dan perkakas selalu datang terakhir. Jadi sementara itu, sementara semua yang terwujud menjadi kenyataan, ada dua dunia. Dua cara menarik untuk melakukan segalanya. Satu dalam bahasa default dan satu dalam markup. Jadi saya mendukung GWT hari ini. Ketika saya menulis dokumentasi, saya harus menulisnya dua kali, sekali untuk Java dan sekali untuk UiBinder XML Markup. Jadi pertanyaan sebenarnya, jika Anda ingin menempuh jalan markup, saya pikir pertanyaannya harus ditanyakan, apakah kerumitan tambahan itu sepadan dengan perjalanannya!

JSX Saya pikir bertujuan untuk memecahkan masalah lain di mana Anda ingin memadukan apa yang Anda lakukan dengan HTML dan javascript. Rasanya kompleksitas tambahan dari spesifikasi markup tidak sesuai dengan kebutuhan penulisan UI dengan markup. Terutama ketika Anda tidak benar-benar memiliki bahasa markup dokumen sebagai target. Setidaknya tidak untuk pengguna sehari-hari.

Pada catatan positif. Saya suka bekerja pada perkakas. Jadi saya bisa melihat bahasa markup cukup berguna. Jauh lebih mudah untuk menulis dan memodifikasi AST saat Anda menggunakan markup.

Tetapi sekali lagi, jika Anda memiliki cukup pikiran tentang pekerjaan itu, tidak masalah apa yang Anda lakukan. Pada akhirnya, jika pengembang dapat menulis aplikasinya lebih cepat dengan api Anda, Anda akan mendapatkan daya tarik. Tapi berapa biayanya untuk tim teknik.

Saya pikir pertanyaan sebenarnya adalah, bagaimana UI bisa dibangun lebih cepat. Saya pikir perkakas bisa menulis panah, lewati markup perantara. Dan tujuan saya tidak benar-benar untuk mengatakan itu tidak layak, tetapi benar-benar menghitung biaya di semua lini jika jalan diambil!

E4X adalah standar ECMA. Mozilla mengirimkannya untuk sementara waktu, tetapi kemudian menghapusnya (langkah yang sangat tidak biasa untuk vendor browser). Vendor browser lain tidak pernah ingin mengimplementasikannya.

Saya akan mengatakan hanya Adobe yang sepenuhnya memperjuangkan E4X dan memiliki pengikut yang baik dengan pengembang. Vendor browser menambah dan menghapus barang dari browser mereka sepanjang waktu; bukankah Google menghapus dukungan MathML?

Itu salah satu teori yang mungkin. Orang cenderung meminta banyak hal lain selain itu, dan banyak hal yang mereka minta diimplementasikan, dan ada solusi untuk GIF animasi juga, jadi saya tidak yakin ini sepenuhnya menjelaskan situasinya.

Inilah hal tentang React dan JSX. Anda benar-benar tidak sepenuhnya menghargai apa yang dibawa React ke meja sampai Anda mengembangkannya untuk sementara, kemudian menjadi malam dan hari terhadap semua kerangka kerja lainnya.

Bagaimana editor GUI menangani markup ini? Saya tidak begitu mengerti bagaimana memvisualisasikan UI untuk ini.

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

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

saya akan mewakili \sebagai persegi panjang dan jika anak/anak-anaknya di mana widget lain saya akan meletakkan persegi panjang untuk itu di dalamnya.
Karena anak dalam kasus ini adalah sebuah fungsi, Anda cukup meletakkan persegi panjang yang bertuliskan 'tidak dapat diedit/kode' untuk memberi tahu pengguna bahwa widget ini dibuat dari kode atau dalam hal ini dengan mudah menyimpulkan bahwa fungsi tersebut adalah pembungkus dangkal kewidget dan cukup tunjukkan itu; Maksud saya persegi panjang yang mengatakan bahwa fungsinya adalah pembungkus fungsi yang dangkal dan di dalamnya persegi panjang widget item Daftar (\pada kasus ini).

Tapi sungguh, markup adalah investasi besar yang sangat besar dalam waktu dan menambahkan alat kompleksitas untuk mentransisikannya ke program nyata.

Yang saya minta hanyalah menambahkan ekstensi sederhana ini pada kompiler Dart sehingga jika pengembang menginginkannya, mereka dapat menulis menggunakan struktur XML ini. Cara lama akan terus bekerja dan jumlah pekerjaan yang terlibat untuk melakukan ini tidak besar sama sekali. Anda sebenarnya dapat melihat berapa banyak baris kode yang diperlukan kompiler babel.js untuk melakukan JSX dan saya berbicara ratusan dan bukan ribuan baris (saya baru saja memeriksanya).

Dan perkakas selalu datang terakhir. Jadi sementara itu, sementara semua itu terwujud menjadi kenyataan, ada dua dunia. Dua cara menarik untuk melakukan segalanya. Satu dalam bahasa default dan satu dalam markup

Tentu tapi React sudah seperti ini dan itu bukan masalah sama sekali.

Ketika saya menulis dokumentasi, saya harus menulisnya dua kali, sekali untuk Java dan sekali untuk UiBinder XML Markup.

Tidak di Bereaksi karena markup tinggal di dalam kode.

adalah kompleksitas tambahan yang sepadan dengan perjalanannya!

Tentu saja, ini seperti argumen apakah Anda harus melatih pengembang Anda dengan teknik terbaru dan mengambil risiko mereka meninggalkan perusahaan Anda. Risiko yang lebih besar adalah membuat mereka tidak terlatih. Jadi, Anda harus mengadopsi teknik terbaru di luar sana atau berisiko tertinggal.

React memimpin perjalanan dengan teknik terbaru untuk mengembangkan UI/UX. Ini memiliki daya tarik yang luar biasa dengan pengembang. Risiko terbesar Anda adalah tidak memenuhi bilah React.

JSX Saya pikir bertujuan untuk memecahkan masalah lain di mana Anda ingin memadukan apa yang Anda lakukan dengan HTML dan javascript

JSX tidak hanya untuk HTML, React Native menghasilkan Tampilan (seperti Widget Flutter) dari markup XML.

Saya pikir pertanyaan sebenarnya adalah, bagaimana UI bisa dibangun lebih cepat.

Lebih seperti bagaimana UI/UX dapat dibangun dengan lebih baik. Arti yang lebih baik: lebih cepat, kualitas lebih tinggi (kode dan UI/UX), interaksi desainer-pengembang yang lancar, dll.

Omong-omong, pekerjaan yang sangat bagus dilakukan pada alat pengembang; 'dokter berdebar-debar' luar biasa !!!
Saya sekarang memasak dengan gas dan bisa sangat kreatif ;)

Saya hanya ingin menanggapi pertanyaan keterbacaan yang diangkat di sini, meskipun saya mengerti keterbacaan hanyalah salah satu dari banyak faktor yang perlu kita pertimbangkan.

Keterbacaan kode dan kesederhanaan yang pada gilirannya mendorong sejumlah besar manfaat lainnya.

Jika ini adalah manfaat utama maka ini adalah sesuatu yang bisa kita uji. Kita bisa mengambil campuran insinyur yang terbiasa menulis HTML, React, kode iOS, kode Android, Flutter, aplikasi baris perintah, dan sebagainya, dan menyajikan masing-masing dengan berbagai sintaks, dan meminta mereka untuk menjelaskan apa yang mereka pikirkan UI yang dihasilkan akan terlihat seperti. Kami kemudian dapat mengukur sintaks mana yang mendapatkan hasil terbaik. @InMatrix apakah ini sesuatu yang bisa kita lihat setelah pekerjaan animasi selesai, mungkin?

Tentu saja ada cara untuk mempelajari keterbacaan kode secara empiris, dan kita dapat melakukan diskusi yang lebih serius ketika saatnya untuk perencanaan Q4. Untuk membuat studi seperti itu berguna, kita perlu mendefinisikan jenis tugas membaca apa yang penting bagi developer dalam konteks pemrograman Flutter. Selain membaca seluruh metode build dan membayangkan UI yang dihasilkan, keterbacaan juga memengaruhi tugas yang lebih kecil seperti mengidentifikasi metode build dalam file dart, mencocokkan kurung kurawal, membaca komentar sebaris, dll.

Untuk mendukung beberapa tugas dengan cakupan yang lebih sempit, kita dapat bereksperimen dengan peningkatan UI di editor terlebih dahulu, yang biasanya lebih murah daripada memperkenalkan dan memelihara bahasa markup. Fitur label penutup dalam kode VS adalah salah satu peningkatan UI semacam itu, dan kita harus memahami seberapa baik fitur ini memecahkan masalah pencocokan penjepit yang ingin diatasi. Ada banyak opsi lain di ruang ini yang belum kami coba. Misalnya, font atau warna latar belakang yang berbeda dapat digunakan untuk menampilkan metode build untuk membantu pengembang memisahkannya secara mental dari kode lainnya.

Hal lain yang menurut saya penting adalah bagaimana kita dapat mendorong orang untuk tidak menulis metode pembuatan raksasa dan memanfaatkan sifat komposisi kerangka kerja. Jika metode build lebih tinggi dari tinggi layar Anda, itu akan sulit dibaca terlepas dari itu Dart atau XML.

Hal lain yang menurut saya penting adalah bagaimana kita dapat mendorong orang untuk tidak menulis metode pembuatan raksasa dan memanfaatkan sifat komposisi kerangka kerja. Jika metode build lebih tinggi dari tinggi layar Anda, itu akan sulit dibaca terlepas dari itu Dart atau XML.

Ini bukan hanya metode pembuatan. Ini semua metode lain yang dipanggil metode build untuk membangun pohon widget. Sangat umum di React untuk menggunakan metode yang lebih kecil untuk membangun potongan sub-pohon dan kemudian memanggilnya ke dalam pohon yang lebih besar.

Juga di WebStorm dengan JSX, setiap node XML memiliki +/- yang dapat digunakan untuk memperluas/menciutkan node dan anak-anak untuk membuat struktur membaca lebih besar dari ketinggian layar lebih mudah.

Satu hal yang kami temukan di Flutter adalah bahwa metode build besar tidak bagus untuk kinerja, dan kami mencoba mendorong orang untuk memecah metode build mereka menjadi widget yang lebih kecil yang dapat digunakan kembali. Khususnya, di Flutter, memiliki metode build yang dibangun dari hasil metode lain agaknya merupakan antipattern yang lebih baik kami hindari daripada membuatnya lebih mudah. (Ini agak merupakan realisasi baru-baru ini sehingga banyak contoh dan widget kami belum melakukannya dengan baik.)

kami mencoba mendorong orang untuk memecah metode pembuatan mereka menjadi widget yang lebih kecil yang dapat digunakan kembali.

Apakah itu benar-benar menjadi widget yang dapat digunakan kembali atau hanya widget pembungkus/komposit? Maksud saya agar dapat digunakan kembali, Anda harus memiliki setidaknya 2 contoh penggunaan.

AppBar di https://flutter.io/catalog/samples/basic-app-bar/ sangat unik sehingga Anda tidak dapat menyebutnya sebagai komponen yang dapat digunakan kembali; ini adalah komponen pembungkus/komposit dan dalam kasus ini mengapa tidak menggunakan metode lokal saja untuk membangun bagian UI itu? Saya kira jika itu melakukan lebih banyak hal, masuk akal untuk menempatkannya di komponen pembungkus/komposit.

Satu hal yang kami temukan di Flutter adalah bahwa metode build besar tidak bagus untuk kinerja

Karena Anda menyebutkan kinerja, memiliki loop animasi yang mendorong metode build akan menyebabkan masalah kinerja untuk animasi yang mulus. Anda tidak ingin metode build Anda dipanggil 60 kali per detik atau lebih, khususnya mengingat metode build adalah kode pengguna (misalnya, itu bisa memiliki loop super panjang yang memakan waktu lama dan akan menyebabkan animasi dilewati). Menjadi pemula Flutter mungkin saya salah.

AppBar di https://flutter.io/catalog/samples/basic-app-bar/ sangat unik sehingga Anda tidak dapat menyebutnya sebagai komponen yang dapat digunakan kembali

Ini juga relatif kecil, jadi tidak apa-apa.

Mengenai kinerja, ini agak di luar topik untuk masalah ini jadi silakan ajukan masalah baru jika Anda ingin mendiskusikannya (atau kirim email ke flutter-dev atau posting di stack overflow, apa pun yang Anda inginkan).

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

Sungguh gila melihat masalah ini terkubur. Menurut pendapat saya, ini akan menjadi terobosan bagi Flutter untuk mengimplementasikan sintaks seperti JSX untuk membuat widget.

Saya benar-benar tidak mengerti audiens target, banyak pengembang ios dan android bergerak untuk bereaksi asli, tampaknya ini adalah peluang sempurna untuk memanen pangsa pasar.

Saya mendorong orang-orang yang terlibat untuk memberikan reaksi asli dan melihat apa yang kita bicarakan.

Saya tidak ketinggalan JSX sedikit di Flutter. Ini hanya akan mengasapi kerangka kerja dan alat untuk beberapa keuntungan kecil di sana-sini.

@birkir Saya 100% dengan Anda dalam masalah ini. Kurangnya JSX, yang sangat cocok untuk Flutter, membuat Flutter terlihat tua dan berkarat, terasa seperti teknologi tahun 1990-an. Sebenarnya sepertinya semua orang, dalam satu atau lain cara, mengadopsi BEJ; yang terbaru adalah kerangka kerja Vue.js yang populer.

+1

@zoechi Apa pengalaman Anda sebelumnya dengan BEJ, apakah Anda benar-benar menggunakannya atau hanya melihatnya? Saya pikir kalian meremehkan BEJ dengan mengatakan itu akan memberikan keuntungan kecil di sana-sini. Jika Anda tidak memiliki pengguna, Anda tidak memiliki produk.

@birkir Saya melihat banyak kegembiraan tentang JSX di sini, tetapi sepertinya tidak ada yang mau repot-repot menjelaskan apa sebenarnya yang akan diperoleh Flutter dari memiliki DSL seperti itu, kecuali mungkin beberapa keterbacaan yang lebih baik yang sebagian besar subjektif.

Lebih banyak fitur biasanya hanya menggunakan kerangka kerja alih-alih meningkatkannya.
Menerapkannya juga menghabiskan banyak sumber daya yang hilang dari area lain di mana fitur yang hilang sebenarnya mencegah orang mengimplementasikan aplikasi tertentu.

Jadi, jika Anda senang Flutter mendapatkan sesuatu seperti BEJ, Anda harus menginvestasikan waktu dan energi Anda untuk menulis argumen yang meyakinkan.
Hanya menambahkan sesuatu karena orang lain juga memilikinya, mungkin merupakan argumen terlemah yang pernah ada.

Ada juga rencana untuk meningkatkan Dart agar penulisan kode Flutter UI tidak terlalu bertele-tele yang semakin melemahkan kasus untuk JSX.

Jadi apa argumen Anda yang meyakinkan?

Betulkah !!! "sepertinya tidak ada yang mau repot-repot menjelaskan apa sebenarnya yang akan diperoleh Flutter... bla bla bla".
Apakah Anda tidak membaca utas ini sepenuhnya? Apakah rentang perhatian Anda lebih besar dari pengetahuan BEJ Anda?

Kalian menderita sindrom NIH (Tidak ditemukan di sini). "Artis baik meniru; seniman hebat mencuri", seniman biasa-biasa saja, yah, berperilaku seperti Anda.

Fakta bahwa mendukung JSX relatif sederhana, dan itu akan sangat membantu menarik pelanggan baru (pengembang seluler React Native) ke platform, menjadikannya hal yang mudah yang tidak bisa kalian lihat. Itu tidak berani dengan baik untuk platform.

Bisakah kita menjaga nada konstruktif saat berdebat.

Menambahkan fitur karena orang lain memilikinya adalah argumen yang lemah. Oke.
Mengapa flutter memiliki reload panas? Darimana itu datang? Yesus bung.

Bagaimana kami gagal memberikan argumen yang kuat untuk kalian? Daya tarik proyek dan menarik pengembang adalah alasan nomor satu kami.

Alasan nomor dua, keterbacaan :

https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/demo/cupertino/cupertino_buttons_demo.dart vs https://Gist.github.com/birkir/e921158239c324ab95bb0b174383a562

Alasan nomor tiga, Pembangun GUI . Saya akan mengutip baris pertama di README.

SDK aplikasi seluler baru untuk membantu pengembang dan perancang membangun aplikasi seluler modern untuk iOS dan Android.

Saya tidak suka melihat Flutter masuk ke lubang kelinci yang sama dengan Polymer bahkan sebelum mencapai beta.

Daya tarik proyek dan menarik pengembang

Hubungannya masih belum jelas.

Alasan nomor dua, keterbacaan:

Membuat kode Dart lebih mudah dibaca tampaknya merupakan tujuan yang lebih baik bagi saya

Alasan nomor tiga, Pembangun GUI. Saya akan mengutip baris pertama di README.

Sejauh yang saya ingat sudah disebutkan di atas bahwa tidak ada alasan mengapa menggunakan kode Dart akan mencegahnya.

Argumen tandingan Anda tidak dapat benar-benar mengabaikan gagasan itu, bukan?

1. Hubungannya cukup jelas. Kecuali itu bukan tujuan agar proyek menjadi populer?
2. Besar! Apakah akan mendekati keterbacaan BEJ? Apa usulan saat ini untuk hal seperti itu?
3. Dikatakan bahwa itu bisa dilakukan . Mengadaptasi dukungan JSX untuk pembuat GUI yang tersedia saat ini akan jauh lebih sederhana.

Ada juga rencana untuk meningkatkan Dart agar penulisan kode Flutter UI tidak terlalu bertele-tele

Senang melihat pengakuan bahwa cara saat ini dapat menggunakan beberapa perbaikan.
Harap memberikan rincian tentang proposal tersebut. Taruhan terbaik Anda adalah berinteraksi dengan komunitas React Native untuk mendapatkan umpan balik.

Beberapa permintaan fitur bahasa Dart dapat membuat kode lebih pendek/dapat dibaca:

• Opsional new dan const untuk Dart 2
• Meta-isu untuk diskusi proposal untuk mengizinkan argumen bernama di mana-mana - - ini dapat memungkinkan widget dengan argumen child untuk melewati argumen bernama.
  
  
  
  • Jumlah Variabel Argumen - ini memungkinkan widget dengan argumen children (seperti Baris dan Kolom) untuk melewati argumen bernama ini dan deklarasi daftarnya.
  
  

Dengan perubahan itu kode bisa terlihat seperti:

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

Selain itu, tergantung pada IDE Anda, Anda dapat secara opsional memiliki komentar sintetis di akhir tanda kurung dan Anda dapat melihat sesuatu seperti ini di IDE Anda:

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

Pembicaraan ini semakin panas. Saya ingin mendorong semua orang untuk membaca kode etik kita:
https://flutter.io/design-principles/#conflict -resolusi
Saya akan menutup percakapan ini selama beberapa hari sementara semua orang mempertimbangkan bagaimana mereka dapat berkontribusi dengan hormat dan produktif.

Kita semua tahu bahwa sintaks untuk membangun UI adalah bagian yang sangat penting dari pengalaman pengembangan seluler. Untuk saat ini sintaksnya sedikit bertele-tele, saya harus new sesuatu hanya untuk tujuan menambahkan margin: margin: new EdgeInsets.symmetric(horizontal: 4.0) , saya pikir mungkin ada cara yang lebih mudah.

Apakah mungkin membangun DSL seperti yang dilakukan tim Kotlin untuk developer Android? Ini disebut Anko , DSL untuk membangun Android UI:

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

Sintaks yang ringkas membantu menjaga agar kode tetap dapat dibaca & dipelihara, juga dapat membuat pekerjaan bangunan menjadi menyenangkan, itu penting. Harap tim Flutter memperkirakannya dengan serius sebelum Anda membuat keputusan. Kami semua senang melihat Flutter meraih kesuksesan yang lebih besar di tahun-tahun mendatang.

Tolong jangan memperkenalkan sintaks seperti XML ke Flutter.

Saya memprogram di Android Java selama lebih dari setahun, lalu saya mulai mencari perangkat lintas platform untuk dicoba.
Saya mulai dengan React Native dan kemudian mencoba React. Saya tidak terlalu menyukai sintaks JSX karena tidak cukup javascript dan tidak cukup html, jadi hanya hal lain untuk dipelajari.
Ketika saya mencoba Flutter, saya merasa lebih mudah untuk memulai (mungkin terutama karena latar belakang Java saya).

Saya pikir beberapa alasan mengapa saya tidak ingin melihat sintaks XML ditambahkan ke flutter :

1. Hal lain untuk dipelajari - bisa dihabiskan untuk belajar Futures sebagai gantinya ;P
2. Pengalihan konteks - Anda mengalihkan konteks antara XML dan kode yang hanya merupakan beban kognitif yang tidak perlu.
3. Ada hari-hari ketika saya memprogram di Java di pagi hari dan Python di sore hari. Dengan React Anda mungkin perlu memahami Javascript, Babel, JSX, HTML, CSS, dan lainnya dalam satu basis kode.
4. Alasan mengapa XML tidak diperlukan di Flutter adalah karena dart memiliki argumen bernama yang menggantikan atribut XML dengan cukup baik.
5. Dart memiliki dartfmt yang sangat keren yang mengindentasi kode dengan sangat baik tanpa usaha.

Dibandingkan dengan Android

1. Anda harus mempelajari cara terprogram, mengapa menambahkan cara lain dalam melakukan sesuatu?
2. Tata letak XML di android lebih cepat untuk menampilkan perubahan pada perangkat, tetapi menjalankan di Flutter praktis instan jadi menambahkan XML tidak akan memberikan keuntungan itu.
3. Kombinasi terprogram Android XML + menambah kerumitan, seperti menggembungkan cuplikan XML dan memasukkan ke dalam pohon XML secara terprogram.
4. Proses instan sangat cepat di Flutter sehingga Anda tidak memerlukan model XML untuk membantu memvisualisasikan tampilannya, Anda cukup menekan tombol dan langsung melihat perubahannya.
5. Kesalahan dari masalah tata letak terprogram berbeda dari masalah tata letak dalam XML, jadi itulah dua rangkaian hal yang perlu Anda pahami.

Saya akan melangkah lebih jauh dan menghapus pubspec.yaml dan menggantinya dengan pubspec.dart dan memiliki konfigurasi dalam kode dart.

Jika Pengembang mengeluh tentang kesulitan meletakkan halaman secara visual - idenya adalah membuat perancang tata letak yang memungkinkan Anda mengatur tema dan mendesain halaman secara visual dengan drag-and-drop. Kemudian itu akan menghasilkan kode Flutter yang tidak dimaksudkan untuk diedit - melainkan membuat kelas yang dapat digunakan untuk membuat aplikasi Anda.

Tidak perlu pengeditan 2 arah (XML/tata letak) seperti Android XML, tetapi Anda cukup menyimpan tata letak untuk nanti. Jika Anda perlu mengubahnya, Anda dapat membuat ulang kode dan (semoga) hanya mengubah beberapa argumen.

Saya tahu percakapan ini sudah lama dan ya itu menjadi cukup panas, Tapi saya ingin menyampaikan beberapa baris tentang apa yang saya anggap sedang terjadi di sini.

Flutter itu BARU. Ini adalah cara yang benar-benar BARU untuk melakukan sesuatu. Ya, itu memang meminjam dari paradigma reaksi. Tetapi tidak berarti ia harus mengikuti langkah-langkah yang sama. Saya tidak berpikir itu tujuan tim flutter untuk menarik pengembang dari reaksi asli menjadi bergetar, itu hanya untuk membangun sesuatu yang baru yang mungkin diminati oleh pengembang. Google menggunakannya secara internal sebelum membagikannya dengan dunia dan mereka telah produktif dengan dia. Saya berbagi komentar dengan @Hixie bahwa tidak ada bedanya dengan JSX untuk membangun UI. Ya itu sedikit lebih bertele-tele ke panah murni kanan. Tapi itu sebenarnya membuat debugging kode Anda jauh lebih mudah.

Alasan mengapa saya menentang bahasa markup atau JSX atau apa pun yang berada di atas teknologi adalah karena itu membutuhkan lebih banyak pekerjaan dari platform. Anda bisa dengan senang hati menyusun bahasa Markup untuk UI, tetapi Anda akan memiliki begitu banyak pengembang yang bekerja di platform menangis dan menarik rambut untuk membuatnya bekerja untuk Anda. Sudut pandang lain adalah bahwa JSX Bekerja untuk komunitas Javascript, Dimana seperti biasa tujuan utamanya adalah untuk membuat segalanya lebih mudah bagi pengembang dan tidak khawatir tentang pengorbanan. Jangan salah paham React(JSX) untuk web adalah pertandingan yang dibuat di surga karena HTML adalah markup. Tetapi untuk React Native, lihat semua kode di repositori yang harus mereka lakukan untuk membuatnya berfungsi. Menambahkan JSX ke flutter akan membutuhkan banyak pekerjaan dan 2 hal untuk dipikirkan saat menambahkan fitur baru. Dan lagi hanya untuk dapat menghapus parameter anak dan const dan Kata Kunci baru?. Saya lebih suka mengetahui apa yang sebenarnya terjadi dalam kode dan memiliki kendali atas apa yang terjadi daripada memiliki Sintaks ajaib yang semua yang dilakukannya hanyalah menambah overhead.

Nah itu pendapat saya. Tidak ingin memulai diskusi raksasa baru. Hanya untuk menyebutkan fakta bahwa JSX luar biasa untuk komunitas reaksi/javascript karena itu bekerja untuk mereka, tetapi untuk Dart/flutter saya merasa agak berlebihan untuk menambahkan JSX Hanya untuk menarik pengembang dari React Native.

Wow, bisa menulis posting blog xD

@Rockvole ,

Hal lain untuk dipelajari - bisa dihabiskan untuk belajar Futures sebagai gantinya ;P

Hal yang perlu dipelajari membuat monster konstruksi objek rekursif saat ini lebih sederhana dan familiar bagi pengembang React Native sehari-hari, jadi tebakan saya adalah orang akan lebih suka mempelajarinya.

Pengalihan konteks - Anda mengalihkan konteks antara XML dan kode yang hanya merupakan beban kognitif yang tidak perlu.

Bukan masalah, tidak ada sakelar konteks, itu hanya bagian dari lingkungan yang membuat pemrograman UI/UX lebih bersih.

Maka itu akan menghasilkan kode Flutter yang tidak dimaksudkan untuk diedit

Kenapa tidak? Tidak terlalu berguna saat itu.

@franzsilva

Saya tidak berpikir itu tujuan tim flutter untuk menarik pengembang dari reaksi asli menjadi flutter

Betulkah !!! React Native mendominasi dan mengingat jumlah total pengembang seluler yang menggunakan alat lintas platform terbatas, apakah Anda benar-benar berpikir Flutter dapat menjadi hit home run tanpa menarik orang React Native?

Ya itu sedikit lebih bertele-tele ke panah murni kanan. Tapi itu sebenarnya membuat debugging kode Anda jauh lebih mudah.

Itu bukan pernyataan yang benar. Men-debug kode JSX, yang hanya merupakan kode javascript tidak lebih mudah atau lebih sulit, sama saja.

Alasan mengapa saya menentang bahasa markup atau JSX atau apa pun yang berada di atas teknologi adalah karena itu membutuhkan lebih banyak pekerjaan dari platform.

Siapa yang peduli berapa banyak pekerjaan yang ditempatkan di platform? Pengembang hanya menginginkan teknik terbaru yang meningkatkan keterbacaan dan produktivitas kode. Tidak ada dev yang ingin menggunakan teknik lama dan usang ketika hal-hal baru memberikan alternatif yang lebih baik.

Saya lebih suka mengetahui apa yang sebenarnya terjadi dalam kode dan memiliki kendali atas apa yang terjadi daripada memiliki Sintaks ajaib yang semua yang dilakukannya hanyalah menambah overhead.

Ini tidak masuk akal, saya tahu persis apa yang terjadi dengan BEJ, ini adalah lapisan kecil kecil yang mengubah hampir 1-1 tetapi memberikan banyak manfaat. Overhead waktu kompilasi yang dapat diabaikan jika Anda bertanya kepada saya.

Hanya untuk menyebutkan fakta bahwa JSX luar biasa untuk komunitas reaksi/javascript karena itu bekerja untuk mereka, tetapi untuk Dart/flutter saya merasa agak berlebihan untuk menambahkan JSX Hanya untuk menarik pengembang dari React Native.

JSX juga harus bekerja dengan baik untuk Dart/Flutter. Ini tidak berlebihan dengan cara apapun. Apakah ada alasan bagus mengapa JSX tidak bekerja untuk Dart/Flutter? Jika saya mengkodekannya dan merilisnya, mengapa itu tidak cocok untuk pengembangan Dart/Flutter?

Mari kita ambil contoh konkret dari @xinthink :

Untuk saat ini sintaksnya sedikit bertele-tele, saya harus new sesuatu hanya untuk tujuan menambahkan margin: margin: new EdgeInsets.symmetric(horizontal: 4.0) , saya pikir mungkin ada cara yang lebih mudah.

Jika Anda ingin menambahkan margin di kiri dan kanan, bagaimana Anda ingin mengungkapkannya? Secara khusus, mari kita ambil contoh sederhana, dan lihat seperti apa tampilannya dalam berbagai sintaks.

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

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

Bagaimana Anda merekomendasikan kami untuk mengungkapkan semantik _exact_ ini?

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

Babel.js memiliki situs web kecil yang rapi ini, tempat Anda dapat mengetik JSX dan mengubahnya menjadi Javascript biasa:
https://babeljs.io/repl/# ?babili=false&evaluate=true&lineWrap=false&presets=es2015%2Creact%2Cstage-0&code=function%20hello()%20%7B%0A%20%20return%20%3Cdiv%3EHello% 20dunia!%3C%2Fdiv%3E%3B%0A%7D

Saya akan melakukan yang setara untuk DSX ke Dart. Hanya bukti konsep, mari kita lihat berapa lama waktu yang saya butuhkan...

Berikut contoh terbaru @Hixie di ”DSX“, menggunakan panduan gaya Airbnb dan dengan asumsi semua elemen turunan dapat secara otomatis dipetakan ke properti child .

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

Jika tujuannya adalah untuk meningkatkan keterbacaan, saya pikir Dart di masa depan akan menang.

Anda harus memeriksa dokumentasi untuk mengetahui apa yang dapat berubah menjadi tag (mungkin hanya Widget s), atau berapa banyak elemen anak yang diperlukan/diizinkan.

Jika tujuan Anda adalah untuk menghasilkan HTML dari JavaScript, JSX sangat masuk akal sebagai jalan tengah. Karena ketika Anda ingin tag di penghujung hari, React.createElement('div', null, 'foo') jauh lebih buruk daripada <div>foo</div> .

Jika tujuan Anda adalah untuk menampilkan pohon objek Dart dari ... Dart, dan pohon konstruktor Dart yang diformat dengan baik dapat dibaca dengan sempurna (bisa dibilang lebih), saya tidak melihat gunanya memutar melalui XML. Dan saya tidak melewatkan XML yang berasal dari Android.

Inilah yang memungkinkan penggunaan XML... Lihat sudah 5 bulan hanya dengan berbicara, sekarang saya melakukan sesuatu tentang hal itu jadi beri saya waktu (saya memiliki pekerjaan penuh waktu dan hanya dapat meluangkan sekitar 4 jam di akhir pekan).

Baru saja menemukan utas ini, menarik di kedua sisi. Sebagai pengembang React yang tertarik dengan Flutter, ada beberapa argumen lain yang belum pernah saya sebutkan (walaupun saya hanya membaca sekilas semua komentar.)

1. Deklarasi tag penutup meningkatkan pemahaman tentang anak-anak vs properti. Sayangnya UI dapat sangat bersarang, dan memiliki tag yang jelas vs yang tidak diketahui ) membantu memperjelas dan menguraikan turunan. Ini juga memungkinkan saya untuk memindahkan kode di antara komponen dan dengan sangat deklaratif melihat ketika ada sesuatu yang tidak pada tempatnya (tag penutup sebelum a misalnya.) Ini lebih sulit dengan beberapa nested ).

2. Reaksi awal saya untuk melihat beberapa komponen bersarang di dalam konstruktor memberi saya kilas balik ke "callback hell" . Itu adalah era JS yang sangat menyakitkan yang mulai membaik, kembali ke sana terasa seperti langkah mundur.

3. Terkait dengan #2, fakta yang disayangkan adalah kita harus meyakinkan orang untuk beralih (atau setidaknya mencobanya). Banyak orang menggunakan React/React Native dan lebih banyak lagi yang menggunakan HTML/JS. Membuat tutorial/panduan sederhana dan sebagian besar familiar secara sintaksis yang secara khusus menargetkan beberapa poin nyeri React mungkin sangat menarik bagi mereka yang sedikit lelah.

Salah satu alasan utama mengapa React menjadi populer di komunitas Pengembang Web adalah dukungan dari JSX.

Benar-benar mengecewakan melihat "suara turun" pada permintaan fitur yang begitu bagus. Ini meningkatkan keterbacaan dan mempercepat adopsi.

Saya pikir ini adalah perbedaan utama antara Open JavaScript dan Dart. JavaScript benar-benar open source sedangkan permintaan di Dart masuk ke percakapan seperti ini dan akhirnya Anda kehilangan motivasi dengan suara yang turun.

Berikan lebih banyak ruang untuk ide-ide baru!

@jayjun Itu terlihat luar biasa! Bisakah saya mencobanya di suatu tempat?

@sanketsahusoft Jangan khawatir segera Anda akan dapat mencoba versi saya dan bahkan lebih baik dari @jayjun.

Pembaruan cepat: 2 akhir pekan yang lalu UI saya berfungsi dengan baik, Akhir pekan lalu saya membuat parser berfungsi penuh dan setengah dari transpiler berfungsi. Akhir pekan yang akan datang ini saya berharap untuk menyelesaikannya jika saya menghindari Superbowl;)

Saya memiliki kulit yang tebal dan keras kepala seperti bagal jadi saya bahkan tidak menyadari suara-suara rendah ini, terima kasih telah menunjukkannya.

Carlos.

Apakah ini membantu dengan masalah kehilangan jejak tag penutup?
Ide: Tag penutup yang dibuat secara otomatis

Berikut ini beberapa sintaks markup yang diusulkan untuk contoh @Hixie :

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

@abarth , hal menarik yang Anda lakukan adalah menambahkan kemungkinan atribut ke-3 yang menyederhanakan tampilan ekspresi ketika itu adalah tag lain.
BEJ memiliki:
1 - <tag attrib=""/> atau <tag attrib=''/>
2 - <tag attrib={}/>
Anda menyarankan yang lain:
3 - <tag attrib=<anotherTag.../>/>
dengan BEJ Anda harus menulisnya sebagai:
<tag attrib={<anotherTag.../>}/>

@cbazza Ya, kasus ketiga cukup umum di Flutter, jadi masuk akal untuk melewatkan tambahan { bersarang.

@abarth Ah tapi saya membuat sebagian besar hal itu tidak perlu dengan menggunakan gaya seperti css !!! Transpiler memperluas gaya seperti css ini menjadi panggilan Flutter yang sesuai. Sekarang struktur penandaan jauh lebih bersih dan gaya dapat dengan mudah diimpor dari alat desainer seperti InVision, Figma, Atom, dll.

@cbazza Keren, saya menggunakan banyak widget dengan penutupan seperti FutureBuilder . Saya harap transpiler Anda dapat menghasilkan sesuatu seperti,

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

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

@jayjun , Ya, itu tidak masalah. Transpiler adalah prosesor XML sederhana dan ketika datang ke ekspresi parsing (semua yang ada di dalam {}), itu hanya menjadi gumpalan teks sehingga menuliskannya kata demi kata.

@xinthink

Apakah mungkin membangun DSL seperti yang dilakukan tim Kotlin untuk developer Android?

Sepertinya banyak orang ingin menggunakan Kotlin dengan Flutter. Sejujurnya, saya tidak mengerti, mengapa pengembang memutuskan untuk menemukan kembali roda di Dart?

Menurut pendapat saya, Flutter tidak membutuhkan JSX. Flutter seharusnya memilih Kotlin daripada Dart. Kotlin memungkinkan kita untuk menulis logika ui yang kompleks dengan sintaks yang indah di luar kotak, memiliki komunitas besar, alat siap produksi, teruji pertempuran dalam pengembangan Android...

Hanya mengatakan.

Kotlin bagus, saya penggemar tetapi tidak berjalan di iOS..... sebenarnya ada tetapi belum dirilis (tahap pra-rilis sekarang).
Untuk pengembangan UI/UX saya masih lebih suka JSX daripada Anko DSL. Saya menyukai kenyataan bahwa saya dapat secara visual memisahkan markup deklaratif dari kode imperatif dan dapat mencampur dan mencocokkan komponen bersama-sama dengan cukup mudah.

Dart, Kotlin dan Swift semuanya memiliki kesamaan:
https://sethladd.github.io/swift-is-like-kotlin-and-kinda-like-dart/

Aku suka itu :

1. Dart lebih akrab jika Anda berasal dari Jawa.
2. Anda dapat mengambil keterampilan Dart Anda dan menggunakannya untuk membangun halaman web - yang berharga saat membuat aplikasi, Anda dapat membangun fitur di web (dan menunjukkannya dalam WebView) di tempat yang lebih masuk akal (mungkin halaman admin cepat atau daftar produk yang perlu diindeks google).
3. Dart dibangun dari awal untuk dikompilasi ke javascript yang saya anggap tidak mudah untuk ditambahkan ke bahasa nanti.

Ini pada dasarnya adalah alasan saya memilih Dart daripada Kotlin/Swift/React.

_Meskipun keputusan untuk mendukung Dart dan Swift di Google OS Fuchsia baru membingungkan saya._

Saya tidak yakin Dart lebih akrab jika Anda berasal dari Jawa. Saya berasal dari Java dan tidak memiliki masalah dengan Kotlin atau Swift; pada dasarnya deklarasi tipe dibalik, tidak ada yang benar-benar baru seperti yang digunakan dalam Pascal dan ActionScript.

Ya, Anda dapat membuat halaman web dengan Dart, tetapi saya tidak melihat hal itu menjadi perhatian besar. Satu-satunya bahasa lain yang bekerja dengan baik di web adalah TypeScript, karena terintegrasi dengan baik dengan 3 kerangka kerja web terpopuler.

Lihatlah sintaks berbeda yang tersedia untuk Bereaksi di Web:
https://github.com/Workiva/over_react#fluent -style-component-consumption
Kedua versi Dart tidak memiliki peluang melawan BEJ !!!

TypeScript dirancang untuk dikompilasi ke Javascript dan lebih baik daripada Dart untuk itu. Ini juga mendukung BEJ.
Dart semakin diperas dari semua sisi. Swift memiliki momentum sehingga sangat bijaksana untuk mendukungnya di Fuchsia OS bersama bayi Anda.

Berapa lama sampai prototipe? Saya ingin menggunakannya!

Saya menggunakan React untuk sementara waktu, dan JSX meningkatkan produktivitas saya sepuluh kali lipat. Ini bukan masalah kontroversial: tim lain memutuskan, dengan benar, bahwa ini akan lebih baik, jadi mengapa tidak Flutter? (Retorika: Saya membaca utasnya ... (facepalm))

Saya sedang mengerjakannya akhir pekan ini tetapi saya terus meningkatkan cakupan dengan ide-ide baru jadi semoga saya bisa mendapatkan sesuatu akhir pekan ini.

Beberapa hal menarik yang saya coba:
1) menggunakan namespace xml pada tag anak sehingga mereka dimasukkan dengan argumen bernama Dart yang benar di induknya.
2) spread operator untuk lebih mengatur gaya seperti properti sehingga mereka dapat didefinisikan/dikelompokkan di luar xml di peta dan kemudian dibawa masuk dan disebarkan pada tag seperti hal-hal React yang khas.
3) properti styleCSS yang menghasilkan gaya flutter dari CSS.

(1) & (2) bersifat generik sehingga berfungsi untuk semua kode Dart Flutter.
(3) khusus untuk Flutter Widget (Container, Text, dll) dan saya hanya melakukan 2 itu untuk saat ini.

@yuriy-manifold hanya karena sesuatu bekerja untuk JS tidak berarti itu ide yang bagus untuk Dart.
Jika Anda telah membaca diskusi di atas, Anda akan melihat bahwa sebenarnya ini kontroversial.
Saya tidak mengerti mengapa 2 bahasa akan lebih baik dari satu.

hanya karena sesuatu bekerja untuk JS tidak berarti itu ide yang bagus untuk Dart.

JSX adalah ide luar biasa untuk pengembangan UI/UX dalam kerangka reaktif terlepas dari bahasanya. Jika saya memiliki lebih banyak waktu luang, saya akan mengeluarkan LSX yang merupakan JSX untuk Logo;)

Saya tidak mengerti mengapa 2 bahasa akan lebih baik dari satu.

Anda dapat memprogram iOS dengan Objective-C dan Swift (2 bahasa)
Anda dapat memprogram Android dengan Java dan Kotlin (2 bahasa)
...

Saya belum melihat argumen yang mendukung BEJ.
Diskusi di atas hanya berisi argumen seperti "lebih baik", "meningkatkan produktivitas", atau serupa tetapi tidak ada argumen mengapa atau bagaimana itu sebenarnya akan lebih baik daripada kode Dart murni, terutama mengingat perubahan bahasa yang direncanakan yang akan mengurangi perbedaan antara JSX-like dan
kode Dart murni bahkan lebih.

@cbazza

Anda dapat memprogram iOS dengan Objective-C dan Swift (2 bahasa)
Anda dapat memprogram Android dengan Java dan Kotlin (2 bahasa)

Apa hubungannya dengan diskusi BEJ? Bagaimana itu bisa dianggap sebagai keuntungan?
Anda dapat menggunakan Swift di iOS karena ini adalah penerus Objectiv-C.
Anda dapat menggunakan Kotlin di Android karena dianggap sebagai peningkatan yang apik untuk Java.
Kedengarannya seperti Anda berpendapat bahwa BEJ harus menggantikan Dart. Itu tidak masuk akal bagiku.

@zoechi

Apa hubungannya dengan diskusi BEJ? Bagaimana itu bisa dianggap sebagai keuntungan?
Anda dapat menggunakan Swift di iOS karena ini adalah penerus Objectiv-C.
Anda dapat menggunakan Kotlin di Android karena dianggap sebagai peningkatan yang apik untuk Java.
Kedengarannya Anda berpendapat bahwa BEJ harus menggantikan Dart. Itu tidak masuk akal bagiku.

Anda benar-benar mengatakannya (JSX adalah peningkatan yang apik dari cara saat ini) tetapi sampai pada kesimpulan yang salah (JSX untuk menggantikan Dart).

@cbazza lebih dari itu

apa keuntungan sebenarnya dari Dart biasa?

"JSX adalah peningkatan yang apik" sama sekali tidak meyakinkan dan bukan merupakan argumen.
Itu hanya pendapat pribadi tanpa (lagi) argumen untuk mendukungnya,
mirip dengan argumen pro-JSX lainnya di atas.

Anda tidak dapat mengharapkan siapa pun untuk mempertimbangkan saran Anda jika Anda tidak bersedia memberikan argumen yang baik.

Menambahkan sesuatu seperti JSX ke Dart menyebabkan banyak pekerjaan dan kerumitan dalam alat Flutter dan IDE. Anda perlu memberikan argumen yang tepat agar orang lain bahkan mempertimbangkan untuk melihatnya.

@zoechi terdengar seperti kaset rusak yang meminta argumen 'baik', banyak yang diberikan sebelumnya tetapi Anda tidak mengerti; yang OK, 'untuk masing-masing mereka sendiri'.

Menambahkan sesuatu seperti JSX ke Dart menyebabkan banyak pekerjaan dan kerumitan dalam alat Flutter dan IDE. Anda perlu memberikan argumen yang tepat agar orang lain bahkan mempertimbangkan untuk melihatnya.

Tidak juga, pekerjaan saya hampir siap dan saya membutuhkan waktu yang sangat sedikit mengingat saya hanya mengerjakannya di akhir pekan.

Sekali lagi, DSX hanyalah perbaikan apik yang dapat dipilih orang untuk digunakan atau tidak, karena tidak mengubah cara saat ini, itu hanya memberikan alternatif yang akan langsung dikenal oleh orang lain (pengembang Bereaksi).

@cbazza

banyak yang diberikan

tidak juga. Hanya klaim umum yang bisa benar atau tidak.
Tidak ada rincian tambahan yang diberikan yang akan memungkinkan orang lain untuk memverifikasi.

Tidak juga, pekerjaan saya hampir siap

Besar. Maka tim Flutter tidak perlu melakukan apa pun dan masalah dapat diselesaikan ;p
Apakah ini termasuk dukungan pelengkapan otomatis dan pemeriksaan sintaks di semua IDE yang didukung oleh Flutter?

Besar. Maka tim Flutter tidak perlu melakukan apa pun dan masalah dapat diselesaikan ;p

;)

Apakah ini termasuk dukungan pelengkapan otomatis dan pemeriksaan sintaks di semua IDE yang didukung oleh Flutter?

Sebagian besar IDE sudah mendukung XML dan JSX sehingga tidak akan sulit bagi mereka untuk menambahkan tambahan kecil saya.

Saya ingin tahu apakah sintaks JSX mungkin lebih dihargai di angular Dart ? Sepertinya ini lebih merupakan situasi yang biasa Anda alami daripada "lebih baik". Sintaks JSX mungkin terasa lebih alami bagi pengembang web.

Saya tahu bahwa pemrograman terasa canggung bagi saya bahkan hanya menggunakan warna penyorotan kode yang berbeda selama sehari.

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

Ya, orang Angular akan sangat nyaman dengan JSX tetapi begitu juga dengan React Native devs dan ini untuk pengembangan seluler. BEJ tentu tidak akan diambil oleh pengembang Flutter saat ini, tetapi alternatif kedua ini akan menarik pengembang baru ke Flutter dan itu sudah pasti.

Artikel di atas salah, Bereaksi tanpa JSX pada dasarnya tidak ada dan semua kerangka kerja web reaktif memungkinkan pencampuran markup dan pemrograman pada DSL mereka.

Waktu telah tiba...
Dengan senang hati saya mengumumkan transpiler DSX online
https://spark-heroku-dsx.herokuapp.com/index.html

Kerja bagus dengan transpiler cbazza
Satu hal yang menurut saya lebih mudah diikuti dengan BEJ adalah tag penutup. Ide yang saya sebutkan sebelumnya:
Ide: Tag penutup yang dibuat secara otomatis

Dalam contoh pertama Anda, akan memberikan kode flutter dari (menghapus opsional baru di masa depan Dart):

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

@cbazza Saya menghargai pekerjaan Anda untuk komunitas dan orang-orang yang ingin membangun UI seperti itu, tetapi saya sangat berharap saya tidak pernah dipaksa untuk menggunakan hal seperti itu di Flutter :-(((

Sebagai pendatang baru di Flutter tetapi cukup akrab dengan React, beberapa hal menonjol bagi saya:

• Model manajemen negara hampir sama
• Pohon render virtual widget/komponen hampir sama
• Mengetahui status dan model komponen, pada dasarnya saya merasa siap untuk menulis aplikasi sekarang, kecuali beberapa spesifikasi Dart dan API platform, tapi...
• Bahasa gaya adalah batu sandungan. Saya mengacu pada https://flutter.io/web-analogs/ tetapi tidak mudah untuk mengetahui impor apa yang diperlukan untuk membuat semuanya berfungsi (EdgeInset? Color?) atau kapan saya harus menggunakan primitif alih-alih instance kelas.
• Pengurai CSS dari konverter DSX @cbazza sangat berguna untuk mengetahui persamaan tata letak dalam model Flutter.

Mengenai BEJ:

• Saya rasa tidak perlu menemukan sintaks JSX baru untuk mendukung pola Flutter. Beberapa quibble sintaks di utas ini dapat diselesaikan menggunakan beberapa pola React yang lebih baru seperti komponen tingkat tinggi (fungsi yang membangun kelas komponen) dan render props (komponen yang menggunakan fungsi sebagai argumen; fungsi mengembalikan elemen). Misalnya, bernama "slot anak" dapat diterjemahkan menjadi sesuatu seperti ini di BEJ:

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

• Argumen terbaik terhadap BEJ yang saya lihat adalah bahwa Dart telah menamai argumen.
• Mengapa penting bagi suatu elemen untuk mengetahui apakah elemen tersebut memiliki banyak anak atau satu anak? Mungkin konstruksi "fragmen" dapat mengaburkan API itu.

Saya masih berpikir, sebagai pendatang baru di Flutter dengan beberapa pengalaman dengan Angular, React, dll., bahwa cara Dart biasa, dan lebih banyak lagi di Dart 2.0, lebih baik daripada DSX ini. Itu lebih masuk akal daripada beberapa parameter XML dan CSS-ish. ️

@cbazza contoh demo kedua Anda memiliki 466 karakter dibandingkan dengan 391 dart (keduanya tanpa spasi). Bagi saya itu terlihat membengkak secara visual. Saya harus mempelajari semantiknya, yang tidak harus saya lakukan dengan kode Dart normal. Dan saya tidak tahu bagaimana menggunakan paradigma pemrograman tujuan umum dengannya (jika, forEach, dll.).

Jika saya punya pilihan, saya akan tetap dengan model saat ini.

Setiap orang hanya memberikan pendapat subjektifnya sendiri tentang membandingkan kedua sintaks, tetapi kita harus menyetujui satu fakta: ini adalah fitur yang sangat kontroversial. Ada cinta dan benci, tetapi sebagian besar pendapat berbeda tentang kegunaan BEJ dibandingkan Dart biasa.

Bagaimanapun saya pikir itu benar-benar tidak masuk akal untuk meminta tim Flutter berkomitmen untuk mendukung fitur ini sebelum rilis 1.0. Meskipun cara membangun UI saat ini mungkin tidak tampak bagus untuk semua orang - cara ini berhasil (dan berhasil dalam beberapa pendapat).

Jika orang benar-benar menginginkan sintaks seperti JSX sekarang, upaya yang didorong oleh komunitas sepertinya adalah cara yang harus dilakukan. Dan itu akan membantu membuat kasus (atau tidak) ketika tim Flutter mempertimbangkannya dalam rilis pasca 1.0.

Secara pribadi saya sangat setuju dengan argumen berikut: itu bukan karena JSX bekerja untuk React (di mana Anda sudah membangun UI menggunakan bahasa markup) yang secara otomatis bekerja untuk Flutter.

@tehfailsafe

Berita baiknya adalah bahwa meskipun ini diadopsi oleh tim Flutter (yang kemungkinan tidak didasarkan pada utas ini) tidak ada yang akan DIPAKSA untuk menggunakannya. Ini adalah OPSI. Saya tidak mengerti mengapa itu sangat emosional sehingga beberapa orang mungkin suka menulis kode dengan sintaks yang tidak Anda sukai ...

Saya tidak peduli apa yang orang lain suka atau tidak suka. Tapi saya peduli dengan fitur yang membantu saya maju dengan aplikasi saya. Sumber daya terbatas, dan saya lebih suka memiliki pemutar video/aliran yang tepat, tampilan anak asli, dan beberapa format grafik vektor.

Misalnya, sekarang di React dan React Native Anda dapat menulis seluruh aplikasi Anda tanpa JSX, itu hanya sebuah opsi. Inilah tampilan React tanpa JSX:
[...]
Ini jauh lebih berantakan daripada versi BEJ, dan hampir tidak ada yang menggunakannya. Itu mungkin mengapa sebagian dari kita yang berasal dari React akan menghargai kemungkinan untuk menghindari keharusan melakukan gaya ini lagi.

Itu karena web tidak dirancang untuk sistem seperti itu. Jika Anda memiliki bahasa markup statis seperti HTML dan ingin "medinamiskannya", Anda harus menciptakan sistem yang perlu bekerja di atasnya. Apa yang akan Anda dapatkan adalah beberapa konstruksi yang dibatasi oleh platform yang mendasarinya.
(lihat: https://gbracha.blogspot.de/2014/09/a-domain-of-shadows.html)

Flutter di sisi lain tidak memiliki bahasa markup. Saya belum melihat alasan untuk menginvestasikan sumber daya ke dalam sesuatu yang kurang dinamis dan kurang ekspresif.

Saya ingin tahu apakah orang yang tidak setuju telah menggunakan Bereaksi dengan dan tanpa JSX. Saya mendorong semua orang untuk mencobanya, jadi diskusi ini akan kurang teoretis. Setelah kurva belajar awal yang dangkal, itu menjadi sangat alami (dan ini tidak semua tentang jumlah karakter, karena tag penutup memungkinkan Anda untuk membacanya dengan lebih mudah). Tidak ada bedanya dengan mempelajari hal lain yang baru, seperti Flutter, yang dalam jangka panjang meningkatkan produktivitas. Dan saya setuju bahwa ini bukan untuk semua orang, itulah sebabnya ini opsional.
Saya pikir penting untuk diingat bahwa kita memiliki kepentingan terbaik satu sama lain - membuatnya lebih mudah untuk membangun barang. Saya pikir transpiler ini akan membantu, dan akan lebih mudah untuk diadopsi jika memiliki dukungan resmi.

Juga, Terima kasih @cbazza :)

@yuriy-manifold

Saya tidak berpikir siapa pun di sini meragukan bahwa JSX React adalah peningkatan dari React klasik. Tetapi seperti yang saya katakan, solusi itu dibuat karena masalah yang terkait dengan properti platform yang mendasarinya. Flutter tidak memiliki properti ini.

Pertanyaannya bukan 'apakah JSX berguna untuk React?' pertanyaannya adalah 'apakah sesuatu seperti JSX berguna untuk Flutter?'.

Saya kira jawabannya adalah tidak.

Ada beberapa hal lain yang perlu dipertimbangkan:

• Memisahkan spesifikasi tata letak dari kode aplikasi dapat membuat kode lebih tahan masa depan; misalnya proposal sintaks Dart 2 ini tidak akan mempengaruhi metode build jika mereka diubah menurut pragma yang dapat diupgrade menjadi kode Dart dari format agnostik seperti JSX.
• Mendefinisikan layout sebagai markup memungkinkan untuk memisahkan mesin render dari mesin widget (stateful/virtualized) ala hubungan React dengan ReactDOM dan React Native, yang berpotensi mempermudah port widget ke platform baru.
• Mendefinisikan format markup mempermudah porting tata letak yang ada ke Flutter, misalnya dari Sketch atau alat desain lainnya

Kerja bagus dengan transpiler cbazza

@Rockvole , terima kasih.

Saya menghargai pekerjaan Anda untuk komunitas dan orang-orang yang ingin membangun UI seperti itu, tetapi saya sangat berharap saya tidak pernah dipaksa untuk menggunakan hal seperti itu di Flutter :-(((

@zoechi , terima kasih. Ya, itu hanyalah pilihan lain bagi orang-orang yang menyukai BEJ untuk digunakan. Jika itu bukan hal keren Anda, terus lakukan seperti yang Anda lakukan, tidak ada yang berubah di sana.

Saya rasa tidak perlu menemukan sintaks JSX baru untuk mendukung pola Flutter.

@alexkrolick , ya Anda dapat menggunakan render props untuk parameter bernama tetapi tidak ada yang dapat Anda lakukan tentang parameter posisi. Kuncinya adalah saya tidak ingin membuat kode keras apa pun di transpiler sehingga itu akan berfungsi untuk semuanya.

Saya masih berpikir, sebagai pendatang baru di Flutter dengan beberapa pengalaman dengan Angular, React, dll., bahwa cara Dart biasa, dan lebih banyak lagi di Dart 2.0, lebih baik daripada DSX ini. Itu lebih masuk akal daripada beberapa parameter XML dan CSS-ish.

@tenhobi , gunakan itu dengan baik, jelas DSX bukan untuk semua orang.

Jika saya punya pilihan, saya akan tetap dengan model saat ini.

@b-strauss, ini bukan pengganti, ini pilihan untuk orang-orang yang menyukai BEJ.

Ada cinta dan benci, tetapi sebagian besar pendapat berbeda tentang kegunaan BEJ dibandingkan Dart biasa.

@lukaspili , DSX adalah untuk orang-orang React Native yang menyukai JSX, jika Anda tidak melihat manfaatnya, jangan menggunakannya. Ini bukan DSX versus Dart biasa. Ini DSX vs. JSX, semakin dekat 2 semakin baik.

Berita baiknya adalah bahwa meskipun ini diadopsi oleh tim Flutter (yang kemungkinan tidak didasarkan pada utas ini) tidak ada yang akan DIPAKSA untuk menggunakannya. Ini adalah OPSI. Saya tidak mengerti mengapa itu sangat emosional sehingga beberapa orang mungkin suka menulis kode dengan sintaks yang tidak Anda sukai ...

@tehfailsafe , terima kasih sudah mendengarkan!!! Anda memukul paku di kepala mengapa resistensi yang begitu besar terhadap sesuatu yang akan membuat orang-orang React Native benar-benar bahagia.

Saya tidak peduli apa yang orang lain suka atau tidak suka. Tapi saya peduli dengan fitur yang membantu saya maju dengan aplikasi saya. Sumber daya terbatas, dan saya lebih suka memiliki pemutar video/aliran yang tepat, tampilan anak asli, dan beberapa format grafik vektor.

@b-strauss, Setelah penggemar React Native pindah ke Flutter, akan ada banyak orang untuk membantu hal-hal lain yang dibutuhkan ini. Prioritas 1 adalah mencuri mind share dari React Native dan membuatnya sesederhana mungkin bagi orang-orang React Native untuk pindah.

Flutter di sisi lain tidak memiliki bahasa markup. Saya belum melihat alasan untuk menginvestasikan sumber daya ke dalam sesuatu yang kurang dinamis dan kurang ekspresif.

@b-strauss, Bagaimana DSX 'kurang dinamis' dan 'kurang ekspresif' daripada Dart biasa? DSX adalah Dart, bukankah Anda mencoba transpiler?

@yuriy-manifold, terima kasih.

Pertanyaannya bukan 'apakah JSX berguna untuk React?' pertanyaannya adalah 'apakah sesuatu seperti JSX berguna untuk Flutter?'.

@b-strauss, tentu saja. ini tidak membantu untuk pengembang Flutter saat ini tetapi sangat membantu bagi desainer yang dapat menampilkan CSS dari alat mereka, ini sangat membantu bagi orang-orang yang menggunakan platform React Native.

@alexkrolick , pengamatan yang sangat bagus.

@cbazza

ini bukan pengganti, ini adalah pilihan bagi orang-orang yang menyukai BEJ.

Saya mengerti... Itu tidak akan mempengaruhi saya seperti itu, tetapi seperti yang saya katakan sebelumnya, ada fitur yang hilang sekarang yang saya perlukan untuk membuat aplikasi flutter.

Setelah penggemar React Native pindah ke Flutter, akan ada banyak orang yang akan membantu hal-hal lain yang dibutuhkan ini. Prioritas 1 adalah mencuri mind share dari React Native dan membuatnya sesederhana mungkin bagi orang-orang React Native untuk pindah.

Jadi Anda mengusulkan tim flutter harus menunda fitur untuk sesuatu yang dipertanyakan dan mungkin atau mungkin tidak menarik sebagian kecil dari subset tertentu dari pengembang web?

Bagaimana DSX 'kurang dinamis' dan 'kurang ekspresif' daripada Dart biasa? DSX adalah Dart, bukankah Anda mencoba transpiler?

Setiap DSL menurut definisi kurang ekspresif daripada GPL. Dengan DSX, bagaimana cara menyembunyikan widget secara kondisional? Bagaimana cara saya mengulangi koleksi dan memetakan setiap elemen ke widget? Bagaimana cara menggunakan sakelar? Anda sekarang harus membuat sintaks dan semantik untuk konstruksi yang sudah Anda miliki di GPL Anda. Jadi mengapa menciptakan DSL di tempat pertama?

tentu saja itu. ini tidak membantu untuk pengembang Flutter saat ini tetapi sangat membantu bagi desainer yang dapat menampilkan CSS dari alat mereka, ini sangat membantu bagi orang-orang yang menggunakan platform React Native.

Bukan itu pertanyaannya... Masalah apa yang akan dipecahkan oleh DSL yang tidak dapat Anda selesaikan saat ini? Anda terus mengatakan itu lebih baik, mengapa lebih baik? Saya yakin DSX akan menarik minat beberapa orang di BEJ. Saya tahu orang tidak menyukai hal-hal yang berbeda. Dan keakraban tampaknya menjadi satu-satunya argumen. Jadi mengapa tidak menggunakan CSS?
Mengapa tidak menggunakan JavaScript? Lebih banyak orang tahu cara menggunakan ini daripada Dart.

Jika Anda merancang sistem Anda berdasarkan beberapa hal lain hanya untuk tujuan mengenal, Anda tidak benar-benar berinovasi.

@b-strauss agar jelas, JSX mengkompilasi ke fungsi panggilan (dalam panggilan Bereaksi ke createElement(ComponentClass) , di Dart itu harus konstruktor).

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

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

Satu-satunya konstruksi adalah transformasi antara nama elemen+atribut dan panggilan fungsi+argumen, dan ekspresi yang lolos ( {...} ).

• Dengan DSX, bagaimana cara menyembunyikan widget secara kondisional?

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

• Bagaimana cara saya mengulangi koleksi dan memetakan setiap elemen ke widget?

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

• Bagaimana cara menggunakan sakelar?
  Sejauh yang saya tahu di Dart seperti di JS, Anda tidak dapat menggunakan sakelar sebaris karena itu bukan ekspresi. Jika Anda berada di luar pohon widget, Anda dapat menggunakan sakelar secara normal.

Jadi Anda mengusulkan tim flutter harus menunda fitur untuk sesuatu yang dipertanyakan dan mungkin atau mungkin tidak menarik sebagian kecil dari subset tertentu dari pengembang web?

@b-strauss, React Native bukanlah pengembangan web, melainkan pengembangan seluler lintas platform yang merupakan pesaing utama Flutter; dan ya JSX seperti sumber cahaya, itu akan menarik banyak pengembang React Native. Saya meminta fitur ini pada Agustus 2017, terlalu banyak bicara, terlalu sedikit tindakan.

Setiap DSL menurut definisi kurang ekspresif daripada GPL. Dengan DSX, bagaimana cara menyembunyikan widget secara kondisional? Bagaimana cara saya mengulangi koleksi dan memetakan setiap elemen ke widget? Bagaimana cara menggunakan sakelar? Anda sekarang harus membuat sintaks dan semantik untuk konstruksi yang sudah Anda miliki di GPL Anda. Jadi mengapa menciptakan DSL di tempat pertama?

Anda benar-benar salah. Berita baiknya adalah saya juga pernah salah. Sebagian besar (tetapi tidak semua) DSL mencoba membuat ulang konstruksi pemrograman dalam markup (dan itu tidak terlalu kuat), JSX membawa markup ke dalam pemrograman (memanfaatkan sepenuhnya bahasa host). Perbedaannya adalah transformasional. Jawaban atas semua pertanyaan Anda pada dasarnya menggunakan cara Anda melakukannya di Dart karena Dart. Segala sesuatu di antara '{}' adalah kode Dart dengan pengecualian operator spread. Itu semua ekspresi panah tetapi Anda juga dapat menggunakan fungsi anonim yang mengembalikan ekspresi. Seperti yang Anda lihat di transpiler sebuah tag (\) hanyalah widget baru (Teks baru()).

Masalah apa yang akan dipecahkan oleh DSL yang tidak dapat Anda selesaikan saat ini?

Mengapa menggunakan Dart ketika Anda dapat menggunakan nol dan satu, bukankah hanya itu yang diperlukan untuk menyelesaikan masalah komputasi apa pun?

Anda terus mengatakan itu lebih baik, mengapa lebih baik?

Saya memberikan alasan saya sebelumnya dan tidak akan mengulanginya di sini. Orang-orang BEJ akan setuju dengan saya tetapi 'untuk masing-masing mereka sendiri'.

Saya yakin DSX akan menarik minat beberapa orang di BEJ. Saya tahu orang tidak menyukai hal-hal yang berbeda. Dan keakraban tampaknya menjadi satu-satunya argumen. Jadi mengapa tidak menggunakan CSS?
Mengapa tidak menggunakan JavaScript? Lebih banyak orang tahu cara menggunakan ini daripada Dart.

Ya, menggunakan CSS masuk akal untuk memudahkan alur kerja desainer-developer. DSX mendukung itu. Keunggulan Dart dibandingkan Javascript adalah kecepatan eksekusi (kinerja).

Jika Anda merancang sistem Anda berdasarkan beberapa hal lain hanya untuk tujuan mengenal, Anda tidak benar-benar berinovasi.

Anda begitu penuh dengan bias salah yang kemungkinan besar mencegah Anda mencapai potensi penuh Anda. Buka pikiran Anda, cobalah berbagai hal.

@alexkrolick , terima kasih atas detailnya.

@cbazza

Anda begitu penuh dengan bias salah yang kemungkinan besar mencegah Anda mencapai potensi penuh Anda. Buka pikiran Anda, cobalah berbagai hal.

Saya akan berhenti berlangganan dari masalah ini sekarang. Tolong jangan pernah menyebut saya di sini atau di mana pun lagi, thx.

@b-strauss

Maaf kawan, saya tidak bermaksud menyakiti perasaan Anda ... Saya hanya mencoba membimbing Anda dengan lembut sambil mencoba mengelola frustrasi saya sendiri. Bagaimanapun, kita semua adalah manusia.

@cbazza Bisakah Anda mengirimi saya email? [email protected]

Sudah membuat proposal ini di utas lama tetapi saya masih berpikir itu poin penting

IMHO menghapus kebutuhan untuk menggunakan new/const sudah banyak membantu. Saya memiliki kesulitan nyata dalam cara format dart memformat pohon. itu tidak cukup menekankan struktur pohon IMHO dibandingkan dengan:

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

Saya setuju untuk tujuan membuat flutter sederhana yang tidak ingin menggunakan sintaks seperti JSX, dan saya juga mendukung konsep split menjadi beberapa widget, tetapi sekarang saya merasa seperti era MVC kembali di jquery. Skenario sedemikian rupa sehingga ada widget sederhana, dengan padding, border, dan tata letak tengah untuk nanti, banyak simbol "} " sangat memengaruhi keterbacaan. Namun, ini adalah widget integral, saya tidak ingin membaginya, apa pun yang berguna larutan? Meskipun bahasa Inggris saya buruk, saya berusaha keras untuk mengungkapkan pikiran saya.

Tuhan tolong kami semua.

Oke, ini tidak akan kemana-mana. Sepertinya tidak ada orang yang akan beralih pihak dalam waktu dekat. Kita pasti perlu mencapai semacam kompromi di sini. Tentu saja "pro-DSX" vs "anti-DSX" tidak benar-benar memiliki kompromi yang memuaskan, yang merupakan realisasi yang membuat frustrasi. Bisakah kita membingkai ulang posisi kita sehingga mereka bisa lebih kompatibel?

@naiveaiguy "mereka" dapat memiliki DSX mereka.
Jika tim Flutter tidak mengimplementasikannya, itu bisa menjadi inisiatif open source.
Itu tidak berarti pendekatan Dart murni seperti sekarang tidak akan berfungsi lagi.
Kedua dunia bisa hidup berdampingan.

Saya sangat setuju dengan @zoechi bahwa mereka dapat hidup berdampingan ... itu saja dan saya pikir ini telah diselesaikan di utas lama

@lrhn

Tolong semuanya, bersikaplah sipil dan konstruktif. Kami sedang mendiskusikan gaya di sini, sesuatu yang sangat subjektif, jadi tidak peduli seberapa besar semua orang menyukai preferensi mereka sendiri, itu tidak mungkin secara inheren lebih unggul dari orang lain. Buat daftar keuntungan dan kerugian yang Anda lihat dengan sintaks yang ada dan yang diusulkan, tetapi ingat bahwa tidak semua orang melihatnya dengan cara yang sama, dan itu tidak masalah.

Bravo, itu benar-benar itu.

Di React Anda dapat melakukannya dengan 4 cara (dan saya baru tahu tentang 2 cara lainnya hari ini !!!)

(1) Anda dapat menggunakan JSX (yang saya suka)
https://reactjs.org/docs/introducing-jsx.html

(2) Anda dapat menggunakan cara asli (yang mirip dengan Flutter)
https://reactjs.org/docs/react-without-jsx.html

Di akhir tautan di atas, mereka bahkan menyebutkan 2 proyek komunitas yang menjanjikan

(3) Sintaks hyperscript untuk markup React.js
https://github.com/mlmorg/react-hyperscript

(4) Sintaks singkat untuk hyperscript.
https://github.com/ohanhi/hyperscript-helpers

Memiliki alternatif adalah hal yang baik, sudah lewat hari-hari di mana Anda bisa mendapatkan Ford dalam warna apa pun yang Anda suka asalkan hitam :)

@naiveaiguy mengapa ini menjadi masalah bagi Anda jika ada pendekatan dan DSX saat ini?
(itulah yang saya dapatkan dari downvotes Anda)

@naiveaiguy "mereka" dapat memiliki DSX mereka.
Jika tim Flutter tidak mengimplementasikannya, itu bisa menjadi inisiatif open source.
Itu tidak berarti pendekatan Dart murni seperti sekarang tidak akan berfungsi lagi.
Kedua dunia bisa hidup berdampingan.

Saya sepenuhnya setuju dengan ini. Meskipun saya pikir itu harus menjadi solusi pluggable daripada out-of-the-box. Memiliki satu standar yang berfungsi tetapi mampu menyesuaikan pengalaman dengan hal-hal ekstra adalah paradigma yang hebat. Dengan begitu tim Flutter dapat tetap fokus pada (apa yang saya yakini) masalah yang lebih relevan, komunitas dapat bereksperimen dengan berbagai alat/solusi dan kemudian kita dapat berdiskusi dengan lebih banyak data dan pengalaman dengan DSX atau alternatif lain apa pun saat ini meta.

Memiliki alternatif adalah hal yang baik, sudah lewat hari-hari di mana Anda bisa mendapatkan Ford dalam warna apa pun yang Anda inginkan
suka asalkan hitam :)

Benar bahwa. Namun, saya pikir kita semua bisa setuju bahwa kita tidak ingin Dart/Flutter menjadi ekosistem JS/Web Frontend lainnya. Flutter bahkan belum keluar dari beta dan kami sudah menginginkannya memiliki 2 standar untuk sesuatu yang agak subjektif.

Di React Anda dapat melakukannya dengan 4 cara (dan saya baru tahu tentang 2 cara lainnya hari ini !!!)

Sebagian besar didorong oleh komunitas meskipun React mengacu pada mereka. Baik di tengah jalan. Sekarang, hanya 2 dari mereka yang didukung secara resmi: cara React.createElement dan JSX, yang merupakan pembungkus dari yang lain. Nilai BEJ terkenal dalam konteks itu tetapi tidak begitu jelas di sini. Dengan pemikiran ini, dapatkah kita bertemu di tengah jalan dengan hanya memiliki satu standar resmi dan dokumen yang mereferensikan DSX jika relevan?

Saya yakin tim Flutter harus berfokus pada kekurangan fitur yang benar-benar mencegah developer membuat aplikasi. Saya tidak dapat merekomendasikan Flutter kepada manajer saya jika kami bahkan tidak dapat menambahkan dukungan Maps dan mengembangkan fitur Kamera membutuhkan waktu 2 minggu.

Ingatlah, saya tidak akan menutup pintu di DSX selamanya. Mungkin ini akan menjadi solusi untuk membangun UI tetapi kami membutuhkan komunitas yang bereksperimen dengannya untuk membuat keputusan itu.

@zoechi Secara pribadi saya tidak percaya dua ide dapat hidup berdampingan dalam keadaan Flutter saat ini - kita benar-benar tidak boleh mendorong perpecahan seperti ini sedini ini - tetapi pada titik ini sepertinya satu-satunya kompromi.

@naiveaiguy

Secara pribadi saya tidak percaya kedua ide dapat hidup berdampingan dalam keadaan Flutter saat ini - kita seharusnya tidak mendorong pemisahan sifat ini sedini ini

Bisakah Anda lebih spesifik mengapa mereka tidak bisa hidup berdampingan? (mengingat fakta bahwa DSX hanyalah gula sintaksis; atau seperti yang dikatakan @emalamela "hanya pembungkus cara saat ini").

Juga mengapa terlalu dini untuk memberikan sintaks yang berbeda untuk hal yang persis sama? Saya pada dasarnya bertanya mengapa ada kebutuhan untuk menunda ini, apa yang akan berbeda di masa depan yang belum ada sekarang?

@emalamela

Namun, saya pikir kita semua bisa setuju bahwa kita tidak ingin Dart/Flutter menjadi ekosistem JS/Web Frontend lainnya.

Secara pribadi saya lebih suka tidak membatasi apa yang dapat dilakukan orang dengan Dart/Flutter. Biarkan pasar/masyarakat yang memutuskan. Pada dasarnya jika yang diciptakan tidak memberikan nilai tambah, orang tidak akan menggunakannya dan akan mati. Jika menjadi populer, itu karena masyarakat menganggapnya berguna dan menghargainya. Tidak perlu memilih pemenang dan pecundang sekarang.

Satu-satunya hal yang menghentikan saya untuk mencoba Flutter adalah kenyataan bahwa mereka memilih untuk tidak menggunakan JSX.
IMHO JSX adalah pilihan terbaik untuk mengekspresikan hierarki komponen

Mendengar tentang Flutter, ingin mencobanya, segera berhenti bahkan mengingat begitu saya melihat sintaksnya, yang memalukan karena kemungkinan besar ini adalah teknologi yang hebat. untuk membangun produk.

Saya telah melakukan pengembangan React/React Native selama 2,5 tahun terakhir, mengorbankan peningkatan produktivitas yang ditawarkan sintaks JSX ketika harus mendeskripsikan UI adalah banyak hal yang harus ditanyakan. Saya akan dengan serius mempertimbangkan untuk menghabiskan waktu untuk mempelajari semua tentang Flutter dan mempelajari apakah layak untuk beralih ke saat fitur seperti itu didukung di luar kotak.

Saya bahkan tidak dapat membayangkan jumlah calon pengadopsi/pengguna/pengembang Flutter yang hilang karena hal ini, akan kembali lagi dalam beberapa bulan ke depan.

Saya bahkan tidak dapat membayangkan jumlah calon pengadopsi/pengguna/pengembang Flutter yang hilang karena hal ini, akan muncul kembali dalam beberapa bulan ke depan.

Ya, 44 Mio merasa cukup penting untuk upvote :D

Ya, 44 menganggapnya cukup penting untuk memberikan suara positif :D

Ketika diurutkan berdasarkan 'upvote', permintaan fitur ini terdaftar di urutan ke-7 dari daftar 3131 tiket yang dibuka.

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

@cbazza Saya tidak ingin membantah fitur tersebut tetapi komentar seperti "jika Anda tidak melakukan x maka y akan terjadi" hanya konyol.

Saya telah melakukan pengembangan React/React Native selama 2,5 tahun terakhir, mengorbankan peningkatan produktivitas yang ditawarkan sintaks JSX ketika harus mendeskripsikan UI adalah banyak hal yang harus ditanyakan. Saya akan dengan serius mempertimbangkan untuk menghabiskan waktu untuk mempelajari semua tentang Flutter dan mempelajari apakah layak untuk beralih ke saat fitur seperti itu didukung di luar kotak.

@sonaye

Karena Anda menyebutkan produktivitas, dapatkah Anda memberikan contoh yang dengan jelas menunjukkan hilangnya produktivitas menggunakan Pola Flutter alih-alih JSX? Contoh harus dibangun dengan dasar pengetahuan yang cukup tentang JS dan Dart untuk dapat mengkodekan contoh tersebut. Saya percaya bahwa jika kita tidak memperhitungkannya maka kita juga membandingkan bahasa pemrograman, yang bukan merupakan diskusi yang sama.

Ketika diurutkan berdasarkan 'upvote', permintaan fitur ini terdaftar di urutan ke-7 dari daftar 3131 tiket yang dibuka.

@cbazza

Itu juga yang paling downvoted. Ini cukup kontroversial.

@emalamela ,

Itu juga yang paling downvoted. Ini cukup kontroversial.

Karena permintaan fitur ini merupakan alternatif dari cara saat ini dan tidak mengubah cara saat ini, seharusnya tidak ada kontroversi sama sekali; jika Anda tidak suka JSX/DSX lanjutkan pemrograman seperti yang Anda lakukan hari ini.

Kontroversi yang disebut hanya ada karena tim Flutter perlu melakukan pekerjaan untuk memungkinkan komunitas melakukan DSX dengan benar. Jika alat Flutter (kompiler, penganalisis, dukungan ide, dll) mendukung pra-pemrosesan dengan peta sumber, DSX telah dilakukan sejak lama, dan kemungkinan besar inovasi/ide bahasa lain, dari pengembang pihak ketiga, akan terjadi juga.

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

Menjadi:

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

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

@emalamela Argumen pro dan kontra terhadap BEJ telah habis oleh diskusi, ada banyak bahan yang bisa Anda cari. Saya hanya berbagi pendapat pribadi saya.

Pertama, keterbacaan kode. Saya bisa langsung mendapatkan ide yang jelas tentang struktur UI di BEJ (membutuhkan beberapa detik), modal mentalnya sangat visual. Kedua, kegunaan. Saya berpendapat bahwa JSX dapat digunakan bahkan tanpa mengetahui JS/Dart atau apa pun tentang API yang mendasarinya. Ini sangat cocok untuk seseorang yang baru belajar pemrograman, atau untuk seseorang yang merupakan bagian dari tim saya, desainer sekarang dapat mengkodekan UI.

Deskripsi aplikasi sepenuhnya deklaratif (bukan hanya ekspresif), ketika Anda mengerjakan proyek besar dengan ratusan komponen, cara mendeskripsikan UI ini membuat perbedaan besar (Anda harus mencobanya untuk benar-benar menghargainya). Saya tidak suka JSX ketika saya pertama kali melihatnya juga, setelah saya menggunakannya hanya terasa benar, beginilah saya ingin menggambarkan UI mulai sekarang, itu adalah terobosan yang jelas dalam cara saya mendekati membangun antarmuka.

Ini bukan tentang menulis lebih sedikit baris kode, ini bukan tentang memiliki "gula sintaksis", ini tentang membangun alat untuk manusia. Saya juga menentang argumen bahwa setiap orang harus menggunakan BEJ, ini konyol. Anda menggunakan alat yang memungkinkan Anda menyelesaikan pekerjaan lebih cepat dengan lebih sedikit kebingungan, dalam kasus banyak (termasuk saya), itu akan menjadi JSX (atau DSX dalam kasus Flutter), itu saja.

Saya berasal dari React, dan pertama kali mencoba Flutter. Sangat aneh bahwa tim flutter tidak memiliki sintaks JSX, maksud saya serius! Di dunia JS, JSX sangat lazim di setiap React-alternatives sekarang! JSX sangat ramah untuk pengembang. Harap terapkan ini secepatnya, sehingga Anda dapat membantu menumbuhkan komunitas.

Anda dapat mengatakan bahwa JSX (atau DSX dalam kasus ini) adalah masalah besar hanya dengan mencari jumlah komentar dalam masalah ini.

BEJ adalah sesuatu yang Anda tidak tahu Anda suka sampai Anda mencobanya. Aneh pada awalnya memiliki markup dalam kode Anda tetapi kemudian menjadi luar biasa.

Sepertinya tidak perlu bagi pria yang sudah tahu flutter/dart, saya mengerti. Tetapi untuk seseorang yang tidak pernah menyentuh panah (seperti saya), BEJ jauh lebih mudah untuk memulai dan itulah intinya. Jika kalian ingin lebih banyak orang datang dan mulai membuat lebih banyak hal hebat, perkakasnya harus lebih mudah.

Dan, seperti yang dikatakan @eseidelGoogle (https://youtu.be/h7HOt3Jb1Ts?t=2m41s) kepada orang lain, "Flutter adalah cara untuk menulis ke iOS dan Android dalam satu basis kode. Kami mencoba membuatnya cepat dan mudah [. ..] Flutter berbicara sampai ke perangkat keras [...] Kami memiliki pendekatan yang sangat berlapis, sehingga Anda dapat mengambil sedikit atau sebanyak yang Anda inginkan. [...] Kami memiliki banyak investasi dalam perkakas ."

Terapkan JSX, silakan.

Saya penggemar Dart dan juga pengguna berat reaksi. Saya selalu menemukan Dart terser dan lebih mudah dipelihara daripada JSX. Jadi, saya pikir JSX/DSX bisa dan mungkin harus diimplementasikan secara komunitas.

@rajaraodv Hanya karena Flutter dipromosikan sebagai kerangka gaya reaktif tidak berarti itu hanya Flavour dari ReactJS.
Dari sebagian besar komentar, saya mendapat kesan bahwa orang-orang hanya kesulitan menerima bahwa sesuatu yang baru tidak sama dengan apa yang sudah mereka ketahui.

Anda dapat mencoba bekerja dengan Flutter untuk sementara waktu dan kemudian memberikan argumen yang tepat mengapa menurut Anda JSX/DSX akan lebih baik daripada Dart biasa dengan cara yang faktual, bukan hanya "karena preferensi pribadi" atau "karena lebih baik" .

@zoechi , Anda melewatkan sesuatu: flutter terinspirasi dari React, menurut dokumen Flutter.
Mungkin itu hanya masalah saya. Saya benar-benar merasa kesulitan membaca kode UI, bahkan dalam sintaks Dart 2.

flutter terinspirasi dari React Native

Saya tidak melihat bagaimana yang mengatakan "semuanya sama kecuali bahasanya disebut Flutter, bukan JS".

Saya benar-benar merasa kesulitan membaca kode UI

dan Anda mengklaim satu-satunya solusi yang bisa dibayangkan untuk itu adalah DSX?

Sudahkah Anda mempertimbangkan bahwa Flutter bahkan bukan 1.0 dan bahwa dukungan IDE dapat meningkat seiring waktu?

Hanya ada langkah kecil pertama yang diambil baru-baru ini untuk mendapatkan dukungan Flutter IDE yang lebih baik di editor kode seperti perbaikan cepat ("wrap xxx") dan menutup label.

Ada kemungkinan tak terbatas untuk meningkatkan pengalaman pengembang dan sebagian besar dalam diskusi ini seperti
"Flutter belum sempurna dan oleh karena itu kami membutuhkan DSX"
biasanya tanpa argumen konkret tentang bagaimana atau mengapa DSX akan menyelesaikan atau meningkatkannya.

@zoechi ,

Anda dapat mencoba bekerja dengan Flutter untuk sementara waktu dan kemudian memberikan argumen yang tepat mengapa menurut Anda JSX/DSX akan lebih baik daripada Dart biasa dengan cara yang faktual, bukan hanya "karena preferensi pribadi" atau "karena lebih baik" .

Sekali lagi Plain Dart atau DSX hanyalah masalah gaya, tidak ada gunanya berdebat mana yang lebih baik. Itu hanya preferensi pribadi dan orang-orang memiliki alasan untuk memilih satu atau yang lain.

Apa yang terjadi di React World adalah begitu Anda pergi dengan JSX, Anda tidak akan kembali lagi. Seperti yang telah dinyatakan orang lain di atas, Anda terpikat pada BEJ setelah menggunakan untuk sementara waktu. JSX telah diadopsi oleh orang lain di luar React's World (Typescript, Vue) dan sangat cocok untuk Flutter.

dan Anda mengklaim satu-satunya solusi yang bisa dibayangkan untuk itu adalah DSX?

Apa yang dibutuhkan komunitas adalah kemampuan pra-pemrosesan umum dengan dukungan peta sumber yang dibangun di alat Dart (kompiler, penganalisis, IDE, dll) sehingga DSX atau apa pun yang lebih baik dapat dikembangkan oleh komunitas dan terintegrasi penuh ke dalam Flutter (debugger, auto- lengkap, dll).

Ada kemungkinan tak terbatas untuk meningkatkan pengalaman pengembang dan sebagian besar dalam diskusi ini seperti
"Flutter belum sempurna dan oleh karena itu kami membutuhkan DSX"
biasanya tanpa argumen konkret tentang bagaimana atau mengapa DSX akan menyelesaikan atau meningkatkannya.

Tentu, masalahnya adalah tiket ini bukan tentang hal umum 'meningkatkan pengalaman pengembang'. Ini sangat spesifik dan ini tentang mendapatkan dukungan JSX di Flutter. Komunitas menginginkan DSX sebagai alternatif dari cara Dart biasa.

Saya tidak dapat melihat diri saya menggunakan ini (tetapi saya bersedia mencobanya). Saya tidak berpikir ini adalah peluru perak, tetapi ada begitu banyak antusiasme yang layak dilakukan.

Saya pikir google harus menghilangkan hambatan bahasa untuk memungkinkan komunitas membangun apa yang mereka inginkan.

Saya tidak mengetahui adanya kendala yang mencegah seseorang di luar tim Flutter/Dart Google untuk menulis hal seperti JSX untuk Dart/Flutter. Saya akan senang melihat bug pada mereka jika seseorang mencoba. (Mungkin juga saya melewatkannya di komentar di atas, karena saya akui tidak membaca setiap kata dari bug yang sangat panjang ini.) :)

Terima kasih! Senang melihat antusiasme seperti itu!

@eseidelGoogle ,

Bagaimana Intellij dan/atau VS Code (dengan Dart-Code) dapat mengatur breakpoint dan menelusuri kode dari file .dsx? (Maksud saya ini bukan file .dart). Bagaimana dengan fungsionalitas pelengkapan otomatis dari file .dsx (seperti file .dart)?

Anda telah banyak berinvestasi pada perkakas tetapi perkakas tersebut tidak mendukung pra-pemrosesan (dengan peta sumber) dari bahasa baru (seperti DSX) yang berubah menjadi Dart/Flutter dengan mulus.

Transpiler tersedia tetapi tidak ada cara mudah untuk mengintegrasikannya sepenuhnya:
https://spark-heroku-dsx.herokuapp.com/index.html

PS Tiket ini hanya setengah dari komentar !!!
https://github.com/flutter/flutter/issues/15922

@cbazza apakah ada repo dengan kompiler itu di suatu tempat? Akan sangat bagus untuk membagikan kode dan melibatkan komunitas untuk meretasnya, meskipun itu tidak sempurna.

@jonahwilliams , tidak ada kode transpiler DSX yang belum dirilis karena terlalu dini untuk itu.
Anda cukup menggunakan 2 file setara yang ditulis tangan (.dsx dan .dart) untuk menguji kemampuan pra-pemrosesan seperti breakpoint, stepping, auto-complete, dll.

Setelah alat mendukung pra-pemrosesan dengan semacam peta sumber, saya dapat menambahkannya ke transpiler dan membuka blokirnya. Ini juga akan memungkinkan orang lain untuk bereksperimen dengan keinginan hati mereka.

Saya tidak bekerja di Flutter, tetapi tampaknya agak tidak masuk akal untuk menuntut alat tertentu untuk memberi manfaat bagi orang lain, tetapi kemudian juga menolak untuk merilis kode sumber awal atau contoh apa pun yang Anda inginkan untuk diintegrasikan dengan alat tersebut.

Untuk apa nilainya, saya tidak tahu bahasa atau toolkit apa pun yang menyediakan kait pra-pemrosesan dalam bentuk apa pun - mungkin karena itu tidak mudah, ada banyak kasus sudut dan asumsi seputar bahasa dan sintaksis.

Jika Anda membuat peta sumber (https://pub.dartlang.org/packages/source_maps), saya membayangkan mendapatkan setidaknya beberapa dukungan dasar dalam IDE cukup sepele, terlepas dari Dart/Flutter. Tetapi sekali lagi, ini semua hanyalah dugaan tanpa mengetahui apa yang dilakukan alat Anda dan bagaimana cara kerjanya.

@matanlurey , mendukung pra-pemrosesan melalui peta sumber adalah mekanisme umum yang tidak bergantung pada transpiler tertentu. Ini adalah fungsionalitas yang dimaksudkan untuk mendukung bahasa apa pun yang dapat dibayangkan di masa depan. Browser/debugger Chrome mendukungnya dengan cukup baik dan saya dapat men-debug bahasa apa pun yang diubah ke JS.

Untuk pengujian, Anda dapat membuat transpiler sederhana apa pun untuk menunjukkan cara menggunakan peta sumber. Misalnya menulis transpiler sepele yang menghasilkan kode Dart/Flutter dengan baris kosong di antara setiap baris pada file asli. (.d2 => .dart, .d2 adalah file Dart/Flutter, keluar file .dart akan berisi baris kosong di antara setiap baris dalam file asli).

Ya, saya dapat bekerja untuk menghasilkan peta sumber untuk file uji.

Flutter saat ini enggan untuk mencoba menyenangkan NativeScript, ReactNative, Android, Web, dan pengembang lain yang terbiasa dengan tata letak XML serupa. Mereka memiliki hal-hal yang lebih penting untuk dilakukan, jadi mari kita bubar dan tidur.

Saya berharap Amy pendukung Sintaks JSX hanya meluangkan beberapa hari untuk benar-benar bekerja dengan Flutter sebelum melanjutkan meratap. Saya berasal dari sistem berbasis Xaml tetapi dengan cepat terbiasa. Hanya mencobanya nyata.

@escamoteur
Hei, escamoteur. Apakah Anda pikir saya tidak menghabiskan banyak waktu untuk belajar bergetar?
Di flutter.io/tutorials/layout/, di akhir bagian "Mengemas widget", kode yang diberikan tutorial tidak berfungsi.
Saya menyebutkan masalah di bawah blok masalah flutter, tetapi tidak ada yang mau peduli tentang ini.

• Kode panah: main.dart
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/main.dart

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

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

@JonathanSum apakah ada hubungan dari komentar Anda dengan topik masalah ini?

@zoechi
escamoteur mengatakan dia berharap pendukung Sintaks JSX hanya meluangkan beberapa hari untuk benar-benar bekerja dengan Flutter sebelum melanjutkan meratapi.
Komentar ini menunjukkan bahwa kami benar-benar telah menghabiskan banyak hari bekerja dengan Flutter, dan permintaan BEJ benar-benar perasaan kami dari hati kami.

Group Dart: "Sintaks Dart jauh lebih baik dan JSX/DSX tidak bagus"
Grup JSX/DSX: "Sintaksis JSX/DSX jauh lebih baik dan Dart tidak bagus"

Saya tidak bisa menjadi satu-satunya orang yang melihat ini? Kedua belah pihak membuat poin yang valid mendukung dan menentang posisi mereka. Saya pikir apa yang hilang di sini adalah bahwa @cbazza tidak hanya memiliki kritik TAPI JUGA MELAKUKAN SESUATU TENTANGNYA. Mencoba menjembatani kesenjangan antara web devs/react/react-native dan flutter untuk mendapatkan keuntungan dari Flutter.

Dan 2 sen saya ... Sebagai pengembang tumpukan penuh, saya memiliki exp dengan beragam bahasa dan pendekatan ... JSX adalah salah satu cara favorit saya untuk menulis kode dan saya berharap akan ada sintaks alternatif untuk Darts.. Dan saya tidak mengatakan sintaks saat ini buruk, hanya saja saya lebih suka gaya JSX.

Saya harus tidak setuju dengan kutipan dari Grup BEJ/DSX ini

Dart tidak bagus

Dart adalah bahasa yang sangat bagus dan kuat, tidak ada yang meremehkan bahasanya. Diskusinya bukan tentang Dart, tetapi lapisan sintetis di atasnya yang sudah digunakan sebagian besar pengembang UI saat ini, dan kami mengusulkan agar Flutter menggabungkan sesuatu seperti itu.

• Android memiliki Tata Letak XML.
• iOS memiliki Papan Cerita XIB (XML)
• GTK+ memiliki XML untuk Pango dll.
• Qt memiliki QML (seperti YAML)
• Xamarin memiliki XAML

Sebagian besar kerangka kerja dan bahasa ini memiliki bahasa markup UI yang memisahkan logika View dari Controller. Kemudian React hadir dengan pendekatan yang berbeda (yang kami usulkan di sini) dan saya pikir kita harus setuju bahwa RN terbang saat ini dalam hal pertumbuhan dan popularitas pengguna, dan saya mungkin salah, tetapi terutama karena JSX.

...

Apakah ini proposal yang sangat gila sehingga kami harus mendapatkan umpan balik seperti ini dari tim/pengguna Flutter?

@birkir dan semuanya membawa sejumlah masalah yang tidak dimiliki Flutter \o/
Tidak perlu bahasa lain.
Anda juga dapat memisahkan tampilan di Flutter, bahkan dengan bahasa yang sama.

@birkir utas ini 100% tentang Dart dan sintaks.

Diskusinya bukan tentang Dart, tetapi lapisan sintetis di atasnya yang sudah digunakan sebagian besar pengembang UI saat ini, dan kami mengusulkan agar Flutter menggabungkan sesuatu seperti itu.

Jadi ini bukan tentang Dart... tapi Flutter perlu menggunakan sesuatu selain Dart untuk tata letak? Sepertinya perkataanmu Dart tidak cukup baik sementara juga mengklaim ini tidak ada hubungannya dengan Dart?

Saya tidak berpikir itu penting pada saat ini, tim Flutter telah melihat umpan balik ini (untuk meminta pendekatan JSX/DSX) dan mereka ingin melanjutkan jalur aslinya. Saya pikir itu bisa ditangani dengan lebih baik tetapi sepertinya mereka tidak menentang komunitas yang menciptakan solusi.

Saya senang ada opsi lintas platform lain... akankah Apple menjadi yang berikutnya menawarkan sesuatu? Dan mungkin mereka akan melihat apa yang disukai banyak dari kita tentang react/react-native? IDK jika mereka punya sesuatu untuk dimasak.

tim Flutter telah melihat umpan balik ini (meminta pendekatan JSX/DSX) dan mereka

Bug ini masih terbuka karena kami belum menemukan apa yang ingin kami lakukan di sini. Kami bersemangat melihat eksperimen (misalnya cbazza) untuk melihat bagaimana orang menggunakannya. Kami berencana, pada titik tertentu, untuk menyediakan pengait dalam sistem build untuk alat codegen seperti ini, meskipun ini bukan sesuatu yang kemungkinan akan kami lakukan dalam waktu dekat. Dalam jangka panjang, kami berharap dapat menggunakan apa yang kami pelajari di sini untuk memengaruhi perkembangan Dart sebagai bahasa. Ini bisa berarti menambahkan sesuatu seperti E4X/H4X/JSX/DSX ke Dart itu sendiri. Atau mungkin kita akan belajar bahwa tidak ada yang benar-benar menggunakannya sehingga kita tidak akan melakukan apa-apa. Atau mungkin setiap orang membutuhkan sesuatu yang berbeda sehingga kait codegen dan paket khusus seperti cbazza adalah jawabannya. Kami belum tahu.

@jstansbe - Apple berpikir bahwa lintas platform berarti IPhone, IPad & Mac OS. Mereka lebih cenderung menambahkan menara di atas taman bertembok daripada membangun sesuatu lintas platform :)

Saya pikir jika mungkin indentasi dan format widget dengan cara lain akan lebih mirip dengan jsx dan ramah bagi pengguna yang memiliki pengalaman dengan xml dan html (hampir semua pengembang Android) ... periksa kode ini di codelab

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

periksa kode panah ke jsx ini

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

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

dan bandingkan dengan format lain ini lebih htmlish

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

ini sedikit lebih mirip dan sekarang Anda hanya perlu melihat dari kiri ke kanan untuk melihat widget berbeda yang mirip dengan html/xml/jsx

atribut elemen (widget) memiliki lebih banyak lekukan daripada widget baru, jadi ini membuat lebih jelas bisa memahami dan memeriksa kode

akan lebih bagus jika saya bisa memiliki lekukan otomatis untuk format ini pada ide yang berbeda, sekarang saya melakukan ini dengan tangan ....

Setelah membaca semua komentar di sini dan berdiskusi secara pribadi dengan teman-teman saya (pengembang aplikasi seluler asli, java/kotlin/objective-c/swift guys), pengamatan saya:

Orang-orang meminta dua hal,

• __Keterbacaan yang lebih baik dan penulisan yang lebih mudah__. Bersarang dalam dicampur dengan beberapa suara sintaks (tanda kurung, titik koma, new , child , children ) mengganggu cara pengkodean saat ini.
• __Pisahkan gaya/desain dari kode__. Pemisahan visual bagus untuk dibaca (Membedakan gaya dari kode imperatif secara sekilas) dan pemisahan nyata bagus untuk perkakas (mis., IDE dengan Layout Editor).

Ada juga terutama dua kelompok dengan pendapat yang berbeda,

• Meningkatkan sintaks saat ini tanpa memperkenalkan kompleksitas lain untuk memecahkan masalah.
  Sudah ada beberapa peningkatan ke arah ini. Misalnya, opsional new , const di Dart 2.0 dan fitur virtual "closing tag" comments yang diusulkan.
• Memperkenalkan bahasa markup tambahan (seperti JSX atau seperti XML) untuk menyelesaikan masalah.

Anda tidak dapat dengan mudah menyimpulkan mana yang lebih baik saat ini. Jadi biarkan komunitas melakukan eksperimen mereka terlebih dahulu dan membuat keputusan akhir (menerima atau menolak) nanti.

@hooluupog komentar tag penutup virtual sudah berfungsi di IntelliJ, AS, VSCode sejak beberapa saat

@Hixie

Bug ini masih terbuka karena kami belum menemukan apa yang ingin kami lakukan di sini. Kami bersemangat melihat eksperimen (misalnya cbazza) untuk melihat bagaimana orang menggunakannya.

Orang tidak dapat menggunakan eksperimen saya karena eksperimen tersebut tidak dapat disematkan dengan mulus sekarang ke Flutter; jadi ini tetap eksperimen luar/online di mana orang hanya bisa melihat potensinya.

Kami berencana, pada titik tertentu, untuk menyediakan pengait dalam sistem build untuk alat codegen seperti ini, meskipun ini bukan sesuatu yang kemungkinan akan kami lakukan dalam waktu dekat. Dalam jangka panjang kami berharap dapat menggunakan apa yang kami pelajari di sini untuk mempengaruhi perkembangan Dart sebagai bahasa.

Bisakah Anda lebih spesifik dari waktu ke waktu kapan kami dapat mengharapkan beberapa gerakan pada perubahan sistem build untuk mendukung preprocessing? Apakah kita berbicara sebulan, seperempat, enam bulan, setahun, 2 tahun, satu dekade, Yobel, dll

Ini bisa berarti menambahkan sesuatu seperti E4X/H4X/JSX/DSX ke Dart itu sendiri.

Harap baca paragraf atas spesifikasi JSX untuk melihat bahwa tidak perlu mengubah bahasa Dart karena JSX/DSX tidak memiliki semantik, dan tidak dimaksudkan untuk diimplementasikan oleh mesin atau dimasukkan ke dalam bahasa. Hal ini dimaksudkan untuk digunakan dalam preprocessor (transpiler). DSX dapat digunakan dengan Flutter & di Web untuk membuat React-Dart persis seperti React.js tetapi dengan bahasa Dart.

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

Atau mungkin kita akan belajar bahwa tidak ada yang benar-benar menggunakannya sehingga kita tidak akan melakukan apa-apa.

Bagaimana orang bisa menggunakan sesuatu yang awalnya tidak tersedia untuk mereka gunakan dan kemudian menyimpulkan bahwa tidak ada yang perlu dilakukan karena orang tidak menggunakannya? Ini sangat mengingatkan saya pada peniruan Sean Spicer Melissa McCarthy di SNL tentang 'larangan perjalanan'... 'penggunaan kata melingkar' :)

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

Atau mungkin setiap orang membutuhkan sesuatu yang berbeda sehingga kait codegen dan paket khusus seperti cbazza adalah jawabannya. Kami belum tahu.

Kemampuan preprocessing sangat dibutuhkan untuk memungkinkan eksperimen. Tanpa itu tidak ada yang bergerak maju dan Anda tidak akan belajar sesuatu yang baru.

Orang tidak dapat menggunakan eksperimen saya

Saya pikir Anda meremehkan seberapa besar keinginan orang untuk mencoba sesuatu, bahkan ketika mereka tidak sepenuhnya dipoles. Misalnya, seseorang dapat dengan mudah menulis skrip shell yang membungkus flutter run untuk melakukan preprocessing terlebih dahulu, kemudian memanggil flutter run . Saya memiliki skrip sendiri yang membungkus hot reload untuk melakukan sesuatu yang serupa (saya menjalankan penganalisis terlebih dahulu, kemudian hanya jika lolos, saya mengirim sinyal hot reload ke skrip flutter ).

Bisakah Anda lebih spesifik dari waktu ke waktu kapan kami dapat mengharapkan beberapa gerakan pada perubahan sistem build?

Tidak juga (lihat misalnya https://en.wikipedia.org/wiki/Forward-Looking_statement untuk mengetahui mengapa mungkin sulit untuk membuat pernyataan seperti itu), tetapi mungkin tidak dalam beberapa minggu mendatang.

tidak perlu mengubah bahasa Dart

Itu sangat mungkin, memang. Saya hanya mengatakan bahwa berdasarkan eksperimen ini, kita dapat mencapai sejumlah kesimpulan, mulai dari "tidak melakukan apa-apa" hingga "menambahkan fitur baru yang radikal ke sintaks bahasa" dan apa pun di antaranya. Intinya, kami belum membuat keputusan apa pun, dan sangat terbuka untuk mempelajari apa yang perlu dilakukan berdasarkan semua diskusi dan eksperimen ini.

Tambahkan BEJ ke backlog dan biarkan bersaing, bergaya gladiator, dengan jutaan lebih kebutuhan mendesak lainnya?

React ditulis untuk web dan dengan demikian membutuhkan solusi sederhana untuk menulis HTML. JSX tidak menjadi populer karena ini adalah solusi terbaik untuk menulis UI, tetapi karena ini adalah solusi terbaik untuk menulis HTML.

Flutter tidak memiliki batasan itu, jadi kita tidak boleh puas dengan solusi yang biasa-biasa saja dan bertele-tele untuk alasan yang salah.

Jika kita ingin mengurangi verbositas, saya lebih suka mengambil inspirasi misalnya dari Anko (https://github.com/Kotlin/anko/wiki/Anko-Layouts). Di sana Anda dapat menentukan variabel lokal baru di mana saja dan menggunakan for-loop normal untuk menyusun daftar turunan secara dinamis, yang dapat membuat kode lebih mudah diikuti. Selain itu, LayoutBuilder akan menjadi lebih mudah dilihat karena setiap level bersarang sudah merupakan fungsi lambda (tidak perlu melewati lambda pembangun tambahan). Bagaimanapun, ini hanya untuk inspirasi dan saya tidak berpikir Flutter harus menyalin 1:1 itu.

React ditulis untuk web dan dengan demikian membutuhkan solusi sederhana untuk menulis HTML. JSX tidak menjadi populer karena ini adalah solusi terbaik untuk menulis UI, tetapi karena ini adalah solusi terbaik untuk menulis HTML.

React Native bukanlah pengembangan web atau menggunakan HTML. Tanyakan kepada pengembang React yang berpengalaman (atau baca sepenuhnya ini dan utas JSX lainnya) dan Anda akan melihat bahwa JSX dianggap oleh banyak pengembang React sebagai cara terbaik untuk menulis UI.

Di sana Anda dapat menentukan variabel lokal baru di mana saja dan menggunakan for-loop normal untuk menyusun daftar turunan secara dinamis, yang dapat membuat kode lebih mudah diikuti.

Pernyataan ini dengan jelas menunjukkan bahwa Anda tidak mengenal BEJ. JSX (seperti dalam DSX) menggunakan semua konstruksi pemrograman (for-loop, dll) dari bahasa hosting (Javascript/Dart).

Tiket ini hanya tertarik pada fungsionalitas seperti BEJ, untuk pendekatan lain (seperti Anko) silakan buat tiket Anda sendiri untuk diskusi di sana.

React Native bukanlah pengembangan web atau menggunakan HTML. Tanyakan kepada pengembang React yang berpengalaman (atau baca sepenuhnya ini dan utas JSX lainnya) dan Anda akan melihat bahwa JSX dianggap oleh banyak pengembang React sebagai cara terbaik untuk menulis UI.

React keluar jauh sebelum React Native. Desain asli JSX didasarkan pada Rendering HTML, bukan UI asli. Tidak ada yang mampu menunjukkan satu argumen yang meyakinkan tentang apa yang dilakukan BEJ dengan lebih baik. Dengan membandingkan

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

ke

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

Anda belum melakukan perbandingan terkini dan Anda hanya menempatkan lebih banyak barang dalam satu baris. Anda harus membandingkannya dengan:

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

Perhatikan bagaimana semua tag {<{<>} />} dan </...> yang jelek hilang.

Pernyataan ini dengan jelas menunjukkan bahwa Anda tidak mengenal BEJ. JSX (seperti dalam DSX) menggunakan semua konstruksi pemrograman (for-loop, dll) dari bahasa hosting (Javascript/Dart).

Tidak, Anda tidak dapat menggunakan pernyataan if atau for-loop (atau switch atau pernyataan lainnya) di dalam BEJ:

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

Hanya ekspresi yang diperbolehkan. Jadi Anda harus menggunakan operator kondisional ( c ? x : y , yang membuat else if sangat jelek) dan Array.map dll. (yang juga bisa sangat jelek) atau memindahkan bagian dari kode Anda ke atas fungsi render atau ke fungsi pembantu yang terpisah. Sama halnya dengan Flutter, tentu saja. Anko tidak memiliki batasan ini dan membuat penulisan (beberapa) kode UI lebih alami.

Saya pikir dalam diskusi tentang memperkenalkan BEJ cukup valid dan perlu untuk menanyakan apakah itu benar-benar solusi terbaik atau apakah kita dapat menemukan sesuatu yang lebih baik. Jika tidak, kita akan membuang sumber daya untuk tugas yang salah.

React keluar jauh sebelum React Native. Desain asli JSX didasarkan pada Rendering HTML, bukan UI asli.

Desain asli JSX adalah tentang cara yang sudah dikenal untuk membuat/memanipulasi struktur pohon yang secara khusus muncul saat melakukan pekerjaan UI; pikirkan hierarki komponen (https://facebook.github.io/jsx/) yang muncul dalam pengembangan web, pengembangan asli, pengembangan UI apa pun, dll.

Tidak ada yang mampu menunjukkan satu argumen yang meyakinkan tentang apa yang dilakukan BEJ dengan lebih baik.

Itulah intinya, kami tidak mencari cara untuk mengganti cara saat ini, kami mencari cara untuk menambahkan cara alternatif yang akrab bagi pengembang Bereaksi.

Proposal Anko Anda akan familiar bagi developer Android Kotlin, jadi lanjutkan dan ajukan spesifikasi yang berfungsi dengan hierarki Flutter saat ini di tiket terpisah. Setelah saya melihat (atau mencoba versi online dari spesifikasi Anda), saya akan dapat melihat apakah itu dapat menghasilkan/berinteroperasi dengan hierarki widget Flutter saat ini.

Tidak, Anda tidak dapat menggunakan pernyataan if atau for-loop (atau switch atau pernyataan lainnya) di dalam BEJ:

Bukannya saya menyarankan Anda melakukan ini tetapi itu mungkin: buat fungsi anonim dan panggil itu.

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

Saya pikir dalam diskusi tentang memperkenalkan JSX cukup valid dan perlu untuk menanyakan apakah itu benar-benar solusi terbaik.

Tidak ada yang namanya solusi terbaik, ini semua tentang memiliki pilihan, memiliki pilihan untuk menggunakan sesuatu yang familier yang memetakan langsung ke widget Flutter dan tidak menambahkan overhead.

Omong-omong, coba yang berikut ini di transpiler online saya di:
https://spark-heroku-dsx.herokuapp.com/index.html

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

dan Anda mendapatkan:

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

DSX mirip dengan JSX tetapi untuk Dart & Flutter sehingga memiliki fitur sendiri yang dijelaskan pada tautan di atas.

ketika saya melihat ini, saya mendapatkan kilas balik dari tata letak xml dari Android.. Saya tidak berpikir itu ide yang baik untuk menerapkan ini. Sekarang Anda bahkan tidak perlu menulis new dan const bahkan terlihat lebih baik.

@charafau Bisakah Anda membagikan contoh/img/tautan, "tata letak xml dari Android" yang Anda maksud?

Tidak, @wkornewald. Jika "JSX tidak menjadi populer karena itu adalah solusi terbaik untuk menulis UI, tetapi karena itu adalah solusi terbaik untuk menulis HTML", mengapa React masih menggunakan JSX untuk membangun aplikasi seluler dan aplikasi desktop? Bahkan aplikasi desktop Github Anda, aplikasi seluler lintas platform Walmart, dan aplikasi Tesla, dan Skype juga dibuat oleh RN.

React tidak menempatkan loop for di tag JSX karena konsep React adalah tentang komponen. Bagian atas adalah logika dan bagian bawah adalah JSX, dan selalu seperti ini. Semuanya dipisahkan menjadi banyak komponen dan dihubungkan bersama menjadi satu komponen besar.

Faktanya, sebagian besar orang di sini yang menentang JSX hanya bisa menebak JSX adalah semacam HTML, XML, atau solusi yang kurang bertele-tele.

@JonathanSum

kebanyakan orang di sini yang melawan JSX hanya bisa menebak JSX adalah semacam HTML

Saya pikir itu lebih karena tidak ada argumen lain yang mendukung BEJ/DSX selain preferensi pribadi. Itu bagus tentu saja seperti yang sudah dibahas di atas, tapi tolong jangan menyiratkan orang menentang BEJ karena mereka tidak memahaminya, ketika tidak ada daftar argumen faktual yang baik yang menunjukkan di mana BEJ lebih baik daripada Dart biasa.

Saya pikir itu lebih karena tidak ada argumen lain yang mendukung BEJ/DSX selain preferensi pribadi.

Tidak juga, banyak yang diberikan sebelumnya, baca saja kedua utasnya sepenuhnya. Saya memang menyebutkan 2 hal ini sebelumnya:
(1) Tidak ada lagi barang 'anak' & 'anak-anak'
(2) mudah untuk dimanipulasi oleh alat pihak ketiga (mengurai, menganalisis, dan membuat ulang)

Dengan (2) Anda dapat meningkatkan markup untuk melakukan hal-hal yang tidak mungkin dilakukan hanya dengan Dart; misalnya operator spread DSX atau menghasilkan banyak parameter fungsi dari set yang lebih kecil.

Yang lain telah memberikan banyak poin bagus tetapi saya tidak menggalinya untuk Anda;)

(1) seperti yang disebutkan hal-hal seperti itu juga dapat diubah/ditingkatkan di Dart dan sudah ada diskusi. Ini tidak akan terjadi sebelum Dart 2 dirilis.
Hanya dengan asumsi bahwa DSX memungkinkan semua jenis fitur baru dan Dart tidak benar-benar argumen yang adil menurut saya.
(2) Saya cukup yakin ini juga bisa dilakukan dengan Dart dan tentu saja sudah ada parser untuk Dart.

Orang lain telah memberikan banyak poin bagus tetapi saya tidak menggalinya untuk Anda;)

Tidak perlu menggalinya untuk saya , tetapi ini sering muncul dan Anda mungkin dapat meyakinkan orang lain bahwa Anda sebenarnya memiliki argumen yang valid.
Saya mengikuti diskusi dan tidak dapat mengingat argumen faktual yang baik dan itu mungkin sama untuk orang lain. Jika Anda meringkasnya, Anda bisa memposting tautan ke pertanyaan berikutnya yang mempertanyakan itu.

Seperti yang telah dibahas sebelumnya, saya dapat menerima preferensi pribadi sebagai argumen yang valid, tetapi jika Anda mengklaim memiliki banyak argumen faktual juga, maka menurut saya sah untuk meminta agar argumen tersebut ditunjukkan.

Anda terus meminta 'argumen yang valid' dan ketika diberikan, Anda mengabaikannya sebagai 'Dart masa depan akan memiliki ini' atau 'ini bukan argumen yang valid'.

Faktanya adalah bahwa saat ini Dart/Flutter memiliki anak/anak-anak yang berisik di mana-mana saat membuat widget dan XML/DSX tidak. Saat ini adalah argumen yang sangat valid untuk menggunakan DSX untuk menghilangkan kebisingan anak/anak-anak ini. Bisakah Anda menerima itu sebagai argumen yang valid? (hanya karena Anda mengatakan Dart akan memilikinya di masa depan, itu tidak membuat argumen tidak valid).

Ini juga merupakan fakta bahwa penguraian XML jauh lebih sederhana daripada penguraian bahasa Dart lengkap dan setiap bahasa di luar sana memiliki pengurai XML, sedangkan hanya Dart yang memiliki pengurai bahasa Dart yang lengkap dan lengkap. Dapatkah Anda melihat bahwa ini juga merupakan argumen yang valid?

Ada banyak argumen yang valid, mereka hanya tidak valid untuk Anda dan itulah mengapa saya berhenti berdebat tentang hal itu. Jika orang tertarik dengan apa yang dikatakan, baca saja 2 utas di BEJ sepenuhnya. Saya tidak tertarik untuk meyakinkan Anda untuk menggunakan DSX, Anda senang dengan Dart biasa; Saya tidak.

Argumen untuk sintaks DSX opsional:

1) Bergabung dan menarik lebih banyak pengembang yang datang dari React (web dan asli)
2) Pengalaman porting komponen React Native yang lebih baik ke widget Flutter
3) Mendorong konsistensi properti anak/anak dalam widget
4) Keterbacaan kode (argumen beropini)
5) Lihat logika linting terpisah dari dart linting
6) Membuka dunia untuk alat pembuatan UI
7) Membuka ekosistem untuk pra-prosesor

DSX +1

DSX +1

Ingin sekali menulis banyak pro/kontra, tetapi dengan membaca semua komentar ini, saya merasa seperti akan mengulangi semuanya berulang-ulang.
Berhentilah menjadi begitu naif dan bodoh, tidak ada yang mengatakan Anda akan DIPASTI untuk menulis UI menggunakan DSX, itu hanyalah sebuah pilihan (alternatif yang lebih baik).
Ada alasan mengapa Anda dapat menulis JS dalam 101203103 dengan cara yang berbeda.

Yah, selalu ada opsi untuk menulis plugin penganalisis yang mem-parsing DSX dan mengubahnya menjadi panggilan fungsi Dart biasa, sehingga kompilator tidak perlu melakukan pekerjaan ekstra.

Pertanyaan sebenarnya adalah apakah plugin penganalisis berlaku dalam konteks kompiler.

Jika Anda bertanya kepada saya, DSX hanya boleh ikut serta, idealnya melalui semacam plug-in. Saya pikir sangat tidak perlu menambahkannya ke bahasa itu sendiri, karena sisi server dan pengguna Web Dart harus beradaptasi dengan perubahan, bukan hanya pengguna Flutter. Sebagian besar kode yang ditulis dalam Dart bahkan tidak memerlukan sintaks XML dari jarak jauh, jadi menerapkannya pada semua orang adalah keputusan yang buruk.

TLDR; jika Anda menginginkan DSX seburuk itu, tulis plugin penganalisis dan bawa sendiri ke Dart. Internet akan menyukai Anda, Anda akan mendapatkan ribuan bintang Github, dan Anda akan merasa seperti React. Menang-menang.

PS Saya bahkan akan memacu Anda untuk melakukannya

Yah, selalu ada opsi untuk menulis plugin penganalisis yang mem-parsing DSX dan mengubahnya menjadi panggilan fungsi Dart biasa, sehingga kompiler tidak perlu melakukan pekerjaan ekstra.

Saat ini tidak ada cara dalam bahasa dart untuk mengimplementasikan ini tanpa peretasan (pikirkan kondisi balapan, impor rekursif, dan lainnya). Ini perlu diintegrasikan pada tingkat di mana semuanya akan berfungsi seperti yang diharapkan, pemuatan ulang panas, analisis statis, dll.

Jika Anda bertanya kepada saya, DSX hanya boleh ikut serta, idealnya melalui semacam plug-in. Saya pikir sangat tidak perlu menambahkannya ke bahasa itu sendiri, karena sisi server dan pengguna Web Dart harus beradaptasi dengan perubahan, bukan hanya pengguna Flutter. Sebagian besar kode yang ditulis dalam Dart bahkan tidak memerlukan sintaks XML dari jarak jauh, jadi menerapkannya pada semua orang adalah keputusan yang buruk.

Jika Anda membaca utasnya, itu adalah idenya sejak hari pertama. Kami hanya ingin dukungan dari flutter/dart untuk membuat transpiler.

TLDR; jika Anda menginginkan DSX seburuk itu, tulis plugin penganalisis dan bawa sendiri ke Dart. Internet akan menyukai Anda, Anda akan mendapatkan ribuan bintang Github, dan Anda akan merasa seperti React. Menang-menang.

Baca utasnya, ini sudah dilakukan oleh @cbazza (plugin penganalisis tidak akan memotongnya)

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

PS Saya bahkan akan memacu Anda untuk melakukannya

Besar! Bahkan teori tentang bagaimana ini akan bekerja akan menarik untuk dilihat.

SGTM. Kira kita semua menunggu semacam dukungan pra-pemrosesan, kalau begitu.

Saya lebih suka sintaks pembangun daripada melewati parameter melalui konstruktor

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

seperti di https://fblitho.com/

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

DSX +1

Saya mendapatkan argumen untuk JSX, tetapi saya pikir ada banyak orang (termasuk diri sendiri) yang membenci pemikiran untuk memasukkan XML ke dalam bahasa pemrograman. Rasanya salah (tapi saya benar -benar mengerti bahwa orang lain tidak merasakan hal yang sama).

Mengingat bahwa hampir tidak mungkin untuk menghilangkan fitur setelah diimplementasikan, saya akan menyarankan prinsip pencegahan. Mari kita lihat bagaimana beberapa fitur sintaks Dart 2 yang lebih baru dimainkan sebelum melakukan perubahan substansial pada cara aplikasi Flutter dibuat.

@wstrange
Aku bisa memahami mu. Saya dulu menentang JSX dan mencampur js dengan xml/html.... lalu saya mencobanya. Setelah beberapa bulan menghabiskan waktu dengan reaksi, saya jatuh cinta dengan BEJ. Dua keuntungan pembunuh adalah:

1. tidak ada sintaks dan utilitas baru
2. tidak ada lagi lewatnya variabel, fungsi, dll.

@wstrange ,

Mengingat bahwa hampir tidak mungkin untuk menghilangkan fitur setelah diimplementasikan,

Itu tidak diberikan, siapa yang mengira bahwa Google akan menghapus MathML dari Chrome?

Mari kita lihat bagaimana beberapa fitur sintaks Dart 2 yang lebih baru dimainkan sebelum melakukan perubahan substansial pada cara aplikasi Flutter dibuat.

Ini sama sekali bukan perubahan cara aplikasi Flutter dibangun, ini hanya cara alternatif yang tidak mengubah cara saat ini, dan yang terpenting ini hanyalah sintaks yang berbeda dengan perpustakaan kelas. Transpiler sederhana melakukan pemetaan tanpa memerlukan informasi apa pun dari kelas Flutter sehingga berfungsi dengan baik untuk kode siapa pun, serta Flutter sekarang dan di masa mendatang.

@Bessonov ,

Ya, Anda tidak tahu Bereaksi sampai Anda menghabiskan beberapa bulan bekerja dengannya dan kemudian Anda menyadari betapa fenomenalnya sebuah perpustakaan untuk menangani hierarki komponen.

@cbazza Saya bisa mengatakan hal yang persis sama tentang Flutter. Habiskan beberapa minggu untuk menggunakannya dan Anda tidak akan melewatkan BEJ.

Reaksi memberitahu kita segalanya.

Seperti sekarang, +1 hampir dua kali lipat -1

@escamoteur ,
Ya, pernyataan yang sangat adil untuk dikatakan, tetapi saya telah menghabiskan banyak waktu dengan Flutter dan saya pasti dapat melihat nilai yang akan ditambahkan DSX ke dalamnya. Seperti yang telah diperhatikan oleh @leedstyh , penggemar DSX memimpin balapan dengan hampir 2-ke-1 yang cukup menakjubkan mengingat orang-orang di forum ini adalah orang-orang Flutter.

Saya punya pertanyaan:

Saat menggunakan sintaks DSX, kami secara implisit berasumsi bahwa anak/anak-anak bersarang bertipe Widget. Bagaimana jika kita ingin secara eksplisit menyatakan bahwa kita ingin anak/anak-anak bersarang menjadi sub-jenis Widget tertentu?

misalnya, ketika saya ingin anak-anak dari widget khusus saya hanya menerima daftar Wadah, saya dapat membubuhi keterangan anak-anak dengan List<Container> dan IDE akan memberikan kesalahan segera setelah saya meletakkan sesuatu yang berbeda dari Wadah. Seperti yang saya ketahui tidak ada cara untuk menegakkan tipe aman seperti ini saat menggunakan dsx. Mungkin kita dapat memiliki beberapa kesalahan saat aplikasi dikompilasi, tetapi saya pikir kesalahan yang meningkat saat saya mengetik masih merupakan pengalaman yang lebih baik.

Saya pikir kita harus memberi semua orang waktu untuk mencoba dan membiasakan diri dengan cara flutter untuk mendeklarasikan UI, setidaknya setelah rilis v1. Kemudian kita bisa melihat fitur ini dengan lebih baik.

@sandangel ,

Tangkapan yang sangat bagus!!! Saya memberikan topi virtual saya kepada Anda. Prototipe awal saya memiliki beberapa lubang di dalamnya sejak awal yang saya sadari dan hanya menunggu orang untuk menemukannya dan maju. Saya hanya berharap orang-orang tertarik untuk membahas teknologi daripada memperebutkannya.

Solusi yang saya miliki untuk ini adalah menyediakan tipe array sebagai parameter lain di namespace. Karena namespace semakin besar, kita dapat mengatur bentuk pendek untuk 'anak-anak' menjadi '*'.

Dalam Contoh 2 di https://spark-heroku-dsx.herokuapp.com/index.html , jika tindakan adalah larik 'Wadah' alih-alih 'Widget' default, itu akan terlihat seperti alternatif berikut:

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

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

hai @cbazza , terima kasih atas tanggapan Anda.

Saya bertanya-tanya tentang solusi Anda. Apakah kita menyalahgunakan namespace xml seperti yang dijelaskan di w3shool-XML Namespaces ?

Seperti yang dinyatakan bahwa namespace terutama digunakan untuk menyelesaikan konflik penamaan dalam dokumen XML.

Jadi, ketika seseorang membaca XML di atas, mereka mungkin berpikir bahwa Anda mendeklarasikan tag Penampung di bawah namespace 'anak-anak' dari 'tindakan' namespace, bukan Anda menerapkan setiap anak bersarang harus menjadi Wadah. Itu membingungkan saya ketika saya pertama kali membaca sintaks yang Anda usulkan tanpa membaca penjelasan di atas.

Bisakah kita memiliki sesuatu yang lebih baik?

DSX bukan XML, ini seperti XML sehingga tidak perlu mengikuti semantik XML, seperti bahasa template Angular ;) Bagaimanapun, saya selalu terbuka untuk alternatif atau saran yang lebih baik dan ingin berdiskusi di sini.

Berasal dari React-native, saya pertama kali mendukung implementasi seperti JSX, dan tidak menyukai objek bersarang, tetapi saya mulai menikmati OOP dan melihat semuanya sebagai Objek!

Untuk orang-orang yang berasal dari React-native, saya sangat merekomendasikan plugin ini! https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer

@clarktank
Bisakah Anda memperluas exp Anda dengan react-native(JSX), Flutter(OOP), dan perjalanan Anda dari satu ke yang lain?

@cbazza Saya pikir sintaks template sudut mengikuti semantik xml dan karena saya sadar tidak ada kasus penggunaan konflik antara sintaks sudut dan dokumen xml.

Dalam TypeScript, kami memiliki dukungan untuk komponen generik .
Jadi saya pikir kita bisa memiliki sesuatu seperti ini:

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

Tetapi sekali lagi, komponen generik digunakan untuk memeriksa jenis input properti. Saya tidak tahu apakah sintaks di atas memiliki makna semantik yang benar dalam kasus penggunaan ini.

Saya benar-benar merasa bahwa tim Flutter telah membuat API saat ini khusus untuk cara baru mendeklarasikan UI yang mereka anggap lebih baik daripada JSX dan segala upaya kami mencoba untuk mengikat sintaks JSX ke API saat ini hanya membuatnya terlihat tidak wajar/tidak nyaman untuk digunakan.

Reaksi memberitahu kita segalanya.

Seperti sekarang, +1 hampir dua kali lipat -1

Ini tidak berarti apa-apa.

Kecuali mereka yang menonton semua masalah Flutter menggandakan masalah yang muncul di masalah ini karena mereka sudah terbiasa dengan BEJ (dan secara eksplisit mencarinya). Jadi ini lebih berarti _orang-orang yang menginginkan pengalaman seperti BEJ menggandakan orang-orang yang menonton semua masalah yang telah memilih -1_. (Saya sebagian dari orang yang memilih +1 bahkan belum benar-benar mencoba flutter)

@sandangel ,

Saya pikir sintaks template sudut mengikuti semantik xml dan karena saya sadar tidak ada kasus penggunaan konflik antara sintaks sudut dan dokumen xml.

Tentu, tetapi JSX tidak menggunakan namespace sehingga ini bukan fitur XML yang menarik.

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

Karena Anda membagi 'anak-anak' dari tindakan menjadi tag itu sendiri, agak mengingatkan saya pada tag Fragmen baru dari React. Ini adalah keseimbangan antara verbositas dan keringkasan itu pasti.

Saya benar-benar merasa bahwa tim Flutter telah membuat API saat ini khusus untuk cara baru mendeklarasikan UI yang mereka anggap lebih baik daripada JSX dan segala upaya kami mencoba untuk mengikat sintaks JSX ke API saat ini hanya membuatnya terlihat tidak wajar/tidak nyaman untuk digunakan.

Tidak ada yang baru dalam cara Flutter mendeklarasikan UI dalam kode, Mungkin menggunakan DSX tidak wajar/tidak nyaman bagi Anda tetapi bagi pengembang JSX tidak. JSX/DSX sangat cocok untuk Flutter, cocok seperti sarung tangan dan jika Anda tidak suka sarung tangan pergilah dengan tangan kosong ;)

@a14n ,

Ini tidak berarti apa-apa.

itu pasti bisa!!! Anda dapat berdebat dengan 'perasaan', 'pemikiran', 'tersangka', 'imho', 'pendapat' tetapi ini adalah data, titik data konkret. Jika data tidak berguna, sebaiknya tidak dikumpulkan. Saya kira data tidak berguna karena tidak melukis gambar Anda.

@cbazza Maksud saya ketika kami mencoba menjawab pertanyaan yang saya miliki di atas tentang menerapkan sub-jenis widget untuk anak-anak, saya merasa bahwa kode Dart melakukan pekerjaan yang lebih baik daripada JSX.

DSX bukan XML, ini seperti XML sehingga tidak perlu mengikuti semantik XML

Tentu, tetapi JSX tidak menggunakan namespace sehingga ini bukan fitur XML yang menarik.

Saya tidak yakin tetapi saya telah membaca beberapa komentar Anda di atas dan saya pikir Anda telah menyebutkan simpul JSX/XML secara bergantian. Bagaimanapun, secara pribadi saya pikir menggunakan namespace sebagai solusi tidak ideal.

Bandingkan saja

<actions:children:Container>

</actions:children:Container>

dan

actions: <Container>[]

sintaksis.

@sandangel ,

Ya, sintaks penandaan lebih bertele-tele untuk kasus ini dan itulah mengapa saya menyebutkan bentuk pendek untuk anak-anak menjadi '*'. Bagaimanapun, kasus ini adalah pengecualian dan bukan aturan. Sebagian besar waktu Anda bahkan tidak perlu menentukan 'anak-anak', apalagi 'Wadah'; tetapi fungsionalitasnya harus ada untuk mencakup semua kemungkinan kasus penggunaan.

@a14n suara adalah suara, itu pasti berarti.

Saya menghargai perasaan Anda, mungkin itu benar. Tetapi bahkan dengan rasio terbalik (1 banding 2), itu masih berarti 33% basis pengguna. Bisakah Anda mengatakan 33% adalah bagian kecil?

orang yang menginginkan pengalaman seperti BEJ

Ya, beberapa orang sedang menonton. Ini juga berarti _kurangnya JSX-like adalah salah satu alasan mengapa orang tidak memilih flutter_.

Flutter membidik lebih banyak pengembang, tidak hanya yang membaca semua masalah.

@jstansbe
Saya seorang programmer otodidak, dan seperti kebanyakan orang otodidak, saya mulai dengan Javascript.
Kemudian saya mulai belajar React dan React-Native. Saya pikir dalam beberapa tahun terakhir, khususnya setelah ES6, gaya OOP ditambahkan ke Javascript.

Jadi orang seperti saya tidak terbiasa dengan gaya pemrograman OOP. Meskipun React native Component adalah kelas seperti Widgets di Flutter.

Jenis JSX menyembunyikan gambar OOP murni. Pada dasarnya, itu menyembunyikan apa yang terjadi di bawah tenda. Catatan: React dirancang untuk pengembang web, dan pengembang web terbiasa dengan sintaks html. Itulah mengapa JSX sangat populer di kalangan pengembang web.

Secara pribadi, saya pikir OOP murni lebih masuk akal untuk proyek-proyek besar.

@clarktank ,

Saat mendiskusikan bahasa komputer, Anda harus menyadari:
(1) Sintaks - karakter dan kata-kata yang membentuk bahasa
(2) Semantik - arti dari karakter dan kata tersebut

Misalnya, panggilan fungsi dalam banyak bahasa terlihat seperti berikut (yaitu memiliki sintaks berikut):

a = someFunction(param1, param2)

Bayangkan sekarang bahwa bahasa lain memutuskan untuk menggunakan tanda kurung siku alih-alih tanda kurung bulat untuk pemanggilan fungsi; itu akan terlihat seperti berikut:

a = someFunction[param1, param2]

Masalahnya di sini adalah sintaksnya berbeda tetapi semantiknya sama. Maksud saya keduanya pada dasarnya melakukan panggilan fungsi tetapi dengan sintaks yang berbeda.

Jenis JSX menyembunyikan gambar OOP murni. Pada dasarnya, itu menyembunyikan apa yang terjadi di bawah tenda.

Tidak benar sama sekali. JSX/DSX hanyalah sintaks yang berbeda untuk hal yang persis sama (semantiknya sama). Dalam kasus JSX, tag XML hanya membuat Komponen Bereaksi (sama seperti Anda dapat melakukannya di Javascript Murni). Dalam kasus DSX, tag XML hanya membuat Widget Flutter (seperti yang dapat Anda lakukan di Pure Dart). Sintaksnya berbeda tetapi menghasilkan hal yang persis sama sehingga identik di bawah tenda.

Catatan: React dirancang untuk pengembang web, dan pengembang web terbiasa dengan sintaks html. Itulah mengapa JSX sangat populer di kalangan pengembang web.

JSX populer karena merupakan cara yang bagus untuk mengelola hierarki pohon komponen, baik untuk pengembangan web, seluler, atau UI apa pun. Perhatikan pada kode di bawah ini Anda tidak tahu apakah komponen dropdown untuk web atau seluler misalnya.

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

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

render(dropdown);

Secara pribadi, saya pikir OOP murni lebih masuk akal untuk proyek-proyek besar.

Bagaimana itu? (mengingat bahwa menggunakan JSX/DSX atau Pure Javascript/Dart menghasilkan hal yang persis sama di bawah tenda).

@cbazza

Saya menggunakan reaksi asli selama hampir satu tahun dan tidak tahu elemen JSX adalah Objek yang sedang dipakai, sampai saya mulai dengan Flutter/Dart. Dari sudut pandang saya, itu menyembunyikan gambar OOP, meskipun seperti yang Anda katakan secara semantik melakukan hal yang sama di bawah tenda!

Dalam aplikasi besar, JSX juga bisa menjadi seburuk objek bersarang berat. Jadi secara sintaksis, saya lebih suka tetap konsisten daripada memperkenalkan gaya lain yang bisa membingungkan.

@clarktank ,

Dalam aplikasi besar, JSX juga bisa menjadi seburuk objek bersarang berat. Jadi secara sintaksis, saya lebih suka tetap konsisten daripada memperkenalkan gaya lain yang bisa membingungkan.

Bagi saya, membuatnya terlihat berbeda dari kode lainnya sebenarnya merupakan keuntungan.

(Saya minta maaf sebelumnya untuk dinding teks.)

Sebagai seseorang yang belum cukup lama menggunakan React-Native atau Flutter untuk menganggap diri saya sebagai sumber definitif apakah Dart mentah atau JSX/DSX "lebih baik", utas masalah ini agak menarik untuk dibaca. Ada beberapa hal yang saya ingin gunakan $0,02 saya.

Untuk memulai, saya setuju dengan berbagai orang tentang sifat sebenarnya dari BEJ dan bagaimana manfaatnya bagi pengembang. Pertama dan terpenting, JSX dirancang sebagai bentuk "HTML dinamis" yang dapat dimasukkan ke dalam kode Javascript yang ada. Ini sangat diperlukan untuk platform web berbasis JS seperti React karena memungkinkan pengembang web untuk berinteraksi secara bersih dan efisien dengan DOM tanpa harus bergulat dengan cara asli yang mengerikan (atau satu-satunya cara jQuery yang sedikit lebih baik). Juga, pada dasarnya, BEJ mendorong pengembangan UI yang dapat dengan mudah dipisahkan dari data yang mendasarinya, mempromosikan struktur proyek yang terorganisir dengan baik. Dalam lingkungan itu, BEJ adalah alat untuk memungkinkan produktivitas yang lebih besar, dan saya merasa hampir tidak mungkin untuk berdebat dengan itu.

Bagaimana paragraf tersebut terkait dengan React-Native adalah, meskipun ini adalah platform pengembangan seluler, namun langsung diturunkan dari React. Dengan demikian, hampir semua sintaks dan paradigma awalnya masih dibuat dengan mempertimbangkan pengembangan web. Itu sesuai dengan desain - keseluruhan shtick RN adalah Anda dapat "membuat aplikasi seluler lintas platform menggunakan React", jadi _seharusnya_ terasa seperti pengembangan web saat menggunakannya. Aplikasi RN juga sebagian besar ditulis dalam Javascript, jadi penyertaan JSX adalah hal yang wajar. JSX membantu pengembangan RN untuk hampir semua alasan yang sama dengan yang membantu dalam pengembangan web. (Saya benar-benar berpikir bahwa ini adalah salah satu alasan besar bahwa, setidaknya di RN, pendekatan JSX digunakan jauh lebih sering daripada pendekatan asli. RN sendiri hanya _terasa_ seperti platform web, jadi pendekatan yang lebih web-natural pasti akan berjalan menjadi dominan.)

Flutter, di sisi lain, tidak memiliki filosofi desain seperti itu. Ini dimaksudkan untuk menjadi solusi lintas platform asli murni, dan meskipun menyatakan bahwa itu terinspirasi oleh React-Native, ia menulis lebih banyak seperti desktop asli atau aplikasi seluler daripada aplikasi web. Itu juga berjalan menggunakan Dart dan bukan Javascript, yang dari sudut pandang mengintegrasikan sesuatu seperti JSX merupakan pertimbangan utama. Pertama, sementara fungsi DOM JS dapat sangat bertele-tele (baik karena desain fungsi dan bahasa JS itu sendiri), Dart sebagai bahasa jauh lebih memfasilitasi kode deklaratif UI yang bersih sementara Flutter sebagian besar melakukan pekerjaan dengan baik menjaga konstruktor UI tetap ringkas. Untuk yang lain ( seperti yang ditunjukkan @sandangel ) Dart adalah bahasa yang diketik secara statis, jadi sifat JSX yang dirancang untuk bahasa yang diketik secara dinamis seperti JS akan mengalami hambatan dalam kasus di mana, misalnya, konstruktor UI memerlukan Widget dari jenis tertentu, satu-satunya solusi yang hanya menambah verbositas. Secara pribadi, ini terasa seperti solusi yang, seiring waktu, pasti akan menghasilkan DSL yang membengkak dan sulit dipelihara karena harus memperhitungkan semakin banyak kasus penggunaan yang melekat pada sistem yang tidak dimaksudkan untuk itu. digunakan untuk.

Karena itu, saya benar-benar tidak melihat bagaimana JSX/DSX akan menguntungkan produktivitas pengembangan Flutter lebih dari sekadar masalah preferensi pribadi. Kedua sintaks secara keseluruhan kira-kira setara dalam verbositas, dan di mana seseorang kehilangan verbositas dalam kasus tertentu, itu membuatnya menjadi jelas (tag penutup XML, misalnya). Sebagian besar bermuara pada apakah seseorang datang ke Flutter dari latar belakang berorientasi web (React/RN, Angular, dll.) atau dari latar belakang asli (Java/Kotlin/Swift, WPF/UWP, dll.) yang akan menentukan mana pendekatan yang mereka sukai. Bahkan di utas ini saja, ada banyak cerita pengguna yang mengatakan bahwa mereka sangat skeptis terhadap BEJ pada awalnya tetapi setelah menggunakannya selama beberapa bulan mengubah pendapat mereka menjadi "tidak bisa tanpa". (Meskipun bagian sinis dari saya ingin menunjukkan bahwa hal yang sama bisa terjadi pada mereka untuk pendekatan Dart asli jika mereka memberikannya kesempatan.)

Semua yang dikatakan, saya tidak dapat benar-benar melihat diri saya menyetujui bahwa DSX harus secara resmi didukung oleh tim Flutter sebagai alternatif untuk konstruktor UI asli. Meskipun itu baik-baik saja sebagai solusi pihak ketiga (dan semua alat peraga untuk @cbazza untuk benar-benar mengimplementasikannya), itu tidak benar-benar cocok dengan sifat inti Flutter sebagai platform berbasis teknologi non-web. Dengan demikian, lebih banyak kekuatan bagi siapa saja yang ingin menggunakan DSX dalam proyek mereka sendiri, tetapi saya akan berpihak pada pola pikir bahwa ada banyak hal lain yang lebih penting yang dapat dan harus dihabiskan oleh tim Flutter.

Sekarang dengan ITU dikatakan, sementara saya tidak begitu setuju dengan DSX yang didukung secara resmi, saya berpikir bahwa harus ada format UI resmi dari jenis _some_. Seperti yang ditunjukkan @birkir , hampir setiap platform UI asli utama, baik itu desktop atau seluler, memiliki format UI selain pendekatan berbasis kode langsung (dan kebanyakan dari mereka sudah diproses sebelumnya menjadi pendekatan berbasis kode). Memiliki file UI terpisah dari file logika selalu menjadi cara yang disarankan untuk merangkul pola MVVM (yang, kebetulan, adalah satu hal yang selalu membuat saya salah paham tentang JSX). Oleh karena itu, apa yang saya perdebatkan adalah bahwa Flutter memiliki sesuatu yang serupa - alih-alih format DSL UI sebaris, ia harus memiliki format UI terpisah yang dimaksudkan untuk masuk ke filenya sendiri jauh dari kode Dart.

Sebagai bagian dari pemikiran ini, saya sebenarnya telah melakukan beberapa pekerjaan akhir pekan lalu di sepanjang akhir itu. Jika saya dapat diizinkan untuk shill sejenak, saya mengembangkan sebuah proyek yang saya ciptakan "FLUI" yang merupakan upaya saya untuk menunjukkan seperti apa format seperti itu . Daripada menggunakan DSL yang sudah ada (atau versi yang dimodifikasi), saya mengembangkan DSL yang sama sekali baru yang mengambil inspirasi dari YAML dan saya telah mencoba yang terbaik untuk tetap dekat dengan "rasa" tata letak pendekatan-konstruktor Flutter. Memang, ini adalah implementasi awal _sangat_, jadi saya tidak berharap itu tidak memiliki banyak masalah, tetapi saya telah menyertakan sumber untuk skrip prosesor (ditulis dalam C#/.NET Standard) sehingga orang dapat bermain dengan itu jika mereka mau. :)

Sebagai pengguna React/RN dan Flutter, saya sangat tidak setuju dengan gagasan "DSX".

DSX tidak akan membawa apa- apa . JSX digunakan dalam reaksi karena sintaks JS mengerikan. Namun dalam kasus Flutter, pembuatan widget sangat mudah.

klasik:

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

sudah siap dibaca, mudah ditulis, kompatibel dengan tipe/generik, dan tanpa duplikasi yang tidak perlu.

Satu-satunya keluhan yang mungkin Anda miliki dengan sintaks saat ini adalah "Sulit untuk mengetahui di mana kurung tutup widget"

Tetapi sekali lagi, plugin dart dari IDE yang didukung secara resmi memecahkan masalah ini. Sehingga ketika kita membuka kode dari sebelumnya di katakan vscode, kita akan melihat

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

Adapun "Sulit untuk membedakan kode biasa dari kode UI", aturan reaksi juga berlaku untuk flutter :

Widget harus bodoh atau pintar. Widget pintar tidak memiliki logika UI. Widget bodoh tidak memiliki apa-apa selain logika UI.

Jika Anda mengikuti pola ini, Anda tidak boleh jatuh ke dalam situasi di mana Anda gagal membedakan UI dari yang lain.
Ini bahkan lebih benar ketika mengikuti sesuatu seperti pola BLoC; yang sangat memaksakan pemisahan bisnis dan UI.

JSX digunakan dalam reaksi karena sintaks JS mengerikan

Pernyataan yang sangat berpendirian dan sama sekali tidak benar.

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

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

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

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

Pernyataan yang sangat berpendirian dan sama sekali tidak benar.

Ada banyak karakter yang tidak dibutuhkan dalam sintaks reaksi default.
Mari kita bandingkan pengulangan kata dan jumlah karakter untuk setiap sintaks (tidak termasuk definisi fungsi, lekukan, dan 'kembali')

Bereaksi tanpa JSX:

• 133 karakter, termasuk 3 tanda kurung, 3 tanda kurung, 3 : , 4 , dan 11 spasi
• React.createElement ditulis dua kali

BEJ:

• 104 karakter, dengan 2 tanda kurung, 3 tanda kurung, 1 : , 4 <> dan 5 spasi
• Container dan Text ditulis dua kali

Anak panah:

• 99 karakter, dengan 2 tanda kurung, 4 : , 3 , dan 4 spasi
• Tidak ada pengulangan

Dalam hal karakter, pemenang yang jelas di sini adalah sintaks dart.

Sekarang kita juga harus mempertimbangkan spesifikasi dart lainnya.

Tipe Dart anak tunggal vs multi-anak, memiliki konstruktor const dan memungkinkan parameter generik dan bahkan diposisikan. BEJ tidak mendukung semua ini.

Beberapa contoh yang akan terkonversi dengan buruk ke JSX :

Tidak selalu children :

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

OR

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

const konstruktor pada widget itu sendiri

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

obat generik

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

alat peraga diposisikan:

Text("foo")

Dinamakan konstruktor

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

pembangun (panah tidak mendukung jenis serikat jadi children tidak dapat menjadi Widget dan fungsi)

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

@rrousselGit

Seperti yang disebutkan beberapa kali sebelum DSX hanyalah sebuah perbedaan
sintaks dan itu adalah superset dari Dart, jadi semua yang dapat Anda lakukan dengan
Dart Anda dapat melakukannya di dalam DSX. Anda juga dapat mencampur dan mencocokkan keduanya
sintaks sesuai keinginan Anda. Jelas Anda bahkan tidak repot-repot memeriksa
apa saja fitur DSX yang dilakukan untuk mendukung
Anak panah:
https://spark-heroku-dsx.herokuapp.com/index.html

-1---------------------------------------------------
Di panah:

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

OR

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

Di DSX:

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

OR

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

-2---------------------------------------
Di panah:

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

Di DSX:

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

-3----------------------------------------
Di panah:

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

Di DSX:

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

  }}
  child={child}
/>

-4---------------------------------------
Di panah:

Text("foo")

Di DSX:

<Text ["foo"]/>

-5----------------------------------------
Di panah:

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

Di DSX:

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

-6---------------------------------------------------
Di panah:

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

Di DSX:

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

Tetapi kemudian argumen memiliki konversi yang lebih mudah dari reaksi ke flutter tidak valid. Karena JSX sangat berbeda dari prototipe Anda:

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

Dan tidak ada contoh Anda di sini atau dari tautan Anda yang benar-benar menyederhanakan kode atau meningkatkan keterbacaan

Sejauh yang saya dapat menghubungkan perasaan Anda tentang JSX yang hilang (mendapat hal yang sama ketika mulai bergetar), setelah beberapa pengalaman, sintaks asli sebenarnya terasa cukup bagus

Sebagai catatan tambahan, ada solusi yang jauh lebih baik untuk pemisahan perhatian Anda. Itu adalah file template
Anda dapat memiliki file xml/yaml di sebelah widget Anda. Dan kemudian gunakan alat pembuat kode yang luar biasa yang disediakan dart.

Saya lebih suka a:

// main.dart
import 'package:flutter/material.dart';

part 'main.g.dart';

class MyState extends StatefulWidget {
  <strong i="14">@override</strong>
  _MyStateState createState() => _MyStateState();
}

class _MyStateState extends State<MyState> {
  <strong i="15">@override</strong>
  Widget build(BuildContext context) {
    return $myStateStateTemplate(theme: Theme.of(context));
  }
}

dikombinasikan dengan

// main.xml
<strong i="19">@theme</strong> ThemeData

<Container  color={@theme.cardColor} />

yang kemudian menggunakan gen kode khusus menghasilkan file dart berikut:

part of 'main.dart';

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

Hasil akhirnya bahkan lebih baik daripada "DSX" untuk pemisahan UI/logika. Lebih baik untuk generator UI potensial juga. Dan itu jauh lebih mudah untuk diterapkan menggunakan built .

Karena JSX sangat berbeda dari prototipe Anda:

Betulkah !!! Satu-satunya hal yang radikal dalam diskusi ini adalah reaksi dari para penentang.

Seperti yang tertera pada judul tiket ini, DSX adalah seperti BEJ, tidak identik dengan BEJ atau akan disebut sebagai BEJ; dan tambahannya kecil dan memberikan opsi kepada pengembang.

Anda bisa menulisnya seperti:

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

or

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

or

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

or

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

Hummmm, Anda sepertinya membingungkan 'pemisahan perhatian' dengan 'pemisahan teknologi'. Hal-hal ini sangat berbeda; Anda memisahkan kode dart dan kode markup dalam file yang berbeda, hanyalah 'pemisahan teknologi' dan tidak memberikan manfaat apa pun dari 'pemisahan masalah'. Kekhawatiran di sini akan komponen/widget yang merangkum kode yang dapat digunakan kembali dengan bersih, tidak masalah bahwa di dalam komponen/widget itu menggunakan teknologi yang berbeda.

Juga memisahkan teknologi seperti yang Anda rekomendasikan sangat rendah dibandingkan JSX/DSX yang menggunakan bahasa host untuk semua konstruksi imperatifnya (untuk loop, panggilan fungsi, pernyataan if, dll).

Setelah banyak kode dan contoh diposting di sini ( terutama ), saya sampai pada kesimpulan, bahwa JSX menambahkan nilai lebih banyak ke JS dibandingkan dengan DSX dan Dart. Tapi satu fitur yang sangat penting dari sudut pandang saya: Tag penutup. Suka:

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

mengurangi BANYAK kompleksitas kognitif dalam struktur yang dalam seperti di sini berbeda dengan:

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

Tapi yah, jika Anda menggunakannya seperti ini:

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

ada keuntungan kecil.

Seperti yang tertera pada judul tiket ini, DSX adalah seperti BEJ, tidak identik dengan BEJ

Anda melewatkan "Tapi kemudian argumen memiliki konversi yang lebih mudah dari reaksi ke flutter tidak valid."

Setengah dari argumen untuk DSX adalah "JSX populer dalam reaksi, kami juga membutuhkan ini di sini". Tapi Anda mengusulkan sesuatu yang berbeda (dan lebih kompleks) dari BEJ.
Setengah lainnya adalah tentang memisahkan UI dari kode; yang juga dapat dilakukan oleh file template.

Juga memisahkan teknologi seperti yang Anda rekomendasikan sangat rendah dibandingkan dengan JSX/DSX yang menggunakan bahasa host untuk semua konstruksi imperatifnya (untuk loop, panggilan fungsi, pernyataan if, dll).

Tidak benar. Anda bisa melakukan if dan hal-hal di dalam file template Anda. Lihat cshtml atau templat bersudut.

Masalahnya adalah file template, selama Anda sudah memiliki parser untuk itu, dapat diimplementasikan untuk flutter dalam waktu kurang dari seminggu berfungsi penuh.
Baik itu yaml, xml, cshtml, atau html dengan arahan.

Sementara DSX akan membutuhkan banyak pekerjaan.

@Bessonov Mereka baru-baru ini menambahkan komentar virtual pada IDE yang didukung untuk mengejek tag penutup.

Jadi di vscode Anda, Anda akan melihat yang berikut:

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

Manfaat tag penutup. Tanpa harus mengetiknya

@rrousselGit

Mereka baru-baru ini menambahkan komentar virtual pada IDE yang didukung untuk mengejek tag penutup.

Ya, saya pernah melihatnya di komentar yang dikutip. Tapi itu tidak sama. Ini memperkenalkan pergeseran sejajar dan mengganggu aliran membaca. Dan ini tidak membantu saya dalam IDE dan prosesor teks lainnya.

Masalahnya adalah file template

Template IMHO menderita sindrom NIH. Saya tidak mengatakan bahwa pendekatan untuk mencampur PHP dan HTML adalah cara yang tepat untuk melakukannya. Tetapi reaksi menunjukkan dengan BEJ bagaimana hal itu dapat dilakukan dengan lebih baik.

@rrousselGit

Anda melewatkan "Tapi kemudian argumen memiliki konversi yang lebih mudah dari reaksi ke flutter tidak valid."

Tidak, saya tidak melewatkan komentar sama sekali, tidak masuk akal jika Anda memberi tahu saya bahwa orang yang berasal dari BEJ akan menganggap DSX terlalu rumit.

Setengah dari argumen untuk DSX...

Ada banyak alasan untuk memilih DSX tetapi dengan alternatif orang akan memilih apa yang mereka sukai untuk alasan apa pun yang mereka miliki.

Tidak benar. Anda dapat melakukannya jika dan hal-hal di dalam file template Anda. Lihat cshtml atau templat sudut.

Masalahnya adalah file template, selama Anda sudah memiliki parser untuk itu, dapat diimplementasikan untuk flutter dalam waktu kurang dari seminggu berfungsi penuh.
Baik itu yaml, xml, cshtml, atau html dengan arahan.

Sementara DSX akan membutuhkan banyak pekerjaan.

Benar-benar berlawanan, DSX hanya mengimplementasikan 2 xml transforms dan mendapatkan yang lainnya secara gratis dari bahasa hosting. Bayangkan upaya mencoba menerapkan kembali kekuatan Dart di dalam bahasa templating baru Anda. Tidak, terima kasih, saya akan mengambil Dart.

Tidak, saya tidak melewatkan komentar sama sekali, tidak masuk akal jika Anda memberi tahu saya bahwa orang yang berasal dari BEJ akan menganggap DSX terlalu rumit.

Hal yang sama berlaku untuk implementasi dart saat ini.

Lagi pula, saya tidak berpikir kita bisa meyakinkan satu sama lain di sini. Jadi saya hanya akan menyebutkan beberapa alasan lagi mengapa saya tidak menyukai JSX di flutter dan kemudian "tunggu dan lihat".

1. Pembuatan widget berbeda dari React

Sebagai reaksi, itu adalah perpustakaan yang menangani pembuatan komponen. BEJ baik-baik saja karena mengatakan "Jangan repot-repot tentang bagaimana segala sesuatunya bekerja. Kami melakukan sesuatu untuk Anda".

Dalam flutter tidak demikian. Kami secara manual membuat widget baru setiap panggilan build. Ini sangat penting untuk dipahami, dan BEJ akan membuatnya kurang jelas.

Dan, dalam kelanjutan logika itu:

2. Orang mungkin berpikir <Foo /> melakukan sesuatu yang istimewa yang new Foo() tidak

<Foo /> dalam sebuah metode terasa istimewa. Sepertinya itu melakukan sesuatu yang asing di dalam kerangka kerja. Yang benar dalam reaksi, di mana komponen dibungkus menjadi React.Element .
Ini diterjemahkan dalam reaksi menjadi <Foo /> != new Foo() dan tidak memiliki akses langsung ke Foo .

Ini tidak berlaku dalam flutter dan dapat menyebabkan kebingungan.

Juga :

<Foo>
  <Bar />
</Foo>

Sebagai reaksi, jika Foo tidak pernah menggunakan anaknya maka Bar tidak pernah dipakai. Dan Foo dipakai setelah metode render kembali.
Sedangkan pada flutter, ini adalah kebalikannya. Bar dan Foo keduanya segera dibuat

Ini berpotensi menyebabkan pengembang Bereaksi membuat kode flutter yang tidak dioptimalkan.

3. Secara umum Dart/flutter bukan JS/react

Jika kita menambahkan BEJ di dart, saya sudah bisa melihat masalah tentang type union atau bisa melakukannya
return foo && <Component /> atau rendering async yang akan datang sebagai reaksi.
Dibenarkan dengan "kami sudah memiliki BEJ sehingga kami dapat memilikinya juga!"

Saya lebih suka sintaks berpemilik atau tanpa sintaks sama sekali, demi tidak harus mengimplementasikan fitur JSX/bereaksi terbaru di dart

4. BEJ membuat beberapa spesifikasi panah tidak jelas

Contoh kecil, Scaffold membutuhkan appbar a PrefferedSizeWidget .
Jika kita membuat Scaffold menggunakan BEJ, orang akan berharap bahwa Anda dapat mengganti BEJ yang diberikan dengan yang lain. Yang tidak benar

Maksudku, itu membuatnya sangat tidak jelas mengapa kita bisa melakukannya

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

tapi tidak

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

@rrousselGit

Lagi pula, saya tidak berpikir kita bisa meyakinkan satu sama lain di sini. Jadi saya hanya akan menyebutkan beberapa alasan lagi mengapa saya tidak menyukai JSX di flutter dan kemudian "tunggu dan lihat".

Saya tidak setuju dengan banyak hal yang Anda katakan, tetapi saya menghargai upaya Anda karena Anda meluangkan waktu untuk memikirkan masalah ini secara mendalam.

1. Pembuatan widget berbeda dari React

Bagi saya itu tidak masalah karena ini hanya detail implementasi, secara konseptual setelah Anda melihat beberapa XML, di React itu adalah Komponen, di Flutter itu adalah Widget.

1. Orang mungkin berpikir melakukan sesuatu yang istimewa yang tidak dilakukan oleh Foo() baru

Saya pikir orang akan belajar dengan cepat bahwa Dart/DSX bukan Javascript/JSX.

1. Secara umum Dart/flutter bukan JS/react

Ya, kami akhirnya menyetujui sesuatu tetapi meskipun mereka berbeda, benang merahnya adalah bahwa mereka adalah kerangka kerja UI deklaratif dan saya pikir struktur pohon deklaratif ditangani dengan baik dengan JSX/DSX. Itu membuat Anda tetap pada cara berpikir pemrograman deklaratif.

Jika kita menambahkan JSX di dart, saya sudah dapat melihat masalah tentang type union atau dapat melakukan return foo && <Component /> atau rendering async yang akan datang sebagai reaksi.
Dibenarkan dengan "kami sudah memiliki BEJ sehingga kami dapat memilikinya juga!"

Kami tidak menambahkan JSX di Dart, kami menambahkan DSX, itu berbeda tetapi memiliki kesamaan dengan JSX dan keakraban adalah hal yang besar.

Saya lebih suka sintaks berpemilik atau tanpa sintaks sama sekali, demi tidak harus mengimplementasikan fitur JSX/bereaksi terbaru di dart.

Jadi dengan alasan itu mengapa Anda menggunakan Dart? terlihat sangat mirip dengan Java namun berbeda dari Java; persetan dengan itu, mari kita singkirkan semua kata kunci dan konsep Java ini dan menghasilkan sesuatu yang samar-samar mirip dengan Erland yang hanya dapat Anda program dengan satu tangan saat melakukan gerakan yoga pretzel di atas Gunung Everest;)

1. BEJ membuat beberapa spesifikasi panah tidak jelas

Tidak juga, jika Anda menghubungkan Widget yang tidak ada bandingannya, kompiler Dart akan mengeluarkan pesan kesalahan seperti jika Anda melakukannya di Dart biasa. Saya tidak bisa cukup menekankan bahwa DSX hanyalah gula sintaksis tipis, tidak ada keajaiban, hanya sintaks perbedaan untuk hal yang sama.

@cbazza Saya menghabiskan waktu berjam-jam membaca posting Anda dan saya sangat menghargai upaya Anda dalam masalah ini. Tapi saya pikir itu (semacam) mudah untuk mengakhiri argumen. Ingat bahwa fluks adalah solusi manajemen negara resmi untuk bereaksi tetapi sekarang semua orang menggunakan redux? Dan berapa banyak lib navigasi yang ada untuk reaksi asli? Buat saja repo DSX dan biarkan pengembang reaksi masuk.

@rrousselGit

Saya belum pernah melihat sintaks part / part of di Dart sebelumnya, dan saya kesulitan menemukan dokumentasi apa pun untuk itu. Apakah ini sesuatu yang secara resmi didukung oleh Dart/Flutter? Saya ingin menggunakan sesuatu seperti itu di FLUI.

@cbazza

Anda terus berputar-putar dengan pembenaran DSX. DSX bukan BEJ. DSX mirip dengan JSX. DSX dimaksudkan untuk menjadi sintaks yang akrab bagi pengembang React. DSX hanyalah gula sintaksis untuk Dart. Orang-orang akan mengetahui bahwa DSX bukanlah BEJ. (Dan seterusnya.)

Sementara saya mendapatkan poin yang Anda coba sampaikan dengan semua penjelasan itu, saya pikir fakta bahwa Anda harus terus membuatnya mengungkapkan masalah utama mengenai sifat DSX secara umum, dan itu adalah poin yang juga diangkat oleh rrouselGit . Bahkan saat Anda terus mengatakan bahwa DSX adalah _bukan_ BEJ, orang yang menemukannya akan berpikir demikian, dan itu adalah masalah. BEJ, dan orang-orang yang menggunakannya, berasal dari ekosistem yang secara konseptual sangat berbeda pada tingkat fundamental dari Dart/Flutter. Dengan demikian, mengembangkan fitur untuk "keakraban" belum tentu merupakan hal yang baik. Salah satu alasan yang lebih jelas untuk itu adalah, seperti yang telah ditunjukkan, orang akan mencoba sesuatu seperti ini:

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

Karena mereka berasal dari Javascript/JSX, mereka mengharapkan sintaks tersebut berfungsi di DSX. Jika tidak, itu menjadi titik disonansi kognitif yang sebenarnya dapat _melukai_ minat mereka tidak hanya pada DSX tetapi juga pada Flutter secara keseluruhan. Keakraban bermanfaat ketika digunakan sebagai sarana untuk memudahkan orang ke sesuatu yang baru, tetapi itu bisa menjadi pedang bermata dua - ketika 90% fiturnya sama, 10% sisanya dapat berfungsi untuk membuat frustrasi dan mengganggu.

Masalah lain dengan DSX adalah bahwa itu tidak mungkin menjadi fitur yang terintegrasi dengan mulus dalam waktu dekat, terlepas dari apakah itu plugin pihak ketiga atau jika itu diadopsi secara resmi oleh Flutter. Seperti yang Anda katakan sendiri, agar dapat benar-benar bekerja dengan proses debug dan penerapan Flutter, dibutuhkan dukungan resmi tidak hanya dari tim Flutter tetapi juga tim Dart. Jika gagal, tanpa dukungan pra-pemrosesan dan perkakas, satu-satunya cara DSX akan bekerja adalah dengan alat konversi manual eksternal, yang merupakan langkah lain (berpotensi panjang) yang harus dilalui pengembang.

Saat mengetik ini, ada hal lain yang terpikir oleh saya. Ada beberapa orang pro-JSX di utas ini yang memuji BEJ, mengatakan bahwa pendekatan "pemisahan masalah" untuk desain UI benar-benar satu-satunya cara mereka akan mempertimbangkan untuk mengembangkan UI lagi. Jika itu masalahnya, mengapa React adalah satu-satunya framework dengan kehadiran pasar yang menggunakannya? Kerangka kerja aplikasi seluler asli dan lintas platform telah terjebak dengan storyboard, file XML, file XAML, dan DST definisi UI lainnya. Bahkan kerangka kerja JS populer lainnya seperti Angular dan Vue yang akan datang masih melakukan pendekatan "pemisahan teknologi". Pengembang Bereaksi berbicara seperti JSX adalah jalan masa depan, tetapi saya belum pernah melihatnya muncul di mana pun selain di Bereaksi dalam kerangka kerja yang telah mendapatkan daya tarik nyata.

@andrewackerman

part / part of adalah fitur dart yang sudah ada. Entah bagaimana menggabungkan dua file menjadi satu. Biasanya digunakan untuk pembuatan kode.

Ada beberapa skenario kasus nyata yang menggunakan teknik tersebut. Seperti json_serializable yang menghasilkan metode toJSON dan pabrik fromJSON untuk kelas berdasarkan propertinya.

part / part of tidak benar-benar melakukan apa pun sendiri. Bagian yang menarik adalah ketika Anda menggabungkannya menjadi sesuatu seperti source_gen .

@sunnylqm

Saya tidak berpikir menempatkan kode pada repo akan memecahkan masalah saya karena masalah saat ini adalah tentang mengintegrasikan DSX dengan alat Flutter dengan benar untuk memberikan pengalaman pengembang yang hebat dengan debugger, pelengkapan otomatis, dll. mengerjakan file .dsx.

Memberi tahu pengguna bahwa mereka dapat menggunakan DSX tetapi tidak dapat menggunakan debugger atau menikmati pelengkapan otomatis bukanlah hal yang baru bagi saya. Jika ada yang ingin membantu, yang saya perlukan adalah mencari cara untuk menambahkan dukungan prapemrosesan penuh (dengan peta sumber) ke Dart Tools dan plug-in VS Code Dart. Setelah alat mendukung DSX itu atau bahasa transpiling lainnya (bahasa apa pun yang adalah superset dari Dart tetapi mengkompilasi semuanya ke Dart) hanya akan berfungsi.

@andrewackerman

Saya tidak perlu membenarkan apapun, saya sangat yakin bahwa DSX akan menjadi hit dan hampir 100 orang tertarik pada tiket ini saja.

Jika gagal, tanpa dukungan pra-pemrosesan dan perkakas, satu-satunya cara DSX akan bekerja adalah dengan alat konversi manual eksternal, yang merupakan langkah lain (berpotensi panjang) yang harus dilalui pengembang.

Transpiler DSX sangat cepat dan dapat mengubah file .dsx menjadi file .dart lebih cepat daripada yang dapat Anda kedipkan, jadi kecepatan tidak menjadi masalah; hanya mencoba untuk mendapatkan paritas fitur agar orang-orang tidak perlu ragu untuk menggunakan DSX.

Jika itu masalahnya, mengapa React adalah satu-satunya framework dengan kehadiran pasar yang menggunakannya? Kerangka kerja aplikasi seluler asli dan lintas platform telah terjebak dengan storyboard, file XML, file XAML, dan DST definisi UI lainnya.

Buat saja timeline dan Anda akan melihat evolusi pengembangan UI. Pengembangan Android dan iOS melalui cara mereka saat ini dimulai lebih dari 10 tahun yang lalu sehingga menggunakan teknik berusia 10 tahun (teknik yang sangat penting). Teknik pengembangan (deklaratif) UI Reaktif mulai muncul untuk web sekitar 8 tahun yang lalu. React muncul 5 tahun yang lalu dan ini adalah framework Reactive pertama yang menggabungkan teknologi secara mulus dengan JSX. Vue sekarang menjadi kerangka kerja Reaktif terbaru yang mendukung teknik 'pemisahan teknologi' yang lebih lama tetapi juga mendukung JSX. Di ponsel Flutter adalah yang terbaru dan menggunakan teknik kerangka kerja Reaktif sebagai Bereaksi dan dapat memanfaatkan DSX seperti halnya Vue memanfaatkan JSX. Vue membunuh Angular karena memberikan pilihan kepada pengembang dan tidak terlalu berpendirian.

Masalah dengan file template terpisah adalah bahwa konstruksi pemrograman imperatif di sana (jika, untuk loop, dll) sangat lemah dibandingkan dengan apa yang tersedia pada bahasa pemrograman yang digunakan untuk logika bisnis. Menggabungkan keduanya seperti yang dilakukan BEJ, bagi saya, jelas merupakan masa depan.

Pengembang Bereaksi berbicara seperti JSX adalah jalan masa depan,

Dia !!!

tapi saya belum pernah melihatnya muncul di mana pun selain di Bereaksi dalam kerangka kerja yang mendapatkan daya tarik nyata.

Vue menggunakan JSX

@cbazza

Saya tidak perlu membenarkan apapun, saya sangat yakin bahwa DSX akan menjadi hit dan hampir 100 orang tertarik pada tiket ini saja.

Saya tidak mengatakan Anda _do_ perlu membenarkan apa pun. Kembali ketika Anda bersikeras bahwa tim Flutter mengambil proposal ini dan menerapkannya sendiri, ya, saya akan mengatakan Anda memiliki cukup banyak pembenaran untuk dilakukan. Sekarang Anda mencoba melakukannya sendiri, Anda dapat melakukan apa pun yang Anda inginkan untuk pembenaran apa pun yang menurut Anda cukup, dan lebih banyak kekuatan untuk Anda. Saya hanya menyatakan alasan yang saya lihat bahwa itu mungkin tidak semudah atau sepopuler yang Anda pikirkan, dan saya menempatkan bola di pengadilan Anda untuk menentangnya.

Transpiler DSX sangat cepat dan dapat mengubah file .dsx menjadi file .dart lebih cepat daripada yang dapat Anda kedipkan, jadi kecepatan tidak menjadi masalah; hanya mencoba untuk mendapatkan paritas fitur agar orang-orang tidak perlu ragu untuk menggunakan DSX.

Saya berasumsi bahwa, pada titik ini, Anda telah mengujinya sejauh ini pada UI dan Aplikasi yang berukuran sepele. Bagaimana dengan yang tidak sepele? Bagaimana dengan yang termasuk dalam kasus tepi? Selain itu, waktu aktual yang diperlukan proses bukanlah satu-satunya bagian yang relevan - hanya fakta bahwa pengembang harus melalui daftar tindakan manual lainnya sebelum mereka dapat membangun sudah cukup mematikan bagi banyak orang.

Anda juga belum benar-benar merilis kode sumber proyek, jadi tidak ada yang bisa melalui proses Anda, periksa kembali temuan Anda, dan sarankan perbaikan. Pada titik ini, semua orang benar-benar dapat melakukan adalah membawa Anda pada kata Anda bahwa itu nyaman dan berkinerja.

Vue menggunakan JSX

Saya telah menggunakan Vue untuk mendekati satu tahun sekarang, dan pada waktu itu saya telah melalui banyak repo proyek open source untuk melihat bagaimana hal-hal yang berbeda dilakukan. Meskipun saya tidak menganggap diri saya seorang master Vue dengan cara apa pun, apa yang akan saya katakan adalah bahwa tidak satu pun dari mereka yang pernah saya lihat JSX benar-benar digunakan - orang tampaknya secara besar-besaran lebih menyukai pendekatan .vue (templat -script-styling) melalui pendekatan render+JSX. Saya sendiri bahkan tidak tahu bahwa Vue bahkan mendukung JSX (setidaknya melalui plugin babel) sampai setelah balasan Anda, saya melakukan penggalian melalui dokumentasi Vue dan menemukan potongan kecil informasi tentangnya di bagian fungsi render .

Tapi ini tidak relevan dengan poin saya secara keseluruhan. Vue masih merupakan kerangka kerja Javascript. Flutter pasti tidak. Dengan demikian, ada banyak alasan yang menjadikan JSX sebagai hal terhebat terbaru di lingkungan Javascript-sentris yang tidak akan diterjemahkan ke Dart+Flutter, banyak di antaranya telah dibahas di utas ini.

Dia !!!

Sampai saya melihatnya berhasil di lingkungan pengembangan non-Javascript, saya dengan hormat tidak akan setuju.

Vue menggunakan JSX

Vue tentukan memiliki berbagai macam penggunaan. BEJ hanya "di sana". Tapi itu bukan sintaks yang dominan
Anda dapat menyambungkan JSX ke Angular jika Anda mau. Meskipun tidak ada yang melakukannya

Pengembang Bereaksi berbicara seperti JSX adalah jalan masa depan,
Dia !!!

Kandidat besar untuk masa depan adalah komponen web. Dan mereka digunakan langsung di html mirip dengan apa yang Anda temukan di Angular atau bentuk paling umum dari Vue

@andrewackerman

hanya fakta bahwa pengembang harus melalui daftar tindakan manual lain sebelum mereka dapat membangun sudah cukup mematikan bagi banyak orang.

Siapa yang mengatakan sesuatu tentang tindakan manual? Bukankah saya sudah menjelaskan bahwa saya mencoba untuk mendapatkan integrasi IDE yang mulus (pengalaman pengguna terbaik untuk pengembang).

Anda juga belum benar-benar merilis kode sumber proyek, jadi tidak ada yang bisa melalui proses Anda, periksa kembali temuan Anda, dan sarankan perbaikan.

Apa hubungannya dengan orang yang menggunakan DSX? Saya telah menggunakan JSX selama lebih dari 2 tahun dan tidak peduli dengan kode sumbernya. Apakah Anda perlu melihat kode sumber kompiler Dart untuk dapat memprogram di Dart?

apa yang akan saya katakan adalah bahwa tidak satu pun dari mereka yang pernah saya lihat JSX benar-benar digunakan - orang tampaknya secara besar-besaran lebih memilih pendekatan .vue (penataan skrip-templat) daripada pendekatan render+JSX.

JSX adalah tambahan baru sehingga akan membutuhkan waktu untuk menyebar tetapi poin penting untuk didapatkan adalah bahwa Vue menerima pendekatan lain tanpa memaksa pengembang untuk menggunakan 'cara yang benar dan satu-satunya cara' bahwa segala sesuatunya harus dilakukan di Vue.

Vue masih merupakan kerangka kerja Javascript. Flutter pasti tidak.

Benar, jadi alih-alih JSX Anda menggunakan DSX dengan Flutter.

@rrousselGit

Kandidat besar untuk masa depan adalah komponen web.

Komponen web adalah zoobies, mati tetapi masih berjalan; mereka tersebar luas seperti kanguru di Kanada. Saya bisa pergi selama berhari-hari tetapi untuk menghindari penyimpangan ...
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/

@cbazza

Siapa yang mengatakan sesuatu tentang tindakan manual? Bukankah saya sudah menjelaskan bahwa saya mencoba untuk mendapatkan integrasi IDE yang mulus (pengalaman pengguna terbaik untuk pengembang).

Anda juga mengatakan bahwa Anda memerlukan dukungan prapemrosesan dari tim Flutter/Dart untuk melakukannya. Apakah saya salah dalam hal itu?

Apa hubungannya dengan orang yang menggunakan DSX? Saya telah menggunakan JSX selama lebih dari 2 tahun dan tidak peduli dengan kode sumbernya.

JSX dikembangkan oleh Facebook untuk React, melalui proses proposal/desain/implementasi/iterasi yang ketat, dan kemudian dirilis ke dunia bertahun-tahun sebelum Anda mendapatkannya. Ini telah diuji secara ketat dan terbukti berkali-kali di lingkungan dunia nyata. Ini adalah teknologi yang matang. Tidak ada alasan untuk menuntut melihat lembar spesifikasi untuk hal seperti itu.

DSX, di sisi lain, sedang dikembangkan hari ini oleh Anda dan segelintir orang. Anda telah berbicara dengan fasih tentang apa yang dapat dan akan dapat dilakukan, tetapi semua yang sebenarnya kami _seen_ adalah segelintir kecil cuplikan kode yang dibuat khusus dan kata-kata Anda yang dihasilkan oleh transpiler. Orang-orang yang bahkan ingin mencobanya dan menyarankan kemungkinan perubahan atau peningkatan tidak dapat melakukannya, jadi mereka tidak memiliki alasan untuk mendukung upaya Anda di luar "Yay JSX!".

Saya tidak menuduh Anda berbohong atau apa, saya hanya mengatakan bahwa BEJ telah mendapatkan tingkat kepercayaan yang tidak dimiliki DSX, jadi bagaimana Anda akan mengubah beberapa kepala jika Anda tidak membiarkan orang mengotak-atiknya?

JSX adalah tambahan baru sehingga akan membutuhkan waktu untuk menyebar tetapi poin penting untuk didapatkan adalah bahwa Vue menerima pendekatan lain tanpa memaksa pengembang untuk menggunakan 'cara yang benar dan satu-satunya cara' bahwa segala sesuatunya harus dilakukan di Vue.

JSX telah berada di Vue selama hampir 2 tahun sekarang. Dan tidak seperti Vue itu sendiri, JSX adalah teknologi yang sudah ada sebelumnya yang tidak perlu diperkenalkan, terutama bagi orang yang akrab dengan React. Jika JSX akan mengambil alih dunia Vue.js, mau tidak mau saya merasa itu akan melakukannya sekarang. (Terutama jika itu merupakan indikasi bahwa banyak orang berteriak-teriak untuk JSX di Flutter seperti yang Anda klaim.)

Benar, jadi alih-alih JSX Anda menggunakan DSX dengan Flutter.

BEJ dan DSX adalah konsep sintaksis yang sama. Masalahnya adalah, di mana JSX dibangun di atas bahasa dinamis yang diketik lemah seperti JavaScript, DSX sedang dibangun di atas bahasa statis yang diketik kuat seperti Dart. Itu berarti ada banyak masalah yang DSX harus pertanggung jawabkan untuk itu JSX tidak perlu jika itu akan menjadi apa pun selain implementasi niche "JSX for Flutter", dan itu akan membutuhkan beberapa modifikasi _cerdas_ untuk membuat DSX benar-benar berfungsi tanpa membuatnya terlalu membengkak untuk membenarkan klaim bahwa itu lebih ringkas secara visual.

Dan untuk mengatasi "DSX is just Dart, jika DSX tidak dapat melakukan sesuatu, gunakan saja sanggahan Dart", maka sanggahan balik saya adalah jika saya harus terus mundur ke Dart setiap kali saya mengalami skenario yang DSX tidak lakukan. t menangani, lalu mengapa saya tidak hanya menggunakan Dart sepanjang waktu?

Dan untuk menjawab sanggahan untuk bacaan itu "Anda bisa jika Anda mau, DSX hanyalah sebuah pilihan", maka Anda benar-benar menjual diri Anda sendiri. Bahkan jika itu benar-benar hanya akan menjadi "pilihan", itu masih perlu membawa sesuatu ke meja yang akan meyakinkan orang untuk menggunakannya. Anda sendiri yang mengatakan bahwa DSX bukanlah BEJ, sehingga orang yang menginginkan BEJ saja tidak akan mendapatkan apa yang mereka inginkan. Itu berarti perlu ada beberapa alasan nyata di luar "daya tarik seperti BEJ" agar orang mau menggunakannya.

Jika Anda hanya membuat alat yang ingin Anda gunakan sendiri, maka semua ini bisa diperdebatkan dan Anda bisa gila. Tetapi jika Anda benar-benar sedang membangun sesuatu yang ingin Anda gunakan untuk orang lain, maka Anda harus meletakkannya dalam bentuk yang solid mengapa menurut Anda mereka harus melakukannya.

Komponen web adalah zoobies, mati tetapi masih berjalan; mereka tersebar luas seperti kanguru di Kanada. Saya bisa pergi selama berhari-hari tetapi untuk menghindari penyimpangan ...

Agak di luar topik, tetapi saya ingin menunjukkan bahwa komponen web benar-benar merupakan tampilan yang menjanjikan di masa depan, bahkan jika dukungan untuk mereka ditambahkan lebih lambat daripada tar. Pikirkan seperti ini: React melakukan apa yang dilakukannya karena pada dasarnya mengimplementasikan ide komponen web dalam Javascript saja. Bayangkan betapa jauh lebih baik jika fitur-fitur itu didukung oleh browser dan diuntungkan dari kinerja non-sandbox dan tidak harus beroperasi melalui manipulasi DOM? (Memang mungkin 20 tahun lagi sebelum kita mengetahuinya, tapi tetap saja...)

@andrewackerman

Maaf kawan, saya tidak punya waktu untuk berdebat tanpa henti dan mengulangi apa yang saya katakan sebelumnya berulang-ulang; kami tidak akan berakhir dalam kesepakatan, jadi semoga sukses dengan FLUI Anda.

Anda telah berbicara dengan fasih tentang apa yang dapat dan akan dapat dilakukan, tetapi yang sebenarnya kami lihat hanyalah segelintir kecil cuplikan kode yang dibuat khusus dan kata-kata Anda bahwa kode tersebut dibuat oleh transpiler.

Transpiler DSX online telah aktif sejak Februari 2018 dan siapa pun dapat menggunakannya sehingga tidak perlu mengambil kata-kata saya untuk apa pun. Tekan 'Kompilasi' dan itu mengkompilasi apa yang tertulis di panel kiri dan menempatkan hasilnya di panel kanan. Buka debugger dan Anda akan melihat AST ditulis.
https://spark-heroku-dsx.herokuapp.com/index.html

Masalahnya adalah, di mana JSX dibangun di atas bahasa dinamis yang diketik lemah seperti JavaScript, DSX sedang dibangun di atas bahasa statis yang diketik kuat seperti Dart.

Itu tidak membuat perbedaan besar sama sekali, seperti konsep dan sintaks OOP (Pemrograman Berorientasi Objek) untuk 'kelas'. Ini hampir identik dalam Javascript tanpa tipe atau Dart yang diketik; yang sama dapat dikatakan untuk pernyataan 'jika', pernyataan 'untuk', dll

masih perlu membawa sesuatu ke meja yang akan meyakinkan orang untuk menggunakannya.

Ternyata sudah berlaku untuk 100 orang di tiket ini; dan itu 100 kali lebih besar dari hanya saya yang menggunakannya; cukup baik untukku.

@cbazza

Maaf kawan, saya tidak punya waktu untuk berdebat tanpa henti dan mengulangi apa yang saya katakan sebelumnya berulang-ulang; kami tidak akan berakhir dalam kesepakatan, jadi semoga sukses dengan FLUI Anda.

Saya tidak berdebat dengan Anda hanya demi argumen atau karena beberapa bias anti-BEJ yang mendalam. Saya mencoba membuat Anda menjawab pertanyaan yang perlu dijawab. Anda sedang mengembangkan alat yang mungkin Anda maksudkan untuk digunakan orang lain, namun Anda masih belum menawarkan alasan kuat _mengapa_ mereka harus menggunakannya di luar manfaat "keakraban" dan "karena lebih baik" yang tidak jelas dan subjektif. Yang pertama, seperti yang saya katakan sebelumnya, belum tentu merupakan hal yang baik, dan yang terakhir masih merupakan klaim yang dibuat tanpa dukungan nyata.

Jika Anda ingin alat Anda sukses, itu perlu ditetapkan dalam batu apa yang Anda lakukan dan mengapa Anda melakukannya, dan Anda perlu melakukannya dengan cara yang dapat dengan mudah disampaikan kepada orang lain. Itu tidak berarti bahwa Anda tidak dapat membuat produk sampai disukai oleh _semua orang_, tetapi tujuan yang jelas dan ringkas sangat penting untuk membentuk desain dan implementasi. Jika tidak, Anda hanya akan berakhir dengan utilitas tanpa arah yang akan menjadi produk khusus terbaik dan akan sangat beruntung jika berakhir dalam kode produksi skala apa pun.

Transpiler DSX online telah aktif sejak Februari 2018 dan siapa pun dapat menggunakannya sehingga tidak perlu mengambil kata-kata saya untuk apa pun. Tekan 'Kompilasi' dan itu mengkompilasi apa yang tertulis di panel kiri dan menempatkan hasilnya di panel kanan. Buka debugger dan Anda akan melihat AST ditulis.

Saya bahkan tidak melihat bahwa tautan itu adalah contoh yang berfungsi. Saya belum pernah menggunakan herokuapp sebelumnya dan itu hanya tampak seperti inti atau sesuatu, jadi itu pada saya. :P

(Meskipun saya akan menunjukkan bahwa mengutak-atik kotak pasir online tidak sama dengan menguji transpiler di lingkungan yang lebih praktis.)

Itu tidak membuat perbedaan besar sama sekali, seperti konsep dan sintaks OOP (Pemrograman Berorientasi Objek) untuk 'kelas'. Ini hampir identik dalam Javascript tanpa tipe atau Dart yang diketik; yang sama dapat dikatakan untuk pernyataan 'jika', pernyataan 'untuk', dll

Anda sudah harus berurusan dengan satu perbedaan dalam pengetikan anak yang kuat . Bagaimana dengan atribut yang kuat-mengetik? Bagaimana dengan widget di perpustakaan yang berbeda dengan nama yang sama? Apa yang terjadi jika seseorang membuat widget dengan lebih dari satu argumen posisi tanpa nama? Apa yang terjadi jika kita mengimpor dua perpustakaan yang memiliki widget dengan nama yang sama? Apa yang terjadi dalam beberapa skenario yang tidak terpikirkan oleh saya untuk lebih menunjukkan perbedaan yang melekat antara sistem seperti Javascript dan Dart? Saya harus mengatakan, Anda begitu sembrono pada poin diskusi ini membuat saya khawatir tentang umur panjang DSX dalam pengaturan dunia nyata.

Ternyata sudah berlaku untuk 100 orang di tiket ini; dan itu 100 kali lebih besar dari hanya saya yang menggunakannya; cukup baik untukku.

Sekali lagi, itu adalah 100 orang yang memilih masalah berdasarkan "Pertimbangkan sintaks seperti JSX di dalam kode panah". Mereka memilih karena mereka menginginkan _JSX_, dan seperti yang ingin Anda tunjukkan, DSX bukanlah JSX. Jadi mengapa lagi mereka ingin menggunakan DSX? Karena deklarasi UI seperti XML sebaris adalah "masa depan"? Sekali lagi, saya hanya tidak melihatnya.

Kami telah membahas JSX di Vue yang tidak mendapatkan daya tarik, tetapi ada juga dua alternatif React yang disebutkan dalam artikel Komponen Web yang Anda tautkan: Inferno dan Preact. Sejauh yang saya tahu, mereka berdua gagal membuat gelombang apa pun di dunia pengembangan aplikasi web berbasis JS, meskipun juga secara native mendukung sintaks seperti JSX. Saya benar-benar berpikir bahwa orang perlu melihat panjang dan keras tentang _persis mengapa_ orang menyukai JSX di React, karena menurut semua akun, sepertinya itu bukan karena JSX itu sendiri. Jika pertanyaan _itu_ dapat dijawab, maka kita dapat bergerak maju menuju inovasi "masa depan" daripada hanya mengungkapkan satu fitur dari satu perpustakaan yang kita sukai ke tempat lain yang menurut kita seharusnya begitu.

Memikirkan jumlah energi yang diinvestasikan hanya dalam diskusi ini dan apa yang bisa dilakukan dengan baik untuk meningkatkan kerangka kerja saat ini malah membuat saya sedih.

@andrewackerman

Masalahnya adalah, di mana JSX dibangun di atas bahasa dinamis yang diketik lemah seperti JavaScript, DSX sedang dibangun di atas bahasa statis yang diketik kuat seperti Dart.

Maaf, tapi ini bukan masalah. Selain itu, ini tidak masuk akal sama sekali. Selain itu, kami menggunakan JSX dengan TypeScript.

@escamoteur benar-benar!

@escamoteur Saya dengan Anda yang satu ini. _100._

@Bessonov

Maaf, tapi ini bukan masalah. Selain itu, ini tidak masuk akal sama sekali. Selain itu, kami menggunakan JSX dengan TypeScript.

Bereaksi tidak dirancang untuk TypeScript. Itu dirancang untuk Javascript. Semua definisi widget, atribut, properti, dan yang lainnya dirancang untuk digunakan dalam lingkungan dinamis JavaScript, sehingga keamanan jenis TypeScript tidak memperkenalkan faktor baru apa pun dengan cara JSX berinteraksi dengan React. Ini adalah contoh lain bagaimana JSX dirancang untuk pengaturan yang sama sekali berbeda dari Flutter.

@andrewackerman
Mengapa menurut Anda itu penting? JSX adalah cara untuk menggambarkan antarmuka. Ini agnostik bahasa itu sendiri. Lihat di sini . Ini bukan JavaScript. Tapi yah, kenapa itu tidak bisa dilakukan dengan BEJ? (Selain itu belum ada implementasi ini (belum))

Dan .. Anda tahu ... aliran datang dari fb juga:

Flow adalah pemeriksa tipe statis untuk JavaScript.

Tolong, berhenti menjual argumen untuk dan menentang ekstensi yang tidak pernah Anda gunakan. Saya menggunakan BEJ setiap hari dan saya senang dengan ATM-nya, meskipun saya sangat skeptis tentang hal itu. Saya dapat membayangkan, bahwa JSX berkembang dalam pola lain, seperti halnya dengan AngularJS.

Dan mungkin topik ini membantu menemukan pola yang lebih baik untuk Dart? DSX hanyalah satu proposal. Lihat contoh pola builder di atas atau tweak bahasa lain yang disajikan di sini. Dan, mungkin flui Anda adalah cara yang lebih baik? Saya tidak tahu. Tapi mari kita cari tahu dan saling membantu untuk memperbaiki saran mereka daripada membahas hal-hal buruk dalam proposal orang lain.

Saya ingin mengusulkan untuk menutup topik ini dan membuka topik payung baru dengan percakapan terbatas. Semua proposal untuk memperbaiki cara, bagaimana flutter dapat digunakan, diskusikan dalam topik sendiri secara objektif dengan cinta dan tanpa kebencian.

Yap, jumlah kebencian di sini sangat epik, pertimbangkan saja ini:
Ada 3587 tiket terbuka, jika Anda mengurutkannya berdasarkan "jempol ke bawah", Anda mendapatkan
1 (yang ini) dengan 57 "jempol ke bawah"
3586 (tiket lain) dengan 1 atau kurang "jempol ke bawah"

@Bessonov

Mengapa menurut Anda itu penting? JSX adalah cara untuk menggambarkan antarmuka. Ini agnostik bahasa itu sendiri. Lihat di sini. Ini bukan JavaScript. Tapi yah, kenapa itu tidak bisa dilakukan dengan BEJ? (Selain itu belum ada implementasi ini (belum))

Ini adalah cara untuk mendeskripsikan UI _dalam Javascript_ (karenanya bagian "JS" dari namanya). Dan tidak, karena ini adalah DSL inline, ini _not_ language-agnostic. Dan bahkan jika ya, itu masih tidak menjadikannya "pilihan yang lebih baik", karena ada banyak DSL yang benar-benar agnostik bahasa di luar sana yang sangat tidak memadai untuk deklarasi UI.

Dan .. Anda tahu ... aliran datang dari fb juga:

Flow sama seperti TypeScript: sistem pengecekan tipe statis untuk Javascript. Ini bukan alat React, juga bukan React yang dirancang untuk digunakan dengannya. React adalah library Javascript pertama dan terutama, dan JSX dirancang untuk digunakan dengan React. Alat dan utilitas sekunder apa pun yang diperkenalkan ke dalam pengembangan React pada akhirnya tidak relevan dengan interoperabilitas React+JSX.

Tolong, berhenti menjual argumen yang mendukung dan menentang ekstensi yang tidak pernah Anda gunakan. Saya menggunakan BEJ setiap hari dan saya senang dengan ATM-nya, meskipun saya sangat skeptis tentangnya. Saya dapat membayangkan, bahwa JSX berkembang dalam pola lain, seperti halnya dengan AngularJS.

Saya telah menggunakan BEJ, dan meskipun saya memiliki pendapat pribadi tentang itu, saya sengaja meninggalkan pendapat itu dari diskusi ini. Sebenarnya, jika Anda membaca komentar saya sebelumnya, Anda akan tahu bahwa saya memuji JSX karena merevolusi pengembangan UI di React. Selain beberapa komentar tangensial ringan yang saya buat tentang penetrasi pasar BEJ secara keseluruhan, argumen saya secara khusus tentang JSX _di Flutter_. Dan pada topik itu, tidak ada dasar praktis untuk menentukan kemanjuran DSX, jadi yang bisa kita lakukan hanyalah memeriksa bagaimana BEJ telah diterapkan di tempat lain, dan pemeriksaan itu bukan pertanda baik.

Kecuali, tentu saja, Anda juga telah menggunakan DSX setiap hari dan dapat memberi tahu kami tentang keuntungan praktis menggunakan DSX di Flutter?

Dan mungkin topik ini membantu menemukan pola yang lebih baik untuk Dart? DSX hanyalah satu proposal. Lihat contoh pola builder di atas atau tweak bahasa lain yang disajikan di sini. Dan, mungkin flui Anda adalah cara yang lebih baik? Saya tidak tahu. Tapi mari kita cari tahu dan saling membantu untuk memperbaiki saran mereka daripada membahas hal-hal buruk dalam proposal orang lain.

_Itulah yang saya lakukan._ DSX sedang diusulkan sebagai solusi UI untuk orang-orang yang akrab dengan BEJ. Ada elemen desain utama di BEJ yang dimaksudkan untuk digunakan untuk lingkungan yang sama sekali berbeda dari Dart dan Flutter. _Perbedaan tersebut perlu diatasi agar DSX berhasil._ Saya tidak menjadi _pembenci_. Saya mencoba untuk mempromosikan diskusi yang konstruktif dan mengajukan pertanyaan-pertanyaan penting. Namun semua tanggapan yang saya dapatkan adalah tautologi subjektif ("JSX bagus karena itu masa depan, dan ini masa depan karena bagus"), lambaian tangan meremehkan poin desain penting ("DSX tidak perlu memperhitungkan untuk perbedaan antara JS dan Dart karena tidak ada"), atau sekadar bermusuhan ("Anda jelas tidak suka JSX jadi berhentilah berbicara tentang DSX").

Anda tidak membuat produk yang sukses hanya dengan pujian murni. Itu perlu untuk berdiri dan memperhitungkan kritik juga. Orang-orang muncul dan berkata "OMG ya tolong, buat DSX", sambil membangkitkan semangat, tidak membantu. Ada beberapa orang di seluruh utas ini yang telah mengemukakan kritik yang benar-benar valid terhadap DSX, baik dengan desain awalnya maupun dengan konsep secara keseluruhan. Dan sebagian besar, banyak dari kritik ini belum langsung ditangani, dengan sikap umum yang meremehkan.

Satu-satunya ketakutan saya adalah bahwa semua cinta tanpa syarat untuk BEJ ini mencegah orang melihat DSX secara objektif. Saya mengerti mengapa kalian menginginkan sesuatu seperti JSX di Flutter, dan saya dapat mengaitkannya - pendapat saya bahwa Flutter membutuhkan DSL UI khusus adalah yang membuat saya membuat flui. Tetapi jika satu-satunya orang yang diizinkan untuk berbicara tentang DSX adalah orang-orang yang tidak memiliki apa-apa selain hal-hal baik untuk dikatakan tentangnya, maka itu _akan_ gagal.

Bisakah kita memperbaharui diskusi tentang topik ini?
Sebenarnya, saya tidak melihat alasan untuk membiarkan masalah ini terbuka.

Tim Dart menyatakan bahwa mereka memiliki prioritas lain. Dan pihak yang pro BEJ secara sukarela membuat implementasi DSX mereka sendiri

Mungkin kita harus memiliki beberapa repositori open source yang mengusulkan solusi yang berbeda (bahkan hampir tidak berfungsi). Seperti DSX, atau template.
Dan kemudian pertimbangkan untuk mengalihkan dari readme Flutter atau awesome_flutter ke repo ini. Dan jika ada sesuatu yang menghalangi implementasi DSX, buat masalah lain dengan spesifiknya.

Kemudian biarkan masyarakat melakukan tugasnya.

Biarkan terbuka apa adanya karena orang akan terus membuka tiket baru yang meminta BEJ (seperti yang sudah terjadi dua kali sebelumnya).

Biarkan terbuka apa adanya karena orang akan terus membuka tiket baru yang meminta BEJ (seperti yang sudah terjadi dua kali sebelumnya).

Perbedaannya di sini adalah bahwa kita sekarang dapat menjawab dengan yang berikut:

"Kami tidak berencana untuk menerapkan ini di dart/flutter untuk saat ini. Tetapi Anda dapat melihat alternatif komunitas [di sini] dan [di sana] atau membaca [masalah ini]"

dan tutup masalah sebagai duplikat.

Satu tempat untuk komentar dan suara dan itu di sini. Permintaan untuk fungsionalitas seperti JSX tidak akan hilang dan tiket dibuka karena memerlukan dukungan alat Flutter (kompiler & IDE Kode VS) dan saya telah memperbarui permintaan tiket dengan info ini (komentar pertama). Jika sejumlah besar orang mulai meminta ini, itu akan memberi tim Flutter insentif untuk memasukkan sumber daya ke dalamnya.

Sepertinya sebagian besar kontroversi di sini bukan seputar BEJ saat ini, tetapi DSX. Saya menyarankan untuk membagi diskusi DSX ke dalam utasnya sendiri dan membiarkan yang satu ini generik untuk BEJ.

Pada akhirnya DSX hanyalah salah satu cara untuk mendekatkan sesuatu ke BEJ sehingga kita tidak boleh mencampuradukkan kedua diskusi ini dalam satu utas.

Tidak besar untuk ini, saya benar-benar berpikir bahwa hanya 1 bahasa adalah keuntungan besar, sintaks jsx akan datang dengan lebih banyak hal seperti pemisahan xml dari js, dll ... Tidak bagus.

itu pendapat saya.

Itu adalah masalah Github terpanjang dan tidak berguna yang pernah saya lihat.

@cbazza Kerja bagus 👍
DSX + 1

@BarryYan , Terima kasih

Harap hindari komentar semacam ini, baik itu "+1" atau "Terima kasih".
Ini mengirim email ke semua pelanggan untuk hal-hal yang tidak menarik.

Harap hindari komentar semacam ini, baik itu "+1" atau "Terima kasih".
Ini mengirim email ke semua pelanggan untuk hal-hal yang tidak menarik.

Tidak ada yang menarik bagi Anda !!!
Harap hindari memberi tahu orang lain apa yang dapat mereka katakan atau lakukan dan fokuslah hanya pada apa yang dapat Anda katakan atau lakukan.

@cbazza

Bung, itu etika dasar. Setiap pesan baru di utas ini mengirim email kepada semua orang yang berlangganan, jadi tidak sopan mengirim komentar yang tidak berkontribusi pada diskusi karena mengganggu orang tanpa alasan. Reaksi dasar seperti "+1" dan "Terima kasih" dapat disampaikan dengan reaksi acungan jempol yang sederhana, jadi lakukan saja.

Karena itu, jika utas ini benar-benar beralih ke perdebatan tentang apakah seseorang harus atau tidak boleh memposting pesan "+1", itu adalah tanda bahaya besar bahwa semua diskusi konstruktif telah secara resmi mati, dan itu benar-benar harus ditutup (mungkin secara permanen kali ini).

@andrewackerman ,

Mengerti tapi saat Anda melakukannya mungkin Anda juga harus mempertimbangkan etiket dasar saat meledakkan utas ini dengan novel Anda (tulisan panjang & fiksi).

Tolong berhenti menyebarkan FUD (takut ketidakpastian & keraguan) dengan rentetan pertanyaan yang tidak masuk akal (Anda tahu, buang omong kosong sebanyak mungkin ke dinding dan lihat apakah ada yang menempel) dan tuntutan.

Setelah semua tulisan Anda, Anda belum menambahkan nilai apa pun ke DSX, jadi saya tidak tertarik untuk berdiskusi dengan Anda tentang hal ini. Motif Anda jelas, promosikan FLUI sambil meledakkan DSX.

Katakan sesuatu, apakah Anda memiliki jawaban atas pertanyaan Anda sendiri ketika diterapkan ke FLUI? Mari kita bahas FLUI sebentar ya?

@cbazza

Mengerti tapi saat Anda melakukannya mungkin Anda juga harus mempertimbangkan etiket dasar saat meledakkan utas ini dengan novel Anda (tulisan panjang & fiksi).

Fakta bahwa Anda merujuk pada tanggapan saya bahwa saya mencurahkan banyak waktu dan upaya untuk menjadi yang dipikirkan dengan matang dan tidak memihak karena saya dapat menjadikannya sebagai "tulisan panjang & fiksi" menggambarkan banyak tentang karakter Anda dan bagaimana Anda mendekati diskusi ini. Saya mencoba untuk mempromosikan diskusi mengenai masalah yang sangat nyata seputar implementasi JSX di Flutter, sementara Anda mengecam siapa pun dengan segala bentuk pendapat yang bertentangan. Siapa di antara kita yang merupakan pelanggar etiket dasar yang lebih besar?

Tolong berhenti menyebarkan FUD (takut ketidakpastian & keraguan) dengan rentetan pertanyaan yang tidak masuk akal (Anda tahu, lemparkan sebanyak mungkin omong kosong ke dinding dan lihat apakah ada yang menempel) dan tuntutan.

Satu-satunya hal yang saya "tuntut" adalah Anda mengatasi banyak masalah yang diangkat oleh banyak orang mengenai DSX dengan lebih dari sekadar gelombang tangan atau permusuhan terbuka. Untuk seseorang yang mengusulkan perubahan/penambahan signifikan pada set fitur Flutter, saya merasa itu bukan harapan yang tidak masuk akal.

Setelah semua tulisan Anda, Anda belum menambahkan nilai apa pun ke DSX, jadi saya tidak tertarik untuk berdiskusi dengan Anda tentang hal ini. Motif Anda jelas, promosikan FLUI sambil meledakkan DSX.

Saya meminta _you_ untuk mempertahankan posisi Anda. Anda telah berulang kali mengatakan bahwa BEJ/DSX adalah yang terbaik/masa depan, tetapi belum menjelaskan bagaimana atau mengapa. Beberapa orang telah menyatakan keprihatinan yang valid tentang DSX, tetapi alih-alih mengatasinya, Anda mengabaikannya dengan bersembunyi di balik argumen tandingan "jika Anda tidak menyukainya, jangan gunakan". "Motif" saya adalah membuat Anda menjawab pertanyaan yang perlu ditanyakan mengenai _setiap_ proyek teknis, pertama dan terpenting adalah mengapa orang harus menggunakannya daripada alternatif. (Dan seperti yang telah saya jelaskan sebelumnya, keakraban bukanlah alasan yang cukup baik.)

Sejauh menyangkut FLUI, yang saya lakukan hanyalah mengusulkan solusi alternatif untuk masalah keseluruhan (sintaks deklaratif UI untuk Flutter) sambil meminta orang melakukan hal yang sama seperti yang saya lakukan pada DSX - menawarkan kritik yang tulus dan membangun. Saya tidak mengatakan bahwa FLUI secara objektif lebih baik daripada DSX - saya mengusulkan alternatif yang dibentuk dari pendekatan yang berbeda untuk pengembangan UI dan meminta orang untuk membentuk pendapat mereka sendiri.

(Saya juga ingin menunjukkan bahwa, selain penyebutan awal saya di mana saya mengusulkan kemungkinan pendekatan alternatif untuk representasi GUI, satu-satunya saat saya berbicara tentang FLUI adalah ketika Anda membahasnya. Jadi bagaimana caranya? masuk akal bahwa motif tersembunyi saya adalah untuk mempromosikannya ketika Anda membicarakannya lebih dari saya?)

Katakan sesuatu, apakah Anda memiliki jawaban atas pertanyaan Anda sendiri ketika diterapkan ke FLUI? Mari kita bahas FLUI sebentar ya?

FLUI bukan DSX - ia tidak harus menjawab _setiap_ pertanyaan yang saya ajukan kepada Anda tentang DSX karena banyak di antaranya khusus untuk desain DSX. Itu tidak berarti bahwa itu tidak memiliki serangkaian pertanyaan sendiri yang perlu dijawab, dan tidak, saya tidak memiliki semua jawaban itu. Itulah _mengapa_ saya menghargai diskusi kritis - FLUI/DSX tidak akan bertahan di pengadilan opini publik kecuali mereka dapat bertahan hidup disapu batu bara beberapa kali. Ini bukan tempat yang tepat untuk membahas FLUI. Jika Anda ingin membahas FLUI panjang lebar, proyek ini memiliki papan masalah sendiri , jadi silakan posting di sana.

Alih-alih menanggapi kritik, Anda malah bersikap defensif dan mengelak, sedemikian rupa sehingga Anda bertanggung jawab langsung atas dua kesempatan terpisah (mendekati tiga) di mana utas ini harus ditutup sementara karena hal-hal yang terlalu panas. Jadi saya akan keluar dari "etiket" dan mengatakan ini sekali: singkirkan ego Anda, berhenti menafsirkan kritik sebagai serangan pribadi, dan jawab pertanyaan penting. Entah itu, atau berdamai dengan DSX tidak pernah turun dari tanah.

andrewackerman Kerja bagus 👍
+ 1

@andrewackerman

Kerja bagus

Sobat, Anda mendapatkan pujian dari @jstansbe yang menyampaikan lebih banyak informasi daripada jempol ke atas dan jempol ke bawah pada pujian itu?

Jelas Anda tidak mengambil petunjuk saya panjang ke hati tetapi tidak sampai pada kesimpulan tentang karakter saya karena Anda tidak mengenal saya sama sekali.

Fakta bahwa Anda merujuk pada tanggapan saya bahwa saya mencurahkan banyak waktu dan upaya untuk menjadi yang dipikirkan dengan matang dan tidak memihak sebisa mungkin.

Bahwa saya menghargai dan saya membaca semua 'tulisan panjang' Anda, menjawab semuanya: tidak mungkin, tetapi ketika saya menjawab dengan benar Anda tidak memahami jawaban saya dan menyimpulkan bahwa saya meremehkan.

Jelas bagi saya bahwa Anda tidak terlalu berpengalaman dengan BEJ, Anda benar-benar tidak mengerti cara kerjanya. Jadi, alih-alih menggandakannya, miliki saja dan saya akan menjelaskannya lebih detail. Misalnya JSX & DSX hanya melakukan 2 transformasi berikut (disebutkan beberapa kali sebelumnya):

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

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

Segala sesuatu yang lain ditangani oleh bahasa host, jadi misalnya: bagaimana menangani impor komponen bernama sama; jawaban: bahasa tuan rumah. Saya tidak meremehkan, itu adalah cara dirancang dan sumber kekuatannya. Anda lihat jika Anda memisahkan markup dan pemrograman ke dalam file terpisah, Anda mulai menduplikasi pemrograman di dalam markup dengan konstruksi sederhana untuk 'jika', dll. Anda akhirnya membangun bahasa pemrograman deklaratif di dalam markup yang tidak pernah bisa sekuat bahasa pemrograman utama. Jadi dengan membawa markup ke dalam bahasa pemrograman Anda memiliki yang terbaik dari kedua dunia dan itulah kekuatan JSX/DSX.

Perhatikan di atas pada (2) bahwa transformasi hardcode <Widget> dan itu tidak selalu terjadi, jadi sekarang Anda dapat menentukannya jika diperlukan seperti yang dibahas sebelumnya. Lihat transformasinya dan sekarang semua simbol berasal dari sumber atau dapat ditentukan sehingga tidak akan ada lagi sihir besar di masa depan.

sementara Anda mengecam siapa pun dengan segala bentuk pendapat yang bertentangan.

Itu tidak benar, Anda dapat memiliki pendapat yang bertentangan tetapi Anda tidak dapat mengklaim sesuatu yang benar ketika saya dapat membuktikan sebaliknya.

Untuk seseorang yang mengusulkan perubahan/penambahan signifikan pada set fitur Flutter, saya merasa itu bukan harapan yang tidak masuk akal.

Tapi itulah masalahnya, saya ingin tim Flutter mengimplementasikan DSX tetapi kemudian saya melakukannya sehingga yang mereka butuhkan untuk mengimplementasikan adalah hal-hal umum yang tidak bergantung pada DSX dan DSX bukan satu-satunya penerima manfaat. Mesin browser js mendukung peta sumber yang memungkinkan ekosistem bahasa baru di browser yang diubah menjadi js; itu memungkinkan pembuatan Dart !!! dan beberapa lainnya (Coffeescript, TypeScript, Reason, dll). Dart dapat melakukan hal yang sama sekarang dan mendapat manfaat dari ekosistem yang dibantunya, semua perahu bangkit.

Saya meminta Anda untuk mempertahankan posisi Anda.

Saya sudah melakukannya berkali-kali dan kesimpulannya adalah Plain Dart atau DSX tergantung pada preferensi pengguna; dan yang penting adalah memberikan pilihan daripada memaksa orang satu arah.

pertama dan terpenting adalah mengapa orang harus menggunakannya di atas alternatif.

Saya akan menggunakan DSX karena saya lebih suka, seperti spasi atau tab, ketik definisi sebelum atau sesudah nama variabel. Tidak ada gunanya memperjuangkannya, terima saja bahwa orang memiliki preferensi yang berbeda; ada lebih dari 1 editor pemrograman di luar sana kan?

keakraban bukanlah alasan yang cukup baik

Hanya pendapat Anda, mengapa kami menggunakan pernyataan "jika" di hampir setiap bahasa, pernyataan 'untuk', 'kelas', dan sekarang 'asyn/menunggu'.

Ini bukan tempat yang tepat untuk membahas FLUI. Jika Anda ingin membahas FLUI panjang lebar, proyek ini memiliki papan masalah sendiri, jadi silakan posting di sana.

Sangat bagus, sekarang Anda mendapatkan rasa hormat saya.

Anda bertanggung jawab langsung untuk dua kesempatan terpisah (mendekati tiga) di mana utas ini harus ditutup sementara karena semuanya menjadi terlalu panas.

Masalahnya bahkan jika ditutup lagi, itu tidak akan menghentikan orang untuk meminta kemampuan seperti BEJ.

singkirkan ego Anda, berhentilah menafsirkan kritik sebagai serangan pribadi, dan jawablah pertanyaan-pertanyaan penting.

Saya tidak memiliki ego tetapi saya memiliki temperamen yang pendek sehingga tidak salah ketika seseorang membuat saya kesal (itu langsung keluar). Bukan untuk menyinggung Anda, tetapi pertanyaan Anda tidak penting.

Entah itu, atau berdamai dengan DSX tidak pernah turun dari tanah.

Anda bukan meteran yang digunakan untuk mengukur kesuksesan dan Anda tidak tahu apa yang saya lakukan.

Sobat, Anda mendapatkan pujian dari @jstansbe yang menyampaikan lebih banyak informasi daripada jempol ke atas dan jempol ke bawah pada pujian itu?

Anda tampaknya tidak menangkap sarkasme yang melekat dalam komentarnya. (Dia benar-benar melakukan semua yang saya katakan untuk tidak dilakukan.) Meskipun sedikit menyenangkan dari trolling yang bisa saya hargai, itu tidak pantas di sini. Dan jika, secara kebetulan, dia tulus, maka saya minta maaf atas kecerobohan saya, tetapi pendapat saya tetap berlaku - komentar semacam itu _masih_ tidak pantas di sini.

Jelas bagi saya bahwa Anda tidak terlalu berpengalaman dengan BEJ...

Apakah penafian saya dalam komentar pertama saya di utas ini mungkin memberi tahu Anda?

... Anda benar-benar tidak mengerti cara kerjanya.

Anda menyamakan saya tidak memiliki banyak pengalaman dengan BEJ dan saya tidak tahu cara kerjanya sama sekali? Meskipun saya tidak pernah mengerjakan proyek React yang serius, saya telah melakukan bagian yang adil dari mengutak-atik. Saya sangat memahami cara _bekerja_.

Segala sesuatu yang lain ditangani oleh bahasa host, jadi misalnya: bagaimana menangani impor komponen bernama sama; jawaban: bahasa tuan rumah.

Dan itu masuk akal jika bahasa markup dan bahasa host berbeda. Dengan JSX, bahasa markup dirancang sebagai _ekstensi_ bahasa host. Dengan demikian, JSX dirancang sebagai perpanjangan dari JS, dan itulah mengapa ia bekerja sebaik itu. DSX merupakan implementasi dari BEJ untuk Dart.

Anda tidak melihat masalah di sana? Bahasa markup yang dirancang sebagai perpanjangan dari satu bahasa yang dicurangi menjadi bahasa yang berbeda secara mendasar. Adalah _tidak terhindarkan_ karena ada banyak masalah, kasus tepi, dan pertimbangan.

Anda lihat jika Anda memisahkan markup dan pemrograman ke dalam file terpisah, Anda mulai menduplikasi pemrograman di dalam markup dengan konstruksi sederhana untuk 'jika', dll. Anda akhirnya membangun bahasa pemrograman deklaratif di dalam markup yang tidak pernah bisa sekuat bahasa pemrograman utama.

Pertama, seluruh gagasan di balik pemisahan markup dan pemrograman adalah, jika Anda melakukannya dengan benar, ada pemisahan yang jelas antara keduanya yang menghasilkan duplikasi _no_.

Kedua, jika Anda melakukan sesuatu yang jauh lebih kompleks daripada if s dan for s dalam kode UI Anda (yang merupakan konstruksi yang dapat dengan mudah ditangani dalam banyak solusi markup), maka saya berpendapat bahwa itu tandanya ada yang salah dengan desainmu. Sesuai prinsip desain MVC/MVVM, jika Anda memasukkan logika kompleks dalam konstruksi UI Anda, itu adalah tanda potensial kode bau dan Anda harus mempertimbangkan desain ulang dengan serius.

(Itu bukan untuk mengatakan bahwa Anda _tidak_ menulis UI deklaratif dalam mode MVVM menggunakan JSX, tetapi itu hanya sesuatu yang mengundang masalah untuk mendapatkan sedikit tujuan. Mengapa menggunakan sesuatu di mana Anda _dapat_ menulis kode yang sesuai standar ketika Anda dapat menggunakannya sesuatu yang mempersulit penulisan kode yang _bukan_?)

Itu tidak benar, Anda dapat memiliki pendapat yang bertentangan tetapi Anda tidak dapat mengklaim sesuatu yang benar ketika saya dapat membuktikan sebaliknya.

Anda belum "membuktikan" apa pun. Anda telah memberikan banyak klaim subjektif yang belum didukung dengan logika yang mendukung. (Meskipun untuk kredit Anda, posting terbaru ini adalah peningkatan besar.)

Tapi itulah masalahnya, saya ingin tim Flutter mengimplementasikan DSX tetapi kemudian saya melakukannya sehingga yang mereka butuhkan untuk mengimplementasikan adalah hal-hal umum yang tidak bergantung pada DSX dan DSX bukan satu-satunya penerima manfaat.

Anda masih meminta mereka untuk melakukan hal-hal yang tidak sepele, jadi Anda bertanggung jawab untuk meyakinkan mereka dan kita semua mengapa mereka harus melakukannya dan mengapa sangat penting bahwa mereka harus menekan hal-hal lain dalam daftar tugas mereka.

Mesin browser js mendukung peta sumber yang memungkinkan ekosistem bahasa baru di browser yang diubah menjadi js; itu memungkinkan pembuatan Dart !!!

Dalam sifat JS sendiri hal seperti itu mudah dilakukan (secara relatif), sedemikian rupa sehingga Dart jauh dari satu-satunya bahasa yang memiliki transpiler ke JS. Seperti yang telah saya tunjukkan berkali-kali, Dart bukan JS. Ini statis dan diketik dengan kuat, artinya banyak hal yang mudah dilakukan di JS sangat rumit di Dart.

Saya akan menggunakan DSX karena saya lebih suka, seperti spasi atau tab, ketik definisi sebelum atau sesudah nama variabel. Tidak ada gunanya memperjuangkannya, terima saja bahwa orang memiliki preferensi yang berbeda; ada lebih dari 1 editor pemrograman di luar sana kan?

Dengan logika itu, saya harus membuat solusi UI di mana Anda mendefinisikan konstruksi menggunakan braille yang disandikan hex. Maksud saya, jika semua yang benar-benar penting adalah preferensi pribadi, yang perlu saya katakan untuk mempertahankan keberadaannya adalah bahwa "beberapa orang lebih menyukainya", bukan?

Anda sedang mengembangkan alat yang Anda maksudkan untuk digunakan orang lain, jadi Anda memerlukan alasan di luar "beberapa orang mungkin menyukainya" untuk membuat diri Anda meyakinkan. Jika Anda tidak dapat mengungkapkannya dengan kata-kata _mengapa_ mereka harus menggunakannya untuk hal lain, lalu apa yang membuat Anda percaya bahwa mereka akan menggunakannya? Dan apa yang mendorong Anda untuk _memastikan_ bahwa mereka akan melakukannya ketika merancang set fitur DSX?

Hanya pendapat Anda, mengapa kami menggunakan pernyataan "jika" di hampir semua bahasa, pernyataan 'untuk', 'kelas', dan sekarang 'async/menunggu'.

Pertama, kata kunci tersebut (selain async/await ) menjadi leksikon pemrograman umum karena popularitas besar bahasa seperti C dan BASIC selama beberapa dekade. Seperti yang telah saya sebutkan sebelumnya, JSX masih jauh dari terbukti dalam umur panjangnya - sudah ada selama 5 tahun dan belum melihat penggunaan yang signifikan di luar React meskipun opsi tersedia.

Kedua, ada perbedaan besar antara keakraban dan konvensi. if , while , for , struct , class , enum , try/catch/finally , async/await ... itu semua adalah cara yang bagus untuk merepresentasikan sebuah konsep secara verbal. Ada alasan untuk mempertahankan menggunakan kata kunci tersebut di luar mereka hanya menjadi apa yang orang kenal - mereka masuk akal secara konseptual. (Tentu saja, itu tidak berarti bahwa mereka adalah konstanta. Beberapa bahasa melakukan if ... then . Beberapa melakukan if ... elif sementara yang lain melakukan if ... else if dan yang lain melakukan if...endif . Beberapa melakukan foreach , yang lain melakukan from . Dan seterusnya, dan seterusnya.)

Sedangkan argumen untuk menggunakan BEJ karena "akrab" tidak masuk dalam kategori yang sama. JSX adalah salah satu cara untuk mewakili UI deklaratif, tetapi itu bukan satu-satunya atau yang paling populer. Lebih jauh, itu dirancang untuk digunakan di satu jenis lingkungan, jadi menggunakannya di lingkungan lain dapat mengubah keakraban menjadi hal yang buruk - keakraban membuat mereka mengharapkannya bekerja kurang lebih sama persis dengan cara kerjanya di tempat lain, jadi jika itu bukankah itu mengarah pada keterputusan mental yang merupakan sesuatu yang ingin Anda _hindari_.

Masalahnya bahkan jika ditutup lagi, itu tidak akan menghentikan orang untuk meminta kemampuan seperti BEJ.

Mereka tetap memintanya, dan masalahnya akan dialihkan ke sini sama saja. Saya tidak melihat bagaimana utas ditutup akan mengubahnya.

Anda bukan meteran yang digunakan untuk mengukur kesuksesan dan Anda tidak tahu apa yang saya lakukan.

Baca buku apa saja tentang desain produk. Bab satu selalu tentang membuat pernyataan, manifesto, slogan, segala sesuatu yang nyata dan dapat diungkapkan dalam bahasa Inggris sederhana yang menggambarkan apa produk itu dan mengapa orang harus peduli tentangnya. Ada alasan bahwa bentuk saran paling umum yang diberikan kepada pengusaha amatir adalah membuat "elevator pitch", sesuatu yang dengan jelas dan ringkas mengomunikasikan produk dan undian dalam 30 detik atau kurang. Jika Anda tidak dapat menjelaskan secara singkat mengapa orang harus menggunakan produk Anda, itu adalah tanda bahwa produk tersebut sedang mengalami krisis identitas. Jika orang yang merancang produk tidak dapat menanggapi kritik secara memadai, maka itu akan memberi kesan kurang percaya pada produk mereka sendiri. Kedua hal itu adalah bendera merah besar bagi investor.

Dalam situasi ini, produknya adalah DSX, dan investor adalah pengembang yang mempertimbangkan untuk menggunakannya. Satu-satunya orang yang Anda dukung adalah orang-orang yang tampaknya tanpa syarat akan mendukung apa pun dengan "BEJ" dalam deskripsi. Setiap orang lain di utas ini saya telah melihat pertanyaan apa yang Anda lakukan telah pergi dengan tampaknya tidak yakin mengikuti jawaban Anda.

Saat ini Anda berada pada atau mendekati tingkat konversi 0%, dan _dari situlah saya berasal ketika saya mengatakan bahwa Anda belum cukup menanggapi kritik. Mungkin Anda tidak peduli, tetapi jika Anda serius ingin DSX menjadi plugin markup deklarasi UI yang dapat digunakan dan digunakan dalam proyek dunia nyata, Anda mungkin ingin memulai.

Tapi sekali lagi, mungkin Anda adalah pengecualian.

Oke, percakapan ini telah melampaui jenis diskusi yang kami anggap dapat diterima di komunitas Flutter, jadi saya akan mengunci utas ini dan menutup bug. Harap pertimbangkan untuk membaca https://flutter.io/design-principles/#conflict -resolusi untuk detail lebih lanjut tentang bagaimana kami berperilaku di sini.

Langkah selanjutnya jika ada yang ingin menyumbangkan kode untuk mengatasi masalah ini adalah membuat desain tentang bagaimana membangun integrasi sistem sehingga kita dapat membuat pembuatan kode bekerja dengan Gradle, Xcode, hot reload, dan integrasi dengan aplikasi yang ada. Jika ada yang tertarik untuk mengerjakan ini, jangan ragu untuk menghubungi saya. Kalau tidak, saya berharap ini adalah sesuatu yang akan kami kerjakan awal tahun depan. Setelah kami memiliki mekanisme untuk melakukannya, solusi seperti DSX akan mudah diintegrasikan ke dalam ekosistem Flutter. Kami bahkan dapat menemukan solusi yang harus diintegrasikan secara default. Sementara itu, kami juga sedang menyempurnakan sintaks Dart untuk melihat apakah kami dapat membuat ekspresi UI lebih mudah untuk ditulis.

Saya ingin meminta agar orang-orang tidak membuka bug baru pada topik ini kecuali ada sesuatu yang sangat konstruktif dan baru yang layak untuk diangkat.