Flutter: Pertimbangkan seperti JSX sebagai React Native

Ini sudah lama ditanyakan:
https://github.com/flutter/flutter/issues/11609
Prototipe fungsional yang dikembangkan:
https://spark-heroku-dsx.herokuapp.com/index.html
Itu menunjukkan alternatif dan beberapa manfaat ...

Masalah saat ini dengan DSX adalah tentang integrasi yang tepat dengan alat Flutter untuk memberikan pengalaman pengembang yang hebat dengan debugger, pelengkapan otomatis, dll. bekerja pada 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.

Jika Anda bisa dan ingin membantu, beri tahu saya.

Saya tidak bisa setuju. Terutama menggunakan IDE seperti Kode Dart Anda mendapatkan tag penutup virtual yang membuat cara membaca lebih mudah. Dengan Dart2 di mana Anda dapat menghilangkan new itu bahkan akan menjadi lebih baik.

Saya juga merasa itu membuat Anda enggan untuk membangun pohon Widget yang terlalu besar tanpa mendekonstruksinya menjadi kelas widget yang lebih kecil dan lebih mudah untuk dipelihara.

Saya menggunakan Android Studio. Saya bahkan tidak melihat tag penutup virtual. Meskipun kami memiliki tag penutup virtual, itu lebih rumit daripada HTML yang dibenci semua orang. Dart hanyalah bahasa pemrograman. Orang-orang di Google tidak memahami pentingnya penyederhanaan.

Saya rasa saya juga tidak ingin sintaks seperti JSX tapi ya, saya menggunakan IntelliJ dan sesuatu perlu dilakukan dengan perkakas sehingga kode UI lebih mudah dipahami.

Saya juga merasa itu membuat Anda enggan untuk membangun pohon Widget yang terlalu besar tanpa mendekonstruksinya menjadi kelas widget yang lebih kecil dan lebih mudah untuk dipelihara.

Saya tidak melihat bagaimana ini berbeda dibandingkan dengan JSX... karena pohon semakin besar Anda dapat memecah menjadi sub-pohon yang lebih kecil dengan keduanya.

Saya rasa saya juga tidak ingin sintaks seperti JSX tapi ya, saya menggunakan IntelliJ dan sesuatu perlu dilakukan dengan perkakas sehingga kode UI lebih mudah dipahami.

dan harus mudah dibaca di semua platform dan tidak hanya Intellij; Maksud saya itu harus mudah dibaca di Bitbucket saat meninjau kode; dan itu juga harus valid saat menggunakan editor apa pun; Maksud saya dengan 'anotasi komentar' ini, apa yang terjadi jika seseorang yang menggunakan 'vi' mengetik komentar yang berbeda di sana?

Ini adalah tiruan dari yang terkunci #11609
@sethladd ?

Maaf, Anda seharusnya melihat "tag penutup virtual" di IntelliJ dan Android Studio.

cc @devoncarew untuk memverifikasi versi mana yang mengaktifkannya, atau jika pengguna perlu ikut serta?

Kami berterima kasih atas komentar Anda tentang: sintaks seperti JSX. Kami percaya ada peluang di seluruh bahasa, alat kami, dan plugin untuk membuat pengeditan kode UI lebih mudah.

Ini menipu #11609 tetapi saya ingin @devoncarew atau @mit-mit menambahkan catatan tentang cara mengaktifkan "tag penutup virtual", jika memungkinkan.

Terima kasih!

@JonathanSum , sayangnya label penutup tidak tersedia di Android Studio 3.0. Anda memerlukan setidaknya IntelliJ 2017.3 atau Android Studio 3.1. Android Studio 3.1 saat ini dalam tahap kandidat rilis, dan kami berencana untuk merilis plugin flutter dengan dukungan untuk itu besok.

Terlepas dari percakapan seputar sintaks seperti JSX, kami ingin berupaya membuatnya lebih mudah untuk menulis kode UI di Dart, di IntelliJ / Android Studio dan di VS Code. Itu awalnya pekerjaan label penutup, tetapi juga tampilan Flutter Outline baru-baru ini. Itu menunjukkan struktur metode build() Anda dalam tampilan outline, dan memungkinkan Anda menavigasi widget dan lebih mudah melihat hubungan induk/anak mereka. Itu saat ini tersedia di IntelliJ - kami berharap dapat membawanya ke VS Code juga.

@zoechi - Ini mungkin tipuan; tetapi utas lainnya menjadi panas, dan terkunci. Jadi mereka tidak ada cara untuk berkontribusi pada percakapan itu. Saya tidak berpikir Anda harus menutup utas ini sebagai penipuan hanya karena Anda tidak suka orang meminta fitur. Ini mungkin harus menjadi utas baru untuk tanggapan bagi orang baru yang datang dan meminta dukungan BEJ (atau fungsi serupa).

@sethladd - Tolong jangan kunci utas ini; Saya pikir meminta komunitas mendiskusikan pro dan kontra tentang metode tata letak alternatif berguna. Saya akan berpartisipasi dalam #11609 seandainya tidak dikunci.

Saya berasal dari latar belakang NativeScript. Saya harus mengatakan ini adalah satu area di mana saya merasa NativeScript jauh lebih mudah digunakan daripada Flutter. Saya bisa membuat layar yang cukup rumit bekerja dalam waktu kurang dari 5 menit dan dengan mudah mengulangi desain dengan cepat. Kemudian tambahkan kode yang menjalankan layar.

Di NativeScript kami sebenarnya memiliki file-file berikut:

• screen.js / screen.ts (.ts diubah menjadi .js jika Anda lebih suka TypeScript). Ini adalah logika utama untuk layar yang Anda tampilkan.
• screen.css (atau screen.android.css dan/atau screen.ios.css ) yang merupakan versi CSS yang jauh lebih terbatas tetapi mendukung hal-hal seperti tinggi, lebar, warna, latar belakang, dll. Sebagian besar waktu file css tunggal hanya diperlukan, tetapi kadang-kadang jika Anda melakukan sesuatu yang aneh, Anda mungkin memisahkan css Anda untuk android dan ios. Ini memiliki dukungan penuh untuk Kelas, Elemen, dan id Jadi saya dapat melakukan TextArea.Login #Password dan sebenarnya akan membatasi dirinya hanya pada rantai elemen spesifik itu.
• screen.xml (Lagi atau screen.android.xml dan/atau screen.ios.xml ) - Ini adalah tata letak layar. Anda BISA membuat kode tata letak dalam JS jika Anda mau (pada dasarnya seperti flutter); tetapi XML jauh lebih mudah. Contoh:

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

Hal yang menarik adalah bahwa ActionBar adalah komponen khusus halaman saja (yaitu khusus untuk Halaman saja); jadi pada dasarnya yang terjadi adalah halaman XML parser See; membuat Elemen Halaman baru; kemudian membuat komponen ActionBar yang kemudian menjalankan fungsi builderChild pada komponen Halaman; komponen halaman menimpa builderChild default dan melihat apakah turunannya adalah ActionBar; jika memang; kemudian secara internal menetapkannya ke variabel yang tepat; jika tidak, sisanya dilewatkan melalui induk/super yang kemudian menetapkannya ke komponen "anak" atau "anak-anak" secara otomatis. Sistem build sangat serbaguna karena setiap komponen dapat menggunakan fungsi builderchild induk atau menimpanya untuk melakukan item tambahan seperti dukungan <Label>Hi</Label> dan menetapkannya ke nilai Teks secara otomatis. Ini membuat tata letak menjadi sangat mudah untuk dijalankan tanpa kode apa pun.

Karena sebagian besar editor memiliki kemampuan pengeditan XML yang baik, maka secara otomatis diwarnai dan dengan definisi xsd yang tepat, intellij (& vscode) melakukan pemeriksaan otomatis dan dukungan konteks terbatas.

Sekarang secara teknis semuanya sebenarnya adalah komponen JavaScript; sehingga Anda dapat melakukan semua ini secara manual (seperti yang dilakukan Flutter); tapi menurut saya mudahnya meletakkan layar di NativeScript adalah hal yang sepele. Dan Anda tidak memerlukan JS atau CSS saat pertama kali memulai; maka Anda dapat menambahkan CSS (biasanya Anda tidak membuat kode keras dalam tata letak properti berbasis css; tetapi Anda bisa jika mau).

Hal yang menyenangkan tentang ini; apakah ini memungkinkan pengembang Web untuk terjun langsung dengan pelatihan ulang yang sangat sedikit (jika ada). Faktanya; karena perendernya yang fleksibel dan berbasis JS -- NativeScript sebenarnya mendukung Angular dan Vue -- sehingga Anda benar-benar dapat berbagi hampir 95% dari basis kode antara web, dan aplikasi seluler Anda jika Anda menggunakan Angular atau Vue. Karena menggunakan komponen OS Asli seperti reaksi asli (bukan tampilan web seperti cordova); itu benar-benar sistem lintas platform yang layak (itu lebih baik daripada React Native). Namun, saya dapat melihat di mana ada beberapa kekuatan yang dimiliki Flutter yang menjadikannya alat pelengkap yang bagus untuk beberapa pengembangan seluler karena ada beberapa aplikasi yang NativeScriptnya lebih buruk dan beberapa masih jauh lebih baik untuk dan berdasarkan tanggapan saya masalah dari Ian; akan tetap menjadi alat yang jauh lebih baik untuk area tersebut.

Lebih baik buka utas yang terkunci itu dan salin komentar ini di sana sehingga kami memiliki riwayat diskusi lengkap.

@JonathanSum ini bukan tentang apakah ada yang menginginkan atau tidak menginginkan fitur tersebut,
apakah ini tempat untuk berdiskusi panas tentangnya. Saya kira reddit atau serupa adalah tempat yang lebih baik.

@cbazza - saya tidak setuju; tetapi Anda harus sangat berhati-hati di masa depan untuk tidak menyindir hal-hal tentang orang. Itu hanya mengobarkan diskusi, tidak peduli seberapa bodohnya Anda percaya mereka sedang.

@zoechi - Sebenarnya saya percaya setiap diskusi tentang fitur baru harus ada di sini. Sejarah harus dipertahankan sehingga ketika John Doe datang sebulan dari sekarang dan mencari tentang fitur XYZ dia dapat :+1: fitur yang ada dan/atau berkontribusi padanya.

Saya tidak berpikir utas itu benar-benar terkunci selama ini karena komentar saya. Jika apa yang saya katakan sangat buruk, bagaimana saya bisa mengomentari yang lainnya, seperti misalnya utas ini?

Utas dikunci karena tim Flutter tidak tertarik melakukan ini dan hanya ingin orang-orang berhenti membicarakannya.

Mari kita tetap diskusi dalam masalah ini terfokus pada kasus penggunaan dan contoh untuk fitur seperti BEJ.

Sebenarnya jika NativeScript sebagus itu, mengapa repot-repot dengan Flutter daripada mencoba membuat Flutter NativeScript seperti itu.
Saya berasal dari Platform berbasis XML (Bentuk Xamarin) dan berpikir pada awalnya mungkin lebih sulit untuk mendesain dalam kode tetapi bukan itu masalahnya.
Sebaliknya, sangat mudah untuk memecah desain Anda di kelas terpisah yang mudah dirawat.

BEJ sedang merancang dalam kode !!!

@sethladd

Mari kita tetap diskusi dalam masalah ini terfokus pada kasus penggunaan dan contoh untuk fitur seperti BEJ.

Oke langsung saja kita bahas tentang desain DSX saya yang bisa dilihat disini :
https://spark-heroku-dsx.herokuapp.com/index.html

Ini memberikan pemetaan langsung ke cara widget saat ini dibangun, namun menyediakan rasa seperti JSX yang sangat ringan dan akrab bagi pengembang Bereaksi. Apakah ada yang kurang dalam desain ini? Bisakah desain ini menghasilkan semua kemungkinan widget di alam liar?

Aturan praktisnya, jika Anda merasa satu tanda seru tidak cukup, Anda mungkin harus menjauh dari keyboard dan istirahat.

Saya pendatang baru di Flutter, hanya memiliki sedikit pengalaman dengan Android dan Java, dan saya harus mengatakan bahwa saya menemukan apa yang ditawarkan Flutter jauh lebih baik daripada yang diusulkan di sini. Saya cenderung menemukan bahwa XML jelek dan berat. Jauh lebih indah memiliki karakter penutup tunggal, daripada lautanyang membuat kode saya 5x lebih lama, kebencian saya saat mengedit XML Android, dan hanya tag penutup virtual yang didukung oleh sebagian besar IDE yang digunakan orang. Ini sangat berguna saat merancang struktur yang lebih panjang. XML bersarang yang rapi menyediakan tidak lebih besar dari kerugian lainnya, menurut pendapat saya, terutama ketika 'anak:/anak-anak:' melakukan pekerjaan yang hampir sama baiknya. Dart sangat bersih, dan itulah alasan saya sangat menyukainya. Saya akan sangat kecewa jika ini hancur.

Saya tahu React melakukannya seperti ini, tetapi terakhir kali saya memeriksanya, tempat ini bertuliskan Flutter. Hanya karena React bukan berarti kami harus melakukannya - Anda bukan satu-satunya yang melompat ke sini! Saya sangat setuju dengan semua poin yang dibuat @escamoteur . Saya tidak melihat gunanya menambahkan bahasa lain yang perlu ditangani orang saat menggunakan Flutter. Kami sudah menggunakan Dart untuk memprogram sebagian besar, kami tidak perlu banyak hal lain untuk dikuasai! Konsistensi dan kesederhanaan harus dihargai.

Beberapa komentar dari DSX vs cuplikan Dart yang dihasilkan:

1. Subjektif: Saya tidak melihat peningkatan keterbacaan yang bagus. Verbositas serupa - jika tidak sedikit lebih lama. Plugin Dart IDE menyediakan tag penutup otomatis, yang mencerminkan tag penutup markup deklaratif. Jika JSX dirancang dalam kode, maka saya tidak melihat bagaimana widget di Dart tidak.

2. Beberapa properti di <vars>

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

Mampu mendefinisikan gaya global yang menggabungkan beberapa properti adalah ide yang bagus.
Namun ketika saya melihat kembali pengalaman flutter sederhana saya, saya tidak melihat di mana saya akan menggunakan ini.

Untuk Text tampaknya sebagian besar dari apa yang saya perlukan untuk digunakan kembali didefinisikan dalam TextStyle , daripada campuran beberapa properti. Mungkin Anda dapat menemukan contoh lain selain Text di mana bukan itu masalahnya.

Melihat TextStyle , saya menemukan saat ini yang tidak dapat diubah + copy() sangat bagus untuk digunakan kembali dan ditulis di Dart:

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

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

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

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

Untuk Container yang dapat digunakan kembali dengan berbagi gaya yang sama, saya pikir membuat widget stateless khusus berfungsi lebih baik daripada <vars> yang ditentukan secara eksternal. Sebagian besar waktu, saya juga ingin padding, tinta, pendengar gerakan atau bayangan.

Untuk setiap kasus tersebut, saya perlu menulis Container dengan widget lain: Material , Padding , Center dll. Jadi jika saya harus membuat widget "wadah" kustom yang dapat digunakan kembali, saya tidak melihat banyak keuntungan untuk memiliki gaya <vars> eksternal yang hanya akan mendefinisikan properti dari satu widget dalam hierarki widget yang dapat digunakan kembali.

Saya tidak melihat "semuanya adalah widget" Flutter berfungsi dengan baik dengan gaya "banyak properti".

1. Tidak disorot dalam contoh DSX Anda saat ini: Bagaimana Anda membuat kode antarmuka dengan widget dinamis? Artinya: cara menampilkan atau tidak menampilkan beberapa widget tergantung pada suatu kondisi.

Saat melakukan desain di Dart, mudah dan nyaman untuk menambahkan atau tidak widget tertentu ke dalam children .
Ini juga sangat nyaman untuk secara dinamis membungkus widget dengan yang lain. Itu membuat fungsi build() lancar dan mudah dimengerti.

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

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

    children.add(wb);

@SirComputer1 proposal DSX adalah tambahan, cara saat ini tidak berubah jadi jika Anda tidak menyukainya, jangan gunakan, lanjutkan seperti Anda hari ini.

Hal <var> hanya dilakukan untuk demo karena saya tidak ingin mengurai Dart penuh. Solusi terakhir tidak akan menyertakan <var> tetapi akan menggunakan variabel panah apa pun. Juga '@' hanya dilakukan untuk demo untuk memudahkan penguraian. Solusi akhir tidak akan memasukkannya.

Jangan lupa bahwa apa pun di file itu adalah kode Dart normal Anda, jadi Anda dapat menggunakannya untuk yang lainnya.

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

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

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

    children.add(wb);

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

Mari berhenti membandingkan DSX dengan cara saat ini, yang satu tidak bersaing dengan yang lain. Beberapa orang akan lebih memilih BEJ dan utas ini untuk mereka. Yang ingin saya ketahui adalah bagaimana saya dapat meningkatkan DSX untuk menangani hal-hal yang tidak akan berhasil.

@escamoteur - Saya tidak cenderung menggunakan palu sebagai obeng. Saya mengevaluasi teknologi yang berbeda dan menggunakan yang tepat untuk kasus penggunaan yang tepat. Itu tidak berarti bahwa hal-hal tidak dapat diubah menjadi lebih baik di setiap platform. :nyengir:

Sebagai contoh; integrasi plugin pihak ketiga. NativeScript benar-benar raja atas setiap platform lintas lainnya. Tidak ada hal lain yang mendekati NativeScript dari jarak jauh; dan integrasi pihak ketiga. Saya memiliki klien yang bertanya tentang penggunaan https://github.com/vipulasri/Timeline-View . Flutter hampir tidak mungkin; NativeScript beri saya beberapa jam dan itu akan berfungsi seperti kontrol NS lainnya mungkin bahkan dengan pengikatan data yang berfungsi penuh. Di sisi lain, flutter memiliki beberapa kekuatan serius di mana NS menandai...

Gunakan alat yang tepat untuk pekerjaan itu. :nyengir:

Saya cenderung menyukai tata letak layar berbasis XML; tapi saya mengerti mengapa orang tidak. Menambahkan kemampuan untuk membangun berbasis XML TIDAK berarti menghilangkan metode yang ada; itu hanya pelengkap ; pilihan. Bagi Anda yang tidak repot-repot membaca, saya dapat melakukan rantai panggilan yang sama di NS yang kita lakukan di flutter; tetapi menggunakan xml jauh lebih sedikit pengetikan dan lebih mudah saya baca. Setiap orang punya preferensinya masing-masing...

Saya sebenarnya telah berpikir untuk menambahkan perender berbasis XML ke Flutter sebagai POC; tapi saya tidak punya waktu luang. Saya hanya ingin berkontribusi pada percakapan dan mengatakan saya ingin melihat langkah ini maju; tapi saya sebenarnya tidak mengharapkan tim inti untuk mengerjakannya. Saya pikir format NS XML dapat dilakukan sebagai proyek komunitas di mana kita yang peduli (yaitu mungkin saya : nyengir:) akan bersedia mengerjakannya. Namun, kekhawatiran terbesar saya @sethladd -- adalah jika saya menghabiskan banyak waktu di patch; apakah akan ditolak karena seseorang di tim inti sangat menentang kemampuan ini. Itulah yang ingin saya pahami terlebih dahulu sebelum saya menghabiskan waktu untuk ini...

@NathanaelA Perspektif yang fantastis !!!!!!! dan lihat saya menggunakan banyak tanda seru ;-) Anda benar-benar memakukannya di kepala.

Ya, saya dapat melakukan DSX, tetapi saya memerlukan cara untuk mengintegrasikannya dalam sistem build Flutter saat ini, jadi saya memerlukan komitmen dari tim Flutter saat ini sebelum melanjutkan. Integrasi IDE hampir sepele pada VS Code tetapi tidak begitu banyak dengan Intellij (kecuali Google memiliki akses ke dukungan Intellij JSX).

@zoech , Tidak! Saya pikir ini adalah masalah. Saya ingat mengembangkan aplikasi Android dengan Java dan XML asli. Kami masih menggunakan XML untuk bagian bahasa UI. Saya pikir menggunakan Dart untuk logika dan UI agak aneh, dan masalah ini agak jelas. selanjutnya, saya hanya berharap Google akan menambahkan ide UI React ke dalam flutter. Bagian UI dari React sangat kuat dan ringkas.

@JonathanSum Saya telah melihat banyak komentar tentang ini.
Bagi saya itu masih terlihat seperti sesuatu yang diinginkan orang karena mereka enggan mengubah kebiasaan mereka, bukan karena itu menguntungkan platform.

Beberapa orang menyukai jsx, Beberapa orang tidak. Mengapa tidak mendukung dua cara untuk mengimplementasikan UI. Anda dapat menulis sintaks seperti jsx, dan akhirnya akan dikompensasi dengan sintaks asli yang bergetar, mengapa tidak mendukung?

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

@zoechi

Bagi saya itu masih terlihat seperti sesuatu yang diinginkan orang karena mereka enggan mengubah kebiasaannya

Ini adalah pengamatan yang adil, tetapi bukankah lebih baik bagi Flutter untuk menjadi enabler dan menghilangkan sebanyak mungkin gesekan bagi orang-orang (di luar Google) untuk mengadopsi Flutter? Perilaku penjaga gerbang ini tidak memenangkan hati dan pikiran para pengembang.

@yuu2lee4

Beberapa orang menyukai jsx, Beberapa orang tidak. Mengapa tidak mendukung dua cara untuk mengimplementasikan UI. Anda dapat menulis sintaks seperti jsx, dan akhirnya akan dikompensasi dengan sintaks asli yang bergetar, mengapa tidak mendukung?

Pertanyaan yang bagus. Mengingat bahwa saya melakukan semua pekerjaan di DSX, yang sama seperti JSX, dan @Hixie secara pribadi mengirimi saya email bersemangat tentang kemajuannya, saya tidak mengerti mengapa tidak mendukungnya, saya tidak mengerti mengapa tidak mengulurkan tangan dan berkata 'Apa yang bisa saya lakukan untuk membantu Anda? Apa yang menghalangi Anda untuk melakukan ini?'

sejujurnya, saya mulai berpikir arah ini ke arah yang sama seperti yang sebelumnya ... yang tidak akan membantu ...

@cbazza

@Hixie secara pribadi mengirimi saya email bersemangat tentang kemajuannya..

Jadi mengapa Anda tidak melanjutkan dan orang lain yang dapat membantu juga harus bergabung dan membantu? Jika kita tidak ingin ini muncul seperti utas lainnya...Saya pikir kita harus mendiskusikan apa bloknya, bagaimana kita melakukannya dan bagaimana kita membuatnya bekerja dan meletakkannya di sana... dan Saya juga berpikir tim flutter dan dart dalam beberapa cara telah memulai beberapa pekerjaan untuk mengurangi sifat verbose dari penulisan UI ...
Mungkin tim mungkin tidak dapat bergabung sekarang, tetapi saya percaya jika itu adalah tujuan yang layak yang saya yakini meskipun bagi saya baik-baik saja pendekatan apa pun ... mereka akan menyusul di beberapa titik ... jadi @cbazza mari lanjutkan dengan apa Anda melakukan dan mengeluarkannya ... seperti yang dilakukan orang ini http://mutisya.com/ di hari-hari awal meskipun saya tidak tahu kondisinya ... Saya juga tahu @NathanaelA dapat membantu karena dia telah berkontribusi beberapa hal dan alat yang benar-benar luar biasa untuk Nativescript ... Mari kita keluarkan untuk memberi lebih banyak opsi kepada pengembang ...

@MichaelSowah
Alasan untuk tidak menginvestasikan lebih banyak waktu untuk ini adalah seperti yang dikatakan @NathanaelA :

Namun, kekhawatiran terbesar saya @sethladd -- adalah jika saya menghabiskan banyak waktu di patch; apakah akan ditolak karena seseorang di tim inti sangat menentang kemampuan ini. Itulah yang ingin saya pahami terlebih dahulu sebelum saya menghabiskan waktu untuk ini...

Oke, inilah yang saya miliki:
(a) Pra-prosesor yang memasukkan file *.dsx dan mengeluarkan file *.dart.

Inilah yang saya butuhkan:
(1) Seseorang untuk mengurus integrasi 'VS Code'. Dari penyelidikan saya itu terlihat sederhana.
(2) Seseorang untuk mengetahui cara menambahkan kemampuan pra-prosesor ke dalam sistem build Flutter sehingga proses debug akan berfungsi dengan baik. Maksud saya, langkah kode akan ada di file *.dsx melalui sesuatu seperti peta sumber, dll.

Setelah 2 item di atas selesai, kami memiliki sistem ujung ke ujung awal untuk membuat bola bergulir. Ada pengambil?

Jadi seperti yang Anda lihat di atas, (1) & (2) memerlukan perubahan pada kode Flutter yang dapat ditolak oleh tim Flutter sehingga tanpa dukungan/komitmen, fitur ini macet.

@cbazza hebat jadi mari kita minta salah satu anggota tim flutter di sini untuk memberi tahu kami apakah mereka mau menerima satu dan dua...jadi siapa yang bisa kami dapatkan di sini untuk membantu kami maju...?

Untuk (2) Saya pikir cara terbaik adalah menghubungi tim Dart, mungkin melalui [email protected] atau pelacak masalah mereka? Saya yakin salah satu tujuan Dart 2 adalah menciptakan infrastruktur untuk lebih banyak eksperimen dengan bahasa dan membiarkan komunitas membuat eksperimen seperti DSX. Mungkin @anders-sandholm @mit-mit atau @mraleph dapat mengarahkan Anda ke arah yang benar.

@sethladd Terima kasih atas tanggapan cepatnya dan bisakah Anda juga menyalin nara sumber dan mungkin
tim panah ke utas ini juga
@cbazza, bisakah Anda ikut serta agar wacana ini berjalan dengan nara sumber yang terdaftar.
sehubungan dengan integrasi 'Kode VS', saya yakin begitu kita mendapatkan 2 dari jalan mungkin @DanTup mungkin tertarik untuk membantu

Hanya beberapa pemikiran

Oke, inilah yang saya miliki:
(a) Pra-prosesor yang memasukkan file *.dsx dan mengeluarkan file *.dart.

Ini mungkin semua yang Anda butuhkan untuk memulai, itu dan pengamat file untuk membangun kembali perubahan - lihat FileSystemEntity . Tantangannya adalah tata bahasa .dx ini adalah superset dari dartlang, jadi Anda juga harus mengurai semua Dart. Ini akan menjadi rumit karena tidak seperti JavaScript, < dan > digunakan di lebih banyak tempat. Saya pikir parser Dart sudah ditulis di Dart, dan di suatu tempat di dalam repo SDK, tapi saya tidak tahu di mana

1. Untuk integrasi vscode dan Intellij, ini bukan sistem build flutter, ini adalah penganalisis panah yang Anda inginkan. Saya pikir Anda dapat membuat plugin untuk ini yang akan menggunakan dx, mengubahnya menjadi dart, lalu memetakan hasilnya kembali ke file asli. Ini adalah cara kerja plugin penganalisis sudut untuk menyediakan hal-hal seperti pelengkapan otomatis ke file html.

2. Anda ingin build runner , ini adalah paket yang jauh lebih canggih untuk melakukan a .

@MichaelSowah
Luar biasa jadi saya kira Anda menggunakan (1) & (2) sehingga saya bisa fokus pada transpiler?

@jonahwilliams
Saya tahu, penguraian panah penuh akan rumit dan tidak terlalu diperlukan saat ini karena saya selalu dapat menggunakan penanda saya untuk rilis pertama (https://spark-heroku-dsx.herokuapp.com/index.html)

Tapi satu hal yang pasti, kita membutuhkan IDE dan debugger untuk bekerja dengan baik atau orang lain tidak akan menggunakan DSX karena trade off-nya terlalu banyak. Maksud saya 'gunakan DSX dan lupakan debugging simbolis', bukan tawaran yang sangat menarik. Itu juga alasan saya ingin setidaknya satu IDE didukung dan Kode VS akan sesederhana pie (karena sudah mendukung JSX dalam file json definisi Typescript & Javascript sintaks)

re: IDE dan debugger, mungkin dengan mengimplementasikan fitur ini di dalam infrastruktur Dart 2 dan "common front end", Anda harus dapat mengaktifkan level tumpukan yang lebih tinggi untuk mengetahui DSX. Saya merekomendasikan bekerja dengan tim Dart dan mempelajari cara menjelajahi berbagai bagian Common Front End dan API-nya.

@MichaelSowah saya melakukan CC orang-orang dari Dart di https://github.com/flutter/flutter/issues/15922#issuecomment -376960770

@NathanaelA apakah Anda tertarik untuk bergabung di (1) & (2) karena sekarang kami jelas mendapat dukungan dari tim

Tidak yakin; saat ini -- saya dibanjiri beberapa proyek klien. Tapi saya akan bersedia untuk melihat bagaimana menghubungkan ke pipa kompilasi dan berpotensi membuat peta sumber. (yaitu 2) Tapi mungkin perlu beberapa minggu sebelum saya bisa melakukannya.

@NathanaelA Tidak ada terburu-buru atau apa pun jadi Anda baik :-)

Jika DSX hanyalah Dart + Virtual closing tag maka tidak ada manfaat nyata. Salah satu manfaat dengan dart adalah kita dapat menggunakan fungsi dan variabel untuk membuat bagian dari widget dan meningkatkan keterbacaan.

Juga dengan DSX dan pre-processor, kita akan kehilangan kemampuan hot reload sub-detik, kan @cbazza ?

Tidak, DSX seperti JSX dan sama sekali berbeda dari 'Tag penutup Dart + Virtual' yang dapat Anda lakukan hari ini dengan pohon widget dan IDE khusus Dart Anda.

DSX dijelaskan di sini:
https://spark-heroku-dsx.herokuapp.com/index.html

DSX adalah Dart jadi semua manfaat Dart seperti yang Anda jelaskan ada di sana. Orang yang akrab dengan BEJ akan langsung mendapatkannya dan menyukainya.

Tidak, Anda tidak akan kehilangan apa pun, tidak ada perubahan untuk file *.dart normal yang Anda buat, Anda masih memiliki hot reload sub-detik.
Sekarang jika Anda memiliki file *.dsx, itu akan terlebih dahulu ditranspilasikan ke *.dart dan proses itu lebih cepat daripada yang bisa saya kedipkan !!! Jadi itu tidak akan terlalu mencolok bagi pengguna DSX.

Sebelum yang ini ditutup lagi, izinkan saya menyelesaikan apa yang ingin saya sampaikan terlebih dahulu.
UI bagian flutter saat ini adalah masalah, dan saya tidak mencoba menjual ide React.
Karena struktur UI dari flutter sangat sulit untuk diwujudkan dalam pikiran dengan tanda kurung tersebut, kami benar-benar membutuhkan sesuatu untuk ditingkatkan. Saya sangat menyarankan untuk menggunakan react native atau semuanya seperti React. React tidak hanya membuat orang mudah dibaca, tetapi juga memisahkan kode UI besar dalam grup yang berbeda. Hasilnya, saya dapat mengelola kode UI kompleks yang besar dengan lebih cepat dan membacanya dengan mudah. Di sisi lain, dengan banyak pohon dengan tanda kurung hanya bergetar, saya tidak tahu cara membacanya.

@JonathanSum apakah Anda mencoba versi terakhir Android Studio (3.1) dengan label penutup?

@14n Ya, saya melihat tag dan komentar penutup virtual itu.

Pohon widget besar seperti XML bisa sulit dibaca seperti hal besar lainnya, baik itu Dart, JSON, YAML, atau JSX. Sepertinya JSX sendiri tidak menyelesaikan masalah keterbacaan.

Saya tidak punya masalah membaca pohon widget berukuran waras dengan sintaks saat ini. Plus Flutter mempromosikan komposisi sehingga setelah widget tertentu menjadi terlalu besar, mudah untuk membaginya menjadi beberapa widget yang lebih kecil.

Pendapat subjektif tentang format DSX yang diusulkan:

1. Secara visual tidak ada manfaat nyata dan sekali lagi - membaca pohon XML besar bisa sama menyakitkannya, jadi sepertinya itu tidak menyelesaikan masalah. Mempromosikan praktik Kode Bersih, misalnya, sebenarnya akan mengatasi masalah keterbacaan, tetapi praktik ini dapat diterapkan ke (hampir) sintaks apa pun.
2. Perlu mempelajari DSL/sintaks lain. Saya sangat-sangat-sangat suka bahwa saya hanya perlu tahu satu sintaks - Dart - untuk melakukan semuanya - tata letak, gaya, animasi, logika. Ini jauh lebih ramah bagi pendatang baru dan pengembang berpengalaman dibandingkan dengan apa yang terjadi pada Web dengan html/js/jsx/ts/coffee/css/sass/scss. Bahkan, saya bahkan menganggap ini sebagai manfaat utama Flutter dibandingkan platform lain.

Yang mengatakan, saya percaya ada ruang untuk perbaikan untuk Dart menjadi lebih ekspresif ketika digunakan untuk menggambarkan UI, meskipun saya lebih suka untuk menjadi lebih dari ekstensi untuk sintaks Dart yang ada daripada DSL yang benar-benar baru.

Tolong berhenti mencoba membuat Flutter menjadi seperti "hal baru yang panas". Ini adalah hal baru yang panas dengan sendirinya, biarkan ia mengeksplorasi paradigma baru.

@naiveaiguy saya pikir ini panas. Itu membuat saya sangat produktif dan memungkinkan saya untuk berbagi kode dengan aplikasi browser dan server.
Saya tidak perlu beberapa hype untuk satu musim panas. Saya membutuhkan sesuatu yang memungkinkan saya untuk menyelesaikan pekerjaan saya.
Itulah tepatnya yang dilakukan Flutter dan Dart.

Pikiran saya di cermin ini apa yang @pulyaevskiy katakan di https://github.com/flutter/flutter/issues/15922#issuecomment -377666972. Semua contoh yang saya lihat yang tidak dapat dibaca biasanya dapat dirapikan dalam kode yang ada dan saya pikir mungkin ada lebih banyak perubahan kecil yang dapat dilakukan pada Dart (mirip dengan menghapus new/const) yang dapat meningkatkannya lebih lanjut . Memelihara seluruh kumpulan file lain dengan sintaks lain dan satu set kode perkakas yang sama sekali baru tampaknya seperti biaya tinggi untuk apa yang saya yakini keuntungannya relatif kecil (FWIW, saya juga lebih suka Bereaksi tanpa JSX).

Saya tidak tahu apakah itu benar-benar berlaku di sini karena dsx yang diusulkan memungkinkan kode Dart normal juga, tetapi setiap kali saya mendengar seseorang berbicara tentang sintaks baru, saya teringat akan posting hebat ini oleh Gilad A DOMain of Shadows . Hal-hal ini selalu lebih rumit daripada yang dipikirkan orang. Ini tidak sesederhana hanya mentranspilasikan kode karena orang akan mengharapkan kesalahan waktu nyata, penyelesaian kode, refactors, tooltips, dll. - ini adalah pekerjaan besar.

Daripada transpiler yang berfungsi, saya akan lebih tertarik untuk melihat perbandingan tiga arah antara beberapa kode yang dianggap sulit dibaca, bagaimana tampilannya dalam sintaks yang diusulkan ini, dan bagaimana tampilannya jika Anda dapat membuat perubahan apa pun pada sintaks Dart yang ada tanpa mengganti semua tanda kurung. Misalnya, sesuatu yang saya suka di React adalah anak-anak yang diteruskan sebagai varargs sebagai parameter terakhir - saya pikir child dan children menambahkan banyak kebisingan di Flutter - mungkin ada ruang untuk perbaikan di sana . Ada juga beberapa diskusi tentang apakah mengubah pemformatan atau menyorot nama kelas Widget dapat membantu. Sepertinya refactor Extract Widget sedang dalam perjalanan untuk dengan mudah memecah metode build besar. Dan tentu saja, IntelliJ memiliki tampilan Flutter Outline yang memungkinkan Anda melihat kode di pohon dan pilihan tetap sinkron dengan posisi kursor di editor (dan saya sangat berharap untuk mendapatkan sesuatu yang mirip dengan VS Code, meskipun diblokir oleh beberapa fitur VS Code seperti ini jadi jangan ragu untuk 👍 it!).

@pulyaevskiy
Saya mengerti apa yang Anda katakan tetapi eksperimen itu bagus, ini adalah jalan menuju evolusi. Bahkan jika eksperimen saya dengan DSX gagal, saya berharap orang lain bereksperimen dengan banyak hal lain dan menyatukan ide-ide terbaik di luar sana untuk menciptakan teknologi yang luar biasa.

@sethladd
Terima kasih atas petunjuknya.
Akan senang mendengar kabar dari @anders-sandholm @mit-mit atau @mraleph on
bagaimana bekerja dengan infrastruktur Dart 2 dan 'front end umum'.
Saya akan memeriksanya dengan @NathanaelA.

@DanTup

Hal-hal ini selalu lebih rumit daripada yang dipikirkan orang. Ini tidak sesederhana hanya mentranspilasikan kode karena orang akan mengharapkan kesalahan waktu nyata, penyelesaian kode, refactors, tooltips, dll. - ini adalah pekerjaan besar.

Ya kamu benar. Komentar 'sepele, sederhana untuk diterapkan' saya hanya diterapkan untuk membuat editor mengenali sintaks .dsx. Saya melihat ke Intellij dan mereka memerlukan parser bahasa lengkap untuk itu (jadi itu rumit), sedangkan Kode VS jauh lebih mudah dengan file sintaks dan saya juga memperhatikan bahwa file sintaks TypeScript/Javascript sudah memiliki dukungan untuk JSX (dan DSX hanya memiliki perubahan kecil dari BEJ).

Kami pasti akan mengganggu Anda untuk bantuan/arahan agar eksperimen kami berjalan.

Singkatnya, saya punya:
(a) Pra-prosesor yang memasukkan file *.dsx dan mengeluarkan file *.dart.
https://spark-heroku-dsx.herokuapp.com/index.html

Saya butuh bantuan dengan:
(1) Seseorang untuk mengurus integrasi 'VS Code'.
(2) Seseorang untuk mengetahui cara menambahkan kemampuan pra-prosesor ke dalam sistem build Flutter sehingga proses debug akan berfungsi dengan baik. Maksud saya, langkah kode akan ada di file *.dsx melalui sesuatu seperti peta sumber, dll.

@NathanaelA akan membantu dengan (2).

Jadi saya masih mencari orang untuk membantu (1)
Ada pengambil? @birkir @yuriy-manifold @tehfailsafe @alexkrolick @sanketsahusoft

@DanTup - Saya bukan pro di JSX, tetapi saya dapat berbicara tentang format XML NativeScript. Dapat saya lakukan:

Properti apa pun yang didukung kelas StackLayout dapat ditambahkan ke XML. Jadi ini adalah hubungan satu-ke-satu; yang menghilangkan satu ton kerusakan ekstra: Jadi mari kita lihat demo Flutter:
https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/gallery/home.dart#L39 -L63

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

Saya merasa ini lebih mudah dibaca dan dipahami jika saya mengonversinya dengan benar. :nyengir:

@NathanaelA Apa yang terjadi jika Anda perlu melakukan sesuatu yang lebih dinamis, seperti menelepon map ? Berikut beberapa kode dari file yang sama:

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

Seperti apa tampilan children: _kBackgroundLayers.map(...) dalam sintaks ini?

JSX/DSX hanya menentukan transformasi tag sebagai:

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

Di dalam:

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

Keluar:

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

dan Anda bisa menggunakan {} untuk meletakkan kode Dart yang valid, seperti evaluasi variabel dan fungsi anonim, dll. {} bisa ditempatkan di 3 tempat. Contoh di bawah ini menampilkan {} yang digunakan di 2 tempat (atribut tag dan sebagai anak-anak), dengan tempat ketiga dengan operator spread.

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

Letakkan kode di atas dalam file Javascript dan lihat dengan VS Code/Intellij. Perhatikan +/- (sisi kiri garis) yang dapat Anda gunakan untuk membuka dan menciutkan node XML untuk membuat pohon lebih kecil/lebih besar.

Mengapa kita tidak bisa mengakui masalah ini dan mengadopsi cara React Native? Apakah kita akan melakukannya atau tidak?

@JonathanSum maaf ketika diarahkan ke sini, tapi menurut Anda siapa Anda? Tidak ada masalah umum hanya sesuatu yang Anda tidak suka.
Pernahkah Anda menulis satu Aplikasi dengan Flutter?
Contoh di atas menggabungkan Dart dengan XML terlihat jauh lebih buruk daripada hanya Dart. Tidak ada untungnya di sini.
Saya berasal dari Xamarin Forms yang menggunakan xaml dan saya sangat menyukainya. Tetapi alih-alih mengeluh mengapa Flutter tidak mendukung Xaml, saya langsung terjun ke dalamnya dan mulai beradaptasi dan belajar.
Hadapi jika Anda ingin bekerja seperti di React maka gunakan Reactive daripada mengganggu semua orang di sini.

Ini adalah blok kode yang sama seperti di atas, tetapi dalam Dart murni dan refactored untuk menghindari sarang yang dalam.
Penasaran bagian mana dari cuplikan di bawah ini yang sulit dibaca dan/atau dipahami?

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

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

Bahkan, secara pribadi saya akan membuatnya terlihat lebih dekat dengan sesuatu seperti ini:

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

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

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

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

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

Sekali lagi, sepertinya kita mencampurkan dua masalah berbeda di sini:

1. Tidak suka sintaks Dart dan membutuhkan sintaks seperti XML/JSX
2. Keterbacaan kode Flutter.

Apakah ada orang di sini yang percaya penerapan BEJ akan menyelesaikan keterbacaan? Masih mungkin untuk membuat pohon yang sangat bersarang dalam kode dan pengembang masih harus melalui langkah-langkah yang sama yang baru saja saya lakukan dengan versi Dart untuk membuat semuanya dapat dibaca.

Tapi yang pasti akan ditambahkan adalah langkah build/transpile ekstra dengan source maps & co, dan banyak pekerjaan untuk mendukung infrastruktur ini di IDE dan Dart SDK (analyzer, debugger, dll).

@JonathanSum @escamoteur Kami tidak berbicara secara agresif tentang proyek ini. Harap tetap kolaboratif kolegial. Terima kasih. Diskusi baru-baru ini berlangsung ramah dan produktif, jadi terima kasih kepada semua orang yang ikut serta dalam diskusi itu!

Secara keseluruhan, menurut saya menambahkan DSX akan memecah ekosistem Flutter pada tahap paling awal, dengan banyak pekerjaan yang dilakukan untuk mencoba dan menjaga kedua sintaksis tetap lengkap, sebenarnya tidak secara signifikan membantu keterbacaan dalam banyak kasus, dan menarik jenis pengembang yang tertarik pada proyek semata-mata karena memiliki sintaksis dan/atau paradigma yang mirip dengan hal baru yang panas.

@Hixie maaf saya kehilangan kesabaran, tetapi saya pikir Flutter sedang dalam perjalanan yang baik dan para pengembang Flutter sudah cukup untuk melakukannya tanpa tuntutan seperti ini

@escmoteur - Saya pikir itu sebabnya saya secara khusus mengatakan upaya "komunitas". Saya tidak berpikir ini perlu melibatkan tim inti flutter di luar mereka yang bersedia menerima tambalan ... Yang tampaknya Seth katakan bahwa kami dapat melanjutkan. Jika Anda tidak tertarik dengan fitur ini; maka jangan menggunakannya ... :nyengir:

@escamoteur , saya minta maaf atas apa yang saya katakan.
Saya telah membangun beberapa aplikasi flutter dari tutorial. Yang saya rasakan tentang flutter adalah semuanya adalah objek daripada widget. Ini seperti sepotong besar kode pemrograman berorientasi objek yang rumit yang saling menempel secara tidak teratur.

Menurut saya yang paling penting adalah membuat framework yang mudah dibaca dan dikelola, dan tidak harus rumit-rumit. Yang terpenting, saya pikir cara React-Native membangun mengikuti apa yang dibuat manusia secara alami. Di sisi lain, flutter perlu menghubungkan widget stateful ke stateless dan... Selain itu, sebagian besar kerangka kerja UI yang kami gunakan di tahun-tahun ini berfokus pada cara Bereaksi ini sebagai standar, dan saya pikir flutter harus lebih fokus pada hal ini daripada memuat ulang panas (ketika saya mencoba menambahkan beberapa kelas baru, konsol memberi tahu saya untuk memulai kembali semuanya alih-alih melakukan memuat ulang panas). Saya benar-benar berpikir ini adalah masalah, bukan komentar atau permintaan.
naiveaiguy berkata:

Tolong berhenti mencoba membuat Flutter menjadi seperti "hal baru yang panas". Ini adalah hal baru yang panas dengan sendirinya, biarkan ia mengeksplorasi paradigma baru.

Anda bisa pergi memeriksanya.
https://facebook.github.io/react-native/
Berpikir dalam Bereaksi:
https://reactjs.org/docs/design-principles.html
Berdebar:
https://flutter.io/tutorials/animation/

Lihat React-Native, ia bahkan menempatkan manajemen status di atas dan bagian UI di bawah. Ini adalah seni dan perilaku alami manusia. Inilah sebabnya mengapa kurva belajar dan waktu manajemen rendah. Jadi, tolong jangan membandingkan XML atau bahkan Xamarin dengan React Native. Apalagi, futter itu hanya seperti kekacauan dan ketidakteraturan. Stateless terhubung ke stateful, dan create-state menghubungkan semua yang ada di stateless. Dengan React-Native, Anda menggambar gambar yang indah dengan pensil. Dengan kepakan, itu seperti menjatuhkan air di atas kertas dan memisahkan air menjadi bagian-bagian yang berbeda. Tapi saya pikir kita masih di hari-hari awal bergetar. React-Native memiliki filosofi dan tujuannya sendiri, dan flutter hanyalah proyek serius, atau semua orang tidak setuju dengan saya.

@JonathanSum

Saya telah membangun beberapa aplikasi flutter dari tutorial. Yang saya rasakan tentang flutter adalah semuanya adalah objek daripada widget. Ini seperti sepotong besar kode pemrograman berorientasi objek yang rumit yang saling menempel secara tidak teratur.

Anda telah gagal untuk memberikan alasan mengapa perasaan subjektif Anda dalam hal ini akan membenarkan sejumlah besar fragmentasi yang pasti akan ditimbulkannya. Ketika di antara dua pendekatan ini, tidak ada yang jelas lebih baik secara objektif daripada yang lain, saya pikir itu tidak sepadan, dan jelas tidak dalam tahap Flutter saat ini sebagai ekosistem.

Menurut saya yang paling penting adalah membuat framework yang mudah dibaca dan dikelola, dan tidak harus rumit-rumit.

Ini adalah tautologi. Jelas semua orang menginginkan ini, tetapi orang memiliki cara yang berbeda untuk mendekati masalah. Paradigma Flutter adalah salah satunya.

Yang terpenting, saya pikir cara React-Native membangun mengikuti apa yang dibuat manusia secara alami.

Saya tidak berpikir sesuatu yang kecil seperti sintaks untuk membangun UI memengaruhi seberapa mudah digunakan kerangka kerja secara keseluruhan.

Di sisi lain, flutter perlu menghubungkan widget stateful ke stateless dan...

Sepertinya Anda pada dasarnya tidak setuju dengan cara Flutter mendekati aplikasi. Mengapa Anda menggunakannya? Selain itu, ini sebenarnya bukan poin yang valid. Anda tidak mengungkapkan sesuatu yang Anda rasa salah, Anda hanya mengatakan "Saya pikir koneksi antara widget stateless dan stateful salah dan rumit dalam beberapa cara yang tidak jelas yang tidak akan saya jelaskan."

Selain itu, sebagian besar kerangka kerja UI yang kami gunakan pada tahun-tahun ini berfokus pada cara Bereaksi ini sebagai standar,

Argumentum ad populum.

dan saya pikir flutter harus lebih fokus pada ini daripada memuat ulang panas (ketika saya mencoba menambahkan beberapa kelas baru, konsol memberi tahu saya untuk memulai kembali semuanya alih-alih melakukan memuat ulang panas)

Ya, karena hot reload bukanlah fitur yang sangat mudah untuk dicapai seperti yang dilakukan Flutter. Saya berpendapat bahwa siklus pengembangan yang berhasil dicapai Flutter, bahkan dalam 30-40% perubahan kode, sangat mengesankan, dan hanya akan diperlambat oleh lapisan transpiling.

Namun, futter hanya seperti kekacauan dan ketidakteraturan.

Di sini Anda telah memperjelas bahwa Anda tidak menyukai pendekatan Flutter. Jangan gunakan itu. Dan jika Anda berpikir bahwa entah bagaimana, secara ajaib, mengubah sintaks UI akan membuat Flutter bukan "kekacauan dan ketidakteraturan", maka Anda harus memberikan bukti yang jelas bahwa itu bekerja dalam jenis pengaturan dan batasan yang sama dengan yang digunakan Flutter.

Itu sebabnya kurva belajar dan waktu pengelolaannya rendah. Tolong jangan bandingkan XML atau bahkan Xamarin dengan React Native.

Cukup adil - gunakan React Native. Pengembang di sana melakukan pekerjaan yang hebat dengan paradigma mereka.

Stateless terhubung ke stateful dan create-state di stateless

Apa? Tidak. Ini benar-benar salah - apa maksud Anda di sini?

Dengan React-Native, Anda menggambar dengan pensil. Dengan kepakan, itu seperti air yang jatuh di atas kertas dan memisahkan air menjadi beberapa bagian.

Terus terang, analogi ini sangat tidak masuk akal bagi saya. Saya dapat dengan mudah menyatakan pendapat sebaliknya dan kami akan segera kembali ke tempat kami mulai di sini.

Anda bertindak seperti ini jelas dengan sendirinya ("ayo hadapi saja") dan kami hanya berpura-pura dan/atau tidak tahan di sini karena mengatakan bahwa tim Flutter tidak harus berurusan dengan ini. Ini bukan sikap yang baik untuk diadopsi jika Anda ingin orang lain menganggap Anda serius.

Poin tambahan: Tolong jangan berpura-pura bahwa ini adalah sesuatu yang dapat dilakukan oleh pengembang pihak ketiga tanpa keterlibatan atau pekerjaan apa pun dari tim inti Flutter. Tim Flutter harus melakukan banyak pekerjaan tambahan dengan IDE dan plugin editor, dan penginjilan, dan menangani masalah GitHub, jika fitur tersebut ingin diimplementasikan secara memuaskan sebagai bagian yang harmonis dari Flutter.

@naiveaiguy
Baiklah, saya pikir Anda benar. Saya hanya orang acak yang membandingkan semua orang di sini dan orang yang menyukai React. Flutter memiliki caranya sendiri, dan React juga memiliki caranya sendiri. Saya minta maaf atas sikap saya, dan saya tidak baik.

@JonathanSum Saya pikir Anda hanya perlu lebih banyak waktu untuk benar-benar memahami bagaimana aplikasi Flutter dibuat. Agar adil tidak banyak dokumen di luar sana tentang arsitektur, cara menggunakan Widget yang Diwarisi dengan benar dan cara menghubungkan model tampilan Anda ke widget.

Yang ingin saya ketahui adalah mengapa Anda sama sekali tertarik dengan Flutter? Bagi saya React tidak boleh dilakukan karena JS

Begitu banyak yang harus dikomentari, begitu sedikit waktu, mungkin saya harus fokus ...

@escamoteur apa sebenarnya yang Anda maksud dengan:

Bagi saya React tidak boleh dilakukan karena JS

ES6/7 atau TypeScript sangat dekat dengan Dart/Kotlin/Swift sehingga saya akan dengan senang hati menari dengan salah satu wanita ini :)

Hal yang menarik saya untuk Flutter adalah dukungan grafis & animasi. Grafik Vektor Skia langsung dibangun di atas OpenGL untuk UX super cepat pada 60fps untuk dengan mudah mengimplementasikan hal-hal seperti yang Anda lihat di:
https://uimovement.com/
Saya menyukai UX khusus dan Flutter memungkinkan itu. Saya telah mengimplementasikan hal-hal UX selama beberapa dekade dan saya sangat suka dapat membangunnya menggunakan teknik deklaratif/reaktif, dan Flutter mendukungnya.

@pulyaevskiy

Sekali lagi, sepertinya kita mencampurkan dua masalah berbeda di sini:

• Tidak suka sintaks Dart dan membutuhkan sintaks seperti XML/JSX
• Keterbacaan kode Flutter.

Benar, tiket ini di sini (dan yang sebelumnya) hanya menginginkan kemampuan seperti BEJ. Ada tiket lain untuk peningkatan bahasa Dart untuk mengurangi verbositas kode bangunan UI saat ini.

Apakah ada orang di sini yang percaya penerapan BEJ akan menyelesaikan keterbacaan?

Mungkin bagi mereka, bagi mereka masing-masing.

Ya, contoh yang Anda berikan membuat pohon lebih kecil tetapi dengan memecahnya menjadi beberapa bagian dan memindahkannya ke tempat lain, itu juga membuat lebih sulit untuk melihat keseluruhan struktur dalam kode. Saya lebih suka menyimpan struktur lengkap di satu tempat dan mengeluarkan dari pohon beberapa properti terkait (bernama parameter) dan menggunakan operator spread DSX untuk memasukkannya. Hanya preferensi saya.

Tapi yang pasti akan ditambahkan adalah langkah build/transpile ekstra dengan source maps & co, dan banyak pekerjaan untuk mendukung infrastruktur ini di IDE dan Dart SDK (analyzer, debugger, dll).

Kami sedang menangani ini dan @sethladd telah menyatakan bahwa I believe one of the goals of Dart 2 was to create an infrastructure for more experimentation with the language and let the community create experiments like DSX.

@naiveaiguy

Saya berpendapat bahwa siklus pengembangan yang berhasil dicapai Flutter, bahkan dalam 30-40% perubahan kode, sangat mengesankan, dan hanya akan diperlambat oleh lapisan transpiling.

Ya, saya sangat menikmati hot loading meskipun tidak bekerja sepanjang waktu. Saya pasti akan menerimanya, tetapi komentar Anda dengan transpiling yang memperlambat itu tidak berdasar. Jika Anda tidak menggunakan DSX, itu tidak akan menambah waktu kompilasi Anda. Jika Anda menggunakan DSX, transpilernya sangat cepat sehingga Anda tidak akan menyadarinya.

Poin tambahan: Tolong jangan berpura-pura bahwa ini adalah sesuatu yang dapat dilakukan oleh pengembang pihak ketiga tanpa keterlibatan atau pekerjaan apa pun dari tim inti Flutter. Tim Flutter harus melakukan banyak pekerjaan tambahan dengan IDE dan plugin editor, dan penginjilan, dan menangani masalah GitHub, jika fitur tersebut ingin diimplementasikan secara memuaskan sebagai bagian yang harmonis dari Flutter.

Tidak juga. Kami melakukan ini dan hanya meminta untuk tidak diblokir. Kami meminta bimbingan untuk mengarahkan kami ke arah yang benar. Saya tidak akan melakukan semua ini sendiri, jadi sekarang ada 2 dari kami (terima kasih @NathanaelA) dan kami mencari lebih banyak orang (setidaknya 1 orang lagi) jika mereka ingin membantu.

Salam semua! Pertama-tama, saya ingin menunjukkan bahwa tidak masuk akal untuk melanjutkan diskusi bolak-balik tentang masalah ini - ini akan menjadi besar dan sulit untuk diikuti karena struktur linier. Argumen Anda akan hilang dan diulang lagi dan lagi. Mari kita kurangi ini menjadi angka murni:

• Jika Anda UNTUK fitur ini - jempol komentar pertama tentang masalah ini.
• Jika Anda MELAWAN fitur ini - jempol ke bawah komentar pertama tentang masalah ini.

Selanjutnya, saya ingin mengklarifikasi pernyataan @sethladd , seharusnya berbunyi _"salah satu tujuan Dart 2 adalah menciptakan infrastruktur untuk lebih banyak eksperimen dengan bahasa untuk tim Dart "_.

Bahkan di Dart 2 kami tidak menyediakan API apa pun yang memungkinkan Anda mengubah sintaks bahasa Dart dengan mudah, tanpa membangun kembali Dart SDK (atau artefak mesin Flutter). Apa yang disediakan Dart 2 adalah infrastruktur _common front-end_ (CFE) (terletak di pkg/front_end dalam sumber Dart SDK) - yang merupakan parser untuk bahasa Dart yang ditulis dalam Dart. Untuk perubahan bahasa gula sintaksis murni seperti DSX, Anda hanya dapat mengedit kode CFE, membuat Dart SDK (atau mesin Flutter) dan memiliki semua alat (kecuali untuk kode penyorotan sintaks yang dibangun ke dalam masing-masing plugin IDE) mengambil ekstensi sintaks baru Anda. Perhatikan bahwa saat ini hanya VM dan dart2js yang benar-benar menggunakan CFE, penganalisis dijadwalkan untuk transisi berikutnya. Seperti yang Anda lihat, ada penghalang tertentu untuk masuk ke sini.

Hal penting untuk disorot di sini adalah karena tidak ada API untuk memperluas sintaks Dart, Anda harus bekerja dengan tim bahasa Dart untuk memperluas bahasa. Saat ini tidak ada proses formal untuk ini, namun untuk fitur seperti DSX perlu banyak bukti dan motivasi untuk dimasukkan ke dalam Dart. (/fyi @leafpetersen @lrhn - tolong koreksi saya jika saya salah)

Berikut adalah rekomendasi saya untuk para pendukung DSX seperti solusi:

• Pertama-tama Anda benar-benar perlu menuliskan proposal Anda dan memindahkan diskusi ke tempat yang memfasilitasi diskusi non-linier. Saat Anda mengusulkan perubahan bahasa, Anda harus memiliki deskripsi _elaborate_ tentang apa yang Anda coba selesaikan dan bagaimana hal itu diselesaikan menggunakan ekstensi sintaks yang Anda usulkan. Jika tidak, tidak mungkin untuk mengevaluasi biaya dan manfaat dari perubahan yang diusulkan. Maka Anda memerlukan cara untuk melakukan diskusi non-linier tentang berbagai bagian proposal, mis

  • jika Anda memasukkan proposal Anda ke Google Doc, maka orang-orang dapat menggunakan komentar bawaan untuk mendiskusikan berbagai komponen proposal Anda;
  • atau Anda dapat membuat repo GitHub dengan deskripsi penurunan harga dari proposal Anda, dan menggunakan masalah GitHub dan PR untuk memperbaiki dan mendiskusikan proposal Anda.

  Catatan, saya tidak mengatakan bahwa Anda perlu membuat _spesifikasi formal_ untuk perubahan Anda yang akan sebanding dengan spesifikasi bahasa Dart di tingkat penyempurnaan. Alih-alih, Anda perlu memiliki contoh ekstensif tentang bagaimana fungsi perubahan yang diusulkan dan manfaat apa yang diberikannya.



• Selanjutnya jika Anda bisa, Anda harus mencoba menerapkannya. Penghalangnya tinggi di sini bahkan dengan infrastruktur CFE - tetapi jauh lebih rendah daripada sebelumnya.

@mraleph Saya pikir argumen tentang integrasi ke Dart lebih tentang kait untuk memanggil pembuatan kode atau serupa, bukan untuk mengubah bahasa.
Saya tidak tahu hal seperti itu diperlukan.
Saya pikir ini sebagian besar dapat diimplementasikan seperti Angular dengan plugin Analyzer-nya, hanya DSX, bukan HTML

@mraleph

Terima kasih banyak atas klarifikasinya.
Kami tidak benar-benar ingin mengubah bahasa Dart, yang kami butuhkan adalah kemampuan pra-pemrosesan untuk mengubah DSX eksperimental kami menjadi Dart.
Omong-omong Anda dapat mencobanya secara online di:
https://spark-heroku-dsx.herokuapp.com/index.html

Masalahnya adalah ketika Dart pertama kali keluar, ia dapat melakukan transpile ke Javascript dan dengan menggunakan peta sumber, ia dapat langsung terhubung ke ekosistem Javascript (beberapa bahasa lain melakukan hal yang sama: Coffeescript, TypeScript, dll). Apa yang kami cari adalah sesuatu yang mirip dengan ini untuk Dart/Flutter. Kami mencari kemampuan pra-pemrosesan umum yang memungkinkan bahasa transpiling lainnya dibangun di atas Dart/Flutter.

Sehubungan dengan pemungutan suara, tiket sebelumnya memiliki beberapa nomor:
https://github.com/flutter/flutter/issues/11609

@cbazza

Kami tidak benar-benar ingin mengubah bahasa Dart, yang kami butuhkan adalah kemampuan pra-pemrosesan untuk mengubah DSX eksperimental kami menjadi Dart.

Saya berbicara dari perspektif bahwa file *.dsx sebenarnya adalah file Dart di mana Anda dapat menggunakan beberapa sintaks tambahan. Dan seperti yang saya katakan saat ini tidak ada API atau titik ekstensi yang memfasilitasi pembuatan ekstensi sintaksis sedemikian rupa sehingga memungkinkan ekstensi sintaksis ini beroperasi secara transparan dengan semua alat di ekosistem Dart. Selain itu, menurut saya tidak ada rencana segera untuk merancang dan menyediakan API atau titik ekstensi semacam itu - jadi taruhan terbaik Anda mulai hari ini adalah melakukan fork Dart SDK dan membangun dukungan DSX ke CFE.

Saya juga merekomendasikan untuk memikirkan kasus sudut - daripada memikirkan kasus sederhana. Misalnya bayangkan Anda sedang mengedit file DSX Anda. Dalam hal ini kemungkinan besar Anda ingin melihat penyelesaian waktu nyata pada kode setengah jadi, misalnya nama konstruktor dan nama atribut. Bagaimana cara kerjanya dengan pemetaan sumber? Hal-hal seperti itu merupakan pengalaman pengembang.

@mraleph Terima kasih sekali lagi.

Kami tentu bertujuan untuk memberikan pengalaman pengguna yang luar biasa bagi pengguna DSX itu pasti.

Beberapa orang menyukai sintaks seperti XML, beberapa orang membencinya. Mungkin menambahkan sintaks seperti jsx terlalu berlebihan. Perhatian utama saya tentang Flutter adalah keterbacaan. IMHO, masih ada ruang untuk meningkatkan sintaks Dart dan Flutter saat ini (Bagi saya itu adalah terutama tentang tanda kurung bersarang dalam, child , children ,suara titik koma,dll.)
Memposting ulang beberapa contoh kode[1] di sini,

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

Versi Dart 2 dengan new dan titik koma opsional (kode dari @sethladd)[2],

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

IMO, versi kotlin bersih dan terlihat lebih baik. Versi Dart 2 sangat dekat dan masih memiliki ruang untuk perbaikan (jika Dart mendukung metode ekstensi?). Jadi saya pikir meningkatkan sintaks Dart untuk mengurangi verbositas adalah arah yang benar.

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

Dari sudut lain, saya suka kemampuan menulis BEJ.

Bekerja dengan komponen (widget) sangat mudah dan dapat diakses, memindahkannya ke atas dan ke bawah pohon di editor hanyalah masalah pintasan keyboard (Alt+UP / Alt+DOWN). Ini terutama berlaku untuk saat memindahkan barang masuk dan keluar dari wadah, baris, kolom, dll.

Tapi ini bukan sesuatu yang DSX akan selesaikan sendiri. Widget yang mereka butuhkan sendiri
lebih dibatasi dengan penamaan properti agar ini berfungsi. Di React, ini adalah properti yang disebut children dan merupakan prinsip utama di JSX. Flutter memungkinkan fleksibilitas dalam penamaan anak (anak, anak, tubuh, dll.).

Berikut ini adalah diskusi hebat tentang pro dan kontra: https://github.com/jsforum/jsforum/issues/1

Anak panah	DSX

Sumber: https://github.com/flutter/flutter/blob/master/examples/platform_view/lib/main.dart

Saya harus mengakui sampel DSX terlihat menarik. Tapi saya takut segera setelah Anda mencampurnya dengan Kode Dart misalnya Saat menggunakan widget pembangun apa pun, itu akan terlihat sangat jelek.

@birkir DSX harus dapat mendukung sesuatu seperti pola render props untuk beberapa/non- children slot anak. Jika itu dapat mengambil fungsi atau referensi kelas sebagai alat peraga (yang mungkin akan otomatis) itu akan berhasil di luar kotak.

Sejauh implementasi tooling berjalan, tooling Javascript telah mendukung sintaks non-standar dan ekstensi bahasa untuk waktu yang lama (Flowtype/Typescript/Babel) sehingga banyak alat untuk JSX memanfaatkan transpiler yang ada. Afaik Dart belum mengalami tingkat fragmentasi tersebut sehingga toolingnya belum ada. Tapi sekarang saat yang tepat untuk mulai membangunnya

IMHO, sintaks seperti json jauh lebih baik daripada sintaks ~xml-like~!

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

@jaychang0917
Saya tidak berpikir JSX dapat dibandingkan dengan XML. Menurut saya JSX dan XML adalah dua hal yang berbeda sebagai pesawat supersonik verse propeller.

Dengan JSX, Anda dapat melakukan hal-hal seperti berikut:

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

atau

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

Dengan JSX, kami bahkan dapat memecah semuanya sepotong demi sepotong seperti di atas, atau Anda dapat mengelompokkan sebagian besar UI menjadi satu tag <> untuk meletakkan sebagian besar UI ini di mana pun Anda inginkan.

Inilah sebabnya mengapa React menggantikan HTML dan XML dan mengadopsi JSX untuk membangun aplikasi iPhone atau aplikasi web, atau orang mengatakan JSX hanyalah versi HTML yang lebih keren.

• Saya tidak suka XML dan HTML dan suka JSX.

• Saya pikir yang paling penting bukan tentang kinerja seperti iPhone vs desktop.

• Yang terpenting mudah digunakan sebagai iPhone vs desktop.

Sebagai contoh:

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

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

atau tulis

< AwkwardScrollingImage/>

untuk menulis-sekali-berjalan-di mana-mana

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

~Flutter menggunakan bahasa pemrograman untuk membangun UI. ~

Referensi:

Berdebar:
https://flutter.io/tutorials/layout/
Bereaksi Asli yang membangun Android, Iphone, dan bahkan desktop:
https://facebook.github.io/react-native/

@birkir
Ohh itu terlihat sangat bagus!!! hanya daging dan tanpa tulang :)
Bayangkan menggunakan https://builderx.io/ dengan itu (lihat gambar animasi kedua - pembuatan UI 2 arah seperti yang digunakan Flex :)

@escamoteur
dengan pembangun inline itu akan terlihat berantakan seperti dengan cara saat ini; sampel disediakan di atas:
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

anyway, saya pikir cara saat ini jelas dan konsisten. Mencampur beberapa kode dart dan tag < dalam file dart membuat saya merasa bahwa kode tersebut canggung dan tidak jelas. Dari sudut pandang pengembang Android, sepertinya menulis kode Java/kotlin dalam file layout xml :)

HANYA DUA SEN SAYA

@JonathanSum um...

Jadi apa keuntungan menggunakan BEJ yang tidak bisa dilakukan dengan cara flutter saat ini? Saya tidak melihat ada argumen yang Anda katakan kuat.

JSX tidak seperti XML. JSX lebih sederhana dan kuat dari XML itu.

Btw, JSX seperti xml , jika tim facebook tidak membohongi saya :)

@jaychang0917
JSX bukan XML karena JSX lebih sederhana dan lebih kuat dari XML itu. (Saya katakan JSX tidak seperti XML)

Jika Anda mengatakan tidak ada argumen yang kuat, izinkan saya mengajukan pertanyaan.
Biarkan saya mengakhiri pembicaraan saya di sini. Jika orang menginginkan BEJ atau DSX apa pun, akan ada yang serupa di masa depan.

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

Saya merindukan tag penutup yang sebenarnya dari XML :)
Ide: Tag penutup yang dibuat secara otomatis

Kotlin akan menyelesaikan ini juga. Lihat saja betapa hebatnya Kotlin-react dan Anko

Kotlin-react tidak terlalu bagus, KSX akan lebih baik :)

import React from 'react';

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

package hello

import react.*
import react.dom.*

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

package hello

import react.*
import react.dom.*

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

Tag hanya tidak termasuk di sana :)

Berada di kamp JSX/DSX/KSX, saya yakin tag termasuk di dalam kode :)

@saied89
Apakah Anda ingin menggunakan tag untuk menyarangkan elemen di dalam elemen lain seperti HTML? Atau Anda ingin mengetikkan kata "anak", "anak", atau [ ]? Selain itu, BEJ menyediakan hal-hal seperti penggunaan kembali ratusan kode UI hanya dengan mengetikkan satu tag.

Mungkin satu aspek lainnya adalah format default yang dilakukan dart format . IMHO sulit dibaca terutama dengan anak terkemuka: /anak-anak.

Saya benar-benar lebih suka beberapa pemformatan yang menekankan struktur pohon seperti itu:

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

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

Ini mungkin bukan solusi yang ideal tetapi harus menunjukkan arah.
@sethladd ada kesempatan untuk melakukan sesuatu ke arah itu?

Pertama-tama, saya senang ini tidak memanas seperti masalah saudaranya : smile:.

Jika saya diminta untuk memilih salah satu dari 2 sintaks, saya akan condong ke sisi Dart. Hal ini didasarkan pada beberapa fakta:

• Saya lebih suka beralih di antara sesedikit mungkin konteks yang saya bisa. Suka atau tidak, melompat di antara sintaks adalah cara untuk melakukan itu. Ini dapat dibantu dengan dukungan perkakas tetapi ini mengarah ke poin di bawah ini.
• Saya lebih suka tim pengembangan mendedikasikan waktu untuk masalah lain yang mencegah kami mengkodekan fitur tertentu dan/atau menghentikan orang melompat ke Flutter. Saya pikir tidak memiliki sintaks seperti JSX seharusnya tidak menjadi alasan perusahaan/pengembang/apa pun menolak Flutter.
• Kami akan mendapat manfaat dari setiap pembaruan Dart. Ini khususnya berlaku untuk Dart karena Flutter adalah salah satu pelanggan utamanya dan merupakan kerangka kerja UI. Lihat perubahan new/const misalnya.
• Saya sangat menghargai keamanan tipe. Tidak mengatakan bahwa sintaks seperti JSX tidak dapat diketik dengan aman, saya tidak percaya upaya dalam mencapainya sepadan dengan pendapatannya.

Selain itu, saya sebenarnya menyukai sintaks seperti Kotlin. Khususnya jika sintaks tersebut membawa beberapa fitur Kotlin ke Dart : innocent:.

@emalamela ,

Inilah masalahnya, tidak ada sakelar konteks seperti yang Anda sebut, tanyakan saja kepada pengembang Bereaksi yang berpengalaman. Juga pemisahan sintaks ini sebenarnya adalah fitur yang hebat karena ketika Anda melihat kodenya, Anda dapat dengan mudah melihat apa yang deklaratif dan apa yang imperatif.

Saya pikir tidak memiliki sintaks seperti JSX seharusnya tidak menjadi alasan perusahaan/pengembang/apa pun menolak Flutter.

Tapi sayangnya itu akan terjadi untuk banyak pengembang Bereaksi.

Kami akan mendapat manfaat dari setiap pembaruan Dart.

Saya tidak melihat bagaimana DSX juga tidak mendapat manfaat dari pembaruan Dart karena ini adalah superset dari Dart.

Saya sangat menghargai keamanan tipe. Tidak mengatakan bahwa sintaks seperti JSX tidak dapat diketik dengan aman, saya tidak percaya upaya dalam mencapainya sepadan dengan pendapatannya.

Upaya untuk mencapai keamanan tipe di DSX adalah nol karena DSX hanyalah lapisan gula sintaksis kecil di atas Dart, jadi ia menggunakan sistem tipe Dart seperti halnya menggunakan pernyataan kontrol Dart, dll.
https://github.com/flutter/flutter/issues/15922#issuecomment -377780062

Terima kasih atas masukan Anda @cbazza !

Inilah masalahnya, tidak ada sakelar konteks seperti yang Anda sebut, tanyakan saja kepada pengembang Bereaksi yang berpengalaman.

Saya bukan pengembang Bereaksi berpengalaman, jadi bagi saya ini adalah sakelar konteks. Sama seperti di Android Anda harus melompat dari Java/Kotlin ke XML, meskipun lompatannya lebih besar di sana. Satu bahasa, perkakas yang sama, lebih sedikit overhead.

Juga pemisahan sintaks ini sebenarnya adalah fitur yang hebat karena ketika Anda melihat kodenya, Anda dapat dengan mudah melihat apa yang deklaratif dan apa yang imperatif.

Cara sekarang cukup deklaratif menurut saya.

Saya tidak melihat bagaimana DSX juga tidak mendapat manfaat dari pembaruan Dart karena ini adalah superset dari Dart.
Upaya untuk mencapai keamanan tipe di DSX adalah nol karena DSX hanyalah lapisan gula sintaksis kecil di atas Dart, jadi ia menggunakan sistem tipe Dart seperti halnya menggunakan pernyataan kontrol Dart, dll.

Poin yang adil. Tetapi DSX masih merupakan sesuatu yang harus dipertahankan dan ditingkatkan, yang masih menyiratkan upaya yang saya ingin lihat difokuskan pada aspek ekosistem yang lebih kritis/kurang.

Aspek lain tentang diskusi yang saya tidak setuju adalah perbandingan konstan dengan React. Saya mengerti relevansinya tetapi saya tidak ingin Flutter menjadi salinan Bereaksi tanpa jembatan JS dan mengubah nama Komponen menjadi Widget. Kalau sama kenapa harus berubah? Itu tidak berarti bahwa Flutter harus berusaha sejauh mungkin dari React. Flutter harus memiliki identitasnya sendiri. Saya lebih suka bahwa budaya Flutter dalam memberikan solusi bersifat proaktif, bukan reaktif. Kita harus menggunakan React hanya sebagai titik kontras, bukan sebagai pedoman.

Sejauh yang saya ketahui, jika ada pengembang yang memilih untuk tidak mengembangkan di Flutter karena DSX/JSX tidak didukung, nah orang itu sama sekali tidak ingin bergabung dengan Flutter.

Aspek lain tentang diskusi yang saya tidak setuju adalah perbandingan konstan dengan React. Saya mengerti relevansinya tetapi saya tidak ingin Flutter menjadi salinan Bereaksi tanpa jembatan JS dan mengubah nama Komponen menjadi Widget. Kalau sama kenapa harus berubah?

Karena React memiliki celah yang dapat diisi oleh Flutter dan kemudian Anda membuat sesuatu yang lebih baik daripada React karena React memperbaiki kekurangan React dengan performa Dart dan grafis akselerasi GPU, sambil menjaga bagian terbaik dari React serta keakrabannya.

Sejauh yang saya ketahui, jika ada pengembang yang memilih untuk tidak mengembangkan di Flutter karena DSX/JSX tidak didukung, nah orang itu sama sekali tidak ingin bergabung dengan Flutter.

Tidak masalah, hasil akhirnya adalah jika pengembang seluler yang menggunakan alat lintas platform tidak bergabung dengan Flutter, Flutter akan gagal di pasar. Jadi Flutter perlu menarik pengembang React Native untuk kelangsungan hidupnya.

Berbicara tentang evolusi, ini bukan 'survival of the fittest', ini 'survival of the most adaptable'. Beradaptasi atau Anda binasa.

@cbazza

Tidak masalah, hasil akhirnya adalah jika pengembang seluler yang menggunakan alat lintas platform tidak bergabung dengan Flutter, Flutter akan gagal di pasar.

Apa? Mengapa perlu? Flutter dapat membentuk ceruknya sendiri saat masih dalam versi beta (seperti yang telah dilakukan dengan sangat sukses), dan kemudian tumbuh secara organik tanpa perlu menarik ngengat dengan fitur yang sangat mirip. Juga apa maksudmu "gagal"? Flutter tidak perlu menjadi populer untuk menjadi sukses.

@naiveaiguy
Dengar, saya tahu Anda telah menurunkan jawaban cbazza.
Tapi bisakah Anda meluangkan waktu 15 detik untuk melihat ini sebelum Anda mengurangi jawaban saya?

Sebelum Anda berpikir tentang DSX.
Lihat saja di bawah, itu hanya BEJ.

Setelah Anda membuat nav bar dan body, Anda cukup mengimpor nav bar code dari nav bar code Anda.

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

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

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

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

Mungkin ada yang membenci BEJ karena berasal dari Facebook, tapi sebenarnya dari perusahaan game kecil Jepang.

Setelah melakukan aplikasi dengan React Native dan Flutter, saya merasa bahwa pada kondisi saat ini JSX lebih mudah dibaca dan disesuaikan daripada kelas Dart bersarang murni.
Namun, seperti yang disebutkan sebelumnya, Facebook memiliki alasan untuk menggunakan JSX karena cara JavaScript ditulis (misalnya tidak ada parameter konstruktor bernama) yang tidak demikian dengan Dart. Juga keamanan tipe Dart yang ditambahkan memang bagus!
Jadi jika Flutter tetap menggunakan sintaks Dart murni pada akhirnya, saya berharap dapat melihat peningkatan dengan penyorot sintaks dan formatter otomatis. Komentar tag penutup yang baru sudah merupakan peningkatan besar tetapi tidak cukup untuk mencapai produktivitas BEJ.

@JonathanSum Anda menjelaskan ide komponen yang dapat digunakan kembali. Anda tidak perlu JSX untuk melakukan komponen yang dapat digunakan kembali. Saya pikir akan memiliki sesuatu yang lebih baik dengan memperbaiki sintaks Dart, tetapi DSX sama sekali bukan cara yang baik untuk melakukannya.

@hartmannj Kami selalu mencari peningkatan pada sintaks Dart, penyorot, dan pemformat yang akan membantu produktivitas. Untuk setiap ide atau proposal khusus untuk perbaikan yang mungkin Anda atau orang lain pikirkan, saya akan sangat penasaran untuk mempelajari lebih lanjut.

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

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

React tidak memerlukan penggunaan JSX, tetapi kebanyakan orang merasa terbantu sebagai bantuan visual saat bekerja dengan UI di dalam kode JavaScript. Ini juga memungkinkan React untuk menampilkan pesan kesalahan dan peringatan yang lebih berguna.

Ketika begitu banyak pengembang yang ingin menggunakan JSX-like untuk membangun UI, itu berarti cara itu diperlukan dan tidak boleh diabaikan.

@woodstream Tipe orang yang ingin sekali menggunakan JSX sudah menjadi penggemar fanboy React. Mereka sudah menggunakan React Native. Flutter melayani jenis pengembang yang sangat berbeda.

EDIT : Saya akui penggunaan fanboy saya salah di sini.

@naiveaiguy , @Hixie

Tipe orang yang ingin sekali menggunakan JSX sudah menjadi fanboy React. Mereka sudah menggunakan React Native. Flutter melayani jenis pengembang yang sangat berbeda.

Anda salah dan nama Anda yang menyebut komentar memecah belah ('React fanboys' & 'berbeda tipe developer') tidak disukai. BEJ/DSX memiliki keunggulan teknis dan yang lain lebih menyukainya. Utas ini untuk membahas itu, jika Anda tidak menyukainya, berhenti berlangganan darinya. Juga berhenti memilih setiap komentar saya, itu bukan pertanda baik bagi Anda.

Saya hanya menyarankan menawarkan dua cara bagi pengembang untuk memilih mana yang mereka sukai, dan seseorang suka memberikan jempol di depan pendapat yang berbeda? Teknologi harus terbuka dan inklusif daripada bermain dalam komunitas tertutup.

@anders-sandholm Saya setuju dengan @escamoteur tentang perlunya meningkatkan visibilitas pohon widget. Saya akan melakukan contohnya seperti berikut:

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

Lebih jauh lagi, saya dapat membayangkan menyorot nama kelas Widget dengan warna, gaya font, atau bobot yang berbeda sehingga akan lebih mudah dikenali.

@cbazza

Nama panggilan? Saya tidak menyiratkan bahwa orang-orang ini negatif, hanya saja mereka berbeda. Saya memang menyukai utas ini tetapi menuduh saya berdebat dengan itikad buruk agak ironis.

Kata "fanboy" umumnya dianggap menghina, dan diambil juga dalam konteks ini. Saya sarankan menghindari kata-kata seperti itu dalam diskusi di sini.

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.

@hartmannj

Hanya beberapa klarifikasi kecil...

Namun, seperti yang disebutkan sebelumnya, Facebook memiliki alasan untuk menggunakan JSX karena cara JavaScript ditulis (misalnya tidak ada parameter konstruktor bernama) yang tidak demikian dengan Dart.

Sebenarnya sejak ES2015/ES6, JS memiliki parameter bernama; anda bisa menggunakan 'de-structuring' untuk itu :)
Berikut ini contohnya:

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


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

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

Juga keamanan tipe Dart yang ditambahkan memang bagus!

Anda mendapatkan keamanan tipe yang sama dengan DSX, yang memang bagus.

Karena ini adalah duplikat dari https://github.com/flutter/flutter/issues/11609 yang dilaporkan sebelumnya, saya akan menutup yang ini demi yang itu.

saya benar-benar tidak mengerti bagaimana orang dapat memilih menentang ini - sesuatu yang begitu alami dengan cara kode deklaratif ditulis di era internet ..

<like><this /></like>

harap cukup fleksibel untuk memberi flutter kesempatan untuk terbang!

sayangnya ini terlihat sia-sia, setiap teknologi menggunakan markup untuk membuat UI di masa lalu dan bahkan sekarang dan semua pengalaman pengembang itu sekarang terbuang sia-sia oleh flutter.

kita tidak perlu melakukannya seperti reaksi asli atau html, cukup gunakan xml sederhana

dan mayeeee... xml tertanam di dart! ;P

Pada Selasa, 28 Agustus 2018 pukul 21:29, Touseef [email protected] menulis:

kita tidak perlu melakukannya seperti reaksi asli atau html, cukup gunakan xml sederhana

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/flutter/flutter/issues/15922#issuecomment-416550338 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AC8aNdVb_NV8c8JH4t36OS1OOvX6kY58ks5uVSmjgaJpZM4S6HPa
.

--
Tony Polinelli

Bagi saya fungsionalitas seperti JSX adalah masa depan dan itu akan menjadi konstruksi standar untuk kerangka kerja deklaratif seperti React, Vue & Flutter.

kita tidak perlu menyematkan xml di dart jika kita hanya dapat memiliki 2 file terpisah untuk UI dan logika maka kita dapat dengan mudah mengikuti mvvm, mvc atau pola lain yang diinginkan.

Saya sudah mengatakannya di utas lain tetapi:

Jika Anda benar-benar menginginkan JSX, permulaan yang baik adalah menggunakan pembuatan kode. Pergi dengan file .html atau .xml dan buat widget dari ini.

Jelas, ini bukan BEJ yang lengkap, tetapi ini adalah permulaan. Cukup untuk melihat bagaimana masyarakat akan bereaksi terhadapnya.
Jika sintaks itu menarik, mungkin tim Flutter akan mempertimbangkan kembali topik tersebut.

Kalau tidak, saya pikir itu hanya membuang-buang waktu. Kita dapat dengan jelas melihat dari sini bahwa ini adalah topik yang sangat diperdebatkan.

Jika flutter memperkenalkan dan xml / jsx / menyebutnya apa yang Anda inginkan cara membuat UI, saya akan mulai menggunakannya untuk aplikasi tingkat produksi dengan detak jantung!

Saya setuju @leossmith tht adalah satu-satunya hal yang menjadi rintangan untuk aplikasi tingkat produksi.

Saya pribadi lebih suka _not_ menambahkan JSX atau bahasa markup eksternal. Saya lebih suka menyimpan semuanya dalam satu jenis bahasa yang dicentang. Saya merasa pendekatan yang lebih baik adalah terus meningkatkan bahasa Dart untuk tujuan pengkodean pohon UI deklaratif yang sangat bersarang. Mereka telah menambahkan beberapa fitur bagus di area ini:

• Menjadikan kata kunci new dan const opsional membantu.
• Tag penutup virtual di IDE
• dartfmt juga membantu

Saya lebih suka menyimpan semuanya dalam satu jenis bahasa yang dicentang

Itulah tepatnya yang dilakukan DSX/JSX, bahasanya adalah Dart untuk DSX, Javascript untuk JSX !!!

Saya merasa pendekatan yang lebih baik adalah terus meningkatkan bahasa Dart untuk tujuan pengkodean pohon UI deklaratif yang sangat bersarang.

DSX adalah peningkatan bahasa Dart untuk lebih mendukung pohon deklaratif bersarang dalam. Sama seperti JSX untuk Javascript.

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

Tujuan dari spesifikasi ini adalah untuk mendefinisikan sintaks yang ringkas dan familiar untuk mendefinisikan struktur pohon dengan atribut.

@cbazza Anda memberikan poin yang bagus. JSX adil dan peningkatan JavaScript.

Jadi pertama-tama mari kita pisahkan dua hal dengan jelas:

1. DSL eksternal untuk mendefinisikan UI. Saya 100% menentang ini. Saya selalu percaya ini menciptakan lebih banyak masalah daripada menyelesaikannya. Saya menulis posting blog yang memperdebatkan hal ini. Itu mendapat 58K tampilan dan yang mengejutkan, hampir tidak ada perbedaan pendapat: 80% dari pengkodean saya melakukan ini (atau mengapa templat mati)
2. Perbaikan bahasa. Untuk mempermudah dalam membangun dan memvisualisasikan struktur hierarki UI yang sangat bersarang. Dalam hal ini kami berdua sepakat bahwa ada ruang untuk perbaikan.

Tapi kami sedikit berbeda dalam pendekatannya. Ada dua alasan mengapa JSX lebih masuk akal untuk React:

1. Struktur data: Di web, JSX sama persis dengan apa yang dihasilkan (node ​​DOM HTML). Dalam flutter, kami membuat instance Widget.
2. Keakraban: Orang terbiasa melihat kode html. Tetapi proposal DSX menyimpang dari JSX/XML cukup untuk membatalkan poin ini.

Di bawah ini adalah dua hal (saya percaya) yang membuat XML bagus (dan dapat dibaca) untuk membangun pohon UI. Pertanyaannya adalah, dapatkah ini dicapai tanpa memasukkan XML ke dalam bahasa:

1. XML memiliki tag Akhir. Ini dimungkinkan dengan atau tanpa sintaks xml-ish. Visual basic memilikinya di tahun 90-an (pikirkan End If). Dan bahasa lain memilikinya. IDE memang menyediakan "tag akhir virtual" tetapi ini agak samar. Saya lebih suka dukungan bahasa.
2. XML memiliki perlakuan khusus terhadap anak-anak. Atribut berbeda dari anak-anak. Tapi saya berpendapat bahwa ini adalah pedang bermata dua. Ada beberapa kasus di mana Dart sebenarnya lebih jelas dan ekspresif daripada XML dalam hal ini. Misalnya, widget container dengan model konten turunan yang berbeda:

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

Proposal Dave untuk masalah tag akhir

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

Ini akan mudah dibaca oleh manusia. Dan parser hanya akan mengganti )ButtonsView dengan ) . Juga, IDE dapat memberikan pemeriksaan dan bantuan yang lebih baik dengan skema ini. Saya akan membuatnya diperlukan setiap kali parens buka dan tutup tidak berada pada baris yang sama.

Proposal Dave untuk masalah anak-anak bersarang

Beberapa bahasa (seperti kotlin) mengizinkan perlakuan khusus untuk argumen tipe lambda. Mereka memungkinkan Anda untuk menempatkan argumen lambda di luar parens. Lihat Melewati lambda ke parameter terakhir .

Saya mengusulkan sesuatu yang serupa untuk Dart, tetapi sebagai arg dari tipe Daftar, bukan untuk lambdas. Saya mengusulkan sintaks khusus untuk melewatkan argumen daftar tipe yang diberi nama "anak-anak":

```
// alih-alih ini:
Foo(a: 1, b:10,c:44, anak-anak:[...])

// kita melakukan ini:
Foo(a: 1, b:10,c:44)[

]

Untuk Konstruktor/fungsi yang mengambil satu anak atau 2 anak (seperti atas dan bawah) biarkan apa adanya, tidak ada perubahan.

Saya lebih suka menyimpan semuanya dalam satu jenis bahasa yang dicentang

Itulah tepatnya yang dilakukan DSX/JSX, bahasanya adalah Dart untuk DSX, Javascript untuk JSX !!!

Saya merasa pendekatan yang lebih baik adalah terus meningkatkan bahasa Dart untuk tujuan pengkodean pohon UI deklaratif yang sangat bersarang.

DSX adalah peningkatan bahasa Dart untuk lebih mendukung pohon deklaratif bersarang dalam. Sama seperti JSX untuk Javascript.

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

Tujuan dari spesifikasi ini adalah untuk mendefinisikan sintaks yang ringkas dan familiar untuk mendefinisikan struktur pohon dengan atribut.

@StokeMasterJack - proposal Anda untuk masalah tag akhir terdengar sama dengan proposal saya beberapa waktu lalu.
Ide: Tag penutup yang dibuat secara otomatis

Saya pikir flutter membutuhkan sesuatu seperti ini. Saya berjuang dengan memasukkan widget baru di dalam sarang yang dalam hampir setiap hari. Saya akan menggunakan sintaks seperti JSX hanya untuk mendapatkan notasi tag akhir.

Saya tidak ingin harus menulis tag penutup. Ini menyebalkan di JSX/html/xml. Terutama ketika saya ingin melakukan refactor.
Saya pikir tag penutup virtual cukup rapi. Sepertinya kompromi yang baik antara kedua dunia.

Jika kami benar-benar membutuhkan beberapa perbaikan di sini, saya pikir kami dapat melanjutkan penjelajahan di sisi IDE. Misalnya, vscode menyediakan panel berikut:

(Cukup yakin Android Studio memiliki hal yang sama)

Alih-alih berhenti pada metode terfokus, kita juga dapat menambahkan konstruktor yang bersarang.
Sehingga ketika mengarahkan kelas tertentu kami akan mendapatkan UI berikut:

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

Jika ini tentang memisahkan widget secara visual dari jenis konten lain, IDE juga dapat melakukannya lagi.

Kita dapat memiliki penyorotan sintaks yang berbeda untuk widget. Alih-alih warna yang biasa digunakan untuk kelas, kita dapat memiliki warna khusus untuk subkelas widget

Jika ini tentang kemampuan edit, maka Flutter sudah menyediakan semua alat yang Anda butuhkan.

Ada beberapa opsi refactoring, termasuk:

• Bungkus menjadi widget baru
• Hapus widget
• Tukar widget dengan anak
• Tukar widget dengan orang tua

Dengan mengingat hal ini, Anda tidak perlu berurusan dengan tanda kurung lagi.

Sejujurnya, saya menghabiskan berjam-jam setiap hari bermain Flutter selama berbulan-bulan. Dan saya tidak merasakan kekurangan dalam keterbacaan atau ketidaknyamanan dalam menulis widget bersarang.
Sementara sebagai perbandingan, saya telah menggunakan React sebanyak mungkin dan ada _are_ beberapa hal yang membuat saya frustrasi.

@rrousselGit - opsi refactoring yang Anda miliki terdengar berguna. Saya tidak melihatnya di Android Studio 3.2.
Saya pikir Android Studio akan menyediakan fitur terbaik untuk pengembangan Flutter.

@Rockvole

Berikut adalah tangkapan layar dari Android Studio:

Diaktifkan sebagai perbaikan cepat Option+Enter (macOS).
Saya menggunakan ini sepanjang waktu, sangat membantu.

Pada topik: tampaknya tim Flutter sedang menjajaki opsi untuk "UI sebagai kode" dan kami mungkin akan mendapatkan lebih banyak peningkatan di bagian depan ini cepat atau lambat. Meskipun ide dari @StokeMasterJack terdengar menarik.

@Rockvole Pikiran yang hebat berpikir sama!

@StokeMasterJack

Balasan yang bagus!!!

Ada dua alasan mengapa JSX lebih masuk akal untuk React:

1. Struktur data: Di web, JSX sama persis dengan apa yang dihasilkan (node ​​DOM HTML). Dalam flutter, kami membuat instance Widget.

Kekuatan JSX bukan dalam menghasilkan node HTML/DOM, tetapi dalam mengelola hierarki komponen; React Native tidak memiliki node HTML/DOM kan?

1. Keakraban: Orang terbiasa melihat kode html. Tetapi proposal DSX menyimpang dari JSX/XML cukup untuk membatalkan poin ini.

Sama seperti di atas, ini bukan tentang kode HTML, ini tentang sintaks yang menjadi jelas terpisah dari konstruksi imperatif bahasa host dan meneriakkan markup deklaratif untuk membangun hierarki pohon .

Saya bukan penggemar proposal Anda atau Kotlin karena sepertinya peretasan dilakukan untuk menghindari pembuatan desain yang tepat. Alih-alih mendesain DSL yang terlihat berbeda, sekarang saya harus melihat kodenya dan mencoba mencari tahu apa fungsinya; Sintaksnya terlihat ambigu. Ada manfaat untuk memisahkan konstruksi imperatif dan deklaratif; Alat pihak ke-3 dapat dengan mudah menemukan markup XML di dalam kode misalnya.

@Rockvole

Saya akan menggunakan sintaks seperti JSX hanya untuk mendapatkan notasi tag akhir

Senang mendengarnya ;)

@rrousselGit

Saya tidak ingin harus menulis tag penutup.

Anda tidak harus; WebStorm misalnya otomatis menghasilkan tag penutup dan bahkan mengganti nama tag terbuka atau penutup saat Anda mengedit yang lain. Fungsionalitas editor yang sangat hebat yang harus diikuti orang lain (melihat Anda 'VS Code').

Sejujurnya, saya menghabiskan berjam-jam setiap hari bermain Flutter selama berbulan-bulan. Dan saya tidak merasakan kekurangan dalam keterbacaan atau ketidaknyamanan dalam menulis widget bersarang

Saya harap Anda dapat menghargai bahwa pengalaman Anda tidak mencerminkan pengalaman orang lain. Dengan tooling, menulis tidak sesulit membaca kode. Buka github untuk membaca kode orang lain dan Anda akan melihat bahwa membaca itu menyebalkan, kodenya terlalu bertele-tele dan panjang dengan struktur bersarang. Sepertinya ketika rantai janji digunakan sebelum async/menunggu menunjukkan cara yang lebih baik. Juga rasanya teknik deklaratif kurang penting daripada yang imperatif; Maksud saya mengapa tidak ada konstruksi grafik vektor deklaratif? alih-alih saya harus menggunakan panggilan penting ke Skia untuk menggambar grafik vektor misalnya.

Anda tidak harus; WebStorm misalnya menghasilkan otomatis

Vscode melakukan itu juga. Tapi itu masih belum sempurna. Terutama pada langkah refactoring saat memindahkan barang.
Saya pikir tag virtual memberikan pengalaman yang jauh lebih lancar di sini.

Saya harap Anda dapat menghargai bahwa pengalaman Anda tidak mencerminkan pengalaman orang lain

Tentunya ! Saya hanya ingin menunjukkan bahwa itu mungkin lebih merupakan pengalaman dengan perkakas daripada kekurangan yang sebenarnya

Pergi ke github untuk membaca kode orang lain dan Anda akan melihat bahwa membaca itu menyusahkan, [...]

Saya tidak begitu mengerti bagaimana argumen Anda di sini terkait dengan topik.
Masalah yang Anda daftarkan berasal dari praktik buruk, bukan sintaks yang buruk. Bukan salah Flutter jika orang ingin membuat pohon widget sepanjang 500.

@pulyaevskiy - terima kasih atas tip yang bermanfaat, di Linux perbaikan cepatnya adalah Alt-Enter. Bukan fitur yang sangat mudah ditemukan, saya menjelajahi opsi menu teratas tetapi sepertinya tidak ada di mana pun kecuali dengan penekanan tombol ajaib :)

Saya pikir tag virtual memberikan pengalaman yang jauh lebih lancar di sini.

Apakah tag virtual ini muncul pada file sumber di github misalnya?

Saya tidak begitu mengerti bagaimana argumen Anda di sini terkait dengan topik.

Pada dasarnya bahasa dapat memberikan konstruksi untuk membuat hal-hal kurang verbose seperti yang saya sebutkan dalam janji vs async/menunggu contoh. Di Flutter Widget, konstruktor sangat besar dan sering kali mereka mengambil banyak parameter; dengan DSX Anda dapat menggunakan operator spread misalnya untuk mengompresi konstruktor 10 baris menjadi konstruktor 1 baris dan karenanya Anda masih dapat memiliki hierarki pohon lengkap yang terlihat dengan lebih sedikit noise di sekitarnya. Ini membuat membaca kode lebih mudah dan memungkinkan pemisahan gaya yang bersih dari struktur pohon misalnya. Saya tidak mengatakan ini tidak dapat dilakukan dengan menyusun ulang kode Dart Anda, tetapi itu dapat dilakukan tanpa banyak usaha atau menyusun ulang hal-hal di sekitarnya. Anda tidak perlu menyesuaikan diri dengan keterbatasan bahasa, bahasa yang cocok untuk Anda.

Masalah yang Anda daftarkan berasal dari praktik buruk, bukan sintaks yang buruk.

Sebelum async/menunggu, praktik terbaik adalah menggunakan janji alih-alih panggilan balik acara gila di mana-mana. Menggunakan janji menyebabkan masalah keterbacaan yang ditangani oleh async/menunggu. Ini pada dasarnya adalah hal yang sama hanya gula sintaksis tetapi async/menunggu lebih jelas ketika membaca kode orang lain.

Ini adalah contoh yang buruk @woodstream

Pembaruan : Hanya untuk menegaskan maksud saya dan tidak hanya melontarkan kata-kata tanpa argumen. Setara dengan DSX sama panjangnya... Ini tidak ada hubungannya dengan jumlah baris, atau HTML.

class MusicImage extends StatelessWidget {

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

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

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

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

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

Sebagai pengembang React, menurut saya apa yang perlu dilakukan komunitas ini adalah menyediakan fitur ini sendiri dan ketika pengembang mulai mengadaptasinya dan benar-benar menggunakannya; kontributor utama akan dipaksa kemudian untuk mengadaptasinya secara asli juga. Saya seorang pengembang Bereaksi dan saya memiliki banyak masalah yang berhubungan dengan bagaimana UI ditulis dalam flutter, saya ingin pindah ke flutter tetapi sintaksnya tidak membantu, saya bahkan akan meneliti bagaimana mengimplementasikan sintaks seperti JSX sendiri, seperti yang dikatakan sebelumnya "Senang memiliki pilihan".

Saya pikir salah satu alasan utama orang menentang ini adalah mereka tidak dapat membayangkan mereka menggunakannya. Sebenarnya, Anda benar-benar tidak harus melakukannya, seperti yang digunakan orang (membandingkan untuk bereaksi) React.createElement(Component, {}, null) sebagai lawan dari <Component /> Jika ini diterapkan, ini akan menarik orang untuk menggunakan Flutter pada awalnya tempat, dan itulah yang kami inginkan. Komunitas besar yang didedikasikan untuk Flutter dengan dukungan satu sama lain. Jika itu bukan jenis sintaks yang akan Anda gunakan, oh well. Tetapi banyak orang lebih memilih notasi seperti BEJ dibandingkan dengan metode saat ini.

Secara pribadi saya pikir SGML dan turunannya sangat jelek. Jika kita melakukan DSL, mengapa tidak menggunakan sintaks seperti QML?

Saya juga berpikir beberapa poin pro-DSX adalah menggabungkan fitur Javascript sebagai bahasa (yang tidak dimiliki Dart sebagai bahasa) dan fitur JSX sebagai DSL. Contohnya,

Pada dasarnya bahasa dapat memberikan konstruksi untuk membuat hal-hal kurang verbose seperti yang saya sebutkan dalam janji vs async/menunggu contoh. Di Flutter Widget, konstruktor sangat besar dan sering kali mereka mengambil banyak parameter; dengan DSX Anda dapat menggunakan operator spread misalnya untuk mengompresi konstruktor 10 baris menjadi konstruktor 1 baris dan karenanya Anda masih dapat memiliki hierarki pohon lengkap yang terlihat dengan lebih sedikit noise di sekitarnya.

Itu bukan fitur yang akan diberikan DSX secara ajaib, itu adalah fitur yang dimiliki JSX karena Javascript memilikinya. Dart sebagai bahasa dapat memperoleh operator spread (IMO yang agak tidak mungkin), dalam hal ini Anda dapat menggunakannya dengan konstruktor dan panggilan fungsi lainnya tanpa memerlukan DSL khusus di atas segalanya. Ini juga merupakan fitur yang berfungsi sebagian besar karena objek, hashmap, dan array Javascript pada dasarnya adalah hal yang sama, yang pasti tidak terjadi pada Dart dan hampir pasti tidak akan pernah berubah.

Dan yang menurut saya adalah masalah yang dimiliki banyak orang yang menentang proposal tersebut meskipun tidak disuarakan - pada dasarnya ini adalah permintaan agar Dart berperilaku (atau berpura-pura berperilaku) seperti Javascript, dan meskipun ada beberapa pro, faktanya adalah bahwa mereka hanyalah bahasa yang berbeda yang telah semakin menyimpang sejak awal Dart 1.

Sunting: Yang tidak berarti bahwa markup/pemodelan DSL untuk UI sepenuhnya merupakan ide yang buruk. Sejujurnya tidak, tetapi saya pikir inspirasi untuk itu harus berasal dari bahasa/kerangka kerja yang sedikit lebih mirip dengan Dart/Flutter (dalam paradigma pengetikan serta detail semantik lainnya - saya tidak berbicara tentang sintaksis biasa) daripada Javascript adalah.

Dart sebagai bahasa dapat memperoleh operator spread (IMO yang agak tidak mungkin)

Sebenarnya penyebaran untuk koleksi sudah ditentukan dan siap untuk diimplementasikan, lihat Koleksi Tersebar dan seluruh "corong Bahasa" untuk info lebih lanjut tentang fitur bahasa Dart yang akan datang.

@mraleph Saya sedang berbicara tentang operator spread yang secara khusus digunakan dalam panggilan fungsi/konstruktor dan dengan objek, bukan hanya dengan Daftar atau Peta - itulah yang menurut saya tidak mungkin. Maaf jika itu tidak jelas!

(Saya samar-samar mengetahui proposal itu, tetapi terakhir saya memeriksanya, Anda tidak bisa hanya menyebarkan Dart Size(10, 10) cara Anda dapat menyebarkan/menghancurkan Javascript Size { width: 10, height: 10 } , atau menyebarkan daftar /map argumen menjadi panggilan fungsi normal (tidak menggunakan Function.apply , yang akan mengorbankan keamanan tipe))

@filluchaos

Secara pribadi saya pikir SGML dan turunannya sangat jelek. Jika kita melakukan DSL, mengapa tidak menggunakan sintaks seperti QML?

Karena banyak orang, tidak seperti Anda, tidak menganggapnya jelek dan lebih menyukainya. Anda tidak harus memiliki banyak visi untuk melihat semua pengembang React yang antusias di luar sana.

JSX/DSX membawa markup ke dalam bahasa host Javascript/Dart dengan cara yang meningkatkan bahasa host dan memungkinkan semua konstruksi bahasa program pada markup. Hal yang sangat sederhana dan kuat.

Itu bukan fitur yang akan diberikan DSX secara ajaib, itu adalah fitur yang dimiliki JSX karena Javascript memilikinya.

Tidak benar sama sekali; DSX dapat mengimplementasikan spread dengan sendirinya, tidak perlu Dart untuk mendukungnya. Akan lebih baik jika itu dilakukan tetapi bukan persyaratan. Itulah indahnya transpiling dari bahasa yang lebih tinggi ke Dart, bahasa yang lebih tinggi tidak perlu dibatasi oleh Dart.

Prototipe transpiler DSX online saya memproses operator spread dengan baik, periksa:
https://spark-heroku-dsx.herokuapp.com/index.html

Dan yang menurut saya adalah masalah yang dimiliki banyak orang yang menentang proposal tersebut meskipun tidak disuarakan - pada dasarnya ini adalah permintaan agar Dart berperilaku (atau berpura-pura berperilaku) seperti Javascript, dan meskipun ada beberapa pro, faktanya adalah bahwa mereka hanyalah bahasa yang berbeda yang telah semakin menyimpang sejak awal Dart 1.

Berhentilah memikirkan apa itu Dart saat ini dan fokuslah pada apa yang bisa terjadi dengan mengambil ide-ide terbaik dari semua bahasa lain di luar sana.

Saya pikir inspirasi untuk itu harus berasal dari bahasa/kerangka kerja yang sedikit lebih mirip dengan Dart/Flutter (dalam paradigma pengetikan serta detail semantik lainnya - saya tidak berbicara tentang sintaks biasa) daripada Javascript.

TypeScript diketik dan mendukung JSX. Kerangka kerja UI yang paling dekat dengan Flutter adalah React, dan coba tebak apa yang dilakukan React karena JSX. Tolong buat sesuatu yang lebih baik daripada JSX/DSX dan jika Anda melakukannya, orang akan berhenti meminta JSX/DSX tapi saya belum melihat apa pun di luar sana yang saya anggap lebih baik jadi sekarang JSX adalah yang paling mutakhir .

Sangat menyenangkan untuk melihat bahwa orang-orang bahasa Dart mengambil ide-ide terbaik dari bahasa lain seperti Python (daftar & pemahaman kamus).

@cbazza

Karena banyak orang, tidak seperti Anda, tidak menganggapnya jelek dan lebih menyukainya.

Dan sebaliknya. Mengapa sintaks yang satu ini dan bukan yang lain, terutama ketika tidak benar-benar memiliki hubungan yang kuat dengan bahasa? (Dengan SDK Android, Java dan XML telah memiliki hubungan selama bertahun-tahun. Begitu pula dengan Javascript dan HTML, yang sangat mirip dengan JSX. DSX seperti yang diusulkan akan membawa sintaks SGML berdasarkan itu masuk akal untuk bahasa lain tetapi tidak harus untuk _Dart_).

JSX/DSX membawa markup ke dalam bahasa host Javascript/Dart dengan cara yang meningkatkan bahasa host dan memungkinkan semua konstruksi bahasa program pada markup. Hal yang sangat sederhana dan kuat.

Tidak benar sama sekali; DSX dapat mengimplementasikan spread dengan sendirinya, tidak perlu Dart untuk mendukungnya. Akan lebih baik jika itu dilakukan tetapi bukan persyaratan. Itulah indahnya transpiling dari bahasa yang lebih tinggi ke Dart, bahasa yang lebih tinggi tidak perlu dibatasi oleh Dart.

Agak menarik untuk melihat dua pernyataan ini secara berdampingan, karena mereka hanya membuktikan maksud saya. JSX sangat bagus (untuk Javascript) khususnya karena kesederhanaannya - itu hanya gula atas apa yang sudah menjadi konstruksi bahasa JS, itu tidak benar-benar mengimplementasikan semantik khusus itu sendiri. Anda benar memuji kesederhanaan itu, kemudian melanjutkan dengan mengatakan bahwa DSX harus mengimplementasikan semantik dengan sendirinya terlepas dari bahasa target tampaknya tanpa mengenali 1) berapa banyak lagi pekerjaan yang harus diminta, dan 2) bagaimana itu sepenuhnya mengalahkan titik menjadi a DSL sederhana namun kuat.

Prototipe transpiler DSX online saya memproses operator spread dengan baik, periksa:
https://spark-heroku-dsx.herokuapp.com/index.html

Saya telah melihat transpiler Anda sebelumnya, dan meskipun ini adalah pekerjaan yang mengesankan, itu sama sekali tidak mendekati pemrosesan operator spread seperti yang dilakukan Javascript sebagai bahasa (dan dengan demikian JSX) secara default. Seperti yang telah disebutkan, menyebarkan (dan akhirnya merusak) koleksi tidak terlalu bertentangan dengan Dart, dan sebenarnya sedang dalam proses untuk diimplementasikan. Menyebarkan dan merusak objek apa pun (yang, tidak seperti di JS, sangat tidak sama dengan Maps), dan transpiler Anda tampaknya juga tidak menanganinya (dan sebenarnya membutuhkan argumen di dalam Maps, yang agak unidiomatik dan Dart yang tidak dapat digunakan (misalnya, tidak dapat berinteraksi dengan cara yang aman untuk tipe yang sopan)).

Berhentilah memikirkan apa itu Dart saat ini dan fokuslah pada apa yang bisa terjadi dengan mengambil ide-ide terbaik dari semua bahasa lain di luar sana.

Tentu. Tetapi dari bahasa di luar sana untuk Dart untuk diangkat, secara pribadi JS tidak terlalu tinggi dalam daftar - sejujurnya saya berpikir mencoba terlalu banyak seperti JS (demi interoperabilitas) melumpuhkan Dart di hari-hari awalnya.

Saya akan menyukai UI DSL, tentu saja. Tapi DSL itu harus idiomatis untuk _Dart_, tidak diangkat dari bahasa yang berbeda secara semantik karena popularitas saja.

Dan saya juga ingin orang-orang berhenti mencampuradukkan apa yang dilakukan Javascript dengan apa yang dilakukan JSX oleh DSL, karena beberapa manfaat yang disebutkan sebenarnya adalah permintaan fitur tingkat bahasa yang menyamar. Untuk melanjutkan operator spread, jika Dart sebagai bahasa benar-benar mendukung seluruh operator seperti di JS maka saya tidak melihat bagaimana return <SomeWidget {...someArgs, arg: newValue } />; lebih disukai untuk dibaca daripada return SomeWidget(...someArgs, arg: newValue); atau return SomeWidget { ...someArgs, arg: newValue }; mirip QML kecuali ada yang memiliki lampiran ke SGML.

@filluchaos

Mengapa sintaks yang satu ini dan bukan yang lain, terutama ketika tidak benar-benar memiliki hubungan yang kuat dengan bahasa? (Dengan SDK Android, Java dan XML telah memiliki hubungan selama bertahun-tahun. Begitu pula dengan Javascript dan HTML, yang sangat mirip dengan JSX. DSX seperti yang diusulkan akan membawa sintaks SGML berdasarkan itu masuk akal untuk bahasa lain tetapi tidak harus untuk Dart).

Berhentilah memasangkan hal-hal yang menurut Anda berjalan bersama (dan memiliki hubungan) dan fokuslah untuk memilih ide-ide terbaik terlepas dari dari mana asalnya. Anda adalah jenis memisahkan hal-hal artifisial ketika tidak perlu untuk itu.

Saya memilih sintaks JSX karena ini dianggap baik di React dan itulah yang diharapkan dan diinginkan orang-orang React. Tiket ini tentang itu, jika itu bukan untuk Anda, jangan gunakan itu.

Agak menarik untuk melihat dua pernyataan ini secara berdampingan, karena mereka hanya membuktikan maksud saya. JSX sangat bagus (untuk Javascript) khususnya karena kesederhanaannya - itu hanya gula atas apa yang sudah menjadi konstruksi bahasa JS, itu tidak benar-benar mengimplementasikan semantik khusus itu sendiri. Anda benar memuji kesederhanaan itu, kemudian melanjutkan dengan mengatakan bahwa DSX harus mengimplementasikan semantik dengan sendirinya terlepas dari bahasa target tampaknya tanpa mengenali 1) berapa banyak lagi pekerjaan yang harus diminta, dan 2) bagaimana itu sepenuhnya mengalahkan titik menjadi a DSL sederhana namun kuat.

Apakah itu mengimplementasikan semantik baru atau tidak, itu tidak relevan. Kesederhanaan berasal dari penggunaannya. Jika mudah digunakan oleh pengguna/pengembang, mereka akan menggunakannya. Pengguna/Pengembang tidak peduli tentang seberapa rumit sesuatu secara internal (atau seberapa banyak pekerjaan yang harus dilakukan), mereka hanya peduli betapa sederhananya itu membuat hidup mereka dan meningkatkan kode mereka.

Saya telah melihat transpiler Anda sebelumnya, dan meskipun ini adalah pekerjaan yang mengesankan, itu sama sekali tidak mendekati pemrosesan operator spread seperti yang dilakukan Javascript sebagai bahasa (dan dengan demikian JSX) secara default.

Niat saya dengan spread di DSX hanya untuk menyebarkan atribut dan bukan implementasi spread JS yang lengkap. Ini berfungsi dengan baik untuk apa adanya dan tidak memiliki masalah keamanan jenis sama sekali. Pengecekan/kebenaran tipe terjadi ketika Dart mengkompilasi apa yang dihasilkan DSX.

melumpuhkan Dart di hari-hari awalnya.

Apa yang melumpuhkan Dart di hari-hari awal tidak menyediakan interoperabilitas JS sederhana sehingga perpustakaan JS saat ini dapat digunakan dengan mudah dengan kode Dart (dan sebaliknya). Juga ini adalah alasan yang sama persis mengapa TypeScript berhasil di mana Dart gagal.

Saya akan menyukai UI DSL, tentu saja. Tapi DSL itu harus idiomatis untuk Dart, tidak diangkat dari bahasa yang berbeda secara semantik karena popularitas saja.

Popularitas menentukan segalanya. Ide terbaik adalah ide terbaik karena menjadi populer karena banyak orang menghargai manfaatnya.

Dan saya juga ingin orang-orang berhenti mencampuradukkan apa yang dilakukan Javascript dengan apa yang dilakukan JSX oleh DSL, karena beberapa manfaat yang disebutkan sebenarnya adalah permintaan fitur tingkat bahasa yang menyamar.

Sekali lagi ini tidak relevan.

Apa yang benar-benar kami butuhkan dari orang-orang Google (Dart/Flutter) adalah dukungan transpiling umum melalui peta sumber sehingga setiap bahasa tingkat yang lebih tinggi dapat dikembangkan yang menargetkan Dart/Flutter dan itu akan berfungsi dengan baik dengan alat saat ini (IDE, debugger, dll) . Tingkatkan lapangan permainan dan Anda menjamin ide-ide terbaik akan datang ke platform dari orang lain.

@cbazza

Saya memilih sintaks JSX karena ini dianggap baik di React dan itulah yang diharapkan dan diinginkan orang-orang React. Tiket ini tentang itu, jika itu bukan untuk Anda, jangan gunakan itu.

Itu tampaknya agak memecah belah dan agak berhak untuk saya. Mengapa Flutter harus memiliki dukungan kelas satu untuk sintaks React khusus? Mengapa bukan file komponen Vue, atau sintaks Xamarin.Forms? Mengapa (mungkin resmi) UI DSL untuk Flutter harus didasarkan pada apa yang diharapkan dan diinginkan oleh sekelompok orang tertentu yang menggunakan kerangka kerja berbeda dalam bahasa yang berbeda? Jika Anda menginginkan alat komunitas khusus untuk pengembang React/JS, itu adalah satu hal. Tetapi meminta kerangka itu sendiri untuk memasukkannya semata-mata untuk melayani Anda semua adalah IMO yang sedikit berlebihan.

Apakah itu mengimplementasikan semantik baru atau tidak, itu tidak relevan. Kesederhanaan berasal dari penggunaannya. Jika mudah digunakan oleh pengguna/pengembang, mereka akan menggunakannya. Pengguna/Pengembang tidak peduli tentang seberapa rumit sesuatu secara internal (atau seberapa banyak pekerjaan yang harus dilakukan), mereka hanya peduli betapa sederhananya itu membuat hidup mereka dan meningkatkan kode mereka.

Ini adalah bentuk hak yang aneh menurut saya. Dan tidak, pengembang akan peduli tentang betapa kompleksnya implementasi ketika mulai menyebabkan masalah dan penyimpangan fitur seperti yang cenderung terjadi pada kompleksitas abstraksi. Pengembang yang ingin melakukan lebih dari sekadar menggunakan DSL - memperluasnya, misalnya - pasti akan peduli dengan betapa rumitnya implementasinya. Pengembang yang harus membangun dan memeliharanya juga orang-orang yang layak dipertimbangkan dalam hal ini.

Niat saya dengan spread di DSX hanya untuk menyebarkan atribut dan bukan implementasi spread JS yang lengkap. Ini berfungsi dengan baik untuk apa adanya dan tidak memiliki masalah keamanan jenis sama sekali. Pengecekan/kebenaran tipe terjadi ketika Dart mengkompilasi apa yang dihasilkan DSX.

Itu hanya "tidak memiliki masalah keamanan tipe" jika Anda tidak memikirkannya sama sekali. Apa yang saya katakan adalah bahwa Peta argumen tidak _dapat digunakan_ dengan cara yang sepenuhnya aman dengan basis kode Dart lainnya, di mana mungkin Anda ingin berinteraksi dengan argumen itu seperti yang Anda bisa dengan alat peraga dan semacamnya dalam JavaScript - meneruskannya dari yang lain Widget, impor mereka dari modul lain, dll - dan tidak hanya mendeklarasikannya di satu tempat, dalam hal ini apa gunanya panggilan konstruktor normal?

Untuk mengilustrasikan apa yang saya maksud, Anda dapat melakukan ini di JS:

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

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

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

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

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

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

Tetapi dengan Dart dan transpiler Anda yang membutuhkan hashmaps argumen:

class MyCustomSize {
  int length, width, height;

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

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

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

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

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

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

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

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

Apa yang melumpuhkan Dart di hari-hari awal tidak menyediakan interoperabilitas JS sederhana sehingga perpustakaan JS saat ini dapat digunakan dengan mudah dengan kode Dart (dan sebaliknya). Juga ini adalah alasan yang sama persis mengapa TypeScript berhasil di mana Dart gagal.

Interop Dart dengan JS tidak pernah rumit, kecuali (dan ini adalah poin yang saya tekankan) Anda hanya ingin tetap menulis Javascript dan menolak mempelajari hal lain. TypeScript menjadi superset tidak begitu banyak memiliki operabilitas dengan JS seperti halnya JS, sampai-sampai sengaja memiliki sistem tipe yang tidak sehat hanya untuk memenuhi JS (dan juga tidak ada runtime untuk benar-benar menegakkan sistem tipe ekspresifnya, yang merupakan sangat memalukan selama bertahun-tahun). Tetapi kembali ke poin saya, saya pribadi merasa Dart membuat beberapa keputusan desain yang buruk demi JS dan Dart 2 seharusnya menjadi iterasi pertama bahasa tersebut.

Popularitas menentukan segalanya. Ide terbaik adalah ide terbaik karena menjadi populer karena banyak orang menghargai manfaatnya.

"Terbaik", atau lebih tepatnya ide bagus adalah ide bagus karena memiliki kelebihan . Terkadang mereka menjadi populer, terkadang tidak. Terkadang ide buruk menjadi populer, terkadang tidak. Menyatakan bahwa popularitas adalah indikator langsung dari prestasi sejujurnya tidak masuk akal dan merupakan sikap yang saya pribadi lebih suka tidak tumpah ke komunitas Dart, sekecil apa pun itu.

Apa yang benar-benar kami butuhkan dari orang-orang Google (Dart/Flutter) adalah dukungan transpiling umum melalui peta sumber sehingga setiap bahasa tingkat yang lebih tinggi dapat dikembangkan yang menargetkan Dart/Flutter dan itu akan berfungsi dengan baik dengan alat saat ini (IDE, debugger, dll) . Tingkatkan lapangan permainan dan Anda menjamin ide-ide terbaik akan datang ke platform dari orang lain.

...Saya tidak berpikir itu mungkin untuk menjadi lebih berhak daripada Anda sebelumnya, namun di sinilah kita. Mengapa SDK UI yang satu ini harus dapat ditargetkan oleh setiap bahasa tingkat tinggi di dunia? Sekali lagi proposal dengan kuat, kuat muncul sebagai "Jadikan Dart/Flutter ke dalam bahasa/kerangka kerja saya" - Anda sebaiknya langsung keluar dan mengatakan Anda ingin membangun aplikasi Flutter dengan Javascript. Dan ya, lebih banyak minyak ke siku Anda dan saya akan berkontribusi pada proyek komunitas seperti itu, tetapi terus terang konyol untuk mengharapkan jawaban positif jika Anda meminta dukungan resmi untuk itu.

Sekali lagi mengulangi - Saya tidak keberatan dengan UI DSL dan akan sangat menyukainya. Tetapi jika kami meminta tim untuk memanggangnya, itu harus menjadi DSL yang merupakan idiomatis untuk Dart. Karena ya, ada lusinan dari kita di sini yang benar-benar menyukai Dart sebagai bahasa.

Namun suntingan lain: Adalah satu hal untuk meminta DSL, menyarankan JSX sebagai kemungkinan inspirasi sintaks/sintaks, dan terbuka untuk saran lain. Ini adalah desakan pada DSX yang menggosok saya (dan saya menduga banyak yang berkomentar) salah.

@filluchaos

Anda sangat bingung dan saya tidak punya banyak waktu untuk disia-siakan.

Satu-satunya hal yang saya minta dari tim Dart/Flutter adalah apa yang saya katakan sebelumnya:

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

Itu menyediakan semua yang diperlukan untuk mengimplementasikan DSX, file komponen Vue, Xamarin.Forms, NativeScript, QML, dll. dan oleh karena itu akan memungkinkan komunitas untuk menghasilkan apa pun yang mereka inginkan dan tidak ada yang harus 'mengambil' DSX saya. Tidak suka DSX, Anda dapat menggunakan Dart biasa atau membuat sendiri dengan mudah.

Saya akan mengatakan Anda sedang mencari hal-hal seperti https://github.com/dart-lang/build dan dartanalyzer.
Anda mungkin akan kehilangan satu atau dua bagian (seperti kemampuan untuk membuat plugin penganalisis sebagai ketergantungan pub), tapi saya cukup yakin Tim Dart baik-baik saja dengan membantu dengan itu.

Bagaimanapun, saya tidak berpikir bersikap kasar satu sama lain terus menerus akan membantu kerangka kerja berkembang dengan cara apa pun.
Yang paling kita dapatkan dari ini adalah masalah lain yang ditutup secara permanen karena "terlalu panas".

@filluchaos

Mengenai contoh 'foo' Anda, spread DSX adalah waktu kompilasi sehingga peta perlu didefinisikan sebagai const atau saya dapat membuat apa pun yang saya ingin buat yang terjadi pada waktu kompilasi (misalnya membuat kata kunci DSX baru atau anotasi untuk itu diikuti oleh peta const). Itu harus pada waktu kompilasi, bukan pada waktu berjalan, karena Dart tidak mendukung penyisipan parameter konstruktor dinamis pada waktu berjalan. Bukan masalah karena menyelesaikan masalah yang ingin saya selesaikan, yaitu menyebarkan atribut pada konstruktor.

@cbazza Intinya adalah bahwa bagian dari apa yang membuat operator spread sangat berguna di JS/JSX adalah Anda tidak perlu memaksakan batasan seperti "Anda hanya dapat menggunakan hashmap" atau "semua argumen Anda harus diketahui pada waktu kompilasi" atau "Anda tidak dapat berinteraksi dengan argumen/alat peraga yang ingin Anda berikan ke Widget dengan cara yang sama seperti Anda berinteraksi dengan yang lainnya" (perhatikan bahwa Anda belum menyarankan apa pun untuk menangani kasus di mana benda dengan properti Anda need sebenarnya adalah objek, bukan literal peta) -0 semuanya baik-baik saja ketika itu adalah contoh sederhana, tetapi hal semacam itu akan membuat _fast_ sangat frustasi dalam proyek berukuran sedang apa pun. Maksud saya, pada titik mana seseorang berhenti menumpuk solusi dan kompromi dan anotasi, mundur selangkah dan bertanya-tanya apakah ekstensi tersebut sebenarnya cocok untuk bahasa yang ada?

BEJ sangat sukses (dibandingkan dengan kebanyakan templat) karena tidak memaksa Anda untuk memprogram dengan cara tertentu (atau lebih tepatnya, tidak memaksa Anda untuk menulis kode secara berbeda dari yang Anda miliki di Javascript). Cukup mudah untuk digunakan dengan _any_ JavaScript; inilah yang saya maksud dengan membuat DSL yang benar-benar sesuai dengan bahasa. Ini hal yang mirip dengan Redux. Redux dalam basis kode JS adalah hal yang indah (bila digunakan dengan benar); di sisi lain semua contoh Flutter yang saya lihat menggunakan Redux secara ekstensif jujur ​​saja terlihat menyakitkan dibandingkan dengan menggunakan Streams/pola BLoC. Itu tidak berarti bahwa tidak ada hal-hal yang tumpang tindih dengan kesuksesan besar: Context InheritedWidget Flutter menerapkan konsep umum yang memenuhi kekuatan keduanya dengan sangat baik. Saya hanya tidak yakin bahwa JSX saat ini adalah salah satu dari hal-hal itu - kecuali beberapa perubahan tingkat bahasa, sejujurnya sepertinya DSX akan menyusahkan untuk mengembangkan _dan_ rasa sakit untuk digunakan untuk sesuatu yang lebih dari contoh sepele, sedangkan orang mungkin bisa menulis transformator JSX lengkap fitur dari awal di akhir pekan yang malas karena betapa mudahnya memetakan ke JS.

Saya juga sedikit agresif sebelumnya dan saya minta maaf.

@filluchaos

Saya tidak mencoba membuat operator spread yang sepenuhnya generik yang berfungsi di mana saja dan untuk semuanya, bahkan yang direncanakan untuk Dart di masa depan tidak segenerik milik JS. Apa yang ingin saya sebarkan untuk ditangani dalam konteks DSX itu baik-baik saja. DSX tidak perlu menyebarkan objek misalnya.

Sebarkan Koleksi
https://github.com/dart-lang/language/issues/47

Saya telah mengembangkan proyek super besar dengan JSX dan benar-benar tidak pernah perlu menggunakan spread pada atribut tag. BEJ bekerja dengan baik tanpanya. Alasan saya menambahkan ke DSX adalah karena ini memecahkan masalah untuk widget Flutter sehingga tidak ada solusi sederhana untuk itu, khususnya jika widget membutuhkan 20 parameter pada konstruktor, bagaimana Anda bisa menulisnya dalam waktu kurang dari 20 baris berkelanjutan yang akan membuat widget pohon piramida malapetaka. Satu-satunya fitur penyebaran DSX adalah memungkinkan pengambilan beberapa garis tersebut dari pohon dan meletakkannya di tempat lain.

@cbazaa Saya mengevaluasi apakah akan menggunakan React Native atau Flutter. Condong ke Flutter karena semuanya hanya Dart sehingga kompiler dapat memeriksa kesalahan ketik UI saya. Lihat juga: https://medium.com/flutter-io/out-of-depth-with-flutter-f683c29305a8

Apakah BEJ juga menemukan kesalahan ketik saya? Saya menggunakan TypeScript.

Saya benci HTML / markup terpisah. Misalnya, di Angular, jika saya salah mengetik sesuatu/variabel dalam HTML, saya hanya menemukan kesalahan saya setelah merender halaman.

@sivabudh

Apakah BEJ juga menemukan kesalahan ketik saya? Saya menggunakan TypeScript.

Ya, beberapa kesalahan ketik JSX ditangkap pada waktu kompilasi (misalnya nama komponen) tetapi bukan nama prop (yang akan ditangkap pada waktu proses) saat menggunakan JS/ES6; tetapi karena Anda menggunakan TypeScript, sistem tipe menangkap semua kesalahan ketik JSX pada waktu kompilasi:
https://www.typescriptlang.org/docs/handbook/jsx.html

@cbazza adalah dsx open source?

@pushqrdx
Belum, saya belum merilis kode sumbernya.

Sebagai konsumen React + TypeScript dan Flutter, saya dapat menawarkan diri saya sebagai penguji. Bersulang

Apakah kita akan memiliki sumber dsx? Ini akan sangat bagus!

Saya memuji upaya cbazza tetapi saya tidak akan menggunakan DSX di Flutter. Senang untuk mengujinya, meskipun.

Masalah #27141 melacak penambahan dukungan pembuatan kode ke sistem build. Ini akan dilakukan melalui https://github.com/dart-lang/build dengan Builder . Secara teori seharusnya cukup sederhana untuk memasang kompiler/transpiler dsx ketika fitur ini sudah siap.

Setelah dua masalah, saya bertemu tim yang keras kepala untuk pertama kalinya.

Ini bukan diskusi tentang BEJ, tapi diskusi tentang neraka bersarang

Bahkan jika Anda tidak dapat memberikan solusi JSX, Anda harus membuat sarang lebih sedikit dan kode lebih mudah dibaca

Saya pikir keuntungan dari JSX sudah jelas, tetapi tim flutter mencoba untuk mengabaikannya.

BEJ tidak menyelesaikan masalah bersarang. Bereaksi menghadapi masalah yang sama

Jika Anda tidak suka bersarang itu, Anda mungkin ingin melihat hooks , yang merupakan port dari React hooks, yang dengan sendirinya merupakan upaya untuk memecahkan neraka bersarang.

Saya pikir kita harus mencari tahu mengapa BEJ muncul. Itu karena fungsi h/createElement ditulis dengan buruk dan kodenya tidak terbaca dengan baik. Tanpa diduga, flutter sekarang ditulis 10.000 kali lebih buruk daripada fungsi h/createElement , yang dapat dilihat dari mata

JSX muncul karena React, pada intinya, merupakan perpaduan antara Javascript dan HTML. Sintaks XML dengan interpolasi/injeksi Javascript secara alami membuat JSX.

Flutter benar-benar terpisah dari Javascript dan HTML, sehingga tidak diterjemahkan dengan baik ke dalam JSX. Saya setuju bahwa proyek Flutter seringkali sangat bersarang dan itu bisa sangat menyebalkan, terutama ketika dartfmt menghancurkan garis-garis yang sangat bersarang ini. Mengerikan.

Saya juga mencatat bahwa saya merasa Flutter sangat terstruktur ketika saya baru mengenalnya, berasal dari React, tetapi Flutter secara objektif jauh lebih mudah untuk dikerjakan ketika Anda melewati kurva pembelajaran awal. Kurva pembelajaran tidak unik untuk Flutter, itu umum saat mempelajari kerangka kerja baru. Flutter sangat sulit karena tidak memiliki alasan untuk bertindak seperti sintaks HTML yang dikenal banyak orang.

Saya pikir ada cara untuk memperbaiki masalah bersarang, dan JSX bukanlah jawabannya.

Beberapa ide:

1. Kembangkan panduan gaya internal yang mengharuskan orang untuk memecah pohon bergetar besar menjadi komponen yang lebih kecil.

2. Dapatkan dartfmt untuk secara formal mengenali bahwa Flutter memiliki serangkaian kebutuhan pemformatan yang unik dibandingkan dengan paket Dart dan bekerja dengan tim Flutter/Dart untuk menghasilkan solusi yang masuk akal. @banyak sekali

3. Gunakan pembuatan kode seperti paket @stateless @rrousselGit untuk memudahkan pengembang melakukan nomor 1

Agar adil, masalah bersarang sebagian besar muncul ketika tidak ingin membiaskan kode kita.

Widget dibuat untuk dipecah menjadi banyak bagian yang lebih kecil.
Menggunakan dan menyalahgunakan alat pemfaktoran ulang extract widget .

Ini membuat kode lebih mudah dibaca, mengurangi redundansi, dan bahkan berpotensi memperbaiki bug/meningkatkan kinerja.

Sementara saya setuju untuk sebagian besar, widget Flutter sangat tinggi sehingga saya telah melihat banyak orang melakukan seluruh tampilan dalam satu widget karena ... itu benar-benar berfungsi dengan sangat baik dan Anda tidak harus menurunkan props melalui 4-5 tingkat widget. Apa yang hilang dalam proses ini adalah Anda mendapatkan kode bersarang yang mengerikan ini yang dartfmt menabrak sesuatu yang tidak dapat dikenali. Jadi saya mengerti mengapa orang melakukannya, saya mengerti bahwa ada solusi, tetapi saya juga mengerti mengapa orang tidak menggunakan solusi tersebut.

JSX muncul karena React, pada intinya, merupakan perpaduan antara Javascript dan HTML. Sintaks XML dengan interpolasi/injeksi Javascript secara alami membuat JSX.

Bagaimana Anda menjelaskan fakta bahwa React Native menggunakan JSX dan tidak ada hubungannya dengan HTML?

Bagaimana Anda menjelaskan fakta bahwa React Native menggunakan JSX dan tidak ada hubungannya dengan HTML?

Karena menggunakan React. Mereka mungkin tidak ingin menemukan kembali sintaks

Karena menggunakan React. Mereka mungkin tidak ingin menemukan kembali sintaks

Jadi JSX sebenarnya bukan perpaduan Javascript & HTML seperti yang dinyatakan oleh @lukepighetti tetapi lebih merupakan XML-like syntax extension to ECMAScript without any defined semantics... who's purpose is to define a concise and familiar syntax for defining tree structures with attributes.
Semuanya dijabarkan dalam spesifikasi: https://facebook.github.io/jsx/

Seperti yang saya pahami, React pertama kali dirilis sebagai react + react-dom dengan kompiler jsx , jadi campuran HTML + JavaScript adalah natural. Setelah itu, react digunakan untuk menggerakkan penyaji lain seperti react-native , react-vr , react-pdf , dll. Jadi saya tetap berpegang pada pernyataan asli saya sebagai masuk akal dan sensitif terhadap sejarah dan silsilah React. Spesifikasi 2019 adalah spesifikasi pada 2019 dan tidak membahas sejarah React.

saya setuju

Tapi bagi saya ada masalah yang lebih besar. Vue dan React bekerja sama dalam aspek itu.
React memiliki createElement dan Vue memiliki fungsi h .

Kami tidak pernah membuat instance komponen secara manual di React dan Vue. Ini adalah kerangka kerja yang menanganinya.

Flutter berperilaku berbeda. Kami secara langsung memanipulasi instance Widget.

Dengan demikian di dunia Flutter, <Foo /> berarti new Foo()

Namun dalam hal ini, BEJ sama sekali tidak terkait dengan Widget. Kami hanya mengubah sintaks bagaimana kami membuat instance kelas di dart.

Bagi saya ini terdengar seperti kita kehilangan arti dari apa itu membuat widget.

@lukepighetti
react-pdf bukan penyaji reaksi lain, Anda pasti memikirkan react-canvas .
Jadi react != react-dom != react-native . Paket react bertanggung jawab untuk mengelola hierarki komponen dengan bantuan JSX jadi react tidak peduli apakah itu menghasilkan react-dom , react-native , react-canvas , jadi react sebenarnya bukan tentang HTML.

Spesifikasi 2019 adalah spesifikasi pada 2019 dan tidak membahas sejarah React.

Tidak ada yang namanya spek BEJ 2019. Hanya ada satu versi BEJ dan itu adalah versi asli yang diterbitkan pada tahun 2014 dari tautan yang saya berikan (https://facebook.github.io/jsx/).

@rrousselGit

Kami hanya mengubah sintaks bagaimana kami membuat instance kelas di dart.

Untuk kasus DSX dengan Flutter, itulah yang dilakukan transpiler.

Bagi saya ini terdengar seperti kita kehilangan arti dari apa itu membuat widget.

Bagaimana Anda bisa kehilangan sesuatu jika tidak ada yang dihapus, Anda hanya mendapatkan cara lain untuk melakukan sesuatu (yang memiliki manfaat & kekurangan) dan sekarang Anda memiliki kebebasan memilih, pilih salah satu yang paling cocok untuk Anda.

Hai, saya yakin Anda mungkin salah paham dengan pesan saya. react menggerakkan penyaji reaksi lain seperti react-dom , react-native , react-pdf , react-vr , dll. Afaik, react dan react-dom dirilis secara bersamaan sehingga warisan jsx , menurut saya, cukup jelas. Saya harap Anda tidak menggali pesan saya karena kami memiliki pendapat yang berbeda tentang nilai JSX dalam konteks Flutter. Mungkin akan lebih baik untuk tetap pada topik dan tidak membagi rambut.

Hai lukepighetti , apakah Anda pernah menggunakan react native dengan JSX selama satu hingga dua bulan? Jika demikian, Anda harus memahami mengapa membangun aplikasi dengan BEJ DAN bereaksi asli (atau bereaksi, saya tahu mereka berbeda) gaya kerangka kerja sederhana dan struktur yang baik.
Namun, jika Anda tidak menggunakannya untuk jangka waktu tertentu, Anda tidak akan pernah mengerti mengapa BEJ sangat membantu dan penting.

Saya masih berharap Google dapat memahami keindahan BEJ, dan karena kami memiliki banyak orang yang mendukung ini. Tim Google mungkin suatu hari nanti memikirkan DSX atau JSX untuk kerangka kerja yang terinspirasi dari React, flutter.

Hai lukepighetti , apakah Anda pernah menggunakan react native dengan JSX selama satu hingga dua bulan? Jika demikian, Anda harus memahami mengapa membangun aplikasi dengan gaya kerangka kerja asli JSX DAN React (atau React, saya tahu mereka berbeda) adalah sederhana dan terstruktur dengan baik.

Saya tidak dapat berbicara untuk lukepighetti, tetapi saya telah bekerja secara profesional dengan React selama dua tahun, sekarang melakukan beberapa Vue. Jadi saya cukup berpengalaman dalam hal JSX.

Demikian pula, saya telah menggunakan Flutter selama sekitar 2 tahun juga. Pada awalnya, saya juga berpikir bahwa Flutter membutuhkan semacam JSX.
Tapi Flutter meningkat cukup banyak pada periode itu, dan saya berubah pikiran.

• BEJ sangat buruk untuk ditulis dengan tangan. Ini membutuhkan banyak alat untuk membuatnya tertahankan, termasuk tag penutup otomatis, tag penggantian nama otomatis & emmet. Dan bahkan itu tidak sesederhana sintaks Flutter.

Misalnya, memfaktorkan ulang Foo() ke Foo(child: Bar()) itu mudah.
Tetapi refactoring <Foo /> ke <Foo><Bar /></Foo> tidak.

• Flutter menawarkan banyak opsi pemfaktoran ulang yang membuat manipulasi tanda kurung menjadi lebih mudah

• Tag penutup virtual yang ditawarkan Flutter menggantikan kurangnya tag penutup.
  _Tapi mereka tidak muncul di ulasan kode!_
  Mereka benar-benar melakukannya! Anda dapat melakukan tinjauan kode dari IDE Anda. Lihat https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests

  • JSX tidak diterjemahkan dengan baik untuk model Flutter.

Bagaimana jika widget mengambil child dan children ? Apakah kita mendapatkan:

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

?

Dalam hal ini, ini berarti bahwa untuk tujuan konsistensi child harus selalu diperlakukan sebagai argumen bernama alih-alih menggunakan slot children .

Masalahnya, sangat sedikit widget yang membutuhkan children . Sebagian besar adalah satu child , atau kombinasi dari parameter bernama khusus (seperti Scaffold ).

Yang berarti sebagian besar widget yang menggunakan BEJ akan terlihat seperti:

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

Manakah yang _lebih buruk_ dari itu:

Container(
  child: Bar(),
)

Kesimpulannya, saya pikir Flutter baik-baik saja. Dan bahkan jika JSX tersedia, saya ragu itu akan benar-benar memperbaiki keadaan.

Seperti yang saya katakan di atas, saya pikir ada banyak perpaduan antara apa yang sebenarnya JS/ECMAScript/fitur web umum (penyebaran objek, perusakan, pertukaran objek/hashmaps, semua node DOM* memiliki antarmuka yang sangat mirip, fleksibilitas HTML dalam umum, dll) dengan apa itu fitur BEJ. Mantan IMO inilah yang membuat BEJ nyaman untuk ditulis. Tanpa mereka, Anda hanya menulis XML, dan kebanyakan orang yang saya kenal yang sebenarnya punya pilihan tidak suka menulis XML.

*Perlu dicatat bahwa ini di atas segalanya adalah penentangan utama saya untuk mencoba memasang kembali Flutter ke XML. Saya tidak berpikir ada gunanya mencoba menyangkal bahwa JSX/React memiliki akar yang dalam di web, dan elemen DOM memiliki standar lama dari setiap node yang memiliki _attributes_ dan _children_. Di sisi lain, Flutter tidak mengikat pengembang untuk memberi nama slot widget khusus untuk widget lain children atau bahkan child dan saya tidak melihat alasan mengapa ia harus mulai melakukan itu.

Saya dapat melihat mengapa utas BEJ lainnya dikunci. Saya tidak perlu mempertahankan keahlian/pengalaman saya dalam komentar GitHub untuk menjelaskan mengapa menurut saya JSX tidak menguntungkan Flutter. Saya dapat dengan mudah mengatakan, "Anda tidak memiliki cukup pengalaman dengan Flutter untuk memiliki pendapat apa pun tentang Flutter." Rasanya tidak enak, ya. Anda semua menikmati suku prajurit keyboard Anda.

Bagaimana jika widget mengambil child dan children ? Apakah kita mendapatkan:

Mengapa widget harus memiliki child dan children ? Ini atau itu
Topik lain，Beberapa widget Flutter menggunakan children , dan yang lainnya menggunakan child , tidak ada yang menganggapnya rumit dan mudah membingungkan？ children berisi child , jadi tidak peduli berapa banyak child yang Anda miliki，satu atau lebih dari satu，cukup gunakan children untuk menyelesaikan pekerjaan.

@rrousselGit

BEJ sangat buruk untuk ditulis dengan tangan. Ini membutuhkan banyak alat untuk membuatnya tertahankan,

Tidak hanya seluruh dunia React yang tidak setuju dengan Anda, tetapi juga seluruh dunia HTML dan XML.

Flutter menawarkan banyak opsi pemfaktoran ulang yang membuat manipulasi tanda kurung menjadi lebih mudah

Jadi Anda mengatakan Flutter 'membutuhkan banyak perkakas' juga, tetapi karena Anda bias, Anda merasa perlu untuk membuang sisi lain. FYI: Hal terbaik yang harus dilakukan adalah menerima bahwa ada lebih dari satu cara untuk melakukan sesuatu dan beberapa orang akan lebih memilih cara lain untuk melakukannya.

Mereka benar-benar melakukannya! Anda dapat melakukan tinjauan kode dari IDE Anda.

Itu tidak menyelesaikan masalah untuk semua alat tinjauan kode online lainnya yang digunakan oleh tim. Alat-alat ini memanipulasi kode sumber dan jika tidak ada dalam kode sumber, itu tidak ada.

JSX tidak diterjemahkan dengan baik untuk model Flutter.

Itu hanya pendapat buruk Anda, siapa pun dapat melihat bahwa DSX menambahkan penyempurnaan ke JSX yang sangat cocok dengan Flutter.
https://spark-heroku-dsx.herokuapp.com/index.html

Jadi Anda mengatakan Flutter 'membutuhkan banyak peralatan'

Tidak, saya mengatakan "lebih mudah" tidak "dapat ditanggung".

Saya sering menjawab StackOverflow/Slack, dan terkadang bahkan dari ponsel saya.
Dan saya jelas mengalami kesulitan saat menjawab pertanyaan terkait html – tetapi Flutter baik-baik saja.

Hal terbaik yang harus dilakukan adalah menerima bahwa ada lebih dari satu cara untuk melakukan sesuatu dan bahwa beberapa orang akan lebih memilih cara lain untuk melakukannya.

Itu bekerja sebaliknya. Anda harus melihat dengan jelas, komunitas ini tidak 100% penggemar BEJ. Jumlah downvotes pada masalah ini dan yang sebelumnya membuktikannya.

Itu hanya pendapat buruk Anda, siapa pun dapat melihat bahwa DSX menambahkan penyempurnaan ke JSX yang sangat cocok dengan Flutter.

saya tidak setuju. Sintaksnya berisi banyak karakter kompleks yang pada banyak tata letak keyboard sulit diakses.
Ini mengandung banyak pengulangan juga.

Bagaimanapun, saya tidak mengerti mengapa Anda secara permanen begitu agresif. Kami semua berusaha membuat Flutter lebih baik.
Tidak ada gunanya bersikap kasar dan membuat diskusi ini ditutup kembali .

Jika BEJ tidak bekerja dengan baik dalam flutter, saya dapat menerima untuk tidak bergabung dengan BEJ, tetapi kita harus mempertimbangkan neraka bersarang.

Cerita sampingan lainnya adalah titik koma bahasa panah. Ini benar-benar menjengkelkan.

Cerita sampingan lainnya adalah titik koma bahasa panah. Ini benar-benar menjengkelkan.

Ada permintaan untuk ini di dart-lang/language: https://github.com/dart-lang/language/issues/69
Ayo berikan 👍

Diskusi panjang ini adalah tentang dapat menggunakan ini:

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

Alih-alih ini:

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

Bahkan jika seseorang setuju dengan sintaks sebelumnya untuk menjadi lebih unggul, sesuatu yang saya pribadi tidak lakukan, ini datang dengan biaya pemeliharaan berkelanjutan, kompleksitas yang lebih tinggi dan kemungkinan sumber kesalahan baru, tidak hanya dalam bahasa/kerangka kerja tetapi juga perkakas sekitarnya seperti IDE, debugger, linter, dll. Ini juga meningkatkan waktu pembuatan. Dan itu membutuhkan pengembang untuk mempelajari sintaks baru dan menyibukkan diri dengan internal transpiler, untuk memahami kapan dan bagaimana instance dibuat. Semua ini cukup banyak dengan satu-satunya tujuan React & co. pengembang merasa di rumah.

Sebelum memulai dengan bahasa baru, saya lebih suka fokus pada peningkatan Dart, yang jauh dari ideal, kehilangan fitur penting seperti pencocokan pola , kelas data , ADTs , destructuring , proper optionals , dll. Beberapa PR ini sudah terbuka 5+ bertahun-tahun. Ini, bertentangan dengan menambahkan lapisan markup kosmetik dan yang tidak perlu untuk membuat widget, memiliki dampak besar pada arsitektur, keamanan, dan kualitas kode secara keseluruhan.

Bahkan jika ini diturunkan ke "didorong oleh komunitas", masih ada waktu yang dapat dihabiskan komunitas untuk mengerjakan sesuatu yang bermakna. Tapi tentu saja setiap orang dapat melakukan apa yang mereka inginkan dengan waktu mereka. Tolong berhenti memberikan tekanan yang tidak proporsional ini pada tim Flutter.

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

Hei i-Schuetz.
ada bagian balasan.

Inilah yang telah saya katakan dalam posting panjang ini. BEJ memperbaiki "masalah spageti HTML dan XML" (kode UI tidak terbaca dan rumit). Menurut pendapat pribadi saya setelah menggunakan flutter, itu lebih rumit daripada JSX atau terburuk.

Dalam beberapa tahun ini, saya telah melihat orang-orang mengatakan Flutter tidak dapat menangkap beberapa keuntungan dari React, misalnya, ide sebenarnya dari segala sesuatu adalah komponen.

Tidak yakin saya mengikuti. Dalam teks yang Anda soroti, pengguna mengatakan bahwa dia merasa BEJ lebih mudah dipelajari karena dia familiar dengan HTML dan sintaksnya mirip. Saya tidak melihat bagaimana ini membenarkan keberadaan JSX dan bahkan meniru Flutter dengan cara apa pun.

Saya tidak menambahkan balasan ke tangkapan layar hanya karena gambar akan memakan terlalu banyak ruang. Mereka tampak agak mendukung apa yang saya posting, jadi juga berlebihan. Saya memposting tautan.

@JonathanSum Flutter lebih rumit daripada JSX, atau Flutter berbeda dari _React_ dan itu menyebabkan gesekan dari Anda? Ini lebih bertele-tele dalam beberapa kasus, ya, dan cukup bisa dibilang kurang mudah dibaca tanpa tag penutup virtual dalam IDE, tapi saya tidak yakin bagaimana menggunakan konstruktor lebih _complicated_ daripada menulis DSL seperti XML dan saya masih belum yakin mengapa begitu banyak orang tampaknya berpikir bahwa DSL seperti XML akan menjadi peluru perak yang akan membuat penggunaan Flutter lebih mudah untuk _dipahami_. Terutama mengingat Flutter tidak memiliki riwayat sebelumnya dengan masalah yang React/JSX diciptakan untuk dipecahkan - React membuat manipulasi DOM lebih mudah dan bersih, dan itu bagus, tapi apa sebenarnya hubungannya dengan Flutter lagi?

Dalam beberapa tahun ini, saya telah melihat orang-orang mengatakan Flutter tidak dapat menangkap beberapa keuntungan dari React, misalnya, ide sebenarnya dari segala sesuatu adalah komponen.

Tanpa menyentuh gagasan bahwa React memiliki beberapa gagasan "benar" tentang segala sesuatu yang menjadi komponen yang tidak dimiliki Flutter, ada juga beberapa keuntungan dari desain Flutter/Dart yang tidak dapat ditangkap oleh React/JS. Dan Anda dapat mengatakan hal yang sama (dan sebaliknya) untuk SDK/kerangka/perpustakaan UI yang paling layak. Luar biasa, proyek yang berbeda sebenarnya berbeda; mungkin orang yang datang ke satu proyek mungkin lebih baik dilayani jika mereka tidak mulai mengharapkannya [masukkan proyek yang pernah mereka gunakan di masa lalu]. 🙂.

Ada beberapa ide menarik di luar sana https://github.com/munificent/ui-as-code

Kemungkinan besar itu akan menjadi perubahan yang sangat besar, tetapi proposal kebebasan parameter membuat saya berpikir betapa lebih ringkasnya metode build jika Dart memiliki misalnya metode argumen Crystal spec .

Tentu saja, penyusun Crystal akan menjadi yang terakhir dalam perlombaan melawan siput dan kura-kura, jadi begitulah

Saya sekarang setuju untuk tidak menambahkan BEJ dan tidak memberikan tekanan ekstra pada flutter.

Tapi sejauh menyangkut dart, itu jauh kurang elegan daripada JS atau TS. Saya merasa tidak berdaya

Misalnya, rute pengembangan teknologi Microsoft UI adalah WinForm ke WPF，dan sekarang di Flutter，meninggalkan WPF dan menggunakan WinForm sebagai gantinya。Menanggapi keluhan pengembang, tim Flutter bekerja keras untuk mengimplementasikan jendela visual dan editor properti WinForm。

Sebagai pendatang baru di flutter saya harus mengatakan bahwa ini harus ada di peta jalan. Jika bukan jsx, cara yang lebih mudah dibaca manusia untuk meletakkan widget.

Saya dapat melihat fungsi render kelas reaksi dan dan gambar kelas yang dirender dan asosiasikan saat ini.

Saya dapat melihat file dart dan konten yang dirender dan saya akan membutuhkan waktu 5-6 menit untuk mengetahui cara kerjanya ...

Saya dapat membuat kelas reaksi semi-kompleks dalam 5 menit dalam editor teks biasa , karena intuitif

Saya tidak bisa melakukan itu di flutter. Tanpa pelengkapan otomatis saya selesai sebagai pengembang. Saya tidak suka bergantung pada ekstensi untuk mengembangkan sesuatu -.-

Namun. Akan menarik bagaimana pengembang dart menangani "masalah" ini. Di panah 2 mereka membuatnya lebih mudah dibaca. Saya tidak tahu bagaimana mereka akan meningkatkan keterbacaan di dart 3 -4 -5 . tetapi saya pikir refactoring fungsi komponen build akan dibutuhkan cepat atau lambat.

EDIT:
Nevermind, coba saja React Native lagi , dan saya benci jsx , sistem props , fakta bahwa semuanya dinamis adalah konsep yang benar-benar menakutkan lagi, saya kira itu hanya pendapat pribadi. Biarkan getar apa adanya....

Mereka meminta DSX, bukan hanya karena mereka mencintai BEJ. Mereka menginginkan Flutter.

Deklarasi UI harus dipisahkan secara visual dalam kode untuk keterbacaan dan dukungan kode yang lebih baik. Terutama di tim besar dengan banyak junior/middle. Berasal dari Adobe Flex, saya dapat mengatakan bahwa membaca deklarasi UI Flutter sangat mengurangi produktivitas.
Jika bukan DSX (yang akan menjadi IMO yang luar biasa) tetapi sesuatu harus dilakukan dengan situasi saat ini setidaknya pada level IDE.
Semua kerangka pengembangan UI sebelumnya memiliki fitur ini dan kami juga harus memilikinya.

Deklarasi UI harus dipisahkan secara visual dalam kode untuk keterbacaan dan dukungan kode yang lebih baik.

dan untuk integrasi yang lebih baik dengan alat lain seperti 'pembangun gui' misalnya.

Berasal dari Adobe Flex, saya dapat mengatakan bahwa membaca deklarasi UI Flutter sangat mengurangi produktivitas.

Bayangkan deklarasi UI seperti MXML dengan kekuatan Flutters! Aku hanya bisa bermimpi!

Sekarang kami memiliki dukungan codegen, cara terbaik untuk memasukkan sesuatu seperti ini ke dalam produk adalah dengan membuat paket yang memungkinkannya dan menunjukkan bahwa itu sangat populer.

@Hixie apakah ada penunjuk ke doc untuk codegen?

Sekarang kami memiliki dukungan codegen, cara terbaik untuk memasukkan sesuatu seperti ini ke dalam produk adalah dengan membuat paket yang memungkinkannya dan menunjukkan bahwa itu sangat populer.

Sepertinya saya codegen hanya untuk .dart -> .dart, file input harus file .dart yang valid. Itu tidak terlalu berguna untuk file .dsx karena ini adalah superset dari dart. Saya masih membutuhkan dukungan untuk kompilasi silang ke .dart dengan peta sumber seperti fitur untuk debugging, dll.

Tolong lihat SwiftUI, yang dirilis kemarin. Tampaknya inilah yang seharusnya dituju oleh Flutter, alih-alih markup seperti Bereaksi.

Ekspresi anggota implisit Swift saja akan sangat menakjubkan

Saya bingung tentang sintaks SwiftUI. Ini pasti ringan, tetapi beberapa aspek terlihat ajaib.

Tetapi secara teknis kami dapat memiliki sesuatu yang relatif mirip:

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

Itu kode panah yang valid, di mana Column adalah _still_ kelas.

Berikut widget stateless yang menampilkannya:

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

  final List<Widget> children;

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

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

Ini boilerplat-ish, tetapi pembuat kode dapat membantu – terutama dengan anggota ekstensi yang akan datang.

Satu-satunya masalah tentang pendekatan ini adalah bahwa kita kehilangan konstruktor const (karena menggunakan fungsi untuk menentukan turunan) dan membuat instance kelas widget _twice_.

Jika sintaks itu diinginkan, idealnya daripada metode call , itu harus diimplementasikan menggunakan kari konstruktor.

@rrousselGit Saya ingin tahu tentang aspek SwiftUI apa yang terlihat ajaib bagi Anda - sepertinya ekstensi sintaks Swift yang cukup mudah bagi saya.

Pada contoh kode mereka dari sini :

• Content bisa berubah? Apakah itu berarti mereka memiliki toko Mobx / Vue bawaan?
• Apa itu @State ?
• Mengapa body merupakan variabel? Apakah itu seorang pengambil? Jika demikian, kapan getter dipanggil lagi?
• apakah body bagian dari antarmuka, atau banyak variabel serupa di dalam Content ?
• Apa yang dilakukan item in _tepatnya_ itu? Mengapa operan yang tepat dari in bukan sesuatu yang dapat diubah, tetapi "hasil" sebagai gantinya?
• Mengapa Image rata kiri ke judul/subjudul ketika tidak ada HStack ?

Saya tidak dapat mengingat dengan pasti, tetapi saya cukup yakin saya tidak memiliki pertanyaan seperti itu ketika mengambil Flutter.

@rrousselGit Itu mungkin karena latar belakang Anda, bukan karena sintaks Flutter atau semantik secara inheren jelas (saya telah bertemu banyak orang yang cukup bingung karenanya). Dan poin-poin yang Anda kemukakan tampaknya merupakan persimpangan aneh dari analisis berlebihan potongan kode 14 baris untuk kesalahan sementara tidak benar-benar mengetahui bahasa penulisannya.

• Itu tidak benar-benar bisa berubah (dalam arti Dart atau JS)? Ini adalah sebuah struktur. Juga toko bergaya MobX/Vue (yaitu membuat kertas dengan dukungan bahasa yang sangat terbatas) bukan satu-satunya cara untuk menangani mutabilitas

• @State adalah atribut, atau dikenal sebagai anotasi dalam beberapa bahasa (misalnya Dart), atau dikenal sebagai hal yang sangat umum dalam kode Swift. Jika Anda bersungguh-sungguh apa yang dilakukannya, bahkan tanpa melihat dokumen, kemungkinan besar itu menandai properti sebagai status yang akan berubah seiring waktu.

• body adalah properti yang dihitung, yang mudah terlihat oleh pengembang Swift. Adapun ketika dihitung ulang, apakah Widget build(BuildContext context) juga secara inheren memberi tahu Anda ketika dipanggil lagi?

• Content (sekali lagi cukup jelas untuk pengembang Swift) extends/implements View , yang mana Anda akan mencari jawaban atas pertanyaan Anda (sebenarnya memiliki halaman referensi API yang sangat bagus).

• Ini cukup banyak "mengapa kata kunci dalam bahasa ini tidak sama dengan kata kunci dalam bahasa yang saya gunakan", bukan sesuatu yang "ajaib". Kata kunci in di sini tidak sama dengan konstruk for...in - ini menunjukkan bahwa badan penutupan akan segera dimulai. { item in ... } adalah blok fungsi yang diteruskan ke konstruktor List ; ListView 's itemBuilder , jika Anda mau.

• Apakah Anda secara sah bertanya mengapa tampilan memiliki aturan tata letak yang dienkapsulasi sendiri?

Di SwiftUI:

1-Senang melihat status dideklarasikan dalam Tampilan dan bukan sebagai embel-embel samping.

2-Metode individual yang bagus untuk mengatur sesuatu alih-alih harus meneruskan semuanya pada konstruktor (metode memungkinkan tindakan untuk diterapkan alih-alih hanya data yang diteruskan).

3-Sangat bagus untuk melihat grafik vektor deklaratif bercampur dengan segala sesuatu yang deklaratif (seperti yang saya sarankan di masa lalu dengan widget seperti SVG deklaratif) !!!
https://developer.apple.com/tutorials/swiftui/drawing-paths-and-shapes

4-Konstruk animasi & transisi yang sangat sederhana
https://developer.apple.com/tutorials/swiftui/animating-views-and-transitions

Alat desain 5-Drag&Drop selaras dengan editor kode dua arah.

Ada kutil seperti yang lainnya tapi saya lebih fokus pada apa yang mereka lakukan dengan sangat baik.

"Pertanyaan" ini ada hanya untuk menunjukkan poin yang berpotensi membingungkan. Ini bukan _pertanyaan aktual_.

Itu mungkin karena latar belakangmu

Mungkin. Saya tidak mengatakan bahwa pendekatan mereka buruk atau apa. Saya mengatakan itu tidak terasa alami bagi saya seperti halnya dengan Flutter.
Widget Flutter hampir tidak menggunakan "fitur bahasa mewah" dan dapat diimplementasikan di hampir semua bahasa (walaupun if/for untuk koleksi baru-baru ini mengubahnya).
Sementara showcase SwiftUI mereka secara ekstensif menggunakan fitur khusus Swift.

Mengenai kapan dihitung ulang, apakah Widget build(BuildContext context) juga secara inheren memberi tahu Anda kapan dipanggil lagi?

Maksud saya di sini adalah kurangnya hubungan antara State dan tindakan menghitung ulang body .
React dan Flutter sangat eksplisit dalam hal ini: setState.
Vue/Mobx adalah "ajaib", menggunakan fitur @State yang sama.

Tidak apa-apa sebenarnya, tapi itu pola yang berbeda.

Apakah Anda secara sah bertanya mengapa tampilan memiliki aturan tata letak yang dienkapsulasi sendiri?

Tidak, ini lebih merupakan "eksplisit" vs "implisit".
Tampaknya mereka benar-benar fokus pada "melakukan sebanyak mungkin dalam kode sesedikit mungkin", bahkan jika itu menyembunyikan beberapa logika (dalam hal ini, logika ltr vs rtl )

Flutter akan meminta Anda untuk menggunakan Row .

Flutter menggunakan dan mengandalkan banyak "fitur bahasa mewah" (baca: fitur bahasa yang tidak digunakan dan/atau tidak disetujui oleh siapa pun pembicaranya). Di luar kepala saya, konstruktor konstan (dan gaya penamaan konstruktor Dart secara umum), kelebihan operator, kelas menjadi antarmuka implisit, @covariant , dan mixin adalah fitur yang akan menarik reaksi dari kebingungan hingga pelabelan langsung sebagai bau kode tergantung pada latar belakang pengembang. Saya mungkin bisa membuat daftar yang lebih panjang dengan pemikiran satu jam. Dan itu bukan dakwaan Flutter lebih dari itu dakwaan SwiftUI - saya tidak mengerti mengapa orang akan berpikir itu suatu kebajikan untuk menulis perangkat lunak dalam bahasa tertentu sehingga dapat ditulis dengan cara yang sama dalam bahasa apa pun - apa titik bahasa yang berbeda jika kita seharusnya berpura-pura seperti perbedaan di antara mereka tidak ada?

Selain itu, saya sepenuhnya tidak setuju bahwa salah satu dari setState atau @State eksplisit tentang hubungannya dengan tindakan membangun kembali tampilan. Dalam kedua kasus, Anda hanya diberitahu bahwa jika Anda mengubah sesuatu yang telah ditandai sebagai status, kerangka kerja akan memilah apa yang harus dibangun. Dalam kedua kasus, dev masih tidak memiliki kontrol eksplisit atas apa yang terjadi atau kapan tepatnya. Anda menemukan panggilan fungsi lebih akrab, orang yang bekerja dalam beberapa bahasa lain menemukan dekorator lebih akrab. Tetapi memanggil suatu fungsi tidak membuat hal-hal tidak ajaib.

Flutter akan meminta Anda untuk menggunakan Row

Saya kira Anda belum pernah menggunakan ListTile , yang memiliki perilaku yang sama seperti yang ditunjukkan di sini tetapi dengan parameter bernama? Haruskah kami juga bertanya mengapa Scaffold "secara ajaib" meletakkan tombol menu di kiri bilah aplikasi Anda ketika Anda tidak memintanya?

Perbedaannya adalah bahwa dalam keadaan Dart saat ini sangat mirip dengan kebanyakan bahasa arus utama.

Itu penting.
Pertanyaan "Apakah saya perlu belajar Dart, atau bisakah saya mulai belajar Flutter?" muncul cukup sering.
Saat ini, jawabannya adalah "belajar saja Flutter. Anda dapat menulis panah yang efektif setelah satu hari".
Itu tidak dijamin akan tetap seperti ini selamanya, tapi menurutku ini adalah salah satu kekuatan Flutter.

Sisa dari diskusi agak di luar topik. Jika Anda mau, kami dapat melanjutkan bagian itu melalui surat (surat github saya berfungsi).

Mengapa ini tidak dikunci? Ini sudah berpindah dengan buruk, dan itu persis sama dengan masalah terkunci sebelumnya.

Saya telah membuat yang sederhana di sini:
https://github.com/danialdezfouli/flutterjsx
https://www.npmjs.com/package/flutterjsx
https://www.youtube.com/watch?v=Oj1JMSurphA

Utas ini telah dikunci secara otomatis karena tidak ada aktivitas terbaru setelah ditutup. Jika Anda masih mengalami masalah serupa, silakan buka bug baru, termasuk keluaran flutter doctor -v dan reproduksi masalah minimal.