Flutter: Kait widget

@Hixie @eseidelGoogle

Berikut adalah tindak lanjut dari https://twitter.com/ericmander/status/1070024779015479302 dengan beberapa detail tentang apa yang ada dalam pikiran saya. Untuk berjaga-jaga jika tim Flutter ingin berinvestasi lebih jauh pada topik

Hai @rrousselGit Saya melihat paket flutter_hooks Anda tempo hari. Saya tidak yakin opsi apa yang kami miliki untuk mengimplementasikannya di Flutter, tetapi saya perhatikan bahwa Anda meneruskan metode hook melalui HookContext, sedangkan di React, hook dapat dibuat secara terpisah dan digunakan sebagai semacam "mixin keadaan". Perbedaan utama adalah bahwa flutter_hooks tampaknya mengharuskan semua metode hook dibangun ke dalam paket, sementara React memungkinkan metode hook untuk benar-benar terpisah.

Sepertinya ini akan sangat penting untuk mencocokkan spesifikasi React. Apakah Anda memiliki pemikiran tentang bagaimana hal ini dapat dicapai?

EDIT :

HookContext telah dihapus dan semua kait sekarang menjadi metode statis. Jadi yang berikut ini sekarang sudah ketinggalan zaman

Paket saya melakukan itu untuk tujuan penyelesaian otomatis, tetapi itu bukan keharusan.

Dari pada

context.useSomeHook()

Kita bisa memiliki

useSomeHook(context)

Ini tidak mengubah apa pun selain kemampuan untuk ditemukan.

Fitur utamanya adalah

T HookContext.use<T>(Hook);

Yang memungkinkan Anda membuat kait Anda sendiri dari sana. Selama kita memiliki metode ini, kita dapat melakukan semua yang React lakukan.

Tetapi karena kekhususan kait, itu akan mendapat banyak manfaat dari linter khusus. Paket eksternal mana yang tidak dapat disediakan saat ini.

Saya akan merekomendasikan Anda memberikan suara positif (dan menambahkan kasus penggunaan Anda ke)
https://github.com/dart-lang/linter/issues/697. Akan sangat bagus jika paket dapat menyediakan lint kustom mereka sendiri.

Masalah lain adalah tentang hot-reload.

Yang satu ini membuatku khawatir. Akan sangat disayangkan jika kita menurunkan pengalaman hot-reload.

Tersedia di sini https://pub.dartlang.org/packages/flutter_hooks

Bisakah Anda menguraikan apa keuntungan memanggang ini ke dalam kerangka Flutter dibandingkan hanya memiliki paket eksternal?

Tentang hot reload, saya memang mengintegrasikannya dan lancar digunakan.

Satu-satunya masalah sebenarnya adalah #26503, yang tampaknya memerlukan perubahan pada perkakas untuk memperbaikinya. Dan saya tidak memiliki bandwidth untuk melakukannya.

Ada beberapa peningkatan kecil yang dapat kami bawa ke hook dengan mengintegrasikannya ke Flutter:

• Beberapa peningkatan kinerja, dengan tidak bergantung pada StatefulElement
• Memfaktorkan ulang/menganalisis, yang saat ini tidak mungkin atau sangat terbatas menggunakan analyzer_plugin

Tapi saya pikir alasan terbesarnya adalah: Hooks adalah bagian dari pekerjaan skala besar di React, yaitu rendering async.

Jika Flutter ingin menggunakan rute Async Rendering (dan memang seharusnya demikian), itu akan membutuhkan dua hal:

• Beberapa perubahan kerangka kerja
• Sesuatu yang mirip dengan kait

Ada juga aspek komunitas yang jelas. Dengan 270 bintang dalam sebulan dan tempat di https://github.com/trending/dart?since=monthly tanpa saya benar-benar mengiklankannya -- hook jelas merupakan sesuatu yang meningkatkan minat komunitas.

Tujuan dari hooks adalah untuk mengubah sintaks widget sehingga orang-orang dapat membagikan logika khusus siklus hidup ke pub.

Dengan pengait yang didukung secara resmi, ini akan meningkatkan upaya komunitas secara eksponensial.

Penasaran: Bisakah Anda menjelaskan bagaimana Anda membuatnya bekerja untuk hot reload?

Saya memperluas StatefulElement alih-alih ComponentElement, sehingga saya dapat memiliki akses ke reassemble .
Ini memungkinkan panggilan build berikutnya untuk mengubah daftar kait sambil mencegah pembangunan kembali normal melakukannya.

Pada dasarnya, jika previousHook.runtimeType != newHook.runtimeType pada indeks tertentu, pengait ini dan semua yang berikut akan dibuang.

Bagian "semua yang berikut" adalah karena sebuah kail dapat menggunakan kail lain; jadi menghapus satu saja tidak cukup.
Dari sebulan penggunaan konstan, itu jarang menjadi masalah.

Justru sebaliknya, pengalaman hot-reload tampaknya ditingkatkan. Karena semuanya berada dalam metode build , hot-reload selalu menerapkan perubahan (sebagai lawan dari initState ). Contoh tipikal adalah AnimationController :

final animationController = useAnimationController(duration: const Duration(second: 1));

Hook ini memungkinkan durasi hot-reload yang mulus; yang merupakan sesuatu yang biasanya membutuhkan hot-restart.

Saya mulai menerjemahkan bagian dari aplikasi utama saya untuk menghapus beberapa boilerplate. Saya tidak melihat Hooks sebagai fitur tetapi pola penuh. Mereka banyak mata pelajaran yang hanya menunggu untuk diimplementasikan dan akan sangat menguntungkan produktivitas tetapi juga pemeliharaan. Saya mulai dengan animasi, menghapus pengontrol dan ingin melihat Hooks for Firebase atau kasus umum lainnya.

Justru sebaliknya, pengalaman hot-reload tampaknya ditingkatkan. Karena semuanya ada dalam metode build, hot-reload selalu menerapkan perubahan (sebagai lawan dari initState).

👍 Saya juga mencapai realisasi ini beberapa minggu setelah saya pertama kali melihat lamaran Sebastian.

Bagian "semua yang berikut" adalah karena sebuah kail dapat menggunakan kail lain; jadi menghapus satu saja tidak cukup.

Saya juga berpikir bahwa di JS mungkin heuristik dapat membantu: jika hot reload menyebabkan render (Flutter's build ) terlempar (misalnya karena jenis yang tidak cocok), kami menyetel ulang semua status Hooks dan coba lagi. Jika gagal lagi maka kita gagal.

Saya kira Anda tidak memiliki masalah ini karena pengetikan yang kuat? Saya tidak yakin. Apa yang terjadi jika Anda mulai mengedit dengan Hook status string dan kemudian mengubah kode untuk menganggapnya sebagai angka?

Apa yang terjadi jika Anda mulai mengedit dengan Hook status string dan kemudian mengubah kode untuk menganggapnya sebagai angka?

Maksud Anda pergi dari:

final counter = useState(0)

ke:

final name = useState('foo');

?

Jika demikian, sistem pengetikan dengan benar mendeteksi bahwa jenisnya berubah. Ini karena tipe useState sebenarnya adalah useState<int> vs useState<String> .

JS kemungkinan akan mengalami kesulitan di sini.

Saya tidak benar-benar mengerti apa yang menyelamatkan Anda. Satu deklarasi yang mudah dipahami, satu baris yang mudah dipahami di initState, dan satu baris yang mudah dipahami di pembuangan, digantikan oleh baris yang kurang efisien dan sepenuhnya buram dalam metode build (di mana kinerjanya kritis). Ini sepertinya bukan kesepakatan yang bagus. Bisakah Anda menguraikan manfaat di sini?

(Yang mengatakan, https://pub.dartlang.org/packages/flutter_hooks sepertinya sudah mengimplementasikan semuanya di sini, jadi saya kira kita tidak perlu menambahkan apa pun ke platform?)

Hooks adalah salah satu solusi untuk masalah yang dihadapi React selama bertahun-tahun. Dan karena Flutter mengambil banyak inspirasi dari React, Flutter juga mengimpor masalah ini.

Saya sangat buruk dalam pemasaran, jadi saya sangat menyarankan menonton pembicaraan Tim React tentang ini. Perkenalan mereka dimulai di sini https://youtu.be/dpw9EHDh2bM.

Diikuti oleh perbandingan berdampingan sebelum/sesudah dari Dan Abramov (yang menjawab di sini beberapa komentar di atas).

Intinya adalah, semua yang mereka bicarakan juga berlaku untuk Flutter (termasuk blog mereka tentang mixin yang berbahaya https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html)

Yang mengatakan, kait dapat diringkas dalam kalimat menarik berikut:

Dengan kait, Anda bisa 'pub mendapatkan' persentase yang lebih besar dari aplikasi Anda

Ini karena kait dapat sepenuhnya diekstraksi dari widget dan dipublikasikan ke pub untuk digunakan orang lain. Itu sesuatu yang saat ini tidak mungkin dengan StatefulWidget karena logika kita terikat dengan siklus hidup State .

Efek lain dari hook adalah mengubah cara kode dikelompokkan. Saat ini kami memiliki yang berikut:

initState() {
  a = A(widget.foo);
  b = B(widget.bar);
}

didUpdateWidget(SomeWidget old) {
  if (old.foo != widget.foo) {
    a.foo = widget.foo;
  }
  if (old.bar != widget.bar) {
    b.bar = widget.bar;
  }
}

dispose() {
  a.dispose();
  b.dispose();
}

Semuanya dicampur dan dibagi di beberapa siklus hidup. Menjadi sangat sulit untuk melihat apakah kita lupa membuang/memperbarui variabel.

Dengan kait menjadi sebagai berikut:

final a = useMemoized(() => A(foo));
useValueChanged(foo, () => a.foo = foo});
useEffect(() => a.dispose, [a]);

final b = useMemoized(() => B(bar));
useValueChanged(bar, () => b.bar = bar});
useEffect(() => b.dispose, [b]);

Semuanya sekarang berkumpul kembali. Menjadi jauh lebih jelas jika kita lupa membuang/memperbarui variabel atau tidak, dan kita dapat dengan mudah mengekstrak logika itu ke dalam fungsi statis yang melakukan semuanya secara internal.

Kait sesuai dengan KERING. Kami menulis sekali logika untuk membuat/memperbarui/membuang variabel. Dan kami menggunakannya kembali di mana-mana alih-alih menyalin-menempelkannya.

Contoh visual (dalam Bereaksi):

Secara keseluruhan, meskipun luar biasa bisa mengimplementasikan hook di luar repositori Flutter; Saya tidak berpikir itu harus tetap seperti itu.

Ini seperti jika Flutter hanya menyediakan kelas dasar Widget , dan menjadikan StatefulWidget sebagai dependensi eksternal: Itu tidak masuk akal.

Flutter adalah kerangka kerja, kami tidak ingin hanya menawarkan dasar-dasarnya

Yang berarti kita juga ingin:

• memberikan kait untuk semua aspek kerangka kerja yang akan mendapat manfaat darinya
• berinteraksi dengan inspektur widget (UI saat ini tidak dioptimalkan untuk kasus penggunaan seperti itu)
• pemfaktoran ulang/linter
• menyediakan utilitas pengujian

Ini membutuhkan banyak pekerjaan dan mungkin memerlukan banyak PR di Flutter.
Ini sangat jauh dari cakupan paket kecil yang dikelola oleh satu orang di waktu luangnya.

Kait adalah KERING dan merupakan logika bisnis/campuran keadaan yang mempromosikan colocation kode yang bersih. Alternatifnya adalah pengulangan terfragmentasi di seluruh basis kode.

Sementara saya setuju bahwa di atas kertas lebih buram, polanya dapat diulang dan dimengerti, jadi setelah seharian digunakan menjadi transparan. Ini seperti pola pemrograman lainnya: buram saat Anda memulai, transparan saat Anda menggunakannya, tetapi dengan Hooks transisinya hampir instan.

Sebagai reaksi, banyak pengembang berpikir bahwa kait membuat banyak kasus yang awalnya mengandalkan komponen kelas tidak diperlukan. Oleh karena itu, komponen fungsional akan menjadi pusat perhatian dalam waktu dekat.

Pertanyaan naif saya adalah apakah mendukung widget fungsional dalam flutter juga masuk akal. Saya mengerti widget fungsional saat ini tidak disarankan karena tidak menautkan ke Elemennya sendiri dan kurangnya BuildContext sendiri. Apakah bermanfaat untuk memperkenalkan mekanisme fungsional baru yang dapat membuat objek di bawah yang sama seperti yang dilakukan widget kelas?

@ivenxu Ini adalah sesuatu yang saya buat juga, dalam paket lain: https://github.com/rrousselGit/functional_widget

Ini adalah pembuat kode yang menghasilkan kelas dari suatu fungsi, (dengan kunci dan semuanya) dan kompatibel dengan kait untuk menghasilkan HookWidget

Jumlah keduanya adalah:

<strong i="11">@hwidget</strong>
Widget foo(BuildContext context, {Duration duration}) {
  final controller = useAninationController(duration: duration);
  useEffect(controller.forward, [controller]);

  final value = useAnination(controller);
  return Text(value.toString());
}

Itu membuat teks bagus yang berubah dari 0 ke 1 secara progresif.
Dalam 6 baris kode...
Yang akan membutuhkan lebih dari 30 baris dengan widget biasa.

Dan saya tidak menghitung penggantian debugFillProperties dan operator== yang dihasilkan secara otomatis.

@rrousselGit Saya mengetahui pekerjaan widget fungsional Anda, barang bagus dan terima kasih! Namun, saya sedang berbicara tentang dukungan asli dari flutter.

Omong-omong, bagaimana debug terlampir untuk gen kode? Apakah itu mungkin mengatur break point di foo() dan memeriksa variabel lokal? Bagaimana tampilan callstack?

Terkadang, paradigma fungsional untuk komponen/widget jauh lebih ringkas daripada rekan kelas. Jadi saya mencari ide apakah widget fungsional yang didukung asli akan membuat perbedaan.

Dengan kait itu menjadi sebagai berikut:

Saya benar-benar berpikir gambar "sebelum" di sini jauh lebih jelas dan lebih mudah dipahami daripada gambar "sesudah". Jelas, bagaimanapun, itu adalah pendapat subjektif.

Ini seperti jika Flutter hanya menyediakan kelas dasar Widget, dan menjadikan StatefulWidget sebagai dependensi eksternal: Itu tidak masuk akal.

Melakukan itu sebenarnya akan sangat sejalan dengan filosofi pelapisan Flutter. Alasan utama kami memiliki StatefulWidget sebagai bagian inti kelas satu dari lapisan widget dalam kerangka kerja adalah karena fitur lain dalam kerangka kerja bergantung padanya (misalnya GlobalKey ), jadi kami tidak bisa. Tetapi sebisa mungkin, kami ingin mengekstrak fitur sehingga fitur tersebut tidak menjadi inti.

Saya pikir sangat masuk akal untuk memiliki ini sebagai paket untuk orang-orang yang ingin menggunakannya. Jika ada yang bisa kita lakukan dalam kerangka inti untuk membuat penerapannya lebih baik, lebih efisien, dll, maka kita pasti harus melakukannya.

Saya pikir ini adalah proyek yang hebat, dan saya mengikuti paket dengan penuh minat.

Yang mengatakan, saya tidak sepenuhnya jelas mengapa ini perlu ada dalam kerangka kerja. Ini sepertinya pola yang sangat berguna yang akan disukai beberapa orang dan yang lain memilih untuk tidak menggunakannya.

@rrousselGit Saya menduga Anda akan memiliki banyak keberhasilan untuk terus mengembangkan ini sebagai paket terpisah dan membuka masalah/PR untuk kerangka kerja inti yang akan membantu membuatnya lebih berhasil. Jika ada sesuatu yang Anda perlukan dalam kerangka kerja yang saat ini tidak berfungsi, mari kita atasi. Jika ada bug dalam kerangka kerja yang menghalangi ini agar tidak berfungsi, mari kita buat!

Dan FWIW, saya katakan ini memiliki pengalaman serupa dengan flutter_svg - yang telah menghasilkan beberapa kontribusi pada kerangka kerja dan dapat bermanfaat bagi banyak orang sebagai satu paket.

Saya baru menyadari:
Jika kait diimplementasikan di Flutter, kandidat yang baik adalah ComponentElement.

Ini berarti bahwa alih-alih memiliki jenis Widget baru, itu akan membuat StatelessWidget dan StatefulWidget kompatibel dengan kait.

Pendekatan ini dapat memungkinkan kedua sintaks untuk hidup berdampingan. Ini bisa berguna mengingat kedua sintaks memiliki pro dan kontra

Saya baik-baik saja dengan kait berada di luar Flutter untuk saat ini.

Satu-satunya kekhawatiran saya adalah bahwa dengan menjadi tidak resmi, ini akan mengurangi penggunaan kait secara keseluruhan. Dan karena itu kurangi jumlah kait yang tersedia di pub.

Mempertimbangkan keuntungan terbesar dari kait adalah dampak komunitas (kait khusus dapat diterbitkan di pub), ini merusak kegunaannya.

Hanya ingin mengatakan — jika ada orang di tim Flutter yang ingin mengobrol 1:1 tentang Hooks, saya akan dengan senang hati menjelaskan konteks historis dan teknis di balik mengapa kami mengadopsinya di React. Komentar ini mungkin juga menarik: https://github.com/reactjs/rfcs/pull/68#issuecomment -439314884.

@Hixie atau @dnfield apakah ada di antara Anda yang pernah menghubungi @gaearon?

Sebagai pengguna Flutter yang juga sering menggunakan React, saya dapat mengatakan bahwa hook adalah pengubah permainan nyata untuk React. Saya menulis semua kode baru saya menggunakan kait eksklusif, dan mem-porting semua kelas lama ke kait saat saya mengerjakannya. Manfaat memiliki semua kode yang terkait dengan bagian tertentu dari komponen Anda di tempat yang sama sungguh menakjubkan!

Saya pikir akan luar biasa jika ada upaya untuk mengevaluasi apakah paradigma itu cocok dengan Flutter atau tidak ❤️

Saya melewatkan komentar itu! Saya baru saja menjangkau mereka.

Saya harus mengakui bahwa saya tidak begitu mengerti bagaimana Hooks berlaku untuk Flutter. Sudah ada beberapa paket Hooks jika Anda ingin bereksperimen dengannya (beberapa disebutkan dalam bug ini di atas). Pada dasarnya, saya tidak begitu mengerti masalah apa yang dipecahkan oleh konsep tersebut.

Untuk detail lebih lanjut tentang perspektif saya di sini, lihat komentar saya sebelumnya: https://github.com/flutter/flutter/issues/25280#issuecomment -455846788, https://github.com/flutter/flutter/issues/25280#issuecomment - 455847134, https://github.com/flutter/flutter/issues/25280#issuecomment -456272076.

Pada dasarnya, saya tidak begitu mengerti masalah apa yang dipecahkan oleh konsep tersebut.

Kait seperti mixin negara bagian, tetapi tanpa masalah bawaan mixin: tidak ada konflik variabel, dan dapat digunakan lebih dari sekali.

Hooks dapat memecahkan salah satu masalah terbesar yang dimiliki Flutter dengan Widget stateful saat ini: berurusan dengan semua pengontrol ini.

Setiap pengontrol membutuhkan initState, didUpdateWidget dan membuang, yang _always_ diimplementasikan dengan cara yang sama.

Kami tidak dapat mengekstraknya ke kelas dasar/mixin karena kami mungkin membutuhkan lebih dari satu.
Jadi alih-alih kita harus menyalin-tempel logika di mana-mana.
Tapi itu juga tidak terlalu bagus. Sangat mudah untuk melupakan satu langkah, seperti mengganti dispose .

Masalah sebenarnya dengan kait adalah bahwa mereka membutuhkan banyak pekerjaan untuk diterapkan.

Kerangka inti sederhana. Tetapi karena perilakunya yang unik, mereka memerlukan integrasi yang mendalam dengan alat linter dan refactoring.

Dan untuk implementasi yang optimal, beberapa fitur bahasa seperti Tupple/destructuring mungkin diperlukan.

Saya tidak merasa ini benar-benar membahas komentar yang saya miliki di atas (https://github.com/flutter/flutter/issues/25280#issuecomment-455846788 dan https://github.com/flutter/flutter/issues/25280# issuecomment-456272076 khususnya).

Hum, @gaearon mungkin akan menjelaskannya lebih baik daripada saya, tetapi dari sudut pandang saya:

• Argumen keterbacaan tergantung pada ukuran widget. Pada widget yang lebih besar, kait cenderung sebenarnya _lebih_ dapat dibaca karena semua bit terkait disatukan alih-alih tersebar di seluruh siklus hidup.

• lebih sedikit bug. API deklaratif mereka membuat lebih sulit untuk lupa memperbarui/membersihkan keadaan.

• tentang "mengapa mereka harus inti?", Saya suka metafora yang digunakan oleh Dan Abramov.
  Kait adalah untuk widget apa elektron untuk atom.
  Tidak masuk akal untuk mengecualikan mereka, ketika mereka primitif digunakan untuk membangun hal-hal yang lebih besar.
  Ini bukan hanya tentang menerapkan kait. Seluruh kerangka kerja bisa mendapatkan keuntungan dari mereka.
  Mereka dapat digunakan untuk meningkatkan hal-hal seperti animasi, formulir, dan banyak lagi.

@Hixie , apakah Anda menghabiskan waktu menggunakan Hooks, atau apakah Anda membuat spreadsheet untuk membuat keputusan? Saya tidak yakin berapa % waktu tim Flutter yang dihabiskan untuk menulis kerangka kerja versus menulis aplikasi untuk pelanggan. Saya menduga orang yang menulis aplikasi untuk pelanggan akan mendekati pertanyaan ini dari sudut yang sedikit berbeda dari pengembang kerangka kerja. Yaitu, bagaimana ini membuat saya lebih efektif dan memberikan nilai lebih kepada pelanggan saya, bukan jika memenuhi kriteria yang sama dengan solusi yang ada.

Saya memperkenalkan flutter_hooks baru-baru ini bersama dengan functional_widget di salah satu aplikasi terbaru kami.

Ini sangat mengurangi kode boilerplate dan setelah memfaktorkan ulang semua widget stateful yang berantakan menjadi fungsi kecil dengan kait, basis kode menyusut sekitar 70%.

Dari tampilan tingkat yang lebih tinggi, widget fungsional dengan satu set kait seperti penyederhanaan penting untuk menggabungkan beberapa yang dapat diamati menggunakan combineLatest di RX. Tetapi alih-alih secara eksplisit menyatakan semua yang dapat diamati dalam pembukaan dan memiliki fungsi yang beroperasi pada mereka, kait jauh lebih fleksibel karena Anda menenunnya ke dalam kode di mana Anda membutuhkan nilainya.

Tapi, pada akhirnya setiap widget tersebut seperti panggung dalam aliran RX.

Saya tentu tidak berpikir kita harus menghapus flutter_hooks. Saya hanya tidak melihat apa yang kami (tim Flutter) dapat berikan yang lebih berharga.

Kait adalah untuk widget apa elektron untuk atom.

Saya pikir jika kita mengikuti metafora itu Anda harus melihat Flutter sebagai quark, atau mungkin hadron. Elektron Hooks adalah lapisan di atas.

@Hixie , apakah Anda menghabiskan waktu menggunakan Hooks, atau apakah Anda membuat spreadsheet untuk membuat keputusan? Saya tidak yakin berapa % waktu tim Flutter yang dihabiskan untuk menulis kerangka kerja versus menulis aplikasi untuk pelanggan.

Saya sendiri belum pernah menggunakan Hooks. Saya menulis aplikasi dengan Flutter. Saya belum menemukan kebutuhan apa pun seperti Hooks saat melakukannya. Namun, seperti disebutkan di atas, menurut saya Hooks tidak cocok dengan gaya pengembangan saya (saya lebih suka melihat boilerplate). Saya pasti tidak ingin menghapus Hooks dari siapa pun yang ingin menggunakannya.

Saya hanya tidak melihat apa yang kami (tim Flutter) dapat berikan yang lebih berharga.

Untuk membuat hook benar-benar berguna, mereka memerlukan plugin penganalisis dan opsi refactoring khusus.
Hanya dengan ini kait benar-benar bersinar.

Kait memungkinkan analisis statis yang sangat kuat yang tidak mungkin dilakukan dengan StatefulWidget biasa.
Ini membuat pengelolaan status lokal widget lebih aman/lebih terukur. Bagi saya, pengurangan boilerplate hanyalah bonus.

Tetapi:

• ada _banyak pekerjaan_, pada API tingkat sangat rendah.
• antarmuka plugin penganalisis tidak stabil, kurang, hampir tidak digunakan, dan tidak direkomendasikan oleh tim (karena ada satu analisis yang dilakukan untuk setiap plugin)
• flutter itu sendiri tidak menggunakan API plugin dan malah mengimplementasikannya langsung di server

Jadi, sebagai paket yang dikelola komunitas, kemungkinan memiliki perkakas lengkap untuk kait sangat rendah.

Saya pikir jika kita mengikuti metafora itu Anda harus melihat Flutter sebagai quark, atau mungkin hadron. Elektron Hooks adalah lapisan di atas.

Jika Flutter adalah quark, itu juga sebuah galaksi.

Kami memang memiliki kelas tingkat yang sangat rendah seperti Layer .
Tetapi ada juga sejumlah besar kelas tingkat tinggi seperti Switch .

Seluruh pustaka Material dan Cupertino dapat diekstraksi sebagai paket, lalu Navigator, dan bentuk objek terkait. Tapi mereka tidak.
Dan Hooks adalah beberapa lapisan di bawah ini.

Tidak terkait tetapi saya sangat yakin Material dan Cupertino tidak boleh berada di perpustakaan inti Flutter karena mempromosikan kurangnya antarmuka yang baik yang diposisikan di suatu tempat antara komponen tingkat super rendah dan Bahan tingkat tinggi. Jika Anda pernah mencoba membuat aplikasi tanpa pustaka Material, itu sangat sulit.

Kait tidak terlalu banyak tentang mengurangi boilerplate. (Kami juga tidak keberatan dengan boilerplate.) Nilai utama bagi saya adalah kemampuan untuk merangkum dan menyusun logika stateful.

const [value, setValue] = useState(0)
const debouncedValue = useDebounced(value, 1000)
const interpolatedValue = useSpring(debouncedValue, {
  friction: 10,
  mass: 20
})

Mampu menyalurkan data di antara mereka tanpa khawatir apakah mereka berisi status atau tidak, mengekstrak logika ini ke dalam Hook khusus, atau bahkan menerapkan Hook yang sama beberapa kali, sangat ekspresif. Dan tidak seperti pendekatan seperti Rx, Anda sebenarnya dapat menelusuri semua kode tanpa menggali kombinator.

Untuk membuat hook benar-benar berguna, mereka memerlukan plugin penganalisis dan opsi refactoring khusus.
Hanya dengan ini kait benar-benar bersinar.

Saya setuju bahwa kita perlu mendukung ini. Itu seharusnya merupakan bug yang diajukan terhadap proyek Dart GitHub. Saya ingin kita memindahkan lint khusus Flutter dari basis kode Dart, tentu saja.

Seluruh pustaka Material dan Cupertino dapat diekstraksi sebagai paket, lalu Navigator, dan bentuk objek terkait. Tapi mereka tidak.

Ya, itu mungkin benar juga. Ada alasan praktis mengapa kami tidak melakukan itu (misalnya, itu akan memperumit "Hello World" yang akan mempersulit untuk mulai menggunakan Flutter), tetapi kami tetap dapat mempertimbangkannya. Namun, sekali lagi, itu adalah masalah terpisah yang harus kami ajukan secara terpisah jika kami ingin mempertimbangkannya.

Nilai utama bagi saya adalah mampu merangkum dan menyusun logika stateful.

Itu memang sangat berharga. Tidak jelas bahwa itu harus dalam kerangka inti.

Itu memang sangat berharga. Tidak jelas bahwa itu harus dalam kerangka inti.

Ini akan memungkinkan penghentian beberapa mixin State inti.

Misalnya AutomaticKeepAliveClientMixin berada dalam posisi yang aneh.
Kita harus memanggil super.build , yang sangat kontra-intuitif. Dan super.build itu mengembalikan null yang tidak akan berfungsi dengan tipe yang tidak dapat dibatalkan.
Tetapi sebagai pengait, kedua masalah ini terpecahkan.

Demikian pula, kita tidak membutuhkan SingleTickerProviderStateMixin dan TickerProviderStateMixin karena hook dapat digunakan kembali sebanyak yang diinginkan.

Atau, kait memiliki aspek komunitas yang penting. Jika mereka bukan inti, orang cenderung tidak membuat dan berbagi kait khusus.

Kami sebenarnya tidak akan _menggunakan_ kait dalam kerangka inti, karena IMHO mereka membuat hal-hal menjadi kurang mudah dibaca. Jadi memilikinya dalam kerangka inti tidak akan membantu menghapus kode lain.

Atau, kait memiliki aspek komunitas yang penting. Jika mereka bukan inti, orang cenderung tidak membuat dan berbagi kait khusus.

Jika hook bagus, maka orang akan menggunakannya terlepas dari apakah mereka berasal dari proyek open source Flutter atau, katakanlah, proyek open source Hooks.

Kami sebenarnya tidak akan _menggunakan_ kait dalam kerangka inti, karena IMHO mereka membuat hal-hal menjadi kurang mudah dibaca. Jadi memilikinya dalam kerangka inti tidak akan membantu menghapus kode lain.

Atau, kait memiliki aspek komunitas yang penting. Jika mereka bukan inti, orang cenderung tidak membuat dan berbagi kait khusus.

Jika hook bagus, maka orang akan menggunakannya terlepas dari apakah mereka berasal dari proyek open source Flutter atau, katakanlah, proyek open source Hooks.

Kedengarannya bukan ide yang buruk. Hooks dapat dijalankan sebagai proyek open source yang terpisah. Apakah tim inti akan memprioritaskan persyaratan perubahan inti dari proyek kait? IMHO Ini cukup penting untuk keberhasilan proyek kait.

Apa yang dimaksud dengan "persyaratan perubahan inti"?

Apa yang dimaksud dengan "persyaratan perubahan inti"?

Devtools.
Terutama tentang plug-in penganalisis, tetapi juga berpotensi sistem plug-in pada flutter/devtools.

Ada banyak pekerjaan yang terlibat di sana, yang tidak bisa dilakukan oleh masyarakat.

Kami sebenarnya tidak akan _menggunakan_ kait dalam kerangka inti, karena IMHO mereka membuat hal-hal menjadi kurang mudah dibaca. Jadi memilikinya dalam kerangka inti tidak akan membantu menghapus kode lain.

Dengan segala hormat, tapi ini terdengar agak bodoh. Anda harus benar-benar mencobanya! Mereka jauh lebih ringkas daripada menari-nari dengan initState/dispose/setState/build untuk setiap aspek status.

Flutter adalah semua tentang komposisi dan menggunakan kait secara alami mengikuti pola komposisi di mana menggunakan mixin di sisi lain adalah kebalikan dari komposisi.

Saya membayangkan kami akan terus mempertimbangkan untuk menjadikan penganalisis yang dapat diperluas menjadi prioritas tinggi. Sayangnya, ada banyak prioritas lain yang lebih tinggi, seperti meningkatkan pengalaman untuk tugas-tugas dasar pada jam pertama dan menerapkan alat untuk perubahan non-nullable-by-default.

Karena itu, saya tidak mengerti mengapa hal itu tidak dapat dilakukan oleh non-Googler. Flutter dan Dart adalah proyek sumber terbuka dan banyak hal yang diimplementasikan oleh non-Googler.

Karena itu, saya tidak mengerti mengapa hal itu tidak dapat dilakukan oleh non-Googler. Flutter dan Dart adalah proyek sumber terbuka dan banyak hal yang diimplementasikan oleh non-Googler.

Kita berbicara tentang pekerjaan berbulan-bulan di beberapa proyek, untuk hal-hal yang dianggap tim sebagai "fitur prioritas rendah", dengan banyak perubahan besar yang melanggar. Dan proyek yang terkena dampak sangat rendah dengan hampir tidak ada dokumentasi publik.

Investasi yang dibutuhkan dan risiko penolakan/terjebak di tengah terlalu tinggi. Terutama ketika kita tidak mendapatkan uang dari itu.

Jadi sementara saya mengerti maksud Anda, itu sangat tidak mungkin

Apakah ada roadmap tentang itu? Apakah Anda tahu jika dan kapan kait bisa mendarat dengan bergetar?

Jika Flutter berhasil (yang saya harap akan berhasil) dalam 1 tahun, setiap pengembang React yang mencoba bergabung ke Flutter akan berteriak ketika mereka mengetahui bahwa tidak ada dukungan kelas satu untuk hook di sini.

Tim Flutter membuat keputusan yang baik dengan menyalin model React berbasis kelas, tetapi itu adalah masa lalu sekarang, komponen fungsional dan kait adalah masa depan, tim Flutter harus menyadari kenyataan baru ini jika mereka ingin tetap setara .

Tepat seperti yang dinyatakan cgarciae, komunitas React bergerak ke hook dan komponen fungsional ke depan. Dan itu membuat flutter terlihat ketinggalan zaman, karena model pemrograman dan produktivitas tidak akan setara dengan solusi pengembangan lintas platform lainnya.

Setelah mencoba kedua reaksi dan flutter baru-baru ini, kehilangan hook in flutter meninggalkan lubang besar dalam hal produktivitas, konsistensi, dan perawatan apartemen dibandingkan. Itu tidak akan membantu organisasi untuk mengadopsi flutter dalam proyek baru, atau meyakinkan orang beralih dari solusi dasar React ke flutter yang sepadan dengan usaha.

Saya mengerti sepenuhnya ketika seseorang membangun toolset, implementasi kerangka kerja tingkat rendah, kode boilerplate mungkin tidak terlalu menjadi masalah. Tetapi jika pengembang aplikasi perlu menulis banyak boilerplate "tidak perlu" untuk membuat sesuatu berfungsi, efeknya tidak diinginkan.

Tergantung dari sudut mana orang melihat masalah tertentu, tradeoff/keseimbangan mungkin terlihat berbeda. Tidak menyediakan perkakas yang tepat atau fitur tertentu mungkin membuat implementasi internal framework terlihat lebih bersih, tetapi itu hanya melepaskan tanggung jawab ke konsumen framework, membuat implementasi sisi klien lebih rumit dan kikuk daripada yang seharusnya, yang pada gilirannya tidak membantu adaptasi pemberian kerangka. Untuk pengembang aplikasi, produktivitas dan konsistensi penting, pendekatan/standar yang seragam penting untuk kerja tim dan komunitas. Pendekatan holistik harus selalu mempertimbangkan orang yang tinggal di sisi lain pagar.

Kait harus mudah diterapkan, tetapi widget fungsional lebih sulit. Itu akan membutuhkan tipe serikat pekerja di Dart karena Anda perlu mengekspresikan sesuatu seperti:

'Widget | Fungsi Widget (Konteks Bangun)'.

widget fungsional lebih sulit. Itu akan membutuhkan tipe serikat pekerja di Dart

Itu jauh dari cukup.
Masih ada pertanyaan tentang:

• bagaimana cara melewatkan parameter ke fungsi? kari?
• sekali di pohon widget, dua widget fungsional harus memiliki runtimeType yang berbeda
• bagaimana cara memasang widget dengan devtools? (metode widget debugFillProperties )

Aku sudah memikirkannya cukup lama. Saya tidak melihat solusi mudah untuk widget fungsional.
Satu-satunya hal yang dapat saya pikirkan adalah kombinasi dari pembuat kode dan plugin penganalisis (untuk mendapatkan definisi dan hal-hal yang tepat).

Sebenarnya, bagian pembuatan kode membuat kami keluar dari paket functional_widget Anda. Itu hanya membuat banyak lompatan saat meninjau kode. Jadi, itu tidak akan terbang untukku...

Itu hanya membuat banyak lompatan saat meninjau kode

Karenanya mengapa saya menyebutkan plugin penganalisis.

Dengan plugin penganalisa khusus, kita seharusnya dapat:

• periksa bahwa fungsi tidak digunakan secara langsung dan kelas lebih disukai
• memiliki "pergi ke definisi"/"mengintip"/... yang tepat, sehingga mengklik kelas dialihkan ke fungsi

Ini harus memperbaiki semua masalah.
Tapi kita akan kembali ke "kait membutuhkan sistem plugin penganalisis yang tepat".

Mungkin memperkenalkan widget functional tidak diperlukan:

Katakanlah menggunakan kait hanya diperbolehkan di dalam metode StatelessWidget build .

Dari sudut pandang teknis - tidak masalah (sejauh yang dapat saya pikirkan sekarang) apakah itu kelas atau fungsi. Bagian yang penting adalah Anda tidak mencampur kelas stateful dan kait. Di bawah tenda, perender flutter masih dapat menghitung kait dan pesanannya jika dipanggil di dalam metode build dan mengelolanya dengan benar.

Di masa depan, jika membuat widget fungsional dimungkinkan, itu tidak merusak perubahan. Juga, itu akan kompatibel kembali, karena tidak merusak aplikasi yang ada.

Saya tidak melihat masalah yang jelas dengan menggunakan kait di dalam StatelessWidget yang akan menghilangkan manfaat menggunakan kait seperti komposisi.

Saya tidak yakin, bagaimanapun, bagaimana perbandingannya dengan kasus-kasus seperti useCallback dll dari reaksi dibandingkan dengan kemampuan menggunakan metode instan

Argumen "kita harus menambahkan ini karena pengembang Bereaksi akan marah" tidak valid. (lihat 500+ komentar diskusi BEJ).

Flutter adalah Flutter, dan ia memiliki bahasa dan pola desainnya sendiri.
Saya pikir kita tidak boleh menambahkan hal-hal ke kerangka hanya demi membuatnya lebih akrab bagi pengembang Bereaksi, mereka dapat menggunakan paket jika mau.

Saya membaca diskusi dan saya pikir @Hixie sebagai pengembang kerangka kerja flutter baru saja melihat sisi masalahnya (Menerapkan dan ... hal-hal) dan memiliki lebih sedikit perspektif tentang bagaimana pengembang aplikasi flutter (yang merupakan audiens targetnya) berpikir, dan menggunakannya dalam perkembangan mereka.

Saya sebagai pengembang Android memiliki masalah seperti itu, mencoba mengembangkan struktur back-end yang bagus untuk aplikasi saya tanpa tahu bagaimana pengalaman pengguna aplikasi saya ketika mereka melihat UI saya yang jelek dan UX yang sulit dipahami.

Seperti yang dikatakan orang lain sebelumnya, hook itu bagus. tidak peduli siapa yang memperkenalkannya, baik FB jahat atau Apple.
itu hanya bekerja. itu memisahkan logika negara dan siklus hidupnya. kita dapat membuat beberapa kait lain yang berguna di atas yang lain, menerbitkan widget independen, apis, alat, ... dari status aplikasi, menggunakan kembali yang sudah diproduksi sebelumnya di proyek lain, ....

Dan saya pikir, jika pra-menambahkan baris di pubspec.yaml untuk mengimpor materi atau cupertino sulit untuk membuat aplikasi hello-word sederhana!!!, tidak ada yang perlu dibahas di sini.
Tetapi karena StatefullWidget sangat penting untuk ekosistem flutter, kait dan relevansinya lebih penting untuk masa depan flutter dan komunitas pengembang ekosistem dan flutter.

Bayangkan saja bagaimana pengembangan aplikasi bergetar menjadi lebih sederhana, tahan bug, mudah dimengerti, dapat diperluas, dapat dibaca, dapat di-debug, portabel, ... (apa pun yang tipis dan bisa di sini tolong 😁) dengan kait yang didukung langsung dengan inti (atau sesuatu di tengah antara inti dan beberapa widget kompleks seperti materi, ...) khusus resmi.

Untuk lebih memahami maksud saya, lihat betapa buruknya pengembangan Android dengan Java dan pustaka dukungan dan betapa mewah dan manisnya dengan Kotlin.
Ini juga membuka pintu untuk hal-hal baik lainnya seperti Coroutine, Flow, dukungan AndroidX + Kotlin, sistem ui baru (Tulis)
Bahkan itu mendorong komunitas java untuk memulai dan mengimplementasikan kotlin futures di lingkungan mereka.

Jadi tolong letakkan buffer apa pun di kait, dan bereaksi dan lakukan saja

Kurangnya dukungan kait resmi adalah satu-satunya alasan saya belum beralih dari reaksi asli.

Kait membuat hidup jauh lebih mudah sehingga saya tidak ingin menulisnya dengan cara lama lagi

Bagian luar biasa dari "kail asli" adalah kita dapat mem-port banyak StatefulWidget internal atau ... ke bentuk sederhana yang dapat dimengerti ini.
Juga sebagai tim flutter menyatakan Flutter dan Dart dibuat agar mudah digunakan, mudah dimengerti, dan kurva belajar cepat. Semua ini bisa benar dan lebih baik dengan Native Hooks.
Dan cara (initState/dispose/setState/build) tidak ada di jalur ini. (kami mungkin membutuhkannya di backend platform tetapi tidak untuk pengembang baru atau bahkan desainer yang ingin menggunakan kode hanya untuk menggambarkan ide mereka (bukan logika kompleks))

Bacaan saya di utas ini adalah bahwa ada banyak orang yang bersemangat menggunakan kait di Flutter, dan beberapa pertanyaan terbuka tentang kait:

• Dampak/pengukuran kinerja - khususnya, efisiensi dari selalu menjalankan fungsi vs. melihat bahwa status boleh digunakan kembali tanpa menjalankan fungsi baru.
• Kemampuan (ketidakmampuan?) untuk bermain dengan baik dengan kunci global dan/atau bergerak secara efisien di sekitar pohon.
• Dukungan penganalisis/serat khusus untuk kait.
• Kemampuan untuk bekerja dengan baik dengan hot reload sebagai widget stateful/stateless biasa.
• Potensi kebutuhan untuk framework API tambahan.

Saya yakin semua pertanyaan ini dapat dijawab, tetapi mengatasinya bukanlah hal yang sepele. Masalahnya bukan "haruskah kait berada dalam kerangka kerja atau haruskah kait hidup dalam paket terpisah." Sampai batas tertentu, keputusan itu sudah dibuat - flutter_hooks telah tersedia di pub.dev selama lebih dari satu tahun sekarang, dan tampaknya menjadi paket yang populer. Itu membuat flutter_hooks pengalaman yang benar-benar dipoles akan membutuhkan beberapa pekerjaan dan investasi yang signifikan, di luar apa yang sudah dilakukan.

Banyak dari pekerjaan itu _telah_ dilakukan untuk kelas kerangka kerja inti, dan butuh beberapa tim teknik serta beberapa kontributor open source bertahun-tahun untuk mencapai titik di mana itu. Terkadang sepertinya ada ilusi "jika kita menggabungkannya ke repo X, semua hal yang belum terselesaikan akan teratasi!" Tetapi cara hal ini terjadi adalah orang-orang yang tertarik dengannya melakukan pekerjaan untuk mengimplementasikannya. @rrousselGit telah melakukan banyak pekerjaan di sekitar ini, dan sepertinya beberapa kontributor lain juga memilikinya di repositori hooks.

Apa yang ingin saya katakan secara singkat adalah - hooks dapat bekerja dengan baik tanpa harus berada di repositori Flutter, berada di repositori Flutter tidak akan mempercepat penyelesaian masalah-masalahnya yang luar biasa, dan bahwa siapa pun dan semua orang yang ingin melihat Hooks berfungsi di Flutter sepenuhnya diberdayakan untuk mewujudkannya.

Menurut pendapat saya, kait seharusnya menjadi fitur bahasa yang mirip dengan generator sinkronisasi /async .
Itu tidak harus berhubungan dengan flutter sama sekali.

Masalah yang dipecahkan oleh hook adalah:

• manajemen negara deklaratif dan reaktif.
  State sangat penting
• komposisi status untuk memperbaiki KERING.
  Semua XXController ini perlu dibuat+diperbarui+dibuang dan tidak ada cara untuk memfaktorkan logika itu.
• keterbacaan, karena tidak melibatkan sarang fungsi/widget tanpa akhir untuk mencapai hasil itu

Tetapi sintaks alternatif dapat berupa:

class MyWidget extends HookWidget {
  const MyWidget({Key key, this.title}): super(key: key);

  final String title;

  Hook<Widget> build() hook* {
    final (flag, setFlag) = yield false;
    final (animationController) = yield* useAnimationController(duration: const Duration(seconds: 2));

    // TODO: do something with animationController
    return CheckBox(
      value: flag,
      onChanged: setFlag,
    );  
  }
}

Hook<AnimationController> useAnimationController({required Duration duration}) hook* {
  final (tickerProvider) = yield* useTickerProvider();
  final (animationController) = yield AnimationController(duration: duration, vsync: tickerProvider);
  animationController.duration = duration;

  return animationController;
}

Ini mencapai efek yang sama seperti flutter_hook, tetapi tidak tergantung pada flutter dan dengan beberapa faktor pengoptimalan yang tidak dapat dilakukan flutter_hook.

Dan ini pada dasarnya memungkinkan _anything_ untuk menggunakan kait, bukan hanya widget.

Itu ide yang menarik. Kedengarannya seperti ada beberapa permintaan fitur bahasa di sana (sesuatu seperti defer dari Go, sesuatu seperti destruktor deterministik dari C++, beberapa kemampuan untuk secara implisit menyusun fungsi menjadi objek) - tetapi ini bukan tempat yang tepat untuk melacak itu.

Saya pikir akan bermanfaat untuk mengidentifikasi titik nyeri yang dialami orang dengan tidak memiliki sesuatu seperti kait di Flutter, dan mengajukan masalah secara khusus tentang rasa sakit itu tanpa memilih solusi untuk memulai. Sangat mungkin, bagaimanapun, bahwa beberapa dari poin nyeri ini mungkin hanya hal-hal yang dipaksakan oleh kerangka kerja untuk mencapai tujuan tentang pertukaran kinerja, kualitas, atau kegunaan (seperti, kita dapat membuat titik nyeri X lebih baik di biaya membuat titik nyeri Y jauh lebih buruk).

Seperti berdiri sekarang, saya akan menutup masalah ini. Ada paket bagus di luar sana yang menangani solusi spesifik ini, dan solusi itu sendiri bukanlah sesuatu yang siap untuk digabungkan ke dalam kerangka kerja dalam kondisi saat ini (untuk alasan yang diuraikan di atas), dan tidak jelas apakah solusi tersebut akan benar-benar manfaat dari yang digabungkan ke dalam kerangka.

@dnfield Hooks berfungsi dengan baik 'sebagai sebuah keluarga', hanya jika Anda memiliki semua area persyaratan utama yang tercakup.

Tidak ada gunanya menggunakan kait status jika Anda akan menabrak dinding saat Anda membutuhkan semacam efek setelah perubahan status.

Setiap hook by design memerlukan perubahan signifikan di dalam inti penyaji atau memperkenalkan jenis komponen inti baru.

Upaya seperti itu tidak sepadan hanya untuk satu jenis pengait (titik nyeri), jadi saya akan mengatakan tidak mungkin untuk menyelesaikan masalah ini sebagai serangkaian masalah yang lebih kecil. Kait tunggal tidak layak untuk beralih dari komponen stateful dan tentu saja tidak layak untuk memperkenalkan perubahan signifikan pada mesin rendering.

Jika masalah ini dimaksudkan untuk mengatakan "Saya ingin Flutter menjadi lebih seperti Bereaksi tetapi juga menjadi seperti Flutter", saya tidak yakin seberapa dapat ditindaklanjuti - dan masalah GitHub mungkin bukan cara yang tepat untuk melacak hal seperti itu, bahkan jika kita memberikan hal seperti itu masuk akal untuk dilacak.

Dengan kata lain: jika ini adalah permintaan untuk menulis ulang inti Flutter, ini bukan cara yang tepat untuk mendekatinya. Saya tidak yakin apa cara yang tepat untuk mendekatinya, tetapi mungkin akan dimulai hanya dengan melakukan forking repositori dan melakukan upaya besar-besaran.

Saya memiliki perasaan aneh ketika kait diperkenalkan kepada orang-orang yang tidak mengenalnya dan memelihara teknologi lain.

Tampaknya balasan sering kali adalah sesuatu seperti "jika Anda ingin X seperti Bereaksi, gunakan reaksi".

Pendapat saya adalah bahwa kait adalah solusi umum untuk banyak masalah frontend di mana Anda perlu menggunakan kembali logika data yang kompleks. Ini lebih seperti ide yang dapat digunakan dalam teknologi apa pun.

Hooks, bagaimanapun, memerlukan semacam peralihan dalam memikirkan aliran data sebelum nilainya terlihat sepenuhnya. Saya pikir itu mungkin menjadi masalah besar ketika "meminta" kait di kerangka kerja lain.

Saya pikir tim React melakukan pekerjaan yang bagus untuk menjelaskan hook, tetapi mungkin ini menciptakan beberapa perlawanan karena membuat hook tampak sangat terkait dengan React.

Saya pikir React sering disebut sebagai hook berikutnya hanya karena di sinilah mereka ditemukan. React juga merupakan sumber informasi terbaik tentang hook (sejauh ini).

Secara umum - saya akan menggambarkan "titik sakit" karena tidak dapat menggunakan pola komposisi untuk logika data secara langsung di Flutter. Kait hanyalah contoh mengizinkan itu.

Saya juga mengerti bahwa memperkenalkan hook adalah tugas besar dan saya harus mengatakan bahwa saya tidak bersedia melakukannya.

Saya pribadi tidak mengerti argumen "komunitas berusaha untuk memperbaiki masalah itu, jadi kami tidak perlu melakukan apa-apa".

Perbaikan komunitas tidak berarti bahwa hal itu tidak dapat dilakukan dengan lebih baik oleh Google.
Ambil ekspresi di dalam koleksi sebagai contoh.
Komunitas dapat "memperbaikinya" dengan mem-forking Row/Column/ListView/... untuk mendukung null .
Tetapi Google memperbaikinya dengan memodifikasi bahasa.

Juga, Flutter sendiri mengatakannya: Flutter terinspirasi dari React.
Ini dapat dilihat dari bagaimana sebagian besar penggunaan Widget pada dasarnya adalah bagaimana kelas React digunakan.

Meskipun ini tidak berarti bahwa Flutter harus cocok dengan React, saya berharap tim Flutter setidaknya terus memperhatikan pembaruan React dan ekosistemnya.
Ini setidaknya harus memberikan jawaban yang lebih baik mengapa "kami tidak ingin kait dalam kerangka kerja" selain argumen komunitas.

@rrousselGit @pie6k

Saya pribadi menemukan Hooks API, seperti di React, agak sulit untuk dipahami. Saya lebih suka metode siklus hidup dan penamaan deskriptif mereka.

Saya tahu ini adalah "masalah saya", tetapi saya mendukung komentar @dnfield yang mengatakan bahwa kita mungkin harus mengambil masalah dan menerapkan solusi secara berbeda.

Saya juga jarang sampai pada situasi dua widget terpisah perlu berbagi logika yang sama (itulah yang saya pahami sebagai manfaat utama dari Hooks?)

Dan tentang Flutter yang terinspirasi oleh React, tidak apa-apa, tapi itu tidak berarti itu akan mengikuti semua pola dan arsitektur React selamanya.
Salah satu masalah utama yang saya miliki dengan React adalah ada begitu banyak cara berbeda untuk melakukan sesuatu, dan "praktik yang direkomendasikan" berubah setiap hari. Saya mengerti itu sifat dari rekayasa perangkat lunak, tapi saya masih berpikir jika ada sesuatu yang buruk tentang cara yang ada, mereka harus berusaha untuk memperbaikinya… daripada menumpuk cara yang berbeda untuk mencapai hal yang sama.

Saya harap ini memberi Anda perspektif yang sedikit berbeda dan tidak menyinggung siapa pun.

Rasa hormat yang besar atas kontribusi Anda pada komunitas Flutter.

Sedih masalah ini ditutup. Itu membuatnya tampak seperti tim Flutter tidak peduli dengan kait atau tidak peduli dengan keadaan pola desain saat ini (saya harap tidak). Ini tidak baik untuk teknologi apa pun, orang yang menghabiskan ratusan jam ingin tahu bahwa apa yang mereka gunakan adalah yang terbaik atau setara dengannya, dan saat ini pola yang paling produktif adalah kait dan Flutter tertinggal, tetapi itu bahkan tidak dipertimbangkan atau diabaikan demi alternatif yang lebih baik secara meyakinkan oleh pengelola.

@cgarciae tidak ada yang bodoh, @dnfield dengan jelas mengatakan - alih-alih mencoba memeras solusi yang ada, buka masalah untuk masalah terkait yang Anda miliki, tim Flutter akan mengevaluasinya dan mungkin menemukan solusi yang lebih cocok untuk Flutter.

Ini adalah fitur yang sangat ditanyakan dan akan ditanyakan oleh komunitas. Jika masalah bukan tempat yang tepat, apakah kalian memiliki permintaan fitur untuk mendaftar persyaratan dari komunitas?

@SpajicM Saya sepenuhnya baik-baik saja dengan "tidak" sebagai jawaban.
Apa yang saya tidak setuju dengan adalah pembenaran saat ini.

Beberapa catatan:

• Kait adalah fitur penting dari React, bapak Flutter
• masalah ini adalah salah satu yang paling banyak dipilih di Flutter
• flutter_hooks cukup populer
• Dan Abramov dari tim React mengusulkan untuk berdiskusi dengan tim https://github.com/flutter/flutter/issues/25280#issuecomment -456404333

Ini harus memberikan beberapa intensif untuk membahas tentang kait. Belum tentu menerapkannya, tetapi setidaknya menjelajahinya.

Ujung-ujungnya bermuara pada masalah komunikasi.

• Apakah tim Flutter menghubungi tim React seperti yang ditawarkan oleh Dan Abramov?
• Apakah tim bereksperimen dengan hook di React?
• Apakah ada alternatif yang dipertimbangkan untuk masalah yang dipecahkan oleh kait?

Kami, sebagai komunitas, tidak tahu apa-apa tentang itu.

Didorong selangkah lebih maju, saya pikir itu ironis bahwa komunitas disarankan untuk membagi masalah ini menjadi "masalah apa yang dipecahkan oleh hook", ketika tim React sendiri menawarkan untuk menjelaskan kepada tim Flutter apa masalah ini.

@rrousselGit Saya pikir ide di baliknya adalah untuk mendengar masalah dari sisi khusus Flutter, langsung dari pengguna, dan menganggapnya sebagai titik awal alih-alih mengambil alasan React, bukan berarti masukan mereka tidak akan berharga.

Pendapat saya adalah akan lebih baik untuk memiliki cara untuk memisahkan dengan jelas antara logika dan desain widget - jadi saya setuju bahwa ada masalah yang harus diselesaikan , tetapi cara React melakukannya agak membingungkan bagi saya dan saya berharap solusi Flutter di masa depan memiliki perubahan paradigma/kurva pembelajaran yang kurang dramatis. Saya tidak memiliki ide dalam pikiran tetapi saya yakin komunitas bersama dengan tim dapat menghasilkan sesuatu jika berpikiran terbuka dan tidak terpaku pada implementasi Hooks yang ada.

Saya kira langkah selanjutnya adalah membuka masalah yang disebut:

_"Flutter membutuhkan cara yang lebih baik untuk mengisolasi logika widget"_

Saya pikir https://svelte.dev/ memiliki pendekatan yang berbeda dan lebih baik untuk menyelesaikan masalah ini. Sebagai langkah awal, tim Flutter harus menyadari bahwa ada masalah dan kami membutuhkan solusi.

Saya baru mengenal flutter dan yang saya rasakan adalah API memiliki banyak boilerplate. Pikir Dart memiliki generik, rasanya seperti saya memprogram di Go di mana lebih umum/lebih mudah untuk melakukan salin dan tempel. Saya berharap akan ada refactoring besar ketika NNDB mendarat, terutama menggunakan metode ekstensi sepenuhnya. Abstraksi API bertahap melalui sesuatu seperti metode ekstensi mungkin layak untuk dijelajahi.

IMHO, tim Flutter terlalu tertarik pada gagasan "semuanya adalah Widget". Widget sangat bagus untuk item dan tata letak visual, tetapi tidak untuk pengambilan/pemrosesan data. Daripada rumit FutureBuilder , StreamBuilder , TweenAnimationBuilder dll. Saya lebih suka API fungsional:

Widget build(BuildContext context) {
    final a = useFuture(someFuture);
    final b = useStream(someStream);
    if (a.value == null || b.value == null) {
        return CircularProgressIndicator();
    }

    final value = a.value + b.value;
    final smoothedValue = animate(value, duration: Duration(milliseconds: 100), curve: Curves.easeInOut);

    return Slider(
        value: smoothedValue
    );
}

Faktanya, Flutter sudah menggunakan hook di beberapa tempat. Jadi, alih-alih lebih banyak "Fluttery"

MediaQueryGetter {
    builder: (BuildContext context, MediaQueryData data) {
        ...
    }
}

Kamu dapat memakai
final data = MediaQuery.of(context);

Sayangnya, mekanisme ini (berlangganan sambil mendapatkan) hanya berfungsi bersama dengan InheritedWidget.

Saya tidak yakin seberapa banyak kemajuan yang dapat kami buat dalam hal ini, tetapi saya ingin membahas beberapa poin yang saya lihat di sini:

1. Jauh lebih sulit untuk mengevaluasi _solusi_ daripada mengevaluasi _masalah_ dalam masalah GitHub. Saat Anda memberikan solusi, ada batasan yang jauh lebih tinggi untuk dicapai untuk mendapatkan penerimaan. Anda harus menunjukkan bahwa solusi tersebut terbentuk dengan baik, sepadan dengan usaha yang dilakukan, dan bahwa solusi tersebut memecahkan sejumlah masalah nyata yang sepadan dengan tingkat upaya yang diperlukan (termasuk tidak hanya pembuatan prototipe dan implementasi awal, tetapi juga pemeliharaan dan kualitas yang berkelanjutan) . Dengan kata lain, masalah di mana kita membahas titik kesulitan tertentu seputar pengelolaan data dan status widget kemungkinan akan mengarah pada sejumlah solusi, beberapa di antaranya dapat diadopsi ke dalam kerangka kerja, beberapa di antaranya dapat menjadi paket pihak ketiga, dan beberapa lainnya. yang akan menyenangkan tapi hanya biaya terlalu banyak.

2. Insinyur Google yang mengerjakan Flutter dan Dart selalu mencari cara untuk membuatnya lebih baik, dan umumnya selalu sibuk. Hal yang sama berlaku untuk banyak engineer non-Google yang berkontribusi pada Flutter. Penutupan bug ini tidak berarti bahwa tidak ada teknisi Google yang akan bekerja untuk membuat hook bekerja lebih baik dengan Flutter. Fakta bahwa paket hooks dimiliki oleh anggota komunitas tidak mengurangi kualitas paket atau nilainya - juga tidak mengurangi kemampuan untuk memenuhi beberapa kekurangan yang diidentifikasi dalam bug ini, misalnya dukungan yang lebih baik untuk analisis/linting

3. Ada berbagai alasan untuk menerima atau menolak suatu fitur. Terkadang fiturnya sangat keren, tetapi tidak sesuai dengan arsitekturnya. Terkadang fitur tersebut terlihat bagus di permukaan, tetapi memiliki beberapa kekurangan utama yang belum diatasi. Kadang-kadang fiturnya hebat, itu akan cocok dengan jumlah usaha yang cukup, tetapi jumlah usaha yang dikeluarkannya melebihi nilai yang diberikannya kepada pengguna, atau akan mengurangi waktu yang dibutuhkan untuk fitur lain yang bahkan lebih berharga. Khususnya untuk Flutter, terkadang kami hanya memiliki arsitektur berlapis tinggi yang memungkinkan ekstensi oleh paket pihak ketiga, dan sering kali lebih baik mempertahankan peletakan dan mengizinkan pihak ketiga melakukan pekerjaan hebat daripada menyertakan beberapa hal baru dalam kerangka kerja. Kami melakukannya sendiri dalam paket seperti paket animasi baru yang ada di https://github.com/flutter/packages/tree/master/packages/animations.

Akhirnya, saya berada di ujung lain ini. Saya sendiri adalah pengelola paket, dan proposal fitur saya ditolak yang akan membuat paket saya lebih mudah dirawat atau dikembangkan. Satu-satunya saran saya adalah jika Anda memiliki paket hebat yang Anda sukai, teruslah mengerjakannya. Orang lain akan mengenalinya dan membantu juga, apakah itu termasuk dalam repo ini atau tidak.

ComposeUI baru Android memiliki status seperti kait: (pratinjau2)

val state = remember { CardDesignerState() } // react: let state = useState(CardDesignerState())
val thing = stateFor<T?> { null } // react: let thing = useState()

juga iOS SwiftUI baru memiliki hal serupa (tetapi secara internal):

// from https://developer.apple.com/tutorials/swiftui/animating-views-and-transitions
Image(systemName: "chevron.right.circle")
                        .imageScale(.large)
                        .rotationEffect(.degrees(showDetail ? 90 : 0))
                        .scaleEffect(showDetail ? 1.5 : 1)
                        .padding()
                        .animation(.easeInOut)

bayangkan swiftUI iOS menggunakan onCreate, onInit, onUpdate, onExit, ...

tapi framework terbaik (tentu saja Flutter) masih menolak juga menggunakan ide kait, kenapa?
Karena terlihat seperti React/ReactNative !!! atau beberapa kutipan luar biasa dari tim pengelola:

Saya lebih suka melihat boilerplate

jelas menentang ide flutter untuk menulis UI dengan sintaksis deklaratif

Saya pikir hooks mixin adalah solusi yang bagus.
Miliki pengait di mana pun kami suka dan jangan sentuh kode dan kerangka kerja pengembang gaya lama.
Tetapi ide ini dan ide-ide hebat lainnya membutuhkan integrasi yang kuat dengan perpustakaan inti dan Ada baiknya melihat pengelola inti untuk mendukung fitur-fitur ini di kelas satu.
Saya juga dapat membayangkan masa depan setelah integrasi kait, bahwa banyak perpustakaan kerangka kerja tingkat atas (seperti materi) sangat mendukung dan bahkan menggunakannya di dalamnya.

Flutter bisa lebih indah:

// this is just scratch, not a complete and true use-case
build(context) {
    final angle = useAnimation(2*PI, 0, 5 /*seconds*/);
    return Image.from(myAwesomeImage)
        .padding(8)
        .scale(2.5)
        .rotate(angle);
}

@HKhademian setuju sekali. Kurangnya dukungan kelas satu untuk apa pun seperti kait (atau dalam istilah lain - apa pun yang memungkinkan komposisi logika bisnis yang dapat digunakan kembali) sebenarnya adalah satu-satunya alasan saya tidak memilih Flutter untuk proyek terakhir saya.

2. Fakta bahwa paket hooks dimiliki oleh anggota komunitas tidak mengurangi kualitas paket atau nilainya - juga tidak mengurangi kemampuan untuk memenuhi beberapa kekurangan yang diidentifikasi dalam bug ini, misalnya dukungan yang lebih baik untuk analisis /linting

Apakah paket hantu anggota komunitas? Ya. Apakah Google akan membuat Flutter inti hantu? Nah, berdasarkan pendirian Anda di sini tampaknya itu adalah kemungkinan. Menegaskan bahwa Flutter inti sama layak untuk dikonsumsi seperti halnya paket komunitas adalah... yang paling salah dan paling buruk bohong.

Selain itu, telah ditunjukkan berkali-kali bahwa kecuali ada pembelian dari @Hixie , yang telah menunjukkan ketertarikan untuk menggunakan preferensi pribadi untuk mengesampingkan permintaan komunitas, tidak peduli apa yang diinginkan atau dibutuhkan komunitas. Tanpa buy in, itu tidak terjadi. Dan jika bukan itu masalahnya, maka proses pengambilan keputusan terlalu buram untuk melihat sebaliknya.

Yang menarik bagi saya adalah orang-orang yang memutuskan apakah fitur hidup atau mati tampaknya hanya memiliki sedikit pengalaman bisnis dalam membangun aplikasi seluler. Sudut pandang itu akan selalu menghasilkan wawasan paling banyak tentang gula mana yang harus dicampur ke dalam Flutter.

Menurut saya, kami memerlukan proses formal untuk memutuskan fitur apa yang menjadikannya Flutter yang memberi bobot lebih pada komunitas untuk berkontribusi pada proses pengambilan keputusan. Jelas tidak 100%, tapi saat ini rasanya seperti sekitar 5%, dan 5% super flakey pada saat itu. @timsneath

Jauh lebih sulit untuk mengevaluasi solusi daripada mengevaluasi masalah dalam masalah GitHub

Tim React telah menawarkan untuk menjelaskan alasan mereka di balik Hooks di awal terbitan ini.
Ini harus sepenuhnya mencakup kebutuhan untuk menjelaskan mengapa kait diperlukan, karena tidak ada yang ditempatkan lebih baik untuk menjelaskan kait selain tim React itu sendiri.

Masalah terkait (meta) https://github.com/flutter/flutter/issues/28884

Luke, aku menghormati dan menghargai semangatmu, tapi tolong hentikan serangan ad hominem itu. Kami semua bekerja untuk mencoba dan membangun platform terbaik yang kami bisa, membuat semua jenis pertukaran berdasarkan kapasitas sumber daya, penelitian pengguna, masukan pemangku kepentingan, kebutuhan pelanggan, dan masukan masyarakat.

Bersikap baiklah. https://github.com/flutter/flutter/blob/master/CODE_OF_CONDUCT.md

Tidak ada serangan ad hominem yang dimaksudkan, terima kasih atas umpan baliknya. Sesuai CoC mungkin kita harus berkumpul untuk membahas apa yang saya coba komunikasikan.

Orang-orang yang tidak setuju harus berkumpul, mencoba untuk memahami sudut pandang satu sama lain, dan bekerja untuk menemukan desain yang menjawab kekhawatiran semua orang.

Apakah ada pembaruan tentang ini, atau di mana kami dapat mengoordinasikan solusi? Saya mengalami ini dengan proyek Flutter saya, terutama dengan Animasi dan Transisi. Kait membantu merangkum status initState dan dispose ini, antara lain, ke dalam satu fungsi dan cukup gunakan fungsi itu alih-alih mengatur semuanya.

Rasanya, setidaknya bagi pengamat/pengguna luar Flutter daripada pengelola plugin, bahwa ada kekhawatiran yang sah yang tidak merasa seperti sedang didengarkan, seperti masalah lain dengan Flutter Overlay (#50961 ), dan mereka tampaknya dianggap bukan masalah nyata bagi pengguna, bukan pengelola. Sekali lagi, tidak ada rasa tidak hormat kepada pengelola, ini hanya pendapat saya sebagai seseorang yang dengan santai membaca utas masalah ini, saya tidak terlalu akrab dengan masalah lain yang mungkin berbeda.

Dengan itu, bagaimana kita dapat melanjutkan secara lebih umum dalam memikirkan solusi untuk masalah yang tampaknya dimiliki pengguna secara sah? Saya tahu Rust memiliki sistem RFC yang menarik yang tampaknya bekerja dengan baik untuk merancang solusi baru.

@satvikpendem Proses RFC di sini adalah mengajukan bug yang menjelaskan masalah, dan kemudian setelah masalah dijelaskan dengan jelas, untuk mendiskusikan solusi yang mungkin.

Tampaknya masalah telah dijelaskan sejauh ini, sehingga solusi dapat didiskusikan sekarang, mengikuti komentar Anda. Apa yang bisa kita lakukan selanjutnya, apakah ada solusi lain yang bekerja lebih baik daripada kait atau yang serupa?

Jika Anda memberi tahu saya bug# Saya dapat memberi tahu Anda jika masalah tersebut menjelaskan masalah dengan cukup detail sehingga masuk akal untuk mulai mendiskusikan solusi yang mungkin.

@hixie https://github.com/flutter/flutter/issues/51752

Saya juga berpikir kita harus menindaklanjuti komentar Dan: https://github.com/flutter/flutter/issues/25280#issuecomment -456404333
Apa hasil dari diskusi ini?

Hai Remi, terima kasih banyak untuk bug #51752. Saya tahu Anda telah menginvestasikan banyak waktu di ruang ini dan menyumbangkan paket yang sangat berharga di sini. Terima kasih x1000 untuk ini!

Untuk mengulangi komentar @dnfield , tampaknya kita belum menyelaraskan ruang masalah dan signifikansinya. Bug di atas adalah langkah yang berguna menuju tujuan itu, dan/atau dalam mendiskusikan pendekatan potensial untuk masalah tersebut. Pertanyaan tindak lanjut Anda di sini mengasumsikan bahwa percakapan dengan tim React adalah langkah pertama dari sini, tetapi jika kita belum memiliki keselarasan pada ruang masalah, itu tampaknya terlalu dini.

Mungkin kami dapat menunjukkan contoh lengkap aplikasi yang memiliki masalah seperti itu yang akan diperbaiki dengan kait. Kami tidak perlu menulis ulang mereka dengan kait tetapi hanya menunjukkan berapa banyak copy paste yang ada. Apakah itu sesuatu yang setuju dengan diskusi, @timsneath? Atau apakah Anda akan memikirkan hal lain? Saya mencoba mencari cara untuk menunjukkan ruang masalah sejelas mungkin.

:wave: @timsneath
Sejujurnya saya tidak begitu mengerti mengapa berdiskusi dengan tim React terlalu dini.

Bahkan tanpa komunitas yang meminta hook, diskusi dengan tim React akan tetap sangat berharga.
React memiliki banyak kesamaan dengan Flutter, dan mereka memiliki beberapa tahun pengalaman ekstra dalam menangani objek seperti Widget.

Berdiskusi dengan mereka hanya dapat membawa manfaat bagi kedua belah pihak.

Sebagai contoh:
Setelah membuat flutter_hooks, saya dihubungi oleh Dan untuk mendiskusikan bagaimana saya menangani hot-reload untuk hook.
Jawaban saya adalah "Hampir tidak ada yang bisa dilakukan karena Flutter menggunakan bahasa yang diketik".
Beberapa bulan kemudian, mereka meningkatkan hot-reload React dengan menghasilkan sesuatu yang mirip dengan tipe dengan Babel

Saya yakin jika tim Flutter dan React berdiskusi, banyak interaksi seperti itu bisa terjadi, dan kedua teknisi akan maju.

Beberapa pertanyaan terbuka yang dapat diajukan tanpa masalah khusus:

• Mengapa kait?
• Mengapa mode ketegangan/bersamaan?
• Mengapa portal?

@satvikpendem Proses RFC di sini adalah mengajukan bug yang menjelaskan masalah, dan kemudian setelah masalah dijelaskan dengan jelas, untuk mendiskusikan solusi yang mungkin.

Apakah ini berarti bahwa setiap diskusi yang bukan merupakan bug akan diabaikan? Saya pikir tujuan RFC adalah untuk hal-hal yang bukan bug, tetapi biasanya untuk memperluas hal-hal yang lebih subjektif seperti pengalaman pengembang atau semantik perkakas.

Jika seseorang berkata, "Saya pikir kita harus memiliki kaitan karena mereka menjadi idiomatis di berbagai kerangka kerja dan orang-orang melaporkan peningkatan pengalaman dan produktivitas," itu adalah diskusi yang valid untuk dimiliki, tetapi ini bukan bug yang dapat direproduksi.

Saya benar-benar yakin tidak ada yang mengatakan "diskusi yang bukan bug akan diabaikan". Ayo, mari kita bekerja sama dengan itikad baik, saling memperlakukan dengan hormat dan sopan. Kami semua melakukan yang terbaik di sini, tetapi dengan banyak bug, desain, dan ide bersaing lainnya yang bersaing untuk mendapatkan perhatian kami :)

@lukepighetti , ironisnya, "kita harus memiliki kait karena kerangka kerja lain memilikinya" adalah jenis percakapan yang coba kita hindari, sebenarnya -- karena itu mengarah ke desain yang menurut definisi dioptimalkan untuk kebutuhan kerangka kerja lain. Ini sangat membantu dalam proses untuk menjelaskan masalah yang kami coba selesaikan dalam konteks Flutter, karena itu membantu kita semua menyetujui apakah masalahnya sama atau tidak, apakah solusinya harus sama, dll.

@rrousselGit -- tentu, ada beberapa percakapan umum yang berguna yang bisa kita lakukan dengan tim React. Saya menyambut baik tawaran itu, dan mungkin kita harus melakukannya di beberapa titik. Mereka memiliki banyak kecerdasan di tim itu, pasti, dan tawaran mereka sangat ramah dan baik. Saat ini, kami terutama akan berbicara dengan mereka karena Anda menyuruh kami, bukan karena kami punya pertanyaan spesifik yang cukup kami informasikan untuk didiskusikan :)

Dan juga, sebagai pengingat: "tim Flutter" hanyalah orang-orang yang berkontribusi pada Flutter. Beberapa kontributor bekerja untuk Google, dan beberapa kontributor memainkan peran yang lebih kuat dalam mengatur arsitektur proyek, tetapi Anda juga berada di tim Flutter seperti halnya orang lain yang berkontribusi pada proyek :)

Seperti biasa -- terima kasih -- atas kesabaran Anda dalam mendiskusikan hal ini, atas kontribusi Anda kepada komunitas, karena terus mendorong proyek ini dengan ide-ide kreatif di ruang ini!

Untuk memperjelas, "bug" seperti yang kami gunakan adalah istilah umum yang mengacu pada apa pun yang dapat menyebabkan perubahan. Bisa jadi kasus penggunaan, bisa jadi ide, bisa jadi kesalahan logika, bisa jadi salah ketik dalam dokumentasi, sesuatu yang membingungkan di situs Web, apa pun.

Mungkin kami dapat menunjukkan contoh lengkap aplikasi yang memiliki masalah seperti itu yang akan diperbaiki dengan kait. Kami tidak perlu menulis ulang mereka dengan kait tetapi hanya menunjukkan berapa banyak copy paste yang ada.

@satvikpendem Jika masalahnya adalah "aplikasi saya memiliki terlalu banyak boilerplate" maka itu pasti bug yang harus Anda laporkan dan kita dapat mendiskusikan cara memperbaikinya. Sebutkan bug # di sini agar kami tahu untuk melanjutkan percakapan di bug Anda.

Terima kasih atas komentarnya @Hixie. Masalah saya secara luas dicakup oleh bug yang sama yang disebutkan @rrousselGit (#51752) jadi saya rasa saya tidak perlu menambahkan lebih banyak berdasarkan apa yang saya baca di masalah itu.

@timsneath Saya tidak yakin saya mengerti komentar Anda ke @lukepighetti , seperti, sepertinya kami telah menjelaskan masalah dalam konteks Flutter beberapa waktu yang berbeda, seperti masalah ini, #51752, dan lainnya. Apa lagi yang perlu kita sertakan? Bagaimana kami dapat membantu Anda lebih terinformasi tentang ruang masalah ini sehingga jika kami berbicara dengan tim React atau orang lain sehingga Anda akan memiliki pengetahuan yang cukup untuk mengajukan pertanyaan yang terinformasi, seperti yang Anda katakan?

Saya setuju bahwa kita tidak boleh menyalin sesuatu dari kerangka kerja lain hanya karena React memilikinya, misalnya, jadi mungkin akan membantu untuk melihat solusi lain untuk masalah duplikasi kode ini. Pendiri Vue @yyx990803 telah memposting beberapa pemikirannya di RFC Vue (https://www.github.com/vuejs/rfcs/tree/function-apis/active-rfcs%2F0000-function-api.md) yang akan sangat membantu untuk pergi melalui. Pandangan khusus pada bagian tentang masalah apa yang diselesaikan dan mengapa mereka dengan hormat tidak setuju tentang API berbasis kelas berguna untuk dibaca.

Terima kasih telah mengklarifikasi @Hixie , saya salah memahami definisi 'bug' yang lebih luas (mungkin internal?)

@timsneath Saya tidak yakin saya mengikuti. Kelompok orang lain, pengembang reaksi inti, telah mengidentifikasi dan mengomunikasikan serangkaian masalah, menciptakan solusi dalam kerangka kerja yang serupa secara arsitektur, dan banyak tim ujung depan di berbagai kerangka melaporkan keberhasilan. Saya tidak melihat indikasi bahwa ini adalah masalah GitHub "solusi sebelum masalah". Tampaknya @Hixie tidak setuju bahwa ada masalah yang harus diselesaikan, dan tampaknya ini didasarkan pada pilihan gaya atau pemeliharaan yang tidak mencerminkan manfaat pengalaman pengembang. Saya mengatakan itu dengan sangat hormat ketika mencoba memahami dari mana keengganan terhadap RFC ini berasal.

Saya biasanya tidak merekomendasikan fitur parroting, tetapi RFC untuk kait bukan tanpa seni sebelumnya dengan pembenaran yang baik. Seni sebelumnya tersedia dari tim reaksi inti, dan setiap pembenaran yang kami buat akan mengulangi apa yang mereka dapat dan telah komunikasikan. @rrousselGit tampaknya menganjurkan kalian untuk mengatur pertemuan dengan mereka untuk membahas topik ini, karena mereka dapat memberikan lebih banyak wawasan daripada yang kami dapat dalam masalah GitHub.

Sebagai masalah meta, bagi saya pribadi, akan sangat membantu jika ada proses konkret untuk memasukkan RFC luas ke dalam peta jalan flutter/flutter yang dibawakan oleh komunitas. Kami memiliki pepatah bahwa pemangku kepentingan eksternal adalah yang menginginkan pekerjaan yang sulit dan perlu, karena itu mereka harus dimasukkan dan ditanggapi dengan serius. Eksternal dalam konteks flutter/flutter akan menjadi non-tim, non-google, non-GDE.

Saya telah mendokumentasikan proses RFC kami di wiki kami.

Eksternal dalam konteks flutter/flutter adalah non-tim, non-google, non-GDE.

Menurut definisi, jika Anda mengirimkan RFC, Anda adalah anggota tim.

Masalah saya secara luas dicakup oleh bug yang sama yang disebutkan @rrousselGit (#51752)

Dalam hal ini saya sarankan untuk berpartisipasi dalam diskusi itu; masalah khusus ini ditutup tetapi yang itu terbuka. Ada beberapa deskripsi proposal dalam masalah itu, meskipun tampaknya tidak ada yang melakukan pekerjaan dengan baik. Belum ada deskripsi yang sangat jelas tentang "kait" di sana, hanya disebutkan secara sepintas.

Saya masih tidak mengerti mengapa kita diharapkan untuk menjelaskan masalah ketika masalah dan solusi yang diusulkan didokumentasikan dengan sangat jelas oleh React dan Vue.

RFC of hooks berisi sekitar 1400 komentar, video perkenalan, dokumentasi, dan artikel dari banyak orang pintar.

Kita bisa tidak setuju pada solusi untuk masalah ini. Tapi seharusnya tidak perlu menjelaskan masalahnya

Masalahnya dijelaskan di #51752, bukan? Bukankah itu masalahnya?

(Tentang alasannya: Karena mengarahkan tim pengembangan ke RFC 1400-komentar untuk produk yang berbeda bukanlah cara yang efektif untuk berkomunikasi dengan tim pengembangan itu. Maaf jika saya merasa bodoh.)

Maaf untuk melakukan ping ke megathread. Hanya ingin mengatakan kepada siapa saja yang telah mengikuti yang ini bahwa saya telah meninggalkan beberapa pemikiran lagi dari perspektif Bereaksi di https://github.com/flutter/flutter/issues/51752#issuecomment -665380355 dan dengan senang hati akan menjawab lebih banyak pertanyaan jika itu akan berguna.

Saya juga ingin mengungkapkan harapan bahwa ini (dan utas terkait) dapat tetap sopan dan tidak menekan pengelola dengan argumen seperti "berfungsi untuk Bereaksi". React dan Flutter memiliki perbedaan yang signifikan dalam model pemrograman, dan React Hooks secara khusus sangat bergantung pada beberapa nuansa kita. Mereka juga memiliki beberapa kebiasaan yang mungkin tidak diterima banyak orang.

Saya telah mengubah pendapat saya tentang hook. Saya pikir mereka adalah pola yang fantastis, tetapi saya baru saja menyelesaikan kontrak React Native dan kait (menurut saya) telah memecah sistem pengembangan secara mengerikan untuk keuntungan yang sangat kecil. Flutter saat ini menggunakan pola yang sangat mirip dengan komponen kelas React dan ada banyak perkakas yang dibangun di sekitarnya. Jika kerangka kerja beralih ke kait sebagai solusi manajemen status utama, itu akan mematahkan semua pekerjaan dan pola mental yang ada yang digunakan pengembang Flutter untuk keuntungan yang sangat kecil.

Saya pikir ada argumen bahwa kait adalah pola unggul untuk pengembangan produktif, tetapi saya pikir ada argumen yang lebih menarik (seperti argumen inti dartfmt) bahwa konsistensi dari waktu ke waktu lebih baik daripada "lebih baik."

Saya juga harus mencatat bahwa ketika berhadapan dengan pengembang Bereaksi baru, kami sering mengalami hambatan dengan kait yang menciptakan hasil yang tidak terduga dan harus mengajari mereka untuk menggunakan komponen kelas terlebih dahulu. (Perbandingan yang baik adalah fenomena bahwa pengembang baru lebih mudah menggunakan for loop dibandingkan dengan metode pengumpulan seperti map/reduce/filter/fold). Kait adalah pola tingkat lanjut dan terkadang kita menganggapnya biasa saja. Hal yang membuat frustrasi di sini adalah bahwa komunitas React dengan cepat menghapus dokumentasi & dukungan untuk pola komponen kelas sehingga lebih sulit untuk menawarkan pendidikan atau opsi ini untuk pengembang baru.

Saya telah menyebutkan di edisi lain #51752 bahwa mungkin kita harus bekerja untuk membuat versi hook yang lebih spesifik Flutter, karena hook itu sendiri tampaknya memiliki beberapa kelemahan seperti pola useEffect(() => ..., [] ) untuk rendering sekali saja. @Hixie membuat versi yang menarik dengan pola Property dan PropertyManager yang tampaknya melakukan sesuatu yang mirip dengan kait tetapi mungkin tidak memiliki kekurangan ini. Kita harus melihat lebih banyak alternatif untuk hook karena, setidaknya untuk Flutter, rasanya ada sesuatu yang bekerja lebih baik daripada hook gaya React tetapi masih memecahkan masalah yang sama.