<p>saran peningkatan dva</p>

Saya pikir Anda pada dasarnya dapat memenuhi kebutuhan Anda dengan menggunakan dva-model-extends.

@ iceberg211 Saya merasa berbeda, dva-model-extends setara dengan pewarisan, dan struktur datanya sama dengan model. Dan apa yang saya kemukakan di sini diatur oleh modul, pada kenyataannya, modul adalah struktur organisasi virtual.

Semua perpustakaan dalam seri redux menekankan perbedaan antara lapisan sinkron dan lapisan asinkron. Keindahan namanya adalah statusnya dapat dilacak, catatan lognya nyaman, dan abstraksi bisnis dari lapisan operasi data nyaman.
Tetapi di sebagian besar aplikasi, abstraksi tindakan saat menulis kode sebenarnya untuk menanggapi operasi tertentu atau mengekstrak tindakan tertentu yang dapat digunakan kembali, yang tidak membedakan antara sinkron dan asinkron.

Ini juga alasan mengapa semakin banyak proyek vue menggunakan toko dan bereaksi langsung dengan mobx.
Menulis dalam gaya redux selama bertahun-tahun terasa sangat bertele-tele, melompat-lompat. Untuk menulis pemuatan asinkron, Anda harus menulis 'sukses', 'kesalahan', 'mulai', dan 'kemajuan'.
Secara obyektif, keuntungan terbesar dari desain ini adalah mudah untuk diuji, tetapi ada sedikit tes bisnis skala besar di China, yang tampaknya hambar~

Itu bisa dicapai dengan yang ini milikku
https://github.com/fangkyi03/dvajs

Ini juga alasan mengapa semakin banyak proyek vue menggunakan toko dan bereaksi langsung dengan mobx.

Bagaimana @yeatszhang sampai pada kesimpulan ini? Punya data?

Ini terlihat sedikit mirip dengan rematch , tetapi rematch juga dibagi menjadi peredam dan efek.

@sorrycc rematch Saya rasa tidak jauh berbeda dengan dva, kecuali cara penulisannya, membuat orang merasa sedikit lebih natural (tapi nyatanya, dva terasa natural setelah lama menulis). Jadi saya pikir itu adalah lapisan model yang melakukan lapisan tambahan konversi gula sintaksis (tanpa mengubah api), tetapi terlihat lebih modular saat mengedit kode.

{
  namespace: 'user',
  state: { },
  userList: {
    before() { },  // 同步，函数显示loading
    after(){}, // 同步，隐藏loading
    *retrieve() {}, // 异步, 请求读取列表
    *create() {}, // 异步，创建用户
    *update(){}, // 异步，更新用户信息
    saveModal(){}, // 同步，显示或者隐藏modal
    successMessage(){}, // 模块内可复用的消息提示
    failMessage() { }, 
  },
}

Daftar pengguna di sini agak tidak jelas, ambil saja? Selain itu, sebagai enkapsulasi atas redux, saya pikir reduksi harus dipertahankan.

Saya membuat beberapa perbaikan pada dva dan menggunakan skrip untuk secara otomatis menghasilkan js yang sesuai untuk antarmuka api latar belakang.
https://github.com/fangkyi03/swaggerToTypeScript

Kemudian jika Anda ingin membuat permintaan jaringan, Anda dapat langsung api.sendData. Kemudian Anda dapat menulis antarmuka apa pun di dalamnya. Semua antarmuka dapat diselesaikan dan parameter apa pun di dalamnya dapat langsung dilihat perubahan dan perubahan yang tidak normal. Logika yang diperlukan tidak tidak perlu ditulis sepadat dva, apalagi bila ada beberapa permintaan jaringan.

api.sendData(ini,[
api.cart (ini adalah modelName yang sesuai).getList (hubungan dari api yang dihasilkan secara otomatis di sini dapat secara otomatis digaungkan langsung dalam ide) (
Berikut adalah efek sampingnya, setiap permintaan jaringan dapat diproses secara terpisah, seperti onCallBack, onError, timeOut, dll.
)
])

Contoh pembuatan otomatis dokumentasi antarmuka api

Jika Anda menggunakan dva untuk menulis hal yang sama, jika ada beberapa permintaan jaringan, Anda perlu memproses setiap antarmuka permintaan jaringan sekali untuk memberikan contoh. Saya menghapus satu hal dan memperbarui daftar pada saat yang sama. Gunakan hasil [] Metode ini simple banget sih tapi interfacenya dipanggil bersamaan bukan berurutan, jadi kalo jaringannya gak stabil akan ada masalah saya hapus daftar interfacenya sebelum saya hapus, dan datanya tidak update.

Dan jika Anda menggunakan panggilan hasil untuk membuat penilaian tunggal, 2-3 antarmuka masih dapat digunakan. Jika ada banyak antarmuka, Anda perlu memastikan keakuratan data. Anda perlu menilai apakah kode 200 untuk setiap antarmuka. Ini benar-benar merepotkan.

Jika saya menggunakan ini, tulis saja langsung di api.sendData. Setiap antarmuka dijalankan secara berurutan, dan masalah kode tidak mengharuskan Anda melakukan pemrosesan dan penilaian apa pun. Ini sangat sederhana. Jika Anda ingin melakukan pemrosesan data pada permintaan Tambahkan langsung ke antarmuka yang sesuai dengan intersepsi
onCallBack atau onError baik-baik saja

Penilaian subyektif
Mengenai mode toko dan mode redux, ada juga banyak diskusi di Internet~ Pendapat pribadi saya adalah bahwa redux memiliki banyak fitur keren, terutama manfaat dari mengejar ide fungsi murni:

• Mundur, snapshot
• Mudah untuk menguji
• Isi ulang panas
• alat pengembang

Jika Anda menganggap tidak mendukung fitur-fitur ini (untuk tim kami, frekuensi pengembangan benar-benar digunakan terlalu sedikit, terutama devtools paling keren), mungkin kami dapat mengekspos API yang lebih efisien ke dunia luar - sama seperti Pengemasan dva sama dengan mengejar pengembangan kemasan gula redux yang efisien, pasti akan kehilangan beberapa fleksibilitas, tetapi karena menyediakan fitur yang diperlukan dan efisien, itu sangat berharga.

Singkatnya, untuk menulis permintaan ajax yang sangat sederhana, fragmen logis perlu tersebar di beberapa file dan perlu bolak-balik selama proses pengembangan.Saya merasa dva dapat memikirkan cara untuk mengoptimalkan status quo ini. ^ ^

Pendapat pribadi terutama untuk mode redux, bukan dva

Saya pribadi berpikir bahwa memisahkan bagian dari kode logika ke dalam model untuk mencapai pemisahan kode yang baik dan menulis apa yang disebut efek samping pada efeknya juga sangat bagus. Tetapi ketika bisnis Anda menjadi semakin rumit, kode itu sendiri ditulis dalam model. Ini adalah efek samping terbesar untuk seluruh sistem. Kemungkinan menulis sekelompok penggunaan kembali secara padat terlalu rendah dan ketika adegannya rumit, itu juga melibatkan pengoperasian data di setiap keadaan dalam model. Itu juga menjadi sangat merepotkan dan sulit dipelihara. Kode logika perlu ditulis terlalu banyak. Naik

@fanngkyi03 setuju dengan beberapa pandangan Anda. Bagian pertama adalah redux dan dva tidak lebih sederhana dari mobx, dan lebih verbose.
Bagian kedua adalah untuk mendukung merger yang Anda sebutkan. Namun, metode Anda tidak dinamai dengan baik, dan daftar pengguna sulit dipahami, seperti efek pengurangan. Ini sangat jelas, dan itu hanya nama tambahan, yang bukan merupakan redundansi. Ini mendukung soricc.
Saya pikir redundansi terletak pada penambahan tipe dan status saat memanggil metode di dva. Kedua atribut ini diperbaiki, dan Anda dapat menggunakan bentuk konvensi yang lebih besar daripada konfigurasi untuk memungkinkan pengguna mengetik beberapa kata lebih sedikit.
Adapun masalah lain yang disebabkan oleh asinkron, saya pikir itu adalah pot saga.Asynchrony awalnya adalah tangkapan, yang paling alami. Metode saga tampaknya lebih intuitif dan nyaman untuk mendapatkan hasil dengan benar, tetapi tidak begitu nyaman untuk menangani pengecualian kesalahan.

Selain itu, saya ingin mengatakan bahwa mobx sangat bagus, karena jauh lebih ringkas daripada redux dan direkomendasikan oleh penulis redux.Saya pikir kelebihannya adalah sebagai berikut:

1. Ini berfokus pada pengelolaan keadaan dan menyerahkan opsi teknik lainnya kepada pengguna. Faktanya, selama mode berlangganan stateful diimplementasikan, peran utama redux telah selesai. Adapun cara menangani asinkron, apakah pengguna hierarki mvc perlu mengimplementasikannya secara bebas.
2. @ dari es7 digunakan, yang mirip dengan anotasi java, yang bisa sangat memudahkan untuk memodulasi kode.

Pertama-tama, rencana saya adalah langsung menggunakan skrip yang saya tulis untuk merayapi api back-end Anda jika back-end Anda sombong, dan kemudian langsung menghasilkan dokumen api yang sesuai secara lokal ketika Anda perlu memanggil antarmuka secara langsung
api.send(ini,[
api.cart('cartModel').getCartList()()
])
Semua nama di sini tergantung dari nama backend interfacenya, jika kurang mudah dipahami, maka menurut saya dokumen angkuh tidak perlu dibaca karena ketika Anda mengklik dokumen angkuh, Anda dapat melihat nama dari dokumen angkuh tersebut. antarmuka yang sesuai di sisi url. Anda dapat langsung membandingkannya untuk mengetahui antarmuka mana, dan karena dokumen secara otomatis dihasilkan oleh api langsung, jika Anda ingin melihat detailnya, klik langsung untuk melihat detailnya.

Apakah mungkin untuk mengetahui apa yang dilakukan api ini?

Kedua, saya telah membuat pemisahan yang lebih abstrak dari perilaku umum. Anda dapat mengganti skrip api untuk memasang lebih banyak fungsi Anda. Anda dapat mengontrol tampilan atau non-tampilan modal yang sesuai seperti ini.
api.toggleModalShow(thz,modelName,state){
thz.props.dispatch({type: ${modelName}/setValue ,payload:{
adalah ShowModal: state
}
}

Keuntungannya adalah jika saya ingin mengontrol tampilan modal apa pun di seluruh proyek di masa mendatang, apa pun modelnya, saya hanya perlu satu baris kode untuk mengontrolnya.

Berikut adalah contoh sederhana. Perilaku lainnya sama. Misalnya, formulir formulir. Ketika skrip api Anda menjadi lebih dan lebih detail, komponen Anda dapat mencapai fungsi ini hanya dengan beberapa baris kode dan Anda dapat mengabaikan modelnya. Lokalitas tidak tidak perlu menulis kode untuk setiap model

Banyak orang suka secara langsung merangkum permintaan untuk membuat permintaan jaringan. Metode permintaan terfragmentasi. Anda tidak dapat melakukan pengelolaan terpadu. Misalnya, ketika antarmuka saya melaporkan 500 atau 401 pengecualian, saya ingin menangkap pengecualian ini dan melakukan yang sesuai memproses permintaan. Pengecualian ditangkap, tetapi lapisan luar masih akan dieksekusi secara langsung. Jika permintaan jaringan Anda ditulis langsung di halaman alih-alih sage, maka tunggu sampai mati. Dua persyaratan yang baru saja saya sebutkan akan menjadi jika Anda mau untuk mencapainya. Ini sangat sulit dan jika Anda memasukkannya ke dalam saga dan menggunakan pengiriman untuk mengontrolnya, Anda akan menghadapi masalah kontrol negara. Misalnya, setiap antarmuka harus menilai apakah kodenya 200. Ini benar-benar pekerjaan yang berulang. Kedua, jika permintaan jaringan Anda dilemparkan ke dalam sage Kesalahan akan masuk ke onError dva, tetapi bukan hanya kesalahan data jaringan yang masuk, jadi ketika Anda menyebabkan program Anda macet dan mengeluarkan pengecualian, Anda memiliki untuk menilai apakah permintaan jaringan salah atau variabel biasa tidak ditentukan. Kesalahan dan membuat kode Anda tidak cukup murni. Kesalahan jaringan dan kesalahan umum digunakan bersama. Saya pribadi tidak menyarankan

@fanngkyi03
1. Apa kegunaan back-end Anda tidak ada hubungannya dengan penamaan front-end Anda yang tidak jelas?Bahkan, kesombongan Anda juga berguna untuk menulis dokumen antarmuka dokumen.
2. Saya sudah mengevaluasi saga, tidak mudah untuk mengontrol keadaan abnormal. Tentu saja, ini tidak akan menjadi saga, adalah mungkin untuk merangkum metode permintaan dengan berbagai cara. 404. Apakah 500 atau pengecualian dapat ditangkap dalam pemrosesan modular. Kode ditulis hanya sekali.

Sudahkah Anda membaca dvaj yang saya tulis dapat dengan mudah menyelesaikan masalah yang Anda temui

@fanngkyi03 Tidak, apa bagusnya dirimu?

Meskipun @fangkyi03 mengeluh tentang dva di beberapa tempat, tetapi dalam rangka mengisolasi efek samping, dva adalah sintesis terbaik. Proyek ini akan mencoba menggunakannya di masa mendatang, terima kasih atas kontribusi Anda~
Disarankan bagi pemula untuk tidak mengekspos bagian konsep saga tentang kontrol proses (sebaiknya saga tidak menyadarinya), tidak semua orang bisa mengerti, apalagi menggunakannya dengan baik~ Anda dapat membuat halaman fungsi lanjutan di dokumen. .
Selain itu, tidak banyak skenario yang digunakan (kebanyakan adalah untuk mengisolasi efek samping dan melakukan operasi asinkron)

Jadi saya berbicara tentang masalah isolasi apa yang Anda khawatirkan, tetapi saya tidak memperhatikan berapa banyak kode berulang yang Anda tulis. Saya memproses dva dan mengoptimalkan beberapa adegan ke dalam kategori berikut, membentuk ModalFrom, dll. Kemudian Anda akan menemukan Anda keseluruhan Program tidak perlu membuat model apa pun dengan sendirinya, juga tidak perlu memproses logika kode ini dengan sendirinya. Cukup gunakan model ini untuk beroperasi secara langsung. Tidak peduli model mana yang dimiliki formulir Anda, Anda dapat langsung memperoleh dan memprosesnya dan kemudian Anda bisa langsung Itu saja

Kemudian Anda menulis satu set ini untuk mengubahnya menjadi model publik, dan kemudian semua hal secara langsung diabstraksikan.Kemudian, Anda akan menemukan bahwa saya ingin memodifikasi formulir dan adegan lainnya dan langsung memanggil perintah yang ditentukan di api. Logikanya tidak perlu saya tulis sendiri, karena hubungan antar model, pemahaman setiap orang tentang model dan redux tidak sama, jadi gaya kode setiap orang juga aneh, jadi kenapa tidak seragam?

Misalnya, ketika formulir saya dibuat seperti ini

SearchDropMenu ini akan secara otomatis membuat data formulir yang sesuai dalam model yang sesuai di komponen
formData data konfigurasi formulir
dataSource formulir sumber data
typeData drop-down ketik data, dll. Kemudian dengan cara ini, Anda akan menemukan bahwa semua hal di sisi saya dapat langsung diproses dengan perintah api. Tidak peduli seberapa rumit formulir Anda dan mengabaikan masalah model, saya dapat menelepon dalam model apa pun. Perintah tetap untuk dicapai

Misalnya, ketika saya ingin mengirimkan formulir dan memvalidasi data formulir, saya hanya perlu menulis penilaian semua formulir dengan cara ini. Tidak perlu menulis semua kode umum untuk mencapai perbedaan. Satu-satunya perbedaan adalah yang mana antarmuka yang akan Anda panggil setelah menggunakan data formulir ini untuk mengirimkannya.

Jadi saya tidak pernah mengerti arti dari penggunaan model untuk menulis begitu banyak kode berulang. Anda selalu mengatakan bahwa tidak ada isolasi. Apakah Anda yakin bahwa biaya isolasi Anda sangat kecil untuk proyek? Tidak lebih sederhana seperti saya.

Proyek saya di sini adalah file model karena ini digunakan untuk permintaan jaringan

Semua bagian mdoel lainnya langsung dihasilkan seperti ini

Tidak perlu membuat begitu banyak file model yang tidak dapat dipelihara secara lokal, dan jika Anda ingin melakukan pemrosesan jaringan atau penanganan pengecualian, Anda hanya perlu melakukan operasi global di sini, dan Anda tidak perlu melakukan pengaturan lain sama sekali.

Misalnya, jika salah satu dari beberapa permintaan gagal, saya dapat langsung mengabaikan permintaan berikutnya untuk menjalankannya, atau sangat mudah untuk melompat ke halaman login setelah token gagal.

Misalnya, jika Anda ingin membuat beberapa permintaan antarmuka secara bersamaan, Anda hanya perlu melakukan ini, jadi beberapa kode telah dapat memperoleh data jaringan dan kemudian menggunakan tranData untuk mengubah format data dan menyegarkan data yang dikonversi. ke model yang sesuai. Tidak perlu melakukan seperti dva. Tulis banyak logika padat di efeknya

@fanngkyi03 mungkin mengerti apa yang Anda katakan, maksud Anda adalah bahwa ada banyak redundansi dalam model, dan banyak bagian dapat digunakan kembali. Dalam deskripsi Anda, jaringan meminta untuk mendapatkan data dan mengubah data yang sesuai dan penanganan kesalahan. Ini operasi yang sama. Tidak perlu mengulang model bangunan.

Saya mengembangkan antd dan kemudian menggunakan mode dva untuk menulis dan menemukan bahwa seluruh tim tidak dapat memiliki gaya terpadu sama sekali. Setiap orang memiliki pemahaman yang berbeda tentang model. Kode yang ditulis adalah semua kode sampah, jadi mengapa formulir sederhana sangat merepotkan? Jika Anda tidak melakukan paket dan mengubahnya menjadi satu kesatuan, maka Anda akan menemukan bahwa operasi bentuk modifikasi bentuk apa pun dapat langsung memanggil api terpadu. Seluruh proyek sangat menyegarkan dan bersih. Permintaan jaringan juga akan menjadi bersih secara tidak normal tanpa banyak hasil. Saya pribadi berpikir bahwa perkembangan normal tidak boleh menyentuh hal-hal ini, karena setelah menggunakan ini, kualitas kode Anda tidak dapat dikontrol sama sekali. Anda tidak dapat menetapkan bahwa permintaan jaringan yang harus diperoleh orang lain data dengan cara ini, refresh data, dll, sehingga kualitas kode menurun Kadang-kadang ketika Anda melihat kode yang ditulis oleh orang lain dalam tim, Anda harus berpikir lama mengapa data di-refresh seperti ini dan mengapa Anda perlu untuk melakukan operasi lain

@fangkyi03 Jadi slot Anda adalah model

Keberadaan model harus dibatasi pada isolasi data penyimpanan dan bukan isolasi panggilan fungsi.Hal ini akan menyebabkan masalah kualitas kode yang besar.

Atau dengan kata lain, keberadaan model hanya boleh digunakan di toko, dan tidak boleh digunakan untuk pengembangan biasa untuk menyentuh level ini, itu harus ditulis sebagai API umum karena Anda tidak dapat membatasi kualitas kode di semua jika pengembangan biasa terkena model. Ide setiap orang berbeda. Itu tidak sama. Anda memiliki begitu banyak fungsi yang dapat mengubah proses redux, seperti hasil pilih, ambil panggilan, dll. Bisakah Anda membatasi mana yang harus dipanggil terlebih dahulu dan mana yang harus dipanggil nanti?

@ fanngkyi03 Saya merasa ada masalah yang Anda sebutkan, yaitu, dva saat ini tidak nyaman untuk pemrosesan terpusat dengan efek atau pengurangan yang sama. Sehingga setiap tempat harus ditempel lagi.
Tapi saya rasa masalah ini menurut Anda menonjol karena Anda memaksimalkan penggunaan dva (hal ini terjadi pada contoh website resmi (dashboard). Ada juga beberapa contoh website resmi umi yang dipandu ke arah ini (penggunaan dva secara maksimal) ), Jika meminimalkan dva hanya menggunakan dva ketika pembaruan lintas komponen diperlukan, maka pada dasarnya hanya ada sedikit pemrosesan dan penggunaan kembali terpusat.
Misal kalau request data, kalau saya tulis tidak pakai dva, tapi request yang dipaketkan sendiri, supaya performanya bagus dan prosesnya terpusat.
Jika Anda benar-benar membutuhkan banyak model untuk menggunakan kembali pengurangan dan efek,
Kita juga dapat memetakan sekelompok objek model dari larik ruang nama konfigurasi, menambahkan pengurangan atau efek yang sama, dan akhirnya menambahkannya dengan metode model aplikasi. Ini juga menghemat kode, menambahkan bagian ini tidak sama dengan konvensi umi.

di atas. Lebih baik meminimalkan penggunaan dva. Slot Anda karena Anda memaksimalkan penggunaan dva, itu bukan cacat bawaan dari dva, saya pikir itu tidak signifikan.

Setelah sesuatu diluncurkan, tetapi Anda akan menemukan bahwa setiap orang bukanlah penulis dva. Sekelompok Xiaobai melihat artikel yang ditulis oleh berbagai orang dan memasukkannya ke dalam produksi. Kemudian Anda akan menemukan bahwa n proyek yang ditulis oleh orang-orang ini adalah proyek sampah. Ini berarti bahwa banyak orang yang menggunakan dva untuk melakukan proyek tidak dapat menjamin kualitas kode. Bukankah ini bertentangan dengan tujuan awal dva?

Manfaat pemrosesan terpadu sudah jelas. Sambil meningkatkan kualitas kode dan membuat keseluruhan proyek lebih dapat dipelihara, itu juga dapat memberi Anda semua kinerja dan fitur yang dapat dibawa dva kepada Anda. Mengapa tidak melakukannya? Sama seperti yang dikatakan dva Menyediakan 8 api yield select call, dll. Tapi ini masih jauh dari produk jadi yang sebenarnya. Akan ada banyak kemungkinan di tengah. Jadi Anda masih membangun jalan dan menulis kerangka kerja. Saya sudah mengemudikan mobil di sini. Ini ada celah dan dapatkah Anda menjamin bahwa kode yang Anda tulis dalam proyek ini dapat digunakan secara langsung di proyek berikutnya, terlalu sulit bagi saya untuk terus mengulang-ulang menulis pemrosesan logika.

@ fankyi03 Saya merasa bahwa tujuan awal dari
Dua fungsi utama redux 1. Komunikasi lintas komponen. 2. Sesuai dengan frameworknya, aliran data dibuat menjadi mvc. Menurut saya alasan ingin memaksimalkan penggunaan dva adalah dengan menggunakan mvc sebagai standar. Artinya, logika lapisan data dapat digunakan kembali setelah mvc yang Anda sebutkan, dan beberapa halaman dapat diikat ke pusat pemrosesan data (model).
Tapi saya masih berpikir bahwa proses minimalisasi lebih baik, hanya 1, data halaman a Anda, operasi pada halaman bc dapat mengubah data halaman a semacam ini sumber data terkait multi-halaman. 2. Logika tampilan data pembaruan yang sama. Dalam kasus ini, sangat cocok untuk ditempatkan di dva.
Jika Anda ingin fokus pada pemrosesan, Anda juga dapat menulis sendiri fungsi pemrosesan data, seperti di utilitas umum Anda, seperti permintaan barusan.
Jika Anda menulis semuanya dalam dva, yang melibatkan perubahan data lintas komponen dan yang tidak terlibat akan ditulis bersama.Dari sudut penyatuan, ini merupakan keuntungan, tetapi juga membawa dua kerugian.
1. Modelnya banyak dan tidak menyegarkan. Lain kali Anda ingin mengatur model umum, Anda harus lebih membedakan.
2. Toko menjadi lebih besar, yang membawa perhitungan ekstra.

………………………………………
Akhirnya, kembali ke model pemrosesan terpadu, seperti yang Anda tulis, itu juga diambil dari daftar model, dan peta ditambahkan dengan metode pengurangan atau efek umum Operasi ini adalah operasi pada fungsi asli dva (penambahan ), dva tidak mencegah Anda melakukan ini, tidak perlu mengubah apa pun. Selain itu, operasi Anda semacam ini tidak mudah untuk dirangkum menjadi metode untuk menjadi metode peningkatan umum, atau Anda harus menulisnya sendiri secara rinci, oleh karena itu, bagaimana Anda perlu mengubah dva?

Jadi saya katakan bahwa Anda masih tidak mengerti ide inti saya. Yang saya maksud adalah bahwa model tersebut hanya digunakan sebagai toko untuk digunakan. Saat ini tidak juga populer seperti komponen stateless. Juga baik untuk melepaskan status dan penggunaan props, meskipun beberapa slot di redux akan menyebabkan beberapa perhitungan yang berlebihan, tetapi jumlah perhitungan masih dapat diperkirakan. Lagi pula, model Anda hanya digunakan untuk menyimpan data dan tidak akan ada pemrosesan logika redundan lainnya. Sebenarnya , jumlah perhitungan terutama tercermin dalam slot redux ini ketika Anda memulai pengiriman. Pada saat itu, semua pengurangan, semua pemantauan, dan semua middleware akan berpartisipasi dalam perhitungan, jadi saya menulis fastDva untuk ini, hanya menjaga bagian-bagian yang dibutuhkan dalam proyek yang sebenarnya, dan yang lainnya telah dibuang, yang membawa peningkatan yang lebih besar dan dapat lebih cocok untuk saya sekarang Konsep
https://github.com/fangkyi03/fastdva-core

Jadi saya akan mengonversi semua dva ke fastDva yang saya tulis di masa mendatang

@fanngkyi03 Saya pikir saya mengerti apa yang Anda katakan, model hanya digunakan sebagai toko, seperti mengurangi, efek untuk memproses data, tidak perlu ditempatkan di model. Benar. Tujuan Anda melakukan ini adalah untuk mempertimbangkan bahwa operasi pemrosesan data dari banyak model adalah sama, sehingga Anda dapat mengelompokkannya untuk memproses daftar model seperti yang Anda lakukan di atas.
Pertanyaan saya adalah: Fungsi asli dva tidak mencegah Anda menambahkan pengurangan dan efek ke sekelompok model dalam batch. Itu tidak mencegah Anda dari hanya memperlakukan model sebagai toko. Anda melakukan penambahan pada dva dengan cara ini, dan tidak ada yang berubah.

Bagaimana Anda mengelola gaya keseluruhan tim dengan cara asli? Ketika saya melakukan ini, kinerja dan kualitas kode dapat ditingkatkan sambil mengoptimalkan, dan logika kode yang ditulis dapat digunakan kembali. Anda bahkan tidak perlu menulisnya lagi jika Anda menulisnya sekali, proyeknya bisa jadi mengapa tidak melakukannya?

@fanngkyi03 juga bingung. Baik penulis vuex dan penulis redux mengatakan bahwa itu memberikan kebebasan maksimum. Bagaimana mengatur proyek dan bagaimana mengatur penyimpanan status terserah pengguna untuk memutuskan (penulis redux sedikit condong untuk mengubah status semua halaman Semua ditempatkan dalam model untuk manajemen terpadu). Tetapi ketika banyak orang mengerjakan proyek teknik bersama-sama, diperlukan panduan praktik terbaik. Tidak semua orang mau dan mampu memikirkan bagaimana kode itu diatur dengan baik, dan kebetulan hasil pemikiran semua orang konsisten~~

Pemikiran teknik Angular jauh lebih baik pada saat ini, cukup ikuti modelnya dan tulis. Barak besi, tentara air mengalir~

Dengan kata lain, masalah teknik tidak harus diselesaikan oleh dva, tetapi jika dva tidak menyelesaikan masalah ini, lebih baik untuk memiliki paket alat tingkat atas, atau memberikan pedoman dan lebih banyak kendala untuk menangani kebutuhan pengembangan seperti itu~ Perluas ekologi

Saya pikir lebih baik untuk menyelesaikan masalah terlebih dahulu. Skalabilitasnya terlalu tinggi, tetapi pengembangan sebenarnya tidak membutuhkan banyak hal. Karena definisi yang tidak diketahui menyebabkan penurunan kinerja, rasanya sangat boros.

Skenario di mana dva dibutuhkan:
1. Halaman yang berbeda, terutama lintas komponen, memiliki sumber data yang terkait atau dapat berlangganan ke sumber data yang sama.
2. Komponen atau halaman yang berbeda memiliki data dan logika tampilan baru yang sama.
Dalam [2], mengapa saya mengatakan bahwa ada komponen dan halaman yang berbeda, karena reaksi dikomponenkan, dan bagian dari fungsi model tampilan yang dapat digunakan kembali langsung dilampirkan dalam komponen. @yeatszhang ng menggunakan mvvm atau mvc untuk mendapatkan manfaat lebih dari bereaksi karena ng tidak merangkum data dalam komponen. ng didasarkan pada data, dan reaksi didasarkan pada komponen. Keuntungan menggunakan data sebagai satu unit adalah untuk memisahkan halaman, dan ada lebih banyak tempat pemrosesan data untuk digunakan kembali. Harganya adalah beberapa halaman perlu digabungkan dengan data dan juga dipisahkan. Anda harus menulis kode untuk menjepitnya bersama.
Oleh karena itu, skenario penggunaan [2] juga sangat berkurang.

Berikut ini adalah apa yang saya pikir sama sekali tidak perlu.
i. Jika logika pemrosesan datanya sama tetapi tidak perlu memperbarui tampilan, itu dapat digunakan kembali tanpa pergi ke dva.
2. Logika pemrosesan data pemrosesan yang sama juga perlu diperbarui dan ditampilkan, tetapi jumlah kode yang hampir sama untuk dimasukkan ke dalam model untuk dihubungkan dan disetel langsung.
Skenario tipikal di atas adalah mengirim permintaan untuk mendapatkan data. Jumlah kode yang diminta hampir sama dengan data baru, diperoleh dari negara bagian dan diperoleh dari toko. Jika tidak ada beberapa halaman yang terkait dengan sumber data yang sama, tidak perlu membuka dva.

………………………………………
Mengenai masalah manajemen terpadu, kami membahas pro dan kontra dari penggunaan alat-alat ini, seperti halnya kami membahas perlunya menggunakan sumpit, sendok dan garpu untuk melengkapi makanan. Mereka memiliki pro dan kontra sendiri. Untuk seragam mengharuskan semua sumpit atau sendok bisa digunakan untuk makan. Oleh karena itu, penggunaan dva sebanyak mungkin dan penggunaan dva sesedikit mungkin dapat dijadikan sebagai acuan spesifikasi.

,

Saya pikir lebih tepat untuk membuat pembagian abstrak sesuai dengan perilaku proyek Anda yang sebenarnya. Misalnya, beberapa perilaku dan komponen seperti formulir modalForm Anda. Anda telah menulis semua perilaku yang umum digunakan. Anda dapat menggunakannya langsung lain kali. Ini set kode dapat dengan senang hati ditempatkan di proyek apa pun. Cara terbaik untuk menggunakan pengalaman ini adalah dengan menggunakan formulir semacam ini di masa mendatang. Anda tidak perlu mengulangi logika dan menggunakannya. Juga nyaman untuk menulis api dokumen, yang juga nyaman untuk pelatihan pendatang baru dalam tim dan pemeliharaan gaya terpadu. Bagian ini juga dapat ditulis. Secara mandiri membentuk antarmuka api terpisah dan kemudian dengan cepat beralih dan mengembangkan halaman terkait antd atau formulir secara langsung tanpa memikirkan logika rumit apa pun untuk mempertimbangkan masalah transmisi data.

Ada banyak orang yang bisa menulis gaya, tapi hanya sedikit orang yang benar-benar bisa menulis bingkai. Dva memberimu pisau tapi tidak memberitahumu cara mengukir bunga. Akibatnya, semakin banyak sayuran busuk di permukaan. pasar. Hal ini karena fakta bahwa redux dan dva terlalu sulit untuk digunakan atau tidak mudah digunakan. Meskipun ada beberapa alasan, saya pikir itu karena tidak ada hubungan solusi terpadu yang mengarah pada mekarnya bunga dan banyak wirausaha atau perusahaan outsourcing tidak bisa mengoptimalkannya dari bawah. Menanam hanya bisa mengikuti tren. Apapun yang populer sekarang. Tidak peduli apa tiga-tujuh-dua-satu digunakan langsung dan kemudian seperti bola salju. Ada semakin banyak proyek Ini juga merupakan masalah umum perusahaan outsourcing dan wirausaha di Cina.

Roda baru redux. . . persegi panjang

Ajukan pertanyaan, dapatkah efek rematch memiliki nilai balik, dapatkah efek dva?

Ajukan pertanyaan, dapatkah efek rematch memiliki nilai balik, dapatkah dampak DVA memilikinya?

Efek dapat mengembalikan data dalam bentuk janji

@fanngkyi03 Saya mengerti, terima kasih.

Yang saya inginkan hanyalah namespace bersarang.
Contoh:

const model = {
  namespace: 'foo',
  model: {
    namespace: 'bar',
    state: {
      msg: "Hello, World!"
    }
  }
}

dapatkan msg dengan foo.bar.msg

Di atas hanya contoh kasar...

Masalah ini secara otomatis ditandai sebagai basi karena tidak ada aktivitas terbaru. Ini akan ditutup jika tidak ada aktivitas lebih lanjut yang terjadi. Terima kasih atas kontribusi Anda.

@sorrycc menyarankan untuk mengubah format tipe dari namespace/ action menjadi action@namespace , yang lebih semantik.