Maui: MVU mungkin tidak seperti yang Anda pikirkan

Terima kasih @aspnetde , saya harap Anda akan bergabung dengan kami saat kami berupaya menerapkan ide ini selama kurang lebih 18 bulan ke depan. Mengingat sejarah Anda dengan MVU, saya berharap Anda akan memiliki banyak kontribusi.

Saya pikir terlalu dini untuk mengatakan bahwa .NET MAUI adalah atau bukan MVU karena kami belum benar-benar membuatnya . :)

Ya, kami memiliki prototipe. Ya, itu terinspirasi oleh eksperimen Comet. Dan ya, kami tahu bahwa ada kekhawatiran bahwa apa yang kami tunjukkan sejauh ini tidak sesuai dengan definisi MVU semua orang.

Harapan saya, kita bisa berkolaborasi! Jika apa yang akhirnya kita rancang dan kirim layak mendapatkan label yang berbeda, saya setuju kita harus memberikannya.

Bagaimana Anda berharap melihat C# MVU di .NET MAUI?

Fitur bahasa baru apa yang menurut Anda diperlukan, jika ada?

Bisakah/haruskah kita mempertimbangkan untuk mengintegrasikan Fabulous dan/atau pola apa yang masuk akal untuk membuat kesamaan antara C# dan F#, dan apa yang seharusnya berbeda?

Bagaimana Anda berharap melihat C# MVU di .NET MAUI?

Pernahkah Anda mendengar seseorang mengatakan C# MVC atau C# MVVM? _Model-View-Update_ alias _The Elm Architecture_ adalah pola arsitektur yang terdefinisi dengan baik, bukan implementasi yang bergantung pada bahasa.

Fitur bahasa baru apa yang menurut Anda diperlukan, jika ada?

• Sementara tipe serikat pekerja akan membantu menyederhanakan definisi pesan secara besar-besaran, itu dapat dilakukan melalui antarmuka/kelas abstrak dan sub-kelas per pesan, meskipun itu memerlukan sedikit lebih banyak kode boilerplate untuk ditulis.
• Untuk memproses pesan, pencocokan pola sangat membantu jika tidak diperlukan. Saya pikir keadaan ekspresi sakelar C# saat ini sudah cukup baik untuk itu, karena bentuk pesannya akan sederhana.
• Last but not least, fitur terpenting yang saya lihat adalah kekekalan secara default dan memungkinkan perbandingan kesetaraan struktural. Sejauh yang saya ingat proposal catatan saat ini di C # 9 (alias kelas data), itu akan memberikan hal itu.

Jadi C# 9 akan, sementara masih lebih berisik daripada F#, baik untuk pergi dari sudut pandang saya saat ini.

Bisakah/haruskah kita mempertimbangkan untuk mengintegrasikan Fabulous dan/atau pola apa yang masuk akal untuk membuat kesamaan antara C# dan F#, dan apa yang seharusnya berbeda?

Seperti yang ditulis di atas, seharusnya tidak ada sesuatu yang khusus bahasa dalam pendekatan keseluruhan karena MVU itu sendiri hanyalah gaya arsitektur atau model aplikasi seperti yang Anda sebut.

@TimLariviere Telah membuat beberapa proposal untuk memajukan Fabulous baru-baru ini, yang juga mencakup gagasan seputar DSL yang lebih mirip SwiftUI. Anda mungkin ingin melihat dan/atau terlibat di sana juga.

Omong-omong: Saya telah membuat perbandingan 1:1 dari XF + C# + MVVM dan XF + F# + MVU tahun lalu, hasilnya dapat ditemukan di sini – termasuk kode sumber.

Saya pikir terlalu dini untuk mengatakan bahwa .NET MAUI adalah atau bukan MVU

Ini bukan tentang apakah MAUI akan menjadi MVU pada akhirnya. Ini tentang contoh di blog pengumuman yang sudah menimbulkan banyak kebingungan di masyarakat. Pada dasarnya saya harus berasumsi bahwa penulis belum benar-benar melihat ke MVU. Berbicara tentang "C# MVU" tidak membuat ini lebih baik.

Saya setuju dengan @aspnetde dan @forki masalahnya di sini terletak pada komunikasi.

Saya pikir tidak ada dari kita yang berdebat untuk menjatuhkan atau mengubah C# DSL yang terinspirasi komet untuk MAUI/XF, tetapi bahkan jika kita mengambil apa yang sejauh ini dilakukan dengannya, ini masih menggunakan konsep pengikatan yang digarisbawahi yang merupakan bagian dari pola MVVM .

Ini adalah sesuatu yang telah saya tanyakan berulang kali dalam komunikasi langsung dan juga dalam masalah, mungkin ini adalah pemikiran yang baik bagi semua orang yang terlibat untuk membaca pola yang berbeda seperti MVVM dan MVU.

Meskipun demikian, bahkan ada cara untuk menerapkan MVU di atas MVVM, tetapi pertanyaannya tetap masalah apa yang akan dipecahkannya.

Pernahkah Anda mendengar seseorang mengatakan C# MVC atau C# MVVM?

Ya, saya mengerti itu aneh untuk mengatakan C# atau XAML diikuti oleh pola arsitektur seperti MVVM atau MVU. Di antara komunitas pengembang yang lebih luas yang saya ajak bicara, ada kebutuhan untuk memperjelas bahwa Anda dapat menggunakan sejumlah kombinasi dalam proyek Anda. Tujuannya bukan untuk mengatakan bahwa "C# MVVM" secara arsitektur berbeda dari "XAML MVVM", tetapi kombinasi itu dimungkinkan dan pengalaman pengembang secara keseluruhan sedikit berbeda.

Saya pikir utas ini mungkin membahas bagaimana tampilan MVU di .NET MAUI, tetapi mungkin diskusi yang lebih produktif di sini adalah bagaimana kita berbicara tentang berbagai pengalaman pengembang dan pola arsitektur dalam satu produk?

Sepertinya itulah arah sebagian besar komentar di sini, ingin membahas apa yang kami sebut dan labeli sesuatu dan bagaimana kami menggunakan istilah. Saya akan sangat menyukai masukan Anda tentang ini, karena saya melakukan banyak komunikasi dan ingin memastikan bahwa saya memang menambahkan kejelasan dan tidak menimbulkan kebingungan.

Ini tentang contoh di blog pengumuman yang sudah menimbulkan banyak kebingungan di masyarakat.

Itu adalah kontribusi saya ke blog dan saya minta maaf atas kebingungan yang dibuatnya untuk Anda. Saya salah menghitung bahwa dengan menambahkan tautan ke blog Elm dan @aspnetde , kami mengatakan "inilah MVU", dan saya tidak mengantisipasi berapa banyak bobot yang akan ditanggung oleh cuplikan kode bagi Anda yang memiliki pengalaman dan harapan MVU seperti apa yang akan/seharusnya terlihat di sini.

Pada dasarnya saya harus berasumsi bahwa penulis belum benar-benar melihat ke MVU.

Kami telah melakukan percakapan dan debat yang ekstensif tentang topik ini. Tolong jangan berasumsi, dan saya akan mencoba untuk tidak juga.

pertanyaannya tetap masalah apa yang akan dipecahkannya.

@dersia masalah umum yang harus dipecahkan adalah memberikan pilihan kepada pengembang. Jika Anda bertanya apa yang dipecahkan MVU di atas MVVM, saya tidak tahu - ini bukan sesuatu yang diminta atau sesuatu yang kami coba lakukan.

Pemfaktoran ulang seperti yang diusulkan di #28 dan #66 sebagian adalah tentang memisahkan pengikatan data dan hal-hal spesifik MVVM dari implementasi penyaji sehingga jika Anda memilih MVU, Anda tidak akan menggunakan fitur tambahan yang digunakan di MVVM.

Saya tidak mengantisipasi berapa banyak bobot yang akan ditanggung oleh cuplikan kode

Tapi itu dagingnya, kan? Dan maaf itu tidak sesuai dengan labelnya.

@davidortinau

Sepertinya itulah arah sebagian besar komentar di sini, ingin membahas apa yang kami sebut dan labeli sesuatu dan bagaimana kami menggunakan istilah. Saya akan sangat menyukai masukan Anda tentang ini, karena saya melakukan banyak komunikasi dan ingin memastikan bahwa saya memang menambahkan kejelasan dan tidak menimbulkan kebingungan.

Saya tidak yakin apa yang tersisa untuk ditambahkan dari pihak saya. Saya pikir saya menyatakan posisi saya dengan lantang dan jelas :-). Jika Anda akan menerapkan MVU, Anda akan mendorong pintu yang terbuka. Jika itu yang dapat diasumsikan dengan melihat cuplikan di pos pengumuman dan repositori Comet, jangan ragu untuk melakukannya – tetapi _please_ berhenti menyebutnya MVU.

Terima kasih.

Seperti yang disebutkan Don di utas ini :-) - CC: @dsyme

Saya tidak mengerti mengapa ini disebut MVU, padahal tidak. Ini mungkin paradigma yang hebat dan bekerja dengan sangat baik di sini - mengapa tidak menemukan istilah yang cocok yang sesuai dengan paradigma dan tidak membingungkan?

@aspnetde apa yang tersisa dari sisi Anda? Banyak saya kira :).
Saya membaca beberapa bagian dari tesis Anda. Saya harus mengatakan bahwa saya menyukainya. Saya juga membaca buku dari Don Syme tentang F#. Saya suka pemrograman fungsional. Dari pengalaman saya ringkas, tetapi sulit untuk dipahami (dipahami). Keterbacaan adalah bagian yang sangat penting dari siklus hidup pengembangan. Banyak waktu sebenarnya dihabiskan untuk membaca kode. Dan rekursi hanya ditulis. Anda dapat menulisnya sekali, tetapi hampir tidak ada yang bisa membacanya (mirip dengan regexp).
Di masa lalu saya mencoba Redux dengan Angular selama waktu pembuatan prototipe/penelitian saya di perusahaan. Apakah ini pendekatan setengah Elmish? Itu adalah pengalaman yang berharga. Saya belajar bahwa saya harus berhati-hati untuk tidak mengubah keadaan, dan sebagai hasilnya saya tidak perlu mengingat seluruh tumpukan, di mana tepatnya keadaan bisa tiba-tiba berubah.
Saya mengerti manfaat dari kekekalan, tapi saya melihat presentasi dengan Erik Meijer yang tiba-tiba merobek kepala boneka beruang, untuk menunjukkan kepada kita, bahwa dunia nyata bisa berubah.

Jadi yang ingin saya tunjukkan: Bukankah pemikiran alami kita bertentangan dengan paradigma ini? Apa pengalaman Anda?

Saya memiliki banyak pengalaman dengan XAML/C#/MVVM, jadi saya bertanya-tanya mengapa Don Syme menganggap XAML tidak perlu.
Dari pengalaman saya, ini membantu untuk memisahkan masalah (UI, presentasi, bisnis, dll. logika). Saya tidak begitu yakin apakah DSL (markup C#) dan MVU ini membantu meningkatkan kualitas kode dalam jangka panjang. Pengembang yang tidak berpengalaman/tidak peduli akan mencampuradukkan tanggung jawab. Saya juga membutuhkan lebih banyak pengalaman dengan pola MVU, untuk memahaminya dengan benar, tetapi Anda mencoba kedua paradigma ini dan itu sangat berharga bagi seluruh komunitas.
Silakan bagikan sebanyak yang Anda bisa. Terima kasih @aspnetde!

Terima kasih banyak atas pengertian Anda

@davidortinau mungkin ada kesalahpahaman di sini, saya sepenuhnya memilih dan menyerahkan kepada semua orang untuk memilih sendiri pola/paradigma apa yang akan digunakan. Saya hanya mencoba mengatakan, bahwa kita harus menyebutkan nama dengan benar. Karena semua orang dalam pengembangan perangkat lunak tahu bahwa menamai sesuatu adalah salah satu hal tersulit untuk dilakukan, tetapi jika sudah ada hal-hal yang terdefinisi dengan baik, kita tidak boleh mulai menggunakan kembali nama-nama itu untuk hal-hal yang bukan.

Nona komunikasi Miskomunikasi adalah salah satu masalah terbesar dalam dunia kita sekarang, saya pikir sebagai sebuah komunitas, sebagai kontributor untuk sebuah proyek, sebagai proyek terkemuka kita harus membantu semua orang dalam hal-hal pemahaman dan juga harus terbuka untuk kritik dan mengakui kesalahan dan bersama-sama untuk memperbaiki itu.
Dalam hal ini saya pikir menggunakan kata-kata yang salah perlu diperbaiki dan agar itu terjadi, saya ingin proyek ini
a) pahami bahwa MVU adalah nama yang salah untuk apa yang kita bicarakan di sini
dan b) untuk menemukan istilah yang tepat untuk menggambarkan apa yang kami coba bangun di sini
dan kemudian c) perbarui semua orang dan mulai gunakan nama baru itu

Saya pikir kita masih pada titik kita masih bisa kembali dan memperbaikinya. Mari kita lakukan dengan benar, hal terburuk yang bisa terjadi adalah komunitas XF/Maui memahami MVU sebagai sesuatu yang lain daripada bagian dunia lainnya.

Meskipun demikian, saya adalah penggemar berat MVU dan saya juga menyukai MVVM, dan saya pikir pendekatan MVVM yang lancar (saya belum memiliki nama yang lebih baik) seperti di Comet dan apa yang telah disajikan sejauh ini sangat bagus dan membantu banyak pengembang dan saya akan mendukungnya, saya hanya berpikir kita harus memperbaiki penamaannya.

Sunting: miss communication keluar dari kontes.

Saya mengerti manfaat dari kekekalan, tapi saya melihat presentasi dengan Erik Meijer yang tiba-tiba merobek kepala boneka beruang, untuk menunjukkan kepada kita, bahwa dunia nyata bisa berubah.

@tomasfabian ini salah.

Anda harus mulai melihat dunia sebagai rangkaian peristiwa, itulah yang sebenarnya (tidak, saya tidak ingin memulai diskusi sumber acara di sini).
Apa yang terjadi pada boneka beruang itu hanyalah peristiwa baru yang ditambahkan ke statusnya, peristiwa dalam hal ini adalah "robek kepala". Dan seperti yang dapat Anda sadari setelah suatu peristiwa terjadi, Anda tidak dapat mengembalikannya, karena Anda tidak dapat membatalkan atau menghapus apa yang terjadi begitu saja. Untuk mengembalikan kepala ke teddy, Anda memerlukan acara baru yang disebut "menjahit kepala kembali ke tubuh". 😉.

Membahas manfaat atau tidak dari FP dan MVU adalah IMHO di luar topik di sini. Masalah ini, saya pikir, hanya tentang potensi miskomunikasi dan penamaan yang akurat.

@isaacabraham mungkin Anda benar, dan saya minta maaf untuk itu. Aku yang salah. Saya tahu bahwa menamai sesuatu itu penting, tetapi di sisi lain judul masalahnya adalah "MVU mungkin tidak seperti yang Anda pikirkan". Jadi mudah-mudahan topiknya sedikit lebih luas daripada menamai sesuatu.
Terima kasih, Tomas

@tomasfabian Saya akan sangat senang mengobrol dengan Anda tentang pro dan kontra dari MVU, FP atau apa pun, nyata atau imajiner 😊 Jangan berpikir bahwa ini adalah forum yang tepat untuk itu.

@davidortinau
Sejauh fitur bahasa dan perubahan arsitektur apa yang akan membantu, semoga saya dapat berkontribusi dengan beberapa saran:

* Kata kunci new dan gangguan sintaksis lainnya.
Tidak seperti Dart atau Kotlin, C# mungkin terjebak dengan kata kunci new selamanya, karena menjadikannya opsional adalah perubahan yang melanggar dan proposal yang tidak populer bahkan sebagai direktif keikutsertaan per file. Jadi sebagai pengganti itu, mungkin kelas statis resmi (dan dipertahankan) (atau kelas statis per ruang nama tampilan MAUI) yang berisi metode statis yang hanya membungkus konstruktor dan menginisialisasi properti init-only, jika ada, setidaknya untuk set inti dari MAUI melihat objek. Kemudian kita dapat meletakkan direktif using static di bagian atas file .cs kode tampilan kita dan kemudian memanggil metode tanpa gangguan sintaks new . Ini akan sedikit mengurangi kekacauan dan kebisingan fungsi tampilan C#. Tentu saja pembungkus konstruktor metode statis ini dapat dibuat secara otomatis oleh komunitas (saya telah melakukan sesuatu yang serupa untuk Xamarin.Forms untuk digunakan dengan CSharpForMarkup), tetapi akan menyenangkan untuk memiliki set di dalam kotak yang dikelola oleh proyek MAUI.

Selain itu, setiap proposal bahasa C# yang akan membantu mengurangi kekacauan sintaksis atau kebisingan di pohon ekspresi besar (seperti yang umum dalam fungsi tampilan MVU/Comet/CSharpForMarkup) akan sangat membantu. C#9 telah melangkah jauh dalam hal ini untuk meningkatkan bagian M dan U dari MVU tetapi bagian V masih merupakan sintaks titik nyeri yang bijaksana.

* Properti ekstensi *
Saya tahu proposal "ekstensi-semuanya" sedang ditunda untuk saat ini, tetapi satu hal yang dapat membantu untuk markup MVVM-dengan-C# (mis. CSharpForMarkup dengan Xamarin.Forms), adalah properti ekstensi. Dengan CSharpForMarkup, setiap helper harus diimplementasikan menggunakan metode ekstensi, tetapi dalam beberapa kasus properti ekstensi (yang dapat digunakan dalam penginisialisasi objek), akan terlihat jauh lebih baik:

// Instead of this:
public View Body() =>
    new Widget() {
        BuiltInProperty = "initial value",
    }.SetExtensionProperty("initial value");

// the extension property could be included in the object initializer:
public View Body() ->
    new Widget() {
        BuiltInProperty = "initial value",
        ExtensionProperty = "initial value",
    };

Ini hanya benar-benar berlaku untuk pohon objek tampilan yang bisa berubah, seperti pada MVVM dengan C# untuk markup. Untuk MVU atau arsitektur UI fungsional lainnya, ini tidak berlaku karena objek tampilan tidak dapat diubah. Dalam kasus tersebut, metode penyuluhan yang lancar masih lebih tepat.

* Kurangi pendapat (atau tingkat rendah jika Anda mau) tentang manajemen negara *
Saya pikir salah satu hambatan terbesar untuk masuk untuk mengimplementasikan MVU di atas Xamarin.Forms adalah kurangnya dua komponen penting: grafik objek ringan yang dapat dikembalikan oleh fungsi tampilan, yang dapat "dirender" oleh kerangka kerja menjadi komponen aktual (dengan representasi khusus platform, dll...). Dan bagian kedua adalah mesin diffing yang secara efisien memperbarui tampilan spesifik platform kelas berat dengan mencari perbedaan antara satu nilai balik dari fungsi tampilan dan lainnya, termasuk cara melakukan diff secara efisien dengan melakukan diff parsial, dll...

Sepertinya MAUI sekarang menyediakan dua bagian penting itu, yang sangat bagus! Namun, tampaknya setidaknya pada tingkat permukaan terikat sangat erat dengan cara mengelola keadaan yang menurut pendapat beberapa komunitas MVU akan mengatakan lebih dekat ke MVVM daripada MVU atau arsitektur UI "fungsional" serupa. Saya pikir preferensi saya adalah mempertahankan dua bagian penting yang saya sebutkan di atas (grafik objek tampilan ringan dan mesin pembeda yang efisien), dan menggabungkannya dengan sistem komponen tingkat yang lebih rendah yang dapat dilapiskan secara efisien oleh MVU atau Comet, per pilihan. Mungkin itu sudah menjadi tujuannya, dan saya tidak melihatnya? Jika demikian, saya ingin melihat lebih banyak diskusi tentang itu dengan setidaknya beberapa contoh dasar.

@aspnetde mengapa Anda menghapus posting Anda?

@tomasfabian

Dari pengalaman saya, [MVVM] membantu memisahkan masalah (UI, presentasi, bisnis, dll. logika)

Ya, memang. Saya telah membuat beberapa pengalaman bagus dengan aplikasi Xamarin.iOS dan Xamarin.Android besar yang dibuat dengan MvvmCross. Meskipun saya lebih suka perpustakaan daripada kerangka kerja hari ini, saya pikir semua proyek itu (beberapa dengan LOC enam angka) telah sukses, secara teknis maupun dari perspektif bisnis.

Saya pikir MVVM secara khusus melakukan pekerjaan dengan baik dalam hal menskalakan aplikasi. Terutama di seluler, di mana kami dipaksa untuk mengirimkan monolit, ini membantu kami untuk memfaktorkan ulang aplikasi kami menjadi modul independen setelah mereka melewati ukuran tertentu.

Bukankah pemikiran alami kita bertentangan dengan paradigma ini ([MVU])? Apa pengalaman Anda?

Saya tidak berpikir begitu. Ambil pengalaman Anda dengan Redux untuk penyimpanan dan bayangkan seluruh aplikasi Anda mendapat manfaat dari kelebihannya. Meskipun tampaknya lebih kompleks dari pandangan pertama, menurut pengalaman saya, ini jauh lebih sederhana untuk dipahami dan digunakan. Seperti yang sering ditunjukkan oleh

Saya tidak begitu yakin apakah DSL (markup C#) dan MVU ini membantu meningkatkan kualitas kode dalam jangka panjang.

Meskipun MVU dan MVVM memiliki kelebihan yang berbeda, keduanya juga memiliki kekurangan yang berbeda.

Meskipun mempertimbangkan proyek MVVM kami berhasil, tim saya dan saya kehilangan rambut karena men-debug mereka. Dalam satu proyek khususnya, kami mulai mengalami kerumitan yang disebabkan oleh kurangnya pengalaman dari anggota tim baru, dan kesalahpahaman – seperti yang telah Anda tunjukkan. Saya pikir itu lebih kecil kemungkinannya di MVU ketika diterapkan secara ketat, karena ini mendefinisikan batas-batas bagaimana segala sesuatunya bekerja dengan sangat sempit, sehingga hampir lebih sulit untuk keluar dari itu dan membangun sesuatu dengan cara yang salah, daripada sebaliknya.

Untuk MVU saya melihat dua masalah utama. Pertama: Penskalaan. Banyak yang menganjurkan untuk satu program. Saya skeptis di sini (dan berpikir banyak program/modul akan menjadi cara yang lebih baik). Kedua: Saat ini, sesuatu seperti Fabulous berada di atas Xamarin.Forms. Jadi ini adalah lapisan abstraksi di atas lapisan abstraksi di atas lapisan abstraksi di atas iOS/Android. Itu kompleksitas yang sangat besar. Jadi Anda tidak hanya berurusan dengan bug yang belum terpecahkan yang tidak dipedulikan siapa pun, tetapi juga pekerjaan yang kurang lebih membosankan dan tidak menyenangkan untuk memperbarui satu lapisan abstraksi (Hebat) ketika yang lain (Xamarin.Forms) berubah.

Di situlah saya akan melihat peluang besar bagi MAUI. Sejujurnya saya akan senang melihat pengelola Fabulous bergabung dengan Microsoft di sini. Dan saya sangat berharap bahwa Microsoft tidak akan merusaknya, seperti yang telah dilakukan oleh bagian lain dari organisasi di masa lalu.

Thomas

Ketika saya membaca pengumuman resmi tempo hari, saya terkejut dengan apa yang disajikan di sana sebagai MVU:

readonly State<int> count = 0;

[Body]
View body() => new StackLayout
{
    new Label("Welcome to .NET MAUI!"),
    new Button(
        () => $"You clicked {count} times.",
        () => count.Value ++)
    )
};

Sejauh yang saya ketahui, ini bukan MVU . Saya sudah menuliskan beberapa pemikiran tentang mengapa saya berpikir begitu di sini .

Don Syme, yang, seperti yang saya pahami, menghabiskan beberapa bulan di tahun 2018 untuk mengimplementasikan MVU di atas Xamarin.Form dan membangun apa yang kemudian menjadi Fabulous , sedikit lebih diplomatis , tetapi intinya sama.

Jadi, apa maksud saya?

• Saya ingin Anda menerapkan pola arsitektur yang sebenarnya, tidak peduli apakah dalam C# atau F#. Menjangkau orang-orang di belakang Fabulous bisa menjadi awal di sini.
• Jika Anda tidak tertarik dengan hal itu tetapi memiliki visi yang jelas untuk membangun di atas apa yang tersedia saat ini sebagai perpustakaan Comet , maka pertimbangkan untuk menggunakan nama yang lebih tepat untuk "model aplikasi" itu. Ciptakan sesuatu yang baru. Beri nama MSMVU. Apa pun. Tapi jangan menjual apel untuk jeruk.

Bersulang!

Mengapa mereka menamakannya MSMVU? Komet telah menjadi MVU, dan akan tetap demikian. Dan Maui adalah MVU.

Saya pikir terlalu dini untuk mengatakan bahwa .NET MAUI adalah atau bukan MVU

Ini bukan tentang apakah MAUI akan menjadi MVU pada akhirnya. Ini tentang contoh di blog pengumuman yang sudah menimbulkan banyak kebingungan di masyarakat. Pada dasarnya saya harus berasumsi bahwa penulis belum benar-benar melihat ke MVU. Berbicara tentang "C# MVU" tidak membuat ini lebih baik.

Itu tidak menyebabkan kebingungan apa pun. Hanya saja beberapa orang tidak tahan melihat C# melakukan MVU.

Untuk apa nilainya, SwiftUI (dari mana Comet mengambil sebagian besar inspirasinya) cenderung menyebut polanya MVVM, meskipun tidak ada pedoman eksplisit.
Saya belum menemukan penyebutan MVU.

@TimLariviere https://github.com/Clancey/Comet#key -concepts
Pada dasarnya Comet menyebutnya MVU dan sudah kehilangan inti dari loop pesan yang kita miliki dalam definisi MVU yang lebih lama

Untuk apa nilainya, SwiftUI (dari mana Comet mengambil sebagian besar inspirasinya) cenderung menyebut polanya MVVM, meskipun tidak ada pedoman eksplisit.

Bahkan tidak salah, melihat contoh di awal posting ini di sini: https://nalexn.github.io/clean-architecture-swiftui/

Saya belum menemukan penyebutan MVU.

Posting yang sama juga membahasnya secara singkat (sebagai kombinasi dari SwiftUI + Redux = TEA). Meskipun kemudian berubah menjadi "Arsitektur Bersih"

Karena saya telah disebutkan di sini, saya hanya akan mengatakan beberapa hal.

• Menurut saya MAUI itu hebat dan menurut saya belajar tentang MVU sebagai arsitektur dapat bermanfaat bagi orang-orang untuk memahami MAUI.

• Sangat mudah untuk terpaku pada kata-kata, dan kita semua mungkin harus mengambil nafas dan mencoba untuk tidak khawatir tentang hal itu pada tahap ini, karena ada banyak waktu untuk menyesuaikan kata-kata yang digunakan dan saya pikir pesan tentang terminologi yang akurat telah mendengar. Secara pribadi saya pikir Elm telah menetapkan bahwa penggunaan "MVU" tanpa hiasan dan tanpa pengecualian berarti pesan eksplisit, pembaruan eksplisit, model fungsional, perhitungan ulang tampilan fungsional, dan pembaruan diferensial. Tetapi ada banyak variasi MVU dan MAUI adalah satu titik dalam spektrum itu (yang mencakup semua jalan ke MVVM sebagai semacam sistem pemrosesan pesan yang ditambahkan secara manual dengan keadaan yang dapat diubah secara implisit dan meresap). Komunikasi SwiftUI menarik dari perspektif ini.

• Saya melihat orang-orang cenderung memiliki keyakinan dan pendapat yang sangat kuat di bidang ini dan dapat mengambil hal-hal secara pribadi. Saya tahu seperti apa itu, dan seperti desain bahasa pemrograman, saya pikir semua poin di ruang memiliki pro dan kontra. Saya mendorong semua orang untuk mencoba, menggunakan, belajar, berbagi, dan bekerja sama untuk membuat berbagai teknologi sebaik mungkin.

@dsyme
Saya pikir istilah yang tepat untuk arsitektur Comet/MAUI adalah variasi aliran data searah (atau UDF), tetapi bukan MVU karena MVU itu sendiri merupakan variasi UDF yang sangat spesifik. MAUI/Comet tentu memenuhi syarat sebagai kerangka kerja UDF (seperti halnya SwiftUI), tetapi tidak memenuhi syarat sebagai kerangka kerja MVU. Ada beberapa variasi UDF termasuk MVU, Flux, Redux, React, dll... tapi itu adalah miskomunikasi untuk memanggil Comet MVU padahal itu sama sekali bukan MVU.

Tidak seperti MVU, Model dapat berubah, dan dimutasi oleh kode dalam fungsi Tampilan. Mutasi kemudian diamati, dan pandangan bereaksi terhadap mutasi tersebut dengan rendering ulang. Itu masih searah karena tampilan tidak bermutasi, tetapi tidak ada fungsi pembaruan, tidak ada pesan, dan tidak ada pengiriman pesan - dengan demikian, bukan MVU. Ini lebih dekat ke variasi searah dari MVVM.

@JeroMiya Terima kasih, apakah Anda memiliki referensi untuk terminologi itu?

@dsyme Saya tidak memiliki referensi khusus untuk itu, tetapi saya pertama kali mulai mendengar istilah yang digunakan pada hari-hari awal React, khususnya mengacu pada React itu sendiri dan beberapa pola awal yang muncul seperti Redux dan Flux. Saya ingat sebuah artikel yang menjelaskan sejumlah varian UDF (kebanyakan di ruang React), tetapi saya tidak dapat menemukannya sekarang.

Dikatakan bahwa itu bukan arsitektur formal - lebih seperti konsep dasar tampilan sebagai fungsi model, sebagai lawan tampilan menjadi pohon objek stateful yang bermutasi sebagai respons terhadap peristiwa. Konsep UDF tidak selalu menentukan bagaimana model diperbarui atau apakah itu dapat diubah atau tidak dapat diubah. MVU memperluas konsep UDF tidak hanya ke tampilan itu sendiri tetapi juga proses memperbarui model. Jadi di MVU modelnya juga tidak berubah, dan perubahan status UI direpresentasikan sebagai perintah yang menghasilkan model baru, yang memicu tampilan baru.

Ini tentu saja bukan konsep baru - bahkan sebelum React sebagian besar kerangka kerja web sisi server seperti Asp.Net MVC, Rails, bahkan PHP secara teknis dianggap searah. Itu tidak umum untuk kerangka SPA arus utama dan kerangka kerja UI sisi klien sebelum React datang.

@dsyme Saya tidak memiliki referensi khusus untuk itu, tetapi saya pertama kali mulai mendengar istilah yang digunakan pada hari-hari awal React, khususnya mengacu pada React itu sendiri dan beberapa pola awal yang muncul seperti Redux dan Flux. Saya ingat sebuah artikel yang menjelaskan sejumlah varian UDF (kebanyakan di ruang React), tetapi saya tidak dapat menemukannya sekarang.

Dikatakan bahwa itu bukan arsitektur formal - lebih seperti konsep dasar tampilan sebagai fungsi model, sebagai lawan tampilan menjadi pohon objek stateful yang bermutasi sebagai respons terhadap peristiwa. Konsep UDF tidak selalu menentukan bagaimana model diperbarui atau apakah itu dapat diubah atau tidak dapat diubah. MVU memperluas konsep UDF tidak hanya ke tampilan itu sendiri tetapi juga proses memperbarui model. Jadi di MVU modelnya juga tidak berubah, dan perubahan status UI direpresentasikan sebagai perintah yang menghasilkan model baru, yang memicu tampilan baru.

Ini tentu saja bukan konsep baru - bahkan sebelum React sebagian besar kerangka kerja web sisi server seperti Asp.Net MVC, Rails, bahkan PHP secara teknis dianggap searah. Itu tidak umum untuk kerangka SPA arus utama dan kerangka kerja UI sisi klien sebelum React datang.

@JeroMiya terima kasih untuk ini, ini persis bagaimana saya memahami MVU.
Saya bahkan akan mengatakan bahwa salah satu aplikasi tertua dan masih banyak digunakan yang menggunakan dan mencontohkan MVU dalam Bentuk terbaiknya adalah MS Excel.

@dsyme membaca komentar Anda, saya merasa bahwa Anda merujuk ke MAUI sebagai istilah untuk arsitektur yang dibahas (CSharpForMarkup dengan MVVM).
Tolong jelaskan kepada saya bahwa ini bukan seperti yang Anda pahami atau jika memang demikian.
Dari pemahaman saya, MAUI hanyalah Kerangka Aplikasi MS berikutnya untuk menggantikan XF di masa mendatang.

Saya sangat suka cara masalah ini dan komentarnya berjalan. Terima kasih untuk semua orang yang berpartisipasi. Mungkin bersama-sama kita bisa mendapatkan semua arsitektur yang berbeda sebanyak mungkin rasa untuk MAUI yang ditetapkan dan diberi nama dengan benar.

@dersia Terima kasih! Sekedar catatan dari pengalaman saya sendiri dengan CSharpForMarkup: levelnya sedikit lebih rendah daripada MVVM - lebih banyak metode dan utilitas ekstensi untuk membuat markup C# lebih ramping dan terlihat lebih bagus. Anda tentu dapat mengimplementasikan pola MVVM dengannya karena memiliki pembantu untuk membuat binding ViewModel lebih mudah, tetapi yang akhirnya saya lakukan adalah mengimplementasikan semua logika tampilan saya di Redux alih-alih ViewModels. Hanya perlu menambahkan beberapa metode ekstensi untuk mengikat properti tampilan ke pemilih status, yang hanya Func<StateType, ChildStateType> Saya meneruskan ke operator Select dan DistinctUntilChanged di toko negara Redux, yaitu sebuah Observable<StateType> . Aliran data tidak cukup searah tetapi saya tidak memiliki cara yang matang untuk melakukan perbedaan pohon objek UI dan melihat fungsi seperti yang dilakukan Fabulous sekarang.

Beberapa waktu yang lalu polisi REST mencoba mendorong ke tenggorokan kita bahwa kita semua tidak boleh disebut REST. Semua orang masih menyebutnya REST hari ini dan kami semua masih hidup dan sehat. 😉.

@bitbonk komunitas REST melepaskan istilah itu karena menjadi semakin tidak berguna karena semakin banyak hal yang dilemparkan ke dalam campuran. Mereka sekarang menggunakan “hypermedia” untuk merujuk pada REpresentational State Transfer. REST, hari ini, sekarang benar-benar hanya berarti “bukan SOAP” atau “JSON melalui HTTP”, keduanya tidak berhasil mengkomunikasikan ide intinya. Para komentator di sini berharap untuk menghindari nasib yang sama untuk MVU.

@davidortinau @tomasfabian , saya belum melihat contoh MVU di MAUI. Saya akan mencoba memberikan contoh malam ini. Saya baru saja melakukan sesuatu yang serupa untuk WinForms di sini . Saya berasumsi itu seharusnya tidak terlalu sulit.

@JeroMiya Terima kasih, apakah Anda memiliki referensi untuk terminologi itu?

@dsyme , saya pikir itu berasal dari React Flux, tetapi mereka menunjuk ke arsitektur game, yaitu Doom 3. Saya pikir saya ingat membahas ini dengan @TIHan ketika pertama kali disajikan.

• https://reactjs.org/blog/2014/05/06/flux.html
• https://www.infoq.com/news/2014/05/facebook-mvc-flux/
• https://facebook.github.io/flux/
• https://github.com/topics/unidirectional-data-flow

Inilah upaya saya pada contoh C #. Saya tidak memiliki MAUI yang tersedia untuk mencoba ini sebagai contoh nyata. Tidak ada pratinjau, kan? Bagaimanapun, ini adalah terjemahan kasar dari ide tersebut.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

Saya pernah mencoba sesuatu yang serupa secara singkat, kecuali untuk bagian tampilan. Dengan Catatan datang ke C# 9 ini akan menjadi lebih masuk akal.

Saya relatif baru di MVU, dan saya mungkin memiliki sedikit pengalaman menggunakannya dibandingkan dengan banyak dari Anda. Tapi konsep MVU benar-benar menarik minat saya, dan saya menikmatinya. Saya sangat senang melihat bahwa pengembang C# diberikan kerangka kerja untuk membantu mengembangkan pola MVU.

Saya sangat setuju bahwa MAUI MVU bukanlah MVU biasa dan memiliki pengaruh besar dari SwiftUI. Penulis utamanya Clancey himeslef telah membuatnya sangat jelas di hampir semua sesinya. Kita semua tahu bahwa Redux sangat dipengaruhi dari MVU, begitu juga SwiftUI, Flutter dan banyak kerangka kerja lainnya. Tak satu pun dari mereka adalah MVU murni.

Tapi saya yakin, kita semua sepakat bahwa pola arsitektur terdekat untuk semua framework ini adalah MVU. Itulah alasan mengapa orang merujuknya. Dan ingat kita berbicara tentang judul blog untuk kerangka kerja yang akan dirilis satu setengah tahun dari sekarang.

Dan jika Anda mengatakan bahwa orang-orang mulai marah karena judul blog ini. Saya tidak berpikir kita harus benar-benar khawatir tentang mereka. Masyarakat tetap harus berjalan. Mari kita habiskan energi kita untuk membuat kerangka kerja ini lebih baik. Tidak terlalu khawatir tentang detail kecil.

Tapi saya yakin, kita semua sepakat bahwa pola arsitektur terdekat untuk semua framework ini adalah MVU. Itulah alasan mengapa orang merujuknya.

Anjing, kuda, kucing, dan simpanse semuanya sangat dekat satu sama lain. Mulai sekarang saya akan menyebut mereka semua sebagai kucing.

:) Yah Anda tidak perlu. Tapi izinkan saya memberi tahu Anda sesuatu: Kucing, Harimau, macan tutul, dll disebut kucing. Dan saya senang Anda mengangkatnya. Coz itulah yang terjadi di sini.

@aspnetde : Thomas, dengan semua yang dikatakan. Saya perlu mengatakan bahwa blog MVU asli Anda adalah salah satu artikel terbaik yang menjelaskan konsep dengan sangat jelas dan tepat. Saya telah belajar sedikit dari itu. Terima kasih

@ libin85 persis ada masalah. Anda mulai menghitung hal-hal yang sebenarnya dalam satu kategori dan mengabaikan yang tidak. Dengan memasukkan sampel MAUI ke dalam kategori MVU, pada dasarnya Anda memasukkan simpanse ke dalam kategori kucing.

Ada kesamaan dengan implementasi MVU, seperti tampilan yang tidak dapat diubah. Tetapi ada perbedaan yang jelas seperti, tidak ada loop pesan dan tidak ada fungsi pembaruan eksplisit. Model dimutasi langsung di View. Ini adalah sesuatu yang secara eksplisit tidak diinginkan orang ketika mereka membuat MVU. Dalam beberapa bahasa bahkan tidak mungkin untuk melakukan itu - itulah mengapa MVU muncul. Dan mengapa itu menjadi populer. Sekarang kita harus berhati-hati jika kita menghapus properti tersebut dari definisi MVU kita.

@forki : Saya tidak menentang apa pun yang Anda katakan. Sebenarnya poin-poin yang Anda kemukakan di komentar terakhir itulah yang perlu kita diskusikan sebagai komunitas dan bukan judul pada posting blog. Itu maksudku. Itu hal yang positif untuk didiskusikan dan kerangka kerja akan mendapatkan keuntungan darinya.

Saya setuju bahwa nama adalah detail kecil yang tidak boleh mengalihkan perhatian dari aspek yang lebih penting. Namun, alasan saya mengangkatnya adalah karena saya pribadi tidak melihat MAUI sebagai upaya komunitas di mana akal sehat pada akhirnya akan mengarah pada solusi yang disepakati bersama. Ini adalah produk Microsoft di mana keputusan akhir dibuat di balik pintu tertutup. Saya di sini dalam kapasitas saya sebagai pelanggan untuk menyampaikan kekhawatiran saya.

Tapi saya yakin, kita semua sepakat bahwa pola arsitektur terdekat untuk semua framework ini adalah MVU.

@ libin85 Saya tidak setuju ini adalah pola arsitektur terdekat. MVU adalah seperangkat batasan terhadap apa yang terlihat lebih umum seperti MVP, atau Model View Presenter. MVVM serupa, mengambil arah yang berbeda karena Presenternya adalah ViewModel dengan data binding. MVP sendiri adalah bentuk MVC yang dibatasi. Saya pikir cukup aman untuk mengatakan ini semua adalah keturunan MVC dan bahkan MVP, tetapi untuk mengatakan bahwa MVU berlaku untuk SwiftUI, Flux, dll. adalah membuat MVU menjadi istilah yang tidak berarti.

Saya setuju bahwa nama adalah detail kecil yang tidak boleh mengalihkan perhatian dari aspek yang lebih penting.

Tidak, nama itu penting. Mereka sulit, baik untuk membangun dan mempertahankan maknanya. Lihat juga REST yang sudah saya bahas di atas. REST begitu disalahgunakan sehingga tidak lagi bermakna kecuali sebagai istilah jargon pemasaran. Saya ingin tidak melihat itu terjadi pada MVU, terutama ketika ada istilah yang ada untuk apa yang disediakan "MVU" MAUI.

Untuk apa nilainya, saya pikir MAUI "MVU" adalah alternatif yang bagus untuk opsi MVVM. Sama seperti dengan REST, Anda tidak perlu melakukan hal yang menentukan untuk membuat sesuatu yang berguna dan baik. Tolong jangan memperkeruh nama dengan alternatif yang jelas menyimpang dari pola yang jelas dan mapan. Bagaimanapun, MVU akan _juga_ menjadi alternatif yang bagus untuk opsi MVVM dan Comet.

Untuk apa nilainya, saya pikir MAUI "MVU" adalah alternatif yang bagus untuk opsi MVVM. Sama seperti REST, Anda tidak perlu melakukan hal yang bersifat definisi untuk membuat sesuatu yang berguna dan bagus, hanya saja jangan memperkeruh nama dengan alternatif yang jelas-jelas menyimpang dari definisinya.

AKSI PENUH.

Mengapa mereka menamakannya MSMVU? Komet telah menjadi MVU, dan akan tetap demikian. Dan Maui adalah MVU.

@ saint4eva mereka "dipasarkan", tetapi menurut definisi tidak, MVU.

Saya setuju bahwa nama adalah detail kecil yang tidak boleh mengalihkan perhatian dari aspek yang lebih penting.

Tidak, nama itu penting. Mereka sulit, baik untuk membangun dan mempertahankan maknanya. Lihat juga REST yang sudah saya bahas di atas. REST begitu disalahgunakan sehingga tidak lagi bermakna kecuali sebagai istilah jargon pemasaran. Saya ingin tidak melihat itu terjadi pada MVU, terutama ketika ada istilah yang ada untuk apa yang disediakan "MVU" MAUI.

Untuk apa nilainya, saya pikir MAUI "MVU" adalah alternatif yang bagus untuk opsi MVVM. Sama seperti dengan REST, Anda tidak perlu melakukan hal yang menentukan untuk membuat sesuatu yang berguna dan baik. Tolong jangan memperkeruh nama dengan alternatif yang jelas menyimpang dari pola yang jelas dan mapan. Bagaimanapun, MVU akan _juga_ menjadi alternatif yang bagus untuk opsi MVVM dan Comet.

Saya setuju dengan sebagian besar apa yang Anda katakan, tetapi saya pikir "Maui MVU" masih sama buruk dan membingungkannya. Saya mungkin akan menggunakan "Maui MVP" atau MVC. Keduanya berfungsi dan lebih dekat dengan apa yang disajikan dalam posting blog daripada MVU.

Sunting tambahkan:
Saya bahkan tidak yakin di mana versi yang diusulkan tinggal. Maksud saya logika dalam MVVM hidup di ViewModel, dengan MVU ia hidup dalam fungsi pembaruan dan dengan MVP ia hidup di Presenter dan dengan MVC ia hidup di Controller.

Apakah akan ada Pemandangan di mana segala sesuatu hidup? Atau apakah semuanya hidup hanya dalam beberapa kelas yang dinamai oleh Model Domain yang menyajikan tampilan, logika, dan model? Apakah model seharusnya menjadi kelas (tipe) atau catatan yang terpisah?

Saya pikir ini adalah titik sakit utama bagi saya di sini, saya tidak tahu bagaimana "disajikan" dan karenanya saya tidak dapat melihat ada pembaruan, model, dan fungsi tampilan.

Di luar kotak, menurut saya MAUI sedikit lebih rendah daripada pola yang dibahas sejauh ini - benar-benar hanya Model (atau Status) dan bagian Tampilan dari pola-pola lainnya. Sesuatu yang mungkin dapat Anda bangun untuk menerapkan pola-pola lain itu (walaupun manajemen negara agak berpendirian).

Jadi misalnya, jika T di State<T> adalah kelas seperti ViewModel, dan Anda menambahkan satu set terpisah dari kelas model data, maka yang akan Anda dapatkan adalah sesuatu seperti MVVM dengan pandangan satu arah.

Di sisi lain, jika Anda menambahkan sistem manajemen status seperti Redux dan memasukkan model status Redux sebagai T di State<T> , maka yang Anda dapatkan adalah sesuatu yang sangat dekat dengan MVU , meskipun tidak sepenuhnya terintegrasi seperti MVU tradisional seperti Elm/Fabulous. Mungkin Anda bisa menyembunyikan tampilan MAUI di balik kerangka kerja MVU, seperti yang dilakukan Fabulous dengan Xamarin.Forms?

Saya tidak yakin bagaimana Anda akan menerapkan pola MVC atau MVP melalui MAUI. Sebagai umpan pertama yang kasar, saya berpikir mungkin jika Anda membuat kelas terpisah yang memaparkan "tindakan" ke fungsi tampilan. Misalnya, Anda memiliki dialog konfirmasi MAUI, dan kelas "controller" Anda memiliki metode "ClickOK" dan metode "ClickCancel". Tampilan MAUI akan meneruskan kejadian klik dari tampilan ke pengontrol, yang akan menghasilkan model baru atau mengubah model yang ada.

@JeroMiya Saya setuju, pasti menggunakan pola Redux dapat membuatnya lebih dekat dengan MVU dan membuat arsitektur jauh lebih sedikit pendapat. Saya adalah pengguna senang React-Redux, React-Hooks, ReactiveX dan belakangan ini untuk Aplikasi Blazor :heart: Fluxor :heart: . @mrpmorris dapat berkontribusi dalam percakapan ini.

Inilah upaya saya pada contoh C #. Saya tidak memiliki MAUI yang tersedia untuk mencoba ini sebagai contoh nyata. Tidak ada pratinjau, kan? Bagaimanapun, ini adalah terjemahan kasar dari ide tersebut.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

Apakah ini akan menimbulkan lebih banyak biaya kinerja untuk pembaruan daripada di sampel Microsoft? Dalam model ini, jika saya mengerti, tampilan baru akan dipakai yang berisi semua elemen UI, sebagai lawan, dalam sampel MS, membiarkan elemen tampilan yang ada di tempatnya dan hanya memperbarui nilai label (yang menimbulkan -sizing biaya ini bisa).

Perbedaan ini tampaknya menjadi salah satu perbedaan inti yang mendorong diskusi seputar penamaan, jadi saya ingin tahu apakah dalam arsitektur MVU yang didefinisikan secara tradisional ada teknik lain untuk memperbarui UI secara efisien, dan jika demikian, apakah mereka diimplementasikan pada tingkat mesin render?

@markmccaigue dalam hal kinerja: seringkali sistem MVU datang dengan tampilan virtual (atau DOM virtual dalam kasus html) dan mesin pembeda. Jadi setelah melakukan diffing DOM dengan virtual DOM framework hanya perlu menerapkan patch pada DOM tersebut. Ini biasanya sangat sangat efisien, terutama jika Anda bekerja dengan struktur data yang tidak dapat diubah.

Halo!!

Saya akan menutup masalah ini untuk saat ini .. Saya ingin membuat ini diskusi tetapi github tidak ingin membuatnya berfungsi :-/

Jika ada yang ingin melanjutkan percakapan ini, silakan buat item diskusi dan referensikan masalah ini