<p>dva 2.0</p>

Bagaimana dengan dukungan asli untuk ts?

Saat unmodeling, apakah Anda mempertimbangkan untuk mendukung melewatkan peredam untuk menghancurkan data status yang tidak digunakan? https://github.com/dvajs/dva/issues/769

Bagaimana dengan dva-cli yang diganti namanya menjadi roadhog? Agar konsepnya tidak membingungkan.

Secara pribadi, saya tidak setuju dengan dukungan asli untuk ts. Kerangka kerja harus mencoba untuk melepaskan ikatannya dari tumpukan teknologi lain yang tidak terkait, tetap murni, dan lebih sedikit melakukan lebih sedikit. Misalnya, masalah status model unmount juga dapat dilakukan dengan api yang ada, dan react-router Rencananya adalah untuk membagi menjadi komponen independen seperti react-router-dva.Saya juga dapat menulis react-navigation-dva untuk rn.

Ada juga skema optimasi yang juga dapat didukung dalam bentuk plug-in, seperti dva.use(reselect) , seperti mekanisme middleware express, hanya plug-in statis yang built-in, dan yang lainnya didukung secara terpisah , dan bahkan saga dapat tersedia

@nihgwu saya salah, artinya, seperti antd, ditulis dalam ts dan tidak membatasi pengguna. Ini memiliki keuntungan karena tidak harus menyinkronkan dan menerbitkan file jenis secara manual setiap saat.

Saya setuju dengan solusi plug-in, apakah mungkin melakukan ini:

view - dva-core - [插件]

Di antara mereka, bagian yang sama dengan dva saat ini adalah:

• inti-dva
• dva-saga
• router

Dua yang terakhir adalah plugin.

Bisakah dva diposisikan sebagai perpustakaan yang berfokus pada pengungkapan hubungan antara tampilan dan data? Kerangka kerja seperti apa tampilannya, dan metode apa sumber datanya, semuanya dapat diganti? Lalu, untuk meningkatkan versi 1.0 dengan lancar, tentukan dva sebagai kombinasi default dva-core dan saga?

Saya tidak tahu apakah enkapsulasi yang mendasarinya nyaman untuk mendukung tipe pengiriman dari tipe instans?

dispatch({
  type: model => model.product.loadAll,
})

Menghafal string juga merepotkan, dan sering lupa menulis namespace, jika ada prompt drop-down, juga nyaman untuk direkonstruksi~

Saya tidak tahu apakah mungkin untuk menyediakan satu set reduksi secara default untuk semua data di negara bagian
Dalam sebagian besar skenario, saya perlu menulis peredam secara manual, yang mungkin hanya menetapkan nilai ke bidang, jadi jika saya dapat memberikan metode set bidang tunggal yang sudah jadi untuk saya secara default, itu akan cukup bagus.

Bisakah reduksi diimplementasikan sebagai pohon? Seperti sekarang, ns split dipaksa untuk meratakan logika. Model sesuai dengan akar peredam, dan ada terlalu banyak reduksi yang tergantung di bawah.

@xufei Saya pikir saga harus menjadi inti, dan ini bukan tanpa saga. Tampaknya sulit untuk mengekstrak saga ke dalam plug-in dari perspektif implementasi.

@xufei Maaf, saya juga merasa bahwa Anda harus mengacu pada penulisan dalam ts, tetapi saya rasa itu tidak perlu. Lagi pula, antarmuka dva juga sederhana, dan tidak dapat ditulis ulang dengan ts karena ketik file.

@sorrycc Separating saga Saya juga memberikan contoh, memang benar inti dari dva adalah redux + redux-saga, tetapi dari segi implementasinya, kita dapat memisahkannya menjadi plug-in dengan cara callback hook.

Bisakah Immutable.js didukung?

Mendukung Immutable.js, Immutable.js memiliki peran penting dalam pengoptimalan kinerja

Pengemasan roadhog terlalu memakan kinerja. Lihat apakah Anda dapat mengoptimalkannya. Jika Anda bisa, optimalkan sebanyak mungkin. Sekarang Anda harus menghentikan kontainer lain sebelum server membangun proyek, jika tidak, server akan macet.

Immutable.js tidak digunakan lagi. Menggabungkan operasi lodash dan spread juga dapat mencapai efek yang tidak dapat diubah. Dan lodash pada dasarnya sudah ada di dalamnya.

Bahkan pengalaman pengembangan dva 1.x sudah sangat baik, mirip dengan apakah mendukung Immutable.js, split saga, dukungan asli ts, rasanya tidak perlu, semua milik pengembang yang mencintai diri sendiri, dan itu tidak banyak dengan efisiensi dan pengalaman pengembangan aktual.

Secara pribadi, ada 4 poin yang perlu diperhatikan oleh dva 2.x:

1. Optimalisasi lapisan layanan, apakah itu dapat diekstraksi ke dalam model, dan dikemas secara terpadu, pada dasarnya tidak peduli tentang request , dan kemudian memberikan penanganan pengecualian jaringan secara default, dan sekarang pada dasarnya Anda perlu untuk menulis request.js sendiri;

2. Ini adalah masalah panggilan balik efek dari lapisan tampilan. Tidak realistis (terlalu rumit) untuk sepenuhnya memisahkan logika bisnis ke dalam data model dan memprosesnya dalam efeknya, sehingga solusi yang lebih elegan diperlukan di area ini.

3. Ini adalah konstruksi dari komunitas sekitar dva. Saat ini, jenis scaffolding kaya akan contoh, tetapi lebih banyak konstruksi diperlukan. Rasanya seperti tujuannya adalah untuk mencapai tingkat sumber daya dari komunitas sudut atau reaksi itu sendiri.

4. Peningkatan alat build, kinerja, fungsi, dll. (saat ini tiruan) masih agak merepotkan

Bagi saya, yang paling mengkhawatirkan saya adalah pemisahan router .Saya pikir dva hanya perlu menyertakan redux + redux-saga . redux menganjurkan melakukan sesedikit mungkin, sehingga kemasan 1.x react-router dan fetch merasa tidak perlu, serta Immutable disebutkan di atas. Ini termasuk preferensi pengembang. Sebagai pengelola, tidak boleh condong. Untuk preferensi pengembang, dapat didukung dalam bentuk plug-in. Ada juga masalah lapisan layanan. Jika perlu , Anda dapat menulis plugin sendiri, Seharusnya tidak disertakan dalam dva-core

@nihgwu Apa tujuan mengekstraksi router?

@nikogu telah melakukan terlalu banyak, dan pemula akan bingung, tidak tahu apa prinsipnya.Tapi kalau doc ​​nya detail, bisa juga

Apa tujuan menghapus router?

@nikogu

Saat ini, ruang lingkup aplikasi dva agak sempit, dan sangat terkait dengan komunitas reaksi, secara alami termasuk tampilan, dan juga sangat terkait dengan router reaksi. Tetapi setelah menggunakannya, saya menemukan bahwa beberapa tempat tidak memerlukan router, seperti aplikasi multi-halaman nirkabel; beberapa tempat react-router tidak berlaku, seperti react-native; beberapa tempat tidak perlu bereaksi, seperti node , elektron dan applet.

Saya pikir dva bisa berbuat lebih banyak.

@nikogu menarik diri dari router karena kita dapat memiliki router yang berbeda. Misalnya, di RN, saya dapat menggunakan react-navigation, dan react-navigation juga mendukung web, yang dapat sepenuhnya didukung oleh plugin untuk mencapai kustomisasi yang lebih baik

Saya mengerti bahwa dva mengatur kode dan logika redux dan saga dalam bentuk baru, daripada menyediakan satu set lengkap kerangka kerja pengembangan web, seperti express, yang juga menggunakan api node yang ada untuk menyediakan fungsi dasar server web. apakah Anda berurusan dengan badan, cookie, dan mesin templat mana yang Anda pilih dapat disesuaikan melalui middleware?

Jika Anda menyukai solusi lengkap, Anda dapat menerapkan dva-ant = dva-core + dva-plugins penggunaan Anda sendiri

Kombinasi dva harus menjadi kombinasi redux dan saga, karena keduanya adalah inti dari aliran status data, dan yang lainnya hanya dapat dianggap sebagai periferal yang dibangun di atas data, dan dapat didukung oleh plug-in atau metode lain. Kita dapat membandingkan Express dan Django, perbedaan khas antara melakukan lebih sedikit dan melakukan lebih banyak, beberapa orang menyukai yang besar dan lengkap, tetapi komunitas js menghargai yang kecil tapi indah

Sedangkan untuk menggunakan redux secara langsung, alasan utama saya menggunakan dva adalah karena dva dapat menyederhanakan struktur kode dan logika redux dan meningkatkan efisiensi produksi, ini juga merupakan inti dari dva berbasis redux.

Jika kita membabi buta melakukan lebih banyak, skenario aplikasi dva akan menjadi semakin sempit, misalnya, router reaksi tidak dapat digunakan di RN (v4 sudah mendukung tetapi sangat mendasar), RN juga dilengkapi dengan fetch, dan ada ikatan kuat lainnya Pustaka juga akan menyebabkan masalah ketergantungan pemutakhiran. Ini masih router reaksi. V4 mendukung RN, tetapi dva masih V2. Kita harus menunggu dva memutakhirkan router reaksi sebelum dapat digunakan. Jika itu adalah plug- masuk dan tingkatkan secara mandiri, tidak akan ada masalah seperti itu

Yang saya maksud dengan dva-core di atas adalah memperlakukan small core sebagai dva-core, mengambil router dan sejenisnya dalam hal ini, dan kemudian mengembangkan beberapa skema integrasi default, seperti versi terpadu internal perusahaan, untuk middle dan back office , dan untuk H5, untuk program kecil, rendering sisi server, dll.

2:00:
1. Dalam pengembangan aktual, logika bisnis diimplementasikan dalam model, dan file terlalu besar Apa hubungan antara yang lain dan layanan? Layanan atau permintaan dapat built-in
2. Ubah react-router ke plug-in sistem sendiri, atau apa pun, tujuannya adalah untuk membebaskan ketergantungan

Kapan 2.0 akan dimulai?

Solusi ssr pluggable mengabstraksikan manajemen router. Sisi server dapat mengambil alih permintaan perutean pertama dan menggunakan dva() bersama untuk menginisialisasi pohon status. Rasanya saat dva terus meningkatkan versi, rendering server lemah dalam penerapan fitur baru.

TypeScript dan RN.Semoga mendapat dukungan yang lebih baik

Pikirkan yang lain, berikan default namespace

Dalam proses menggunakan dva, akan selalu ada kasus di mana reducer tidak memerlukan awalan apa pun, dan implementasi dva saat ini harus menyediakan namespace , jadi saya punya proposal, jika namespace adalah default (atau global , * ), menurut kami model bawah reducers adalah Tanpa awalan

Secara pribadi pikirkan beberapa poin:

• Tidak bergantung pada redux-saga , sehingga Anda dapat dengan mudah menambahkan beberapa fitur (seperti dukungan async/menunggu)
• Dibagi menjadi beberapa modul kecil (misalnya, satu toko, satu router)
• Mendukung model bersarang

Kami baru-baru ini membuat model vuex berdasarkan redux menulis titik referensi: https://github.com/d-band/yax

Disarankan agar server dapat dirender di sisi server, dan ujung depan dan belakang dapat ditulis bersama!

Bisakah saya mengatur nama direktori route? Misalnya, gunakan wadah
Sebenarnya, saya ingin membagi katalog berdasarkan fungsi, menyatukan model, layanan, dan wadah, jika tidak, melompat ke beberapa katalog akan menghancurkan aliran hati. Untuk mengetahui apa yang dibuka user.js pada tab di atas sublime, saya telah menamakannya seperti ini: user.jsx, user.model.js, user.service.js. Kumpulkan pengguna/model.js, service.js, container.js

Organisasi direktori seperti @zheeeng sekarang didukung, dan dva tidak memiliki batasan pada organisasi direktori.

@xufei
@maaf

Saat unmodeling, apakah Anda mempertimbangkan untuk mendukung melewatkan peredam untuk menghancurkan data status yang tidak digunakan?

Kontrol manual terlalu merepotkan, disarankan untuk langsung menerapkan satu set GC

Harap tingkatkan pathToRegexp, metode parse dan kompilasinya tidak dapat digunakan secara langsung

Kesepakatan lebih baik daripada konfigurasi, mengurangi penggabungan dengan proyek lain atau tumpukan teknologi.

Bisnis efeknya terlalu berat, dan ide model-extend cukup bagus

@nihgwu secara pribadi setuju bahwa "inti dari

@sorrycc Apakah

Saya sangat berharap dva-cli dapat memilih untuk menghasilkan boilerplate TypeScript

dva-core sudah dapat digunakan di applet WeChat

@yautah mencobanya? Anda dapat membagikan paket setelah Anda mencobanya.

Saya merasa bahwa dva-core hanya perlu menyediakan redux data stream re-encapsulation, apakah yang lain dapat disediakan dalam bentuk plug-in, atau akan lebih baik bagi pengguna untuk memilihnya, seperti skema pengemasan dan perutean.

Berharap untuk mendukung dva-cli untuk mendukung stylus

Dukungan ssr tidak.

Cara mengkonfigurasi HRM, penulisan API relatif sedikit