Redux: Permintaan Diskusi: Redux "boilerplate", kurva pembelajaran, abstraksi, dan opini

Beberapa ide:

• paket redux-preset resmi yang berisi redux, react-redux, redux-thunk sudah terhubung bersama
• dispatch(actionType, payload) dapat mengurangi kebutuhan akan pembuat aksi
• pembuat peredam gaya jumpstate bawaan, misalnya createReducer({[actionType]: (state, payload) => state}, initState)

Kebanyakan orang yang saya kenal yang menggunakan redux banyak, akhirnya menjauh dari redux-thunk karena mereka merasa tidak berskala dengan baik, dan akhirnya mengarah ke pembuat tindakan yang mulai melakukan terlalu banyak, dan lebih suka menggunakan sesuatu yang lain untuk mengelola sisi -efek seperti redux-observable atau redux-saga.

Saya dapat memahami daya tarik di dalamnya, terutama ketika memulai dengan redux - tetapi saya tidak yakin apakah menggabungkannya sebagai bagian dari 'paket boilerplate praktik terbaik' akan menjadi ide terbaik.

Jadi, bagian ini lebih penting bagi saya (ini tidak akan menjadi ide untuk memecahkan masalah, melainkan kendala yang, setidaknya bagi saya, penting):

Redux tidak dimaksudkan untuk menjadi "cara paling ringkas dalam melakukan sesuatu", melainkan untuk membuat aliran data menjadi jelas dan dapat dibaca

Hal yang hebat tentang Redux adalah bagaimana itu hampir lebih merupakan pola desain daripada kerangka kerja, dan semua kode yang Anda lihat (selain untuk toko dan react-redux ) adalah milik Anda sendiri.

Melihat Jumpstate (saya tidak mengetahuinya sampai sekarang), ini adalah salah satu lapisan abstraksi pertama yang saya lihat untuk Redux yang terlihat bagus. Hebat bahkan! Tetapi pada saat yang sama, itu hanya membawa Anda jauh dari kerangka kerja lain seperti MobX, dan memiliki banyak kerangka kerja yang membawa hal yang sama ke dalam tabel tidak terlalu berguna. Jadi fokus pada apa yang membuat Redux berbeda dari yang lain itu penting, bukan hanya bagaimana kita bisa membuat Redux lebih baik dalam ruang hampa (karena ia hidup di dunia yang sama dengan alat lain).

Hal penting lainnya, adalah bahwa banyak tantangan yang dihadapi pendatang baru ketika mereka menekan Redux bukanlah Redux itu sendiri, tetapi JavaScript. Kerangka kerja besar lainnya seperti Angular abstrak JavaScript itu sendiri. Menulis peredam Redux hanyalah menerapkan "pola desain" javascript vanilla, yang mungkin tidak asing bagi pendatang baru, dan akan membuat orang ingin menggunakan kotak hitam sebagai gantinya.

Akhirnya, banyak perpustakaan pengurangan boilerplate mencoba menambahkan hubungan 1:1:1 antara komponen, reduksi, dan pembuat tindakan (mungkin tidak semuanya 3, tetapi sering 2 di antaranya), yang membuat pendatang baru lupa bahwa mereka dapat memiliki beberapa reduksi yang menangani suatu tindakan , beberapa komponen menggunakan status dari beberapa reduksi, dan seterusnya. Itu salah satu pertanyaan #1 yang saya jawab di tempat kerja dan tempat lain, dan itu sangat berguna. Jadi alat untuk membantu di area itu tidak boleh kehilangan ini (juga, "switch is icky" bukanlah argumen terbaik di dunia).

Jadi IMO, CTA akan melibatkan penautan sumber daya JavaScript vanilla yang baik, serta mendokumentasikan lebih banyak "mengapa" di sepanjang konsep "memulai", dan menjaga semuanya tetap sederhana. Anda dapat membangun aplikasi raksasa di Redux tanpa mempelajari banyak konsep baru sama sekali. Sementara saya sendiri adalah orang yang dapat diamati redux, saya telah melihat ratusan ribu baris aplikasi kode menggunakan Thunk tanpa masalah (dan saya telah melihat aplikasi kecil membuat kereta api dengan thunks). Memperkenalkan sangat sedikit konsep "inti" dan menunjukkan bagaimana konsep tersebut dapat diterapkan pada banyak konsep sangat membantu.

"Semua boilerplate harus dikurangi berapa pun biayanya" adalah masalah dengan komunitas rekayasa perangkat lunak secara keseluruhan akhir-akhir ini ... itu lebih sulit untuk ditangani.

Sejak awal perhatian utama saya dengan redux adalah bahwa saya membaca atau menulis kode, saya harus melompat di antara file N, logika b/c dari bagian UI tunggal tersebar di seluruh basis kode antara tindakan, jenis tindakan, dan beberapa reduksi. Saya sangat suka bahwa saya dapat menjangkau bagian mana pun dari pohon status dari setiap tempat di UI dan saya dapat mengubah bagian yang berbeda dari status sebagai respons terhadap satu tindakan (alasan utama mengapa saya menggunakan redux), tetapi semakin banyak bagian dari keadaan yang saya ubah sebagai respons terhadap satu tindakan, semakin logika saya kabur. Saya tidak bisa begitu saja membaca atau menulis apa yang terjadi ketika pengguna melakukan ini atau itu. Tapi yang saya inginkan bisa digambarkan seperti ini:

// meta code
dispatch(ACTION);

onAction = {
  ACTION: [
    // handler 1: hide spinner here,
    // handler 2: change status there,
    // handler 3: update entity
  ],
};

Pada akhirnya saya mendapatkan redux-interactions + redux-tree dan saya cukup senang dengan sejauh ini.

Pendekatan dalam proyek kami saat ini:

catatan, akan sangat berbeda tergantung pada persyaratan aplikasi :) setelah kami menambahkan pembaruan objek waktu nyata, mungkin kisah atau pengamatan akan memberikan manfaat lebih dari thunk/janji

• redux-thunk
• janji middleware
• "pembungkus api" kami, yang merupakan pembungkus di sekitar aplikasi bulu klien, service(name, method, ...opts) yang merupakan pembuat tindakan dengan payload menjadi janji untuk memanggil API kami (yaitu, middleware janji mengambilnya dan mengirimkan x_FULFILLED , x_PENDING , dan x_REJECTED ). juga bisa menimpa nama tindakan untuk ini.

Pertama-tama kita menggunakan componentDidMount() untuk memanggil API kita, menyimpan data dalam status komponen. Namun, kami menggunakan pembungkus api kami untuk ini, yang berarti suatu tindakan masih dikirim (dan dicatat oleh middleware logger, termasuk meta yang merupakan info permintaan), dan jika kami ingin melakukan refactor untuk menggunakan toko untuk komponen itu, semua yang kami butuhkan to adalah menambahkan peredam yang mendengarkan aksi. Kita mulai dengan menggunakan status lokal saja, dan refactor menjadi redux ketika status komponen itu perlu diakses/dimodifikasi dari komponen lain. Karena itu, saya melihat daya tarik menggunakan redux di mana-mana, karena menyediakan jejak kertas untuk semuanya. Mengingat waktu tim dan aplikasi kami saat ini, itu tidak bermanfaat bagi kami atm.

Saya telah bermain dengan redux-saga sedikit, tetapi karena aliran async kami yang paling rumit adalah login/logout, yang berfungsi (dan kode tidak terlalu rumit), tidak banyak alasan besar untuk beralih (tetapi mungkin layak untuk pengujian alasan - iterable + mock adalah cara yang bagus untuk menguji). redux-observable Saya tidak melihat manfaat langsung kecuali yang dapat diamati itu sendiri memberikan manfaat, misalnya, jika Anda ingin mengklik dua kali acara dengan baik.

Kami telah sedikit menjauh dari boilerplate dengan memiliki fungsi pabrik kami sendiri untuk mengembalikan reduksi, dan memiliki reduksi pesanan kami sendiri yang lebih tinggi di atas fungsionalitas khusus (misalnya peredam di atas "paginator" sehingga konten diberi halaman tetapi dapat memiliki kustom tindakan untuk memodifikasi item).

Apa yang menurut saya perlu dilakukan adalah tutorial raksasa yang bekerja dari aplikasi reaksi dasar, mendemonstrasikan masalah yang muncul dengan komunikasi antar-komponen, kemudian memperkenalkan redux, lalu melanjutkan, menunjukkan masalah yang terjadi dalam situasi tertentu, dan bagaimana mereka bisa dibantu dengan redux-x . Artinya, panduan untuk kapan dan apa yang harus digunakan. Pasti ada beberapa posting blog yang ada di luar sana dengan diskusi ke arah ini.

Yang juga relevan adalah ringkasan saya yang saya buat untuk pola yang digunakan di gothinkster/react-redux-realworld-example-app

Kebanyakan orang yang saya kenal yang menggunakan redux banyak, akhirnya pindah dari redux-thunk karena mereka merasa tidak skala dengan baik

Saya mengerti apa yang Anda katakan, tetapi inilah kekhawatiran saya yang lain: kami melihat semakin banyak bukti anekdotal bahwa sekelompok besar pengembang JS bahkan belum menggunakan _arrow functions_ dan fitur dasar ES(6|2015) lainnya , karena kurangnya pemahaman, intimidasi, dll. Mengharapkan orang-orang yang ingin memulai dengan Redux, dan siapa yang dapat mengambil manfaat dari mempelajari _patterns_ yang diperkenalkan Redux, untuk mempelajari observables atau generators, apakah saya pikir mungkin terlalu banyak bertanya?

Redux-thunk juga sedikit rumit dalam arti bahwa middleware redux pada umumnya membengkokkan otak Anda, tetapi setidaknya hanya fungsi/panggilan balik, yang mudah diambil jika Anda menulis JS sama sekali. Saya sangat menyukai gagasan memiliki paket lengkap alat terkait untuk memulai, tersedia melalui satu unduhan, bahkan jika itu disebut sebagai "belajar-redux" alih-alih "praktik terbaik-selalu-redux". Mirip dengan bagaimana create-react-app membutuhkan tweaking saat Anda mempelajari semua hal yang diaturnya untuk Anda, ini dapat mendorong tweaking Anda sendiri, mungkin menunjukkan cara mengonversi pengaturan redux-thunk sederhana menjadi menggunakan saga, dll. sebagai bentuknya sendiri dari "mengeluarkan" ...

Hanya beberapa pemikiran.

Saya mengerti apa yang Anda katakan, tetapi inilah kekhawatiran saya yang lain: kami melihat semakin banyak bukti anekdotal bahwa sekelompok besar pengembang JS bahkan belum menggunakan fungsi panah dan fitur dasar ES (6|2015) lainnya. , karena kurangnya pemahaman, intimidasi, dll. Mengharapkan orang-orang yang ingin memulai dengan Redux, dan yang dapat mengambil manfaat dari mempelajari pola-pola yang diperkenalkan Redux, untuk pertama-tama mempelajari yang dapat diamati atau generator, apakah saya pikir mungkin terlalu banyak bertanya?

Bingo! Kami berada di lingkungan di mana BANYAK orang baru mengenal JS (atau mereka "tahu" JS, tetapi itu bukan spesialisasi mereka, dan mereka mulai dari ujung yang dalam). Terutama jika orang-orang itu adalah insinyur perangkat lunak berpengalaman dari ekosistem lain (java, rails, dll), mereka akan dengan cepat mencoba dan menerapkan konsep yang mereka ketahui sebelum mempelajari yang tidak mereka ketahui, dan itu tidak akan berhasil dan mereka terjebak. Saya tidak tahu apa cara terbaik untuk meyakinkan orang untuk mendapatkan pemahaman mendalam tentang JS sebelum melompat ke dalam pola desain UX fungsional.

Perhatikan bahwa dokumen Redux memang memiliki bagian tentang Mengurangi Boilerplate bagi Anda yang membaca yang mencari sesuatu sekarang dan tidak ingin mengadopsi seluruh perpustakaan di atas Redux.

Kita harus sedikit berhati-hati tentang diskusi ini dan menyadari bahwa ini mungkin telah banyak ditumbangkan. Tim Redux telah mendengar, mempertimbangkan, dan menolak banyak hal yang mungkin akan diusulkan di sini. Sangat mungkin tidak ada yang keluar dari diskusi ini jika kita hanya bertengkar tentang hal-hal yang sudah dibahas.

Karena itu, saya pikir itu ide yang bagus untuk berbicara tentang cara membuat kerangka kerja lebih mudah diakses oleh semua orang (baru dan berpengalaman).

Apa pun yang Anda usulkan untuk mengurangi boilerplate harus sedemikian rupa sehingga memungkinkan untuk kembali ke hal-hal di bawah abstraksi kapan pun diperlukan. Tidak menyenangkan untuk mengadopsi abstraksi hanya untuk menjatuhkannya nanti untuk kembali ke hal-hal tingkat yang lebih rendah karena Anda memerlukan satu hal tambahan yang tidak dipikirkan oleh penulis abstraksi.

Kurva pembelajaran redux bisa curam, tetapi begitu Anda memahami konsep, kebutuhan untuk
lapisan abstraksi sering hilang

Saya bertanya-tanya, jika ini masalahnya, bagian mana dari Redux yang kami sarankan untuk ditingkatkan? Bagian apa yang akan Anda hapus atau abstrakkan sehingga Anda tidak perlu segera menambahkannya kembali?

Ini adalah diagram dari seluruh siklus reaksi/redux yang saya buat untuk ceramah di tempat kerja sekitar setahun yang lalu:

Ada beberapa bagian dari ini, tetapi saya tidak dapat membayangkan Redux bekerja dengan baik tanpa salah satu dari mereka. Wadah kadang-kadang agak mengganggu, tetapi jika Anda menghapusnya, Anda sangat menggabungkan logika tampilan Anda dengan tata letak data Anda. Jika Anda menghapus tindakan, pada dasarnya Anda MVC lagi yang kehilangan gunanya menggunakan Redux di tempat pertama. "Tampilan" dalam diagram itu hampir tidak ada karena dapat dimodelkan hanya sebagai fungsi yang berlangganan toko dan merender komponen reaksi.

Saya tidak berpikir ada banyak boilerplate untuk dihapus dalam kerangka keseluruhan itu sendiri. Mungkin Anda mengacu pada boilerplate di masing-masing bagian kerangka kerja seperti pembuat tindakan, reduksi, atau wadah. Dalam hal ini, tips dari halaman Reducing Boilerplate yang disebutkan di atas sudah membahas sebagian besar hal tersebut. Kami tidak membutuhkan apa pun di atas itu untuk membuatnya "lebih baik". (Catatan: Bukannya saya tidak terbuka untuk menambahkan sesuatu untuk membuat segalanya lebih baik, saya hanya belum melihatnya.)

Mungkin ini bukan masalah pengurangan boilerplate tetapi masalah peningkatan pendidikan Redux. Jika kerangka kerja sulit untuk di-grok untuk pemula, kami mungkin perlu meningkatkan dokumen Redux dan membuatnya lebih mudah diakses. Mungkin beberapa tip pengurang boilerplate perlu diiklankan lebih agresif di dokumen.

Mengurangi jumlah langkah yang diperlukan (boilerplate) tidak selalu menyelesaikan masalah. Untuk menekankan poin saya sejak awal posting saya, Anda tidak ingin menulis abstraksi yang akan dibuang karena Anda tidak memikirkan setiap cara yang diperlukan orang untuk menggunakannya.

Beberapa diskusi yang bagus sejauh ini. Biarkan saya memberikan beberapa contoh cepat dari keluhan umum terkait "boilerplate" yang saya lihat:

• "Mengapa saya harus menulis fungsi 'pencipta tindakan' hanya untuk segera mengembalikan objek?"
• "Saya harus menyentuh SOOO banyak file hanya untuk menambahkan fitur baru yang sederhana! Juga, saya terus mengulangi nama yang sama berulang-ulang untuk konstanta dan nama fungsi dan..."
• "Mengapa saya memerlukan hal-hal 'middleware' ini hanya untuk melakukan panggilan AJAX?"
• "Mengapa saya harus menggunakan pernyataan switch untuk semuanya?"
• "Mengapa saya membutuhkan benda dispatch ? Mengapa saya harus membungkus semua fungsi ini untuk membuatnya bekerja?"

Dan beberapa contoh spesifik dari jenis komentar ini:

• Menerapkan Redux itu membosankan.
• Pengaturan Redux minimal
• Jumpstate README dan Jumpstate + Redux + CRA - tidak diperlukan pengiriman atau pembuat tindakan!

Dan untuk segera membuang beberapa tanggapan terhadap masalah "boilerplate" tersebut: dari lima kategori yang terdaftar, hanya "penggunaan dispatch " yang sebenarnya _diperlukan_. Untuk sisanya:

• Anda tidak _memiliki_ untuk menggunakan pembuat tindakan, tetapi ini adalah praktik yang baik untuk konsistensi (per posting saya Idiomatic Redux: Mengapa menggunakan pembuat tindakan? )
• Anda tidak _memiliki_ untuk memiliki file yang sepenuhnya terpisah untuk pembuat tindakan, konstanta tindakan, dan reduksi. Pola "bebek" adalah pendekatan populer untuk menyatukan semuanya dalam satu file. Itu memang memiliki kelemahan "menyembunyikan" kemampuan untuk membuat banyak reduksi mendengarkan satu tindakan. Redux pada akhirnya tidak peduli apa struktur file Anda.
• Anda _can_ melakukan pekerjaan async di luar Redux sepenuhnya, seperti dalam sebuah komponen. Tapi, sesuai deskripsi Dan di Mengapa kita membutuhkan middleware untuk aliran async di Redux? , biasanya baik untuk mengekstrak logika itu di luar komponen, dan middleware menyediakan "celah" untuk melakukan pekerjaan asinkron saat memiliki akses ke toko Redux.
• Anda pasti _tidak_ harus menggunakan pernyataan switch di reduksi, itu hanya cara paling "jelas" untuk menangani banyak nilai untuk variabel tertentu. Tabel pencarian, pernyataan if/else, dan hal lain yang Anda inginkan baik-baik saja (per FAQ: Apakah saya harus menggunakan pernyataan switch? )
• Anda _do_ harus benar-benar memanggil store.dispatch() untuk membuat sesuatu yang berguna terjadi - itulah keputusan desain dasar Redux. Mengikat pembuat tindakan memungkinkan untuk menyebarkannya ke komponen anak yang tidak terhubung dan tetap mengirimnya kapan pun fungsi dipanggil.

Jadi secara keseluruhan, hampir tidak ada masalah "boilerplate" ini yang _diperlukan_. Ini adalah kombinasi contoh dari dokumen dan "praktik pemrograman yang baik" seperti kode de-duplikasi dan pemisahan masalah.

Saya pikir pertanyaan yang diajukan oleh @markerikson benar-benar adil dan saya telah menanyakannya sendiri di beberapa titik di masa lalu juga.

Redux dalam arti tertentu perpustakaan "tingkat rendah" untuk pemodelan data. Seperti perpustakaan tingkat rendah lainnya, ini memaparkan banyak hal yang dapat Anda abstraksi dengan mudah untuk menjelaskan sebagian besar kasus. Saya pikir alasan @gaearon awalnya tidak melakukan itu karena dia ingin menjaga perpustakaan sekecil dan sefleksibel mungkin. Berkat keputusan itu, kami dapat membangun banyak hal berbeda di atas Redux tanpa perlu memiliki semuanya di inti Redux.

Mungkin kita harus mempertimbangkan bahwa jalan yang benar mungkin untuk mengembangkan dan menstabilkan perpustakaan yang baik di atas Redux (seperti Jumpstate?). Kami mulai dengan mengajari orang-orang itu, dan kemudian memberi mereka jalur mudah untuk menggunakan Redux secara langsung saat mereka membutuhkannya.

Saya tidak berpikir Redux membutuhkan lebih banyak lagi dalam basis kode intinya dan saya tidak melihat bagian mana pun darinya yang perlu diabstraksikan secara permanen. (Jika Anda melakukannya, beri tahu saya :smile:) Menurut pendapat saya, tidak banyak keuntungan dengan menambahkan atau menghapus sesuatu dari inti Redux.

Meningkatkan perpustakaan ke titik di mana itu stabil dan cukup fleksibel untuk digunakan semua orang mungkin merupakan pilihan yang lebih baik. Seperti yang Anda katakan, tidak banyak "boilerplate" yang sebenarnya diperlukan , jadi mari kita singkirkan itu di perpustakaan di atas Redux daripada memodifikasi Redux itu sendiri.

Contoh dari hal ini terjadi di komunitas lain dalam bahasa pemrograman Rust. Ada perpustakaan IO non-blocking untuk bahasa pemrograman Rust yang disebut "mio" . Ini berfokus pada menjadi kecil dan tingkat rendah seperti yang dilakukan Redux. Masalahnya, hampir tidak ada yang menggunakannya secara langsung karena itu akan sangat keras dan penuh dengan boilerplate. Kebanyakan orang menggunakan perpustakaan lain yang disebut tokio yang dibangun di atas mio dan membuatnya sangat berguna dan ergonomis. Dengan cara ini, siapa saja yang membutuhkan pipa dari mio dapat menggunakannya secara langsung, tetapi siapa pun yang hanya ingin membuat sesuatu dengan cepat dapat menggunakan tokio.

Kita harus mengadopsi model serupa.

Untuk memperluas beberapa komentar @sunjay :

Ada komentar baru-baru ini di #775 yang menurut saya menangkap semuanya dengan baik:

Redux adalah kerangka kerja generik yang memberikan keseimbangan struktur yang cukup dan fleksibilitas yang cukup. Dengan demikian, ini menyediakan platform bagi pengembang untuk membangun manajemen status yang disesuaikan untuk kasus penggunaan mereka, sambil dapat menggunakan kembali hal-hal seperti debugger grafis atau middleware.

Jadi ya, Redux adalah "hanya sebuah pola" dalam banyak hal. Pustaka inti benar-benar lengkap fitur - satu-satunya perubahan semi-rencana yang nyata adalah hal-hal seperti restrukturisasi penambah yang diusulkan ( #1702, #2214 ), dan mungkin membuat combineReducers lebih fleksibel ( #1768 , #1792 , dll ).

Hampir dua tahun telah berlalu sejak Redux dibuat, dan kami sekarang memiliki ide yang cukup bagus tentang bagaimana orang menggunakannya. Sebagai salah satu contoh, @jimbolla mengumpulkan daftar semua kegunaannya . Saya masih penggemar berat kesederhanaan dan fleksibilitas Redux, tetapi saya ingin melihat beberapa abstraksi idiomatik di atas Redux yang akan menyederhanakan penggunaan umum dan memecahkan masalah bagi orang-orang.

Satu set topik semi-terkait lainnya, dan sesuatu yang saya minati secara pribadi, adalah gagasan "logika/komponen yang dienkapsulasi" (per "frontend yang dapat diskalakan dengan Elm/Redux" taman bermain @slorber ), dan "plug -and-play Redux setup" (seperti yang terlihat dalam eksperimen seperti https://github.com/brianneisler/duxtape/issues/1 , https://github.com/jcoreio/redux-features/issues/7 , dll). Pengaturan status dan aplikasi global sangat bagus untuk beberapa kasus penggunaan, tetapi tidak untuk kasus lain.

Sebagai poin terkait yang menarik, @toranb telah melakukan beberapa pekerjaan hebat membuat pembungkus Ember untuk Redux di https://github.com/ember-redux/ember-redux . Dunia Ember _benar-benar_ menjadi "konvensi atas konfigurasi", dan karenanya ember-redux menyiapkan konfigurasi toko default yang masuk akal, termasuk redux-thunk dan semacamnya. Beberapa jenis pendekatan seperti itu mungkin bisa membantu.

Jadi ya, saya agak membuang banyak pemikiran yang berbeda di sini, tetapi mereka terkait dalam berbagai cara. Secara keseluruhan, saya ingin menurunkan hambatan untuk belajar dan menggunakan Redux, dan memungkinkan kasus penggunaan yang lebih canggih di seluruh papan.

Redux adalah API umum, bukan khusus. Ini membuatnya lebih bertele-tele, sementara juga mencakup lebih banyak kasus. Kekuatannya ada dalam perangkat lunak yang kompleks, sedangkan proyek baru atau sederhana apa pun ini berada di luar cakupan kebutuhan.

Namun Anda dapat membangun spesialisasi di atas API umum. Misalnya, saya menggunakan https://github.com/acdlite/redux-actions yang mengurangi boilerplate untuk kasus umum. Saya masih menggunakan kekuatan penuh redux dan hanya memiliki antarmuka itu tidak akan cukup untuk kebutuhan saya.

Masalah lainnya adalah dengan orang-orang baru yang belum pernah mengalami rasa sakit dari aplikasi yang sangat rumit bertanya-tanya apa gunanya. Yah, bagi mereka mereka mungkin bahkan tidak boleh menggunakan redux sampai mereka mengalami rasa sakit itu, tetapi seri egghead Dan dapat menendang mereka melewati titik ini dengan cukup mudah.

https://egghead.io/courses/getting-started-with-redux
https://egghead.io/series/building-react-applications-with-idiomatic-redux

Referensi: Spektrum abstraksi: https://www.youtube.com/watch?v=mVVNJKv9esE

Seperti yang disebutkan - redux-actions cukup baik dalam menghapus beberapa boilerplate, menghapus konstanta dari persamaan dengan melampirkan .toString adalah ide yang sangat rapi yang saya suka, namun saya lebih suka menulis logika ini sendiri daripada menggunakan redux-actions sendiri, tapi itu pilihan pribadi untuk menjaga kode saya lebih kecil.

Imho harus ada mekanisme bawaan ( argumen panggilan balik subscribe ?) untuk mengamati aliran tindakan yang dikirim (saya tahu itu bisa dilakukan di middleware, tapi itu kasus penggunaan yang cukup membatasi, karena tidak dapat digunakan luar, yaitu dengan komponen atau connect )

Saya sering kali mengajar redux kepada orang lain dan itu bisa sangat menakutkan karena alasan berikut:

• Banyak bagian yang bergerak: simpan, status, reduksi, pembuat tindakan, tindakan, tindakan asinkron, middleware, komponen yang terhubung
• Perpustakaan. Untuk aplikasi sederhana yang berbicara dengan REST API yang Anda butuhkan: redux, react-redux, redux-thunk (atau lainnya) + pustaka tambahan jika Anda ingin menguji sesuatu
• Jumlah tempat Anda harus memasukkan kode (lihat _bagian bergerak_)

Saya pikir redux adalah perpustakaan hebat yang masuk akal dalam dirinya sendiri dan saya pikir itu memiliki abstraksi yang hebat dan sangat skalabel bila digunakan dengan benar. Saya juga menghargai bahwa redux dapat digunakan dengan perpustakaan UI apa pun tetapi berpikir bahwa dalam sebagian besar kasus itu akan digunakan dengan reaksi.

Secara umum saya percaya banyak frustrasi datang dari banyak bagian yang bergerak.

Berikut adalah beberapa pemikiran yang saya miliki. Semuanya bisa dibangun di atas redux sehingga bisa tetap apa adanya.

• Sediakan perpustakaan seperti reaksi redux yang juga dilengkapi dengan dukungan untuk tindakan asinkron bawaan.
• Banyak tindakan async berbicara dengan REST API jadi sediakan middleware idiomatis untuk itu
• Tulis komponen cerdas sebagai komponen aktual alih-alih menggunakan koneksi. Mereka kemudian dapat membuat komponen bodoh dalam metode render
• Tetapkan tata letak file yang dapat diskalakan untuk _container components_, _smart components_, _dumb components_, _action creators_ dan _reducers_.
• Berikan _redux-cli_ untuk menghasilkan kode misalnya redux action loadUsers
• Standarisasi pada lapisan async seperti redux-saga atau redux-observable dan sertakan dalam dokumen (Akan menyenangkan memiliki _one_ tempat untuk berkonsultasi untuk sebagian besar masalah redux)
• default ke fitur bahasa yang diperluas (mis. dekorator (@koneksi)) atau TypeScript untuk membuat hal-hal kurang bertele-tele khususnya mapStateToProps dan mapDispatchToProps (mobx membutuhkan dekorator dan sintaksnya mudah)

T

Setuju, redux-actions adalah contoh yang baik dari beberapa abstraksi sederhana yang menghapus boilerplate.

Izinkan saya menanyakan ini: Create-React-App memiliki paket react-scripts , yang memiliki konfigurasi Babel dan Webpack bawaan, dan dilengkapi dengan sekumpulan bawaan bawaan yang masuk akal. Seperti apa paket redux-scripts yang sesuai?

Saya setuju dengan beberapa komentar (negatif) lainnya tentang redux-thunk . Saya tidak akan merekomendasikannya kepada pemula (saya mungkin tidak akan merekomendasikannya sama sekali lagi):

1. Sepertinya keajaiban untuk memulai.
2. Itu tidak benar-benar menghilangkan banyak boiler-plate. Mengingat proses async yang lebih kompleks, harus mendapatkan dispatch dari props dan meneruskannya berhasil menjadi hanya sebagian kecil dari kode.
3. Ini menghasilkan pembuat tindakan yang tidak dapat Anda buat bersama menjadi alur kerja yang lebih besar.
4. Poin terakhir yang saya tidak dapat mengartikulasikan dengan baik tentang hal itu membuat gaya redux menjadi lebih dari kerangka kerja daripada perpustakaan: Anda mengandalkan kerangka kerja untuk memanggil kode Anda, daripada Anda memanggil ke perpustakaan.

Kami menggunakannya cukup banyak dalam aplikasi React-Native, dan itu sebagian besar berguna, tetapi kami mengalami kesulitan menyusun tindakan bersama-sama (pikirkan "memuat profil setelah login berhasil"), karena pembuat tindakan redux-thunk secara efektif mengembalikan void (mis. tidak memiliki apa pun seperti janji untuk digunakan untuk mengurutkan tindakan selanjutnya).

Itu cenderung mendorong orang untuk berpikir bahwa "satu-satunya cara untuk melakukan sesuatu adalah dengan dispatch segera dari event handler/callback React". Dan karena kami menggunakan connect dari react-redux dan sangat bergantung pada mapDispatchToProps , kami cenderung lupa bahwa event handler kami bisa saja menjadi fungsi biasa.

(perhatikan bahwa aplikasi di atas sebagian besar ditulis awal tahun lalu, dan kami tidak benar-benar mengikuti apa yang terjadi di ekosistem Redux yang lebih besar, jadi mungkin sudah ketinggalan zaman).

@bodhi : tanpa menyinggung _terlalu banyak, saya tidak setuju dengan beberapa kesimpulan itu. redux-thunk panjangnya 11 baris, dan ada beberapa penjelasan bagus di luar sana seperti "Apa itu Thunk?" . Thunks _are_ dapat dikomposisi hingga _some_ , dan saya pikir umumnya lebih mudah untuk memberi tahu seseorang "tulis beberapa baris deklarasi fungsi ini, lalu buat panggilan AJAX Anda dan semacamnya di sini". Saya memiliki posting yang membahas beberapa dari berbagai pengorbanan thunks (dan sampai batas tertentu saga) di Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability .

Saya setuju bahwa perlu ada cara _some_ "diberkati" atau "bawaan" untuk menangani efek samping di beberapa lapisan abstraksi hipotetis. Saga dan observable sama-sama bagus, _jika_ Anda mengerti cara menggunakannya. Saya hanya tidak tahu apakah itu pantas, mengingat bahwa tujuan potensial di sini adalah untuk memberikan jalur kemudahan untuk belajar dan menggunakan Redux.

Saya menemukan bahwa menggunakan redux-thunk bukan hanya tentang melakukan sesuatu secara tidak sinkron, tetapi juga melakukan sesuatu yang bergantung pada keadaan saat ini. Antarmuka yang sangat bersih, sederhana, dan mendorong penggunaan pembuat tindakan.

Bodhi: Mungkin sedikit di luar topik, tetapi hanya berpikir mungkin perlu disebutkan bahwa pengiriman tidak kembali batal, itu mengembalikan hasil dari fungsi batin Anda. Jadi, jika Anda misalnya mengembalikan janji, Anda dapat dengan mudah mengaitkan tindakan bersama. Lihat bagian komposisi di readme:
https://github.com/gaearon/redux-thunk/blob/master/README.md

Selain itu saya hanya ingin mengucapkan terima kasih kepada komunitas karena telah mengadakan diskusi terbuka ini, sangat menarik untuk mendengar pemikiran dan ide semua orang.
Secara pribadi berpegang teguh pada thunks sejauh ini tetapi mencoba memisahkan dengan jelas "apa yang terjadi" dari "bagaimana keadaan harus berubah". Saya melihat beberapa contoh dalam kode kami di mana kami membuat kesalahan itu (menggunakan tindakan untuk memberi tahu reduksi apa yang harus dilakukan, alih-alih reduksi hanya bereaksi terhadap apa yang terjadi), jadi alangkah baiknya melihat beberapa perpustakaan yang entah bagaimana membuatnya lebih sulit untuk lakukan (belum dijual di saga).

Pada 19 Mar 2017, pukul 23:48, Bodhi [email protected] menulis:

Saya setuju dengan beberapa komentar (negatif) lainnya tentang redux-thunk. Saya tidak akan merekomendasikannya kepada pemula (saya mungkin tidak akan merekomendasikannya sama sekali lagi):

Sepertinya keajaiban untuk memulai.
Itu tidak benar-benar menghilangkan banyak boiler-plate. Mengingat proses async yang lebih kompleks, harus mendapatkan pengiriman dari alat peraga dan meneruskannya berhasil menjadi hanya sebagian kecil dari kode.
Ini menghasilkan pembuat tindakan yang tidak dapat Anda buat bersama menjadi alur kerja yang lebih besar.
Poin terakhir yang saya tidak dapat mengartikulasikan dengan baik tentang hal itu membuat gaya redux menjadi lebih dari kerangka kerja daripada perpustakaan: Anda mengandalkan kerangka kerja untuk memanggil kode Anda, daripada Anda memanggil ke perpustakaan.
Kami menggunakannya cukup banyak dalam aplikasi React-Native, dan itu sebagian besar berguna, tetapi kami mengalami kesulitan menyusun tindakan bersama-sama (pikirkan "memuat profil setelah login berhasil"), karena pembuat tindakan redux-thunk secara efektif mengembalikan kekosongan (mis. tidak ada yang seperti janji untuk digunakan untuk mengurutkan tindakan selanjutnya).

Itu cenderung mendorong orang untuk berpikir bahwa "satu-satunya cara untuk melakukan sesuatu adalah dengan segera mengirim dari event handler/panggilan balik React". Dan karena kami menggunakan connect from react-redux dan sangat bergantung pada mapDispatchToProps, kami cenderung lupa bahwa event handler kami bisa saja berupa fungsi biasa.

(perhatikan bahwa aplikasi di atas sebagian besar ditulis awal tahun lalu, dan kami tidak benar-benar mengikuti apa yang terjadi di ekosistem Redux yang lebih besar, jadi mungkin sudah ketinggalan zaman).

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

(maaf untuk melanjutkan garis singgung, tapi...)

perlu disebutkan bahwa pengiriman tidak mengembalikan batal, itu mengembalikan hasil fungsi batin Anda.

Heh, bagus! Kurasa aku tidak pernah melihat terlalu dekat pada dokumentasi sebelum mencoba menemukan cara lain untuk memecahkan masalah kita.

Satu hal yang paling berharga yang membuat Redux jauh lebih mudah bagi saya adalah memperlakukan tindakan sebagai peristiwa dan bukan perintah . Ini sepenuhnya menghilangkan perjuangan untuk memutuskan bagaimana merancang tindakan dan apa yang harus dimasukkan ke dalamnya.

Komponen tidak perlu tahu bagaimana interaksi pengguna harus mempengaruhi negara, mereka hanya memberitahu dunia luar apa yang terjadi di dalamnya, misalnya "tombol X diklik". Saat menggunakan tindakan sebagai perintah, Anda secara efektif memperkenalkan pengikatan dua arah antara komponen dan status.

Pereduksi tidak terikat pada komponen, mereka mewakili status aplikasi dan bukan status komponen , dan mereka adalah satu-satunya pihak yang benar-benar mengetahui bagaimana status berubah. Tidak ada hambatan kognitif dalam menangani tindakan tunggal dalam banyak reduksi karena suatu tindakan bukanlah pernyataan "apa yang harus dilakukan dengan keadaan" .

Ini juga menghilangkan kasus apa pun untuk mengirim beberapa tindakan secara sinkron.

Kasus apa pun untuk mengirim satu tindakan dari beberapa tempat juga hilang. Anda dapat menyimpan pembuat tindakan di dekat komponen yang memudahkan untuk melacak komponen yang mengirimkan tindakan.

Dengan melihat log tindakan di DevTools, Anda dapat melihat riwayat lengkap tentang apa yang terjadi di dalam aplikasi Anda dan mudah untuk melihat irisan status konkret yang terpengaruh oleh tindakan tersebut. Sejarah tetap sesingkat mungkin.

Pendekatan berbasis tarikan ini membuat aliran data benar - benar redux-saga atau redux-observable .

@aikoven meskipun saya sangat setuju dengan ini (pasti ada banyak diskusi di masa lalu yang membandingkan redux dengan sumber acara), apa yang Anda lakukan dengan hal-hal seperti FETCH_USER , yang sangat umum untuk dilihat (dan sesuatu yang harus diselesaikan). Itu tampaknya lebih "seperti perintah" daripada "seperti acara".

@blocka Selalu ada beberapa acara yang menghasilkan permintaan jaringan. Permintaan itu sendiri dapat dibungkus dengan tindakan FETCH_USER_STARTED dan FETCH_USER_DONE / FETCH_USER_FAILED , yang merupakan bagaimana hasil permintaan berakhir di status.

👍 untuk redux-actions

Apa yang saya juga suka tentang itu selain hanya mengurangi boilerplate, rasanya seperti perpanjangan redux yang sangat alami. Untuk sesuatu seperti jumpstate Saya merasa implementasinya akan sedikit lebih jauh, dan sekarang saya harus mempelajari dua hal, bukan satu.

Jadi maksud saya adalah, plugin apa pun yang kami tambahkan untuk mengurangi pelat boiler akan terasa sangat mirip dengan bekerja dengan redux meskipun yang memiliki API yang lebih sedikit bertele-tele.

Banyak pelat ketel adalah pelat ketel yang sama dengan yang Anda miliki di lingkungan apa pun. Ketika Anda menemukan duplikasi, kami biasanya menyelesaikannya dengan abstraksi khusus. Abstraksi ini, sangat sering, tidak berguna di luar proyek Anda saat ini, dan "peluru perak" tidak mungkin ada. Persyaratan setiap proyek berbeda.

Hal yang sama dengan redux. Jika Anda setuju bahwa Anda memerlukan tindakan FETCH_X_STARTED , dan pembuat tindakan fetchX() , dan peredam untuk menanganinya, dll., jangan ragu untuk membuat abstraksi Anda sendiri!

Menyalahkan redux untuk boilerplate seperti menyalin dan menempelkan semua kode Anda, dan kemudian menyalahkan javascript karena memiliki terlalu banyak boilerplate.

Saya menemukan bahwa menggunakan redux-thunk bukan hanya tentang melakukan sesuatu secara tidak sinkron, tetapi juga melakukan sesuatu yang bergantung pada keadaan saat ini. Antarmuka yang sangat bersih, sederhana, dan mendorong penggunaan pembuat tindakan.

Menggunakan redux-thunk untuk kode sinkron bukanlah ide bagus dan harus disebutkan dalam dokumen.
Jika Anda membuat banyak fungsi bersama-sama, Anda tidak yakin bahwa alur pengiriman tidak bergantung pada pesanan sehingga lebih sulit untuk beralasan dan menguji.

Tampaknya lebih baik bagi saya untuk memiliki pembuat tindakan murni dan cukup menggunakan kumpulan tindakan untuk modifikasi keadaan yang lebih kompleks. Dengan cara ini Anda hanya memiliki fungsi murni untuk diuji.

Saya merekomendasikan posting blog ini untuk mendapatkan pemahaman yang lebih baik: http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/

@Machiaweliczny terima kasih atas artikelnya. Saya kira pertanyaannya kepada saya lebih tentang di mana Anda akhirnya meletakkan logika bisnis Anda (seperti yang dibahas di https://medium.com/@jeffbski/where -do-i-put-my-business-logic-in-a- react-redux-application-9253ef91ce1#.3ce3hk7y0). Anda tidak mengatakan bahwa alur pengiriman Anda (thunk, epic, saga, apa pun), tidak boleh memiliki akses ke status aplikasi saat ini, bukan?

@dfbaskin

Perlu diingat bahwa Redux bukan pengembangan berbasis domain. "Logika bisnis" adalah masalah yang jauh lebih kabur di sini, dan lebih pada "tanda tangan fungsi konsep apa yang paling sesuai dengan logika yang saya coba terapkan". "Logika bisnis" Anda tersebar di seluruh pemilih, reduksi, pembuat tindakan, dan "pengatur" (apakah kami memiliki kata yang lebih baik untuk ini?) Tergantung pada apa yang Anda butuhkan.

Peredam, menjadi (state, action) => state adalah tempat "logika yang bergantung pada keadaan" umumnya seharusnya. Dan tentu saja, dalam hal-hal seperti Arsitektur Elm, semua logika tersebut ada dalam fungsi "perbarui" (setara dengan peredam kami).

Sayangnya di Redux, peredam hanya dapat menangani logika sinkron. Jadi "logika bisnis" asinkron yang bergantung pada keadaan perlu mendapatkannya dari komponen melalui pengiriman (jika komponen memiliki info itu, yang tidak selalu), atau melalui konsep orkestra pilihan Anda (thunk, sagas, epic), yang memiliki akses ke negara untuk itu.

Jika bukan karena batasan peredam, tidak akan ada kebutuhan untuk itu. Anda benar-benar melihatnya ketika orang menggunakan redux-saga atau redux-observable: tindakan/pembuat tindakan mereka biasanya menjadi hampir sepele (dalam banyak kasus, plus atau minus beberapa normalisasi atau pemformatan), dan kisah/epik hampir "pereduksi alternatif" , pada itu Anda sekarang memiliki hal lain yang memiliki akses ke tindakan dan menyatakan dan mengembalikan "sesuatu", dan sebagai hasilnya kompleksitas peredam yang sebenarnya berkurang. Pereduksi dan orkestra sangat erat kaitannya (kadang-kadang terlalu dekat, dan tidak bagus untuk memiliki 2 konstruksi yang dapat dipertukarkan separuh waktu ... tapi itulah yang kita miliki, mungkin juga menikmatinya)

@Machiaweliczny : sebagai penulis posting "Thunks on Thunks" itu, saya dapat meyakinkan Anda bahwa "hindari menggunakan thunks untuk pekerjaan sinkron" adalah _opposite_ dari apa yang saya coba katakan :)

Lebih banyak diskusi yang bagus, tapi kita mulai menyimpang sedikit dari topik. (Apakah itu gudang sepeda yang saya lihat di sana? :))

Biarkan saya menunjuk kembali ke pertanyaan awal:

• Seperti apa penggunaan Redux idiomatik dengan "less boilerplate"? Bagaimana cara kami memberikan solusi atas keluhan tersebut?
• Apa abstraksi yang mungkin dapat dibuat yang menyederhanakan proses pembelajaran dan penggunaan, tetapi tanpa benar-benar menyembunyikan Redux (dan diharapkan akan memberikan jalur migrasi/pembelajaran ke "dasar" Redux)?
• Berapa banyak dari ini yang dapat diselesaikan dengan dokumen yang ditingkatkan dalam beberapa cara?

Langkah konkrit apa yang bisa kita terapkan untuk mengatasinya?

Dalam ranah langkah-langkah jangka pendek yang tidak kontroversial, dapat ditindaklanjuti, saya akan mengatakan:

1) Buat toko lebih mudah dikonfigurasi (mungkin dengan konfigurasi default? Saya tidak tahu apakah ini masih terjadi, tetapi Elm dulu memiliki tipe "aplikasi pemula", dan tipe aplikasi biasa. Aplikasi pemula digunakan untuk aplikasi sederhana dan materi pelatihan untuk menutupi 90% kasus ketika orang baru belajar. Sampai hari ini, saya akui saya tidak dapat mengonfigurasi toko Redux dengan middlewares dasar (devtools, thunks) tanpa mencari dokumen untuk tanda tangan. Saya tidak berpikir banyak orang akan berpendapat bahwa pendatang baru perlu tahu cara mengkonfigurasi middlewares toko untuk mempelajari konsep inti Redux.

2) Ini mungkin sudah terjadi, pastikan menambahkan Redux dengan "toko pemula" di atas untuk membuat-bereaksi-aplikasi semudah mungkin, sehingga pendatang baru dapat memiliki dan menjalankan aplikasi Redux dalam 2 menit.

Saya pikir ini akan membuat kita sangat, sangat jauh.

Sunting: dengan aplikasi pemula, maksud saya bukan boilerplate aplikasi, melainkan "createStore" yang tidak dapat dikonfigurasi tetapi memiliki default yang masuk akal sehingga orang dapat mengimpor dan menyelesaikannya. Kemudian mereka dapat melanjutkan ke createStore "asli" ketika mereka telah melampauinya.

Kedengarannya seperti konsep yang cukup fantastis di sana.

Pada Senin, 20 Mar 2017 pukul 10:02 Francois Ward [email protected]
menulis:

Dalam ranah langkah-langkah jangka pendek yang tidak kontroversial, dapat ditindaklanjuti, saya akan mengatakan:

1.

Buat toko lebih mudah dikonfigurasi (mungkin dengan default
konfigurasi? Saya tidak tahu apakah ini masih terjadi, tetapi Elm dulu pernah
jenis "aplikasi pemula", dan jenis aplikasi biasa. Aplikasi pemula digunakan untuk
aplikasi sederhana dan dalam materi pelatihan untuk menutupi 90% kasus ketika orang-orang
hanya belajar. Sampai hari ini, saya akui saya tidak dapat mengonfigurasi toko Redux
dengan middlewares dasar (devtools, thunks) tanpa mencari dokumen untuk
tanda tangan. Saya tidak berpikir banyak orang akan berpendapat bahwa pendatang baru membutuhkan
untuk mengetahui cara mengonfigurasi middleware toko untuk mempelajari inti Redux
konsep.
2.

Ini mungkin sudah terjadi, pastikan menambahkan Redux dengan yang di atas
"toko pemula" untuk membuat-reaksi-aplikasi semudah mungkin, jadi pendatang baru
dapat memiliki dan menjalankan aplikasi Redux dalam 2 menit.

Saya pikir ini akan membuat kita sangat, sangat jauh.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/reactjs/redux/issues/2295#issuecomment-287806663 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AFUmCQYkUwjkCugevDBWC8TOu0HhWJTnks5rnqMWgaJpZM4MhnVF
.

Modul kami menggunakan combineReducers sehingga setiap irisan status dalam modul memiliki peredam khusus untuknya (saya percaya pendekatan ini diuraikan di bagian Penyusunan Struktur pada dokumen alias "pengurang irisan"). Ini membuat segalanya lebih mudah untuk dipikirkan karena pernyataan switch jauh lebih kecil. Itu juga memungkinkan reduksi umum muncul di seluruh basis kode kami. Pereduksi paling sederhana identik di seluruh modul kecuali untuk jenis tindakannya, jadi kami dapat mengurangi boilerplate dengan memiliki fungsi pembantu (pabrik peredam?) yang membuat reduksi ini untuk kami berdasarkan jenis tindakan:

const { makeIndicator, makePayloadAssignor } from '../shared/reducers';

const searchModule = combineReducers({
  searching: makeIndicator(c.SEARCH),
  results: makePayloadAssignor(c.SEARCH_RESPONSE, [])
});

Mungkin mengidentifikasi pengurang irisan yang lebih umum seperti ini akan menjadi cara yang baik untuk meringankan masalah boilerplate, di mana mereka dapat berfungsi sebagai blok bangunan primitif untuk reduksi kami.

Ini adalah refactoring javascript dasar. Seperti yang saya katakan sebelumnya..."javascript" memiliki
banyak "boilerplate", sampai Anda menerapkan hal-hal seperti abstraksi ke kode Anda.

Redux hanyalah javascript. Tidak ada yang ajaib tentang itu.

Pada Senin, 20 Maret 2017 pukul 12:44, Markus Coetzee [email protected]
menulis:

Modul kami menggunakan combineReducers sehingga setiap status diiris menjadi
modul memiliki peredam khusus untuk itu (saya percaya pendekatan ini diuraikan
di bagian Structuring Reducers dari dokumen alias "slice
reduksi"). Ini membuat segalanya lebih mudah untuk dipikirkan karena sakelar
pernyataan jauh lebih kecil. Itu juga memungkinkan reduksi umum muncul
di seluruh basis kode kami. Pereduksi paling sederhana identik di seluruh modul
kecuali untuk jenis tindakan mereka, jadi kami dapat mengurangi boilerplate dengan
memiliki fungsi pembantu (pabrik peredam?) yang membuat reduksi ini untuk
kami berdasarkan jenis tindakan:

const { makeIndicator, makePayloadAssignor } dari '../shared/reducers';
const searchModule = combineReducers({
mencari: makeIndicator(c.SEARCH),
hasil: makePayloadAssignor(c.SEARCH_RESPONSE, [])
});

Mungkin mengidentifikasi pengurang irisan yang lebih umum seperti ini akan lebih baik
cara untuk meringankan masalah boilerplate, di mana mereka dapat berfungsi sebagai
blok bangunan primitif untuk reduksi kami.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/reactjs/redux/issues/2295#issuecomment-287820595 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AACourLpL5--NJiRzrWmKFJ31cl5DXJrks5rnqzxgaJpZM4MhnVF
.

Saya setuju dengan sebagian besar komentator yang mengatakan bahwa lebih baik menjelaskan pola redux umum daripada mengembangkan beberapa peredam boilerplate. Rekan tim saya dan saya mulai bekerja dengan redux 1,5 tahun yang lalu dan sebagian besar bingung tentang hal-hal yang paling sederhana: bahwa redux sebagian besar adalah sumber acara, bahwa tindakan yang sama dapat ditangani oleh beberapa reduksi, tindakan itu dapat berisi seluruh entitas bisnis tidak hanya id-nya , bahwa reduksi hanyalah fungsi dan Anda bebas melakukan apa pun yang Anda inginkan dengannya - menulis, membuat, membagi, dll. Kami membuat kesalahan umum - menggunakan tindakan sebagai perintah jarak jauh dan bertanya-tanya mengapa tidak menggunakan pemanggilan metode klasik; membuat middlewares besar dan menghindari redux-saga karena "generator terlalu rumit" (meskipun redux-saga hebat!), membuat file panjang dengan sakelar besar. Hal ini tentu saja karena kemampuan pemrograman yang biasa-biasa saja tetapi juga karena kurangnya informasi yang terstruktur. Dokumentasi hari ini jauh lebih baik, terima kasih banyak kepada pengelola!

Ini adalah topik yang sangat berharga di Redux sebagai perpustakaan.

Ini adalah refactoring javascript dasar. Seperti yang saya katakan sebelumnya..."javascript" memiliki
banyak "boilerplate", sampai Anda menerapkan hal-hal seperti abstraksi ke kode Anda.
Redux hanyalah javascript. Tidak ada yang ajaib tentang itu.

Sempurna, @blocka! Saya pikir pesan ini perlu disebarkan.

Redux merasa tidak biasa dan tidak biasa bagi orang-orang karena pendekatannya yang minimal. Minimal terasa aneh untuk "kerangka kerja" secara umum (kode minimal, prinsip minimal).

Beberapa orang terbiasa menulis kode "framework-y" daripada menulis JavaScript itu sendiri. Ketika pengembang menggunakan kerangka kerja, cara bawaan untuk melakukan sesuatu diharapkan secara implisit. Sedih sekali tapi benar.

Saya percaya Redux semakin mudah untuk memulai daripada sebelumnya, tetapi kita masih perlu menjelaskan kepada orang-orang untuk tidak mengharapkan Redux melakukan segalanya. @gaearon dengan jelas mengatakan ini sepanjang waktu, tetapi sayangnya orang terbiasa dengan kerangka kerja yang melakukan segalanya. Mengapa mereka harus termotivasi untuk mempelajari sesuatu yang "tidak banyak membantu"? Angular melakukan lebih banyak daripada Redux. Mengapa Redux? Jawabannya mungkin jelas bagi kita semua dalam masalah ini. Tapi apakah sudah jelas bagi pemula?

Saya menulis artikel singkat tentang itu kemarin: Jangan salahkan React atau Redux . Tentu saja saya bisa salah dalam semua ini.

Ada preseden untuk memiliki lapisan abstraksi di atas perpustakaan tingkat lanjut. Baru-baru ini, Tensorflow menghadirkan Keras sebagai abstraksi di atas API inti: http://www.fast.ai/2017/01/03/keras/.

Menggunakan TensorFlow membuat saya merasa tidak cukup pintar untuk menggunakan TensorFlow; sedangkan menggunakan Keras membuat saya merasa seperti jaringan saraf lebih mudah daripada yang saya sadari. Ini karena API TensorFlow bertele-tele dan membingungkan, dan karena Keras memiliki API ekspresif yang paling dirancang dengan cermat yang pernah saya alami. Saya terlalu malu untuk secara terbuka mengkritik TensorFlow setelah beberapa interaksi frustasi pertama saya dengan TensorFlow. Rasanya sangat kikuk dan tidak wajar, tetapi tentu saja ini adalah kegagalan saya.

Saya merasa itu adalah pengalaman serupa untuk sebagian besar timer pertama yang masuk ke Redux. Ganti Tensorflow dengan Redux dan Keras dengan Jumpstate . Redux sangat kuat, tetapi sebagian besar pengguna mungkin tidak memerlukan semua kontrol yang tersedia. Kemungkinan besar, mereka datang dari Angular atau diajarkan React + Redux di bootcamp atau dari menonton berbagai tutorial. Sementara Redux tidak perlu dibodohi untuk pengguna baru, itu juga bukan anti-pola untuk memberikan abstraksi yang lebih mudah yang mungkin dapat mencakup 80% kasus penggunaan potensial.

Kalian semua, jika redux baik-baik saja seperti itu, kita tidak akan melakukan percakapan ini. Terlepas dari apakah redux berguna atau terdengar secara struktural, orang masih merasa "buruk" saat pertama kali mempelajarinya. Perasaan ini valid.

Orang-orang yang berkomentar di utas ini semuanya adalah pakar redux -- tentu saja kami senang dengan redux; kami telah menginternalisasi filosofinya dan kami merasa nyaman membuat abstraksi kami sendiri untuk mengelola "boilerplate". Kami bukan audiens yang ingin dilayani oleh utas ini. Kita perlu memiliki beberapa empati untuk pengguna yang datang ke redux untuk pertama kalinya, bahkan mungkin datang ke pemrograman fungsional untuk pertama kalinya.

Sebagai contoh: inilah keluhan yang sering saya dengar tentang redux (yang menurut saya tidak disebutkan di atas): tidak cukup hanya menggunakan redux, Anda juga "perlu" menggunakan react-redux, redux-thunk, redux-actions, dll .

Apakah Anda benar-benar perlu menggunakan semua paket lain itu untuk menggunakan redux? Tidak.
Akankah sebagian besar pengguna redux akhirnya menggunakan beberapa atau semua paket tambahan itu? Ya.

Apakah jumlah paket dalam package.json penting? Tidak terlalu.
Apakah jumlah paket dalam package.json mempengaruhi perasaan orang? Sangat.

Sekarang, saya pikir adil untuk percaya bahwa redux itu sendiri harus tetap seperti itu, dan paket lain ( create-redux-app atau apa pun) harus menangani perakitan bersama. Tetapi kami memiliki masalah kompleksitas nyata di tangan kami dan itu tidak cukup untuk memberi tahu pengguna ke RTFM.

Terlepas dari apakah redux berguna atau terdengar secara struktural, orang masih merasa "buruk" saat pertama kali mempelajarinya. Perasaan ini valid

Sangat. Tapi tidak semua orang merasa seperti itu. Beberapa melakukannya. Ingatlah bahwa Anda tidak akan pernah mendengar dari orang yang tidak memiliki masalah. Anda hanya melihat orang-orang yang mengajukan pertanyaan kepada Anda, atau menekan stackoverflow/reactiflux. Dari mereka yang tidak pernah melakukannya, beberapa juga membutuhkan bantuan tetapi tidak tahu bagaimana memintanya...dan beberapa juga baik-baik saja, dan Anda tidak ingin memperburuk keadaan mereka...jika tidak, mereka akan melakukannya jadilah yang datang ke forum sebagai gantinya dan itu akan menjadi keuntungan nol bersih.

Redux tidak menjadi populer tanpa alasan. Banyak orang berpikir itu sangat bagus dan merekomendasikannya kepada orang lain :)

Sekarang, saya pikir adil untuk percaya bahwa redux itu sendiri harus tetap apa adanya, dan paket lain (buat-redux-app atau apa pun) harus menangani perakitan bersama.

Saya menyukai ide ini. Mungkin saja untuk mengatakan bahwa boilerplate yang ada sudah menyelesaikannya, tetapi React juga memiliki banyak boilerplate pada saat orang-orang mengeluh karena kewalahan dengan alat ketika mencoba masuk ke React. create-react-app adalah jawaban yang bagus untuk semua ini, karena telah menghilangkan banyak langkah bagi pemula untuk masuk ke React _itself_.

Tapi itu masih boilerplate di bawah tenda. Jadi, kita masih perlu mendorong orang untuk membeli ekosistem dan memperjelas bahwa Redux sendiri tidak berbuat banyak dalam hal desain . Tidak mungkin lari dari ekosistem jika Anda ingin menggunakan React atau Redux.

Saya tidak percaya bahwa memasukkan paket seperti redux-thunk di inti Redux adalah cara untuk pergi ke sini.

Hanya untuk kejelasan, jenis ide yang saya lemparkan bukan tentang benar-benar memasukkan hal-hal secara langsung ke dalam inti. Mereka secara hipotetis membuat semacam "konfigurasi pra-bangun" atau "lapisan abstraksi yang mudah digunakan" yang akan menjadi paket terpisah atau alat CLI atau sesuatu, lebih seperti create-react-app .

Saya pikir saya sebaiknya berpadu sebagai penulis Jumpstate/Jumpsuit.

TL; DR:
Redux sulit dipelajari dan sulit untuk dikonfigurasi/diintegrasikan karena levelnya sangat rendah. Komunitas dapat memperoleh manfaat dari redux api standar tingkat tinggi yang ditujukan pada kasus penggunaan 90% untuk memudahkan kurva pembelajaran dan bahkan beroperasi sebagai solusi untuk proyek yang lebih sederhana. Jumpstate sedang mencoba menyelesaikan ini, tetapi bukan solusi jangka panjang. Kita perlu mulai mengusulkan ide-ide yang mungkin (kode nyata atau meta) tentang bagaimana api ini bisa terlihat.

Redux sangat sulit untuk dipelajari di luar gerbang dan, sangat sering, sama sulitnya untuk diintegrasikan dengan konsep baru seperti logika async, efek samping, middleware khusus, dll. Saya mengalaminya sendiri hanya sedikit lebih dari setahun yang lalu ketika saya sangat baru dalam ekosistem reaksi.

Baru beberapa hari belajar react saya langsung direkomendasikan untuk belajar redux. Rekomendasi ini datang dari pengembang yang sangat berpengalaman dan pemula yang telah melakukan (atau sedang melakukan) hal yang sama. Itu dipuji sebagai solusi de facto untuk apa pun yang melampaui setState (mari kita jauhkan gerbang setState dari ini ). Semua ini untuk alasan yang bagus, karena redux luar biasa.

Saya pasti mencapai kurva belajar dan ketika mencari bantuan segera menyadari bahwa pendekatan pemasaran dan terdokumentasi untuk redux mengambil nada "Redux sulit, konsepnya tingkat rendah, api terkunci, dan Anda hanya perlu daya melalui dia."

Jadi ini adalah apa yang saya lakukan bersama dengan semua rekan-rekan saya. Kami mendukungnya karena itulah yang kami dididik untuk dilakukan. Namun, sepanjang perjalanan ini, saya berani membuat lapisan abstraksi sejak awal yang untuk sementara dan sengaja menyembunyikan beberapa kerumitan dan fitur canggih yang ditawarkan redux.

Saya tidak membutuhkan pembuat tindakan khusus, tidak ingin khawatir tentang tindakan pemetaan dan operator ke komponen, dan seperti banyak lainnya, memilih tata letak peredam yang tidak terlalu bertele-tele sebagai pengganti pernyataan sakelar.

Itu bekerja dengan fantastis. Sebenarnya, itu mempercepat proses belajar redux untuk rekan-rekan saya yang lain dan pengembang lain yang juga berjuang dengan kurva belajar.

Kami merancangnya sedemikian rupa sehingga redux tingkat lanjut atau "idiomatik" masih dapat digunakan saat kami membutuhkannya, tetapi benar-benar mendesainnya untuk kasus penggunaan 90% kami.

Saya tidak bermaksud mengatakan bahwa jumpstate telah mencakup semua basis, pada kenyataannya, masih ada begitu banyak hal yang perlu diubah agar jumpstate berperilaku "secara idiomatis" (pembuat tindakan yang dapat disesuaikan, menghapus impor tindakan global ... ada banyak) , tetapi itu pasti membantu banyak orang mempelajari dasar-dasarnya dan memberi mereka jalan untuk memahami cara kerja redux pada tingkat yang sangat sederhana. Setiap saat saya menerima pesan di slack org Jumpstate bahwa jumpstate membantu seseorang belajar redux.

Apakah orang-orang itu masih menggunakan jumpstate hari ini atau tidak tidak terlalu menjadi masalah (tetapi banyak orang masih menggunakannya produksi hari ini). Yang penting adalah pengalaman yang mereka miliki, dan seberapa cepat mereka bisa menjadi produktif di ekosistem redux.

Beberapa ide lagi yang muncul di benak untuk diskusi ini:

• usulkan contoh meta tentang bagaimana tampilan redux yang disederhanakan, coba saja!
• mendiskusikan persyaratan untuk, dan memutuskan standar untuk perang tengah redux yang sering diduplikasi dan sangat keras kepala. Kita bisa mulai dengan penanganan async. Ini bisa memecahkan begitu banyak fragmentasi di komunitas redux dan membantu upaya semua orang membuat perbedaan untuk kelangsungan hidup jangka panjang dan penggunaan redux.

Berapa banyak dari ini yang dapat diselesaikan dengan dokumen yang ditingkatkan dalam beberapa cara?

Banyak. Ketika datang ke dokumentasi Redux, saya merasa dalam banyak derajat lebih buruk daripada dokumen AngularJS 1 karena seperti AngularJS, itu tidak perlu bertele-tele tetapi tidak seperti AngularJS, ia gagal dalam prinsip "tunjukkan, jangan beri tahu".

Dokumen Redux lebih memilih cuplikan kode daripada demonstrasi sebenarnya dari kode yang berarti ada terlalu banyak momen "inilah satu set kode; kami tidak akan memberi tahu Anda cara menghubungkannya tetapi percayalah pada kami bahwa itu berfungsi". Kurangnya kemampuan untuk menjalankan contoh dalam browser berarti bahwa pengguna dipaksa untuk mempercayai insting mereka sendiri bahwa apa yang mereka lakukan secara lokal berfungsi dan jika sesuatu tidak berhasil, mereka akan mati sendiri. Bahkan aplikasi Daftar Todo sederhana yang saya rasa bukanlah contoh Redux "halo dunia" terbaik - itu bisa dibuat lebih sederhana.

Diagram pasti akan membantu di sini. Misalnya, saya suka yang @sunjay ; salah satu yang mungkin lebih baik adalah mendesain satu untuk contoh Todo List itu sendiri - bagaimana file terhubung, dll. dari tampilan tingkat tinggi. Gambar hampir selalu lebih baik untuk menyampaikan teks panjang dan dapat membantu mengurangi verbositas dokumen. Gambar juga akan membantu pemula tetap fokus dan lebih memahami Redux secara keseluruhan.

Dua sen saya: tolong jangan ubah inti. Kecemerlangannya ada pada kesederhanaannya. Pada titik ini, menambahkan sesuatu ke dalamnya kemungkinan akan menghilangkan keseluruhan.

Keramahan pengguna dan abstraksi lebih lanjut dapat terjadi di userland. Saya tidak merasa perlu ada cara resmi atau idiomatis untuk menggunakannya. Ini adalah wadah negara yang dapat diprediksi, itu saja!

Bisa berdiri sendiri, biar ❤️

Yang mengatakan, tentu saja, kemas sesuai keinginan Anda dengan membuat lebih banyak lib yang berpendapat di atasnya. Itu yang saya lakukan juga, tapi jangan mengubah inti, tolong.

@HenrikJoreteg , jangan takut! Saya hampir yakin bahwa tidak ada yang kita diskusikan di sini yang akan mengubah intinya. Inti adalah fitur lengkap dan berdiri sendiri. :)

Banyak. Ketika datang ke dokumentasi Redux, saya merasa dalam banyak derajat lebih buruk daripada dokumen AngularJS 1 karena seperti AngularJS, itu tidak perlu bertele-tele tetapi tidak seperti AngularJS, ia gagal dalam prinsip "tunjukkan, jangan beri tahu".

Ini sangat benar. Satu hal ketika Redux masih baru adalah dokumen itu jarang, tetapi dasar-dasarnya ada di sana. Banyak orang mengadopsinya karena "sangat sederhana". Tetapi sumber daya online sekarang mencoba untuk menunjukkan "teknik dunia nyata", yang sering kali hanya "middleware favorit saya" dan "perkakas pengurangan boilerplate favorit saya". Orang-orang kewalahan.

Ada sesuatu yang bisa dikatakan tentang "kurang lebih"

@Phoenixmatrix , @Sylphony : jadi, seperti apa potensi perombakan dokumen?

Secara pribadi, untuk menggabungkannya dengan saran saya di atas untuk memiliki "toko pemula", saya akan membaginya menjadi dua (bukan 2 situs/dokumen berbeda, tetapi 2 bagian berbeda).

"Arsitektur Redux", yang akan memiliki banyak gambar lucu dan sederhana, menjelaskan tindakan dan reduksi, memperkenalkan react-redux dan mungkin thunks, menggunakan "toko pemula" untuk membatasi segala jenis konfigurasi di muka, dan menunjukkan betapa mudahnya hal itu dapat dilakukan. adalah membuat aplikasi sederhana yang melakukan beberapa permintaan ajax dan merender barang di layar.

Segala sesuatu yang lain bisa masuk ke bagian "jelajahi" dengan konsep yang lebih maju. Bahkan kemudian, saya mungkin akan merobek banyak barang. Seseorang menunjukkan kepada saya hari ini bahwa ada bagian tentang memiliki banyak toko di suatu aplikasi. Itu bagus untuk diketahui, tetapi kegunaannya sangat canggih. Saya tidak berpikir setiap pendatang baru perlu tersandung tanpa melihat.

Dokumen yang lebih baik selalu merupakan ide yang bagus, tetapi saya rasa itu tidak menyelesaikan masalah inti di sini. Pustaka abstraksi sedang ditulis dan diadopsi karena boilerplate dan verbositas api Redux. Pustaka yang sama itu memecah komunitas Redux karena mereka jelas dibutuhkan pada tingkat tertentu atau lainnya. Ini membuat frustrasi ketika penulis yang sama yang secara aktif mencoba berkontribusi pada ekosistem dijatuhkan dan diberhentikan secara terbuka karena mereka "tidak mengerti Redux". Jika komunitas dapat membuat abstraksi yang lebih sederhana, bukan bagian dari inti React, tetapi "diberkati" sampai tingkat tertentu, maka semua orang menang. Pengguna hardcore tetap menggunakan Redux apa adanya, orang lain dapat menggunakan abstraksi dengan api verbose yang lebih mudah/kurang.

@derekperkins Bagaimana kita mencapai konsensus tentang perpustakaan "diberkati"? Bagaimana kita memutuskan apa yang ada di dalamnya dan siapa yang akan mengerjakannya?

Saya setuju untuk hal seperti ini, tetapi bagaimana kita menghindari hanya membuat perpustakaan lain yang hanya digunakan beberapa orang dan dengan demikian memecah ekosistem lebih jauh.

xkcd yang relevan: https://xkcd.com/927/

Ya, inti redux dan reaksi-redux sedekat mungkin dengan konsensus yang bisa didapat. Bahkan tindakan redux-thunk dan redux-action cukup batas, karena bahkan pada tingkat itu mayoritas orang memiliki kebutuhan yang berbeda.

Mengurangi boilerplate di Redux adalah masalah "Saya tidak perlujadi saya akan mengabstraksikannya. Tetapi bahkan untuk pendatang baru, "bagian itu" sangat bervariasi.

Heck, kami memiliki banyak (beberapa lusin) aplikasi redux yang sedang bekerja dan sulit untuk membangun tumpukan pengurang boilerplate yang umum karena aplikasi yang berbeda memiliki persyaratan yang berbeda. Sangat mudah bila Anda memiliki satu aplikasi, atau beberapa dengan persyaratan yang sama. Bahkan yang kecil sedikit berbeda.

Idenya di sini bukan untuk menyusun perangkat yang memecahkan semua masalah bagi semua orang. Menggunakan CRA sebagai contoh: ada banyak cara untuk mengkonfigurasi Babel dan Webpack dan ESLint. Apa yang dilakukan CRA adalah menawarkan satu cara berpendirian untuk membuat semuanya bekerja tanpa kerumitan di pihak pengguna, dan dengan sengaja memilih sejumlah pengaturan yang membuat segalanya lebih baik bagi pelajar. Ini kemudian memungkinkan pengguna untuk mengendalikan konfigurasi _jika mereka mau_.

Itu juga tidak mencoba menyelesaikan setiap kasus penggunaan. CRA tidak mencoba menangani pemecahan kode tingkat lanjut, beberapa titik masuk, SSR, atau hal-hal seperti itu. Dokumen CRA _do_ menunjuk ke alat dan opsi lain yang mungkin menawarkan lebih banyak konfigurasi dan bekerja lebih baik untuk kasus penggunaan tertentu.

Itu cara yang bagus untuk mengatakannya. Sesuatu untuk bangun dan berlari cepat itu
hanya melibatkan menginstal redux dan lapisan konfigurasi hipotetis ini? Itu
akan menjadi hebat.

Ide lain yang saya miliki adalah bendera yang dapat Anda atur dalam mode dev yang bisa
perhatikan dan paparkan peluang belajar tambahan bagi pengguna. Di dalam
dengan cara ini lapisan abstraksi dapat berfungsi sebagai alat pengajaran interaktif.
Pada Mon, Mar 20, 2017 at 04:14 Mark Erikson [email protected]
menulis:

Idenya di sini bukan untuk menyusun perangkat yang menyelesaikan semua masalah
untuk semua orang. Menggunakan CRA sebagai contoh: ada banyak cara untuk mengonfigurasi
Babel dan Webpack dan ESLint. Apa yang dilakukan CRA adalah menawarkan satu, berpendirian
cara untuk membuat semuanya berfungsi tanpa kerumitan di pihak pengguna, dan itu
sengaja memilih sejumlah pengaturan yang membuat segalanya lebih baik untuk
pelajar. Ini kemudian memungkinkan pengguna untuk mengambil kendali konfigurasi jikamereka ingin .

Itu juga tidak mencoba menyelesaikan setiap kasus penggunaan. CRA tidak mencoba untuk
mengatasi pemecahan kode tingkat lanjut, beberapa titik masuk, SSR, atau hal-hal seperti
itu. Dokumen CRA memang menunjukkan alat dan opsi lain yang mungkin menawarkan
lebih dapat dikonfigurasi dan bekerja lebih baik untuk kasus penggunaan tertentu.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/reactjs/redux/issues/2295#issuecomment-287914805 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AFUmCactFzsw7etmGGP8MFK6kfNaOzTJks5rnvorgaJpZM4MhnVF
.

@sunjay Saya tahu tautan xkcd apa itu tanpa harus mengklik. :)

Saya setuju dengan @markerikson. Ini bukan upaya untuk menangani setiap kasus tepi untuk setiap orang. Ini adalah pernyataan pendapat dari pengembang inti Redux yang mengatakan, "ini adalah cara yang baik untuk membuat semuanya berfungsi". Ada default waras yang dapat diganti jika diperlukan, tetapi saya berani bertaruh bahwa default akan berfungsi untuk 80% pengembang.

Itu mungkin atau mungkin tidak ditulis pada inti Redux. Saya masih berpikir ada tempat untuk sesuatu seperti Jumpstate yang tidak lebih dari mempercepat kurva belajar.

Kurva pembelajaran redux bisa curam, tetapi begitu Anda memahami konsep, kebutuhan akan lapisan abstraksi sering kali hilang

Saya pikir itu benar sampai batas tertentu, tetapi tidak berarti Anda selalu ingin menghilangkan lapisan abstraksi. Meskipun saya telah menulis C di masa lalu dan memahami alokasi memori, saya lebih suka menulis di Go tempat pengumpulan sampah ditangani untuk saya. Per contoh Tensorflow saya sebelumnya, akan lebih berkinerja untuk menulis ke apis tingkat yang lebih rendah, tetapi ada juga banyak yang bisa dikatakan untuk kemudahan penggunaan abstraksi keras Python. Demikian pula, untuk Redux vs Jumpstate (atau abstraksi apa pun yang berasal dari masalah ini), bukan karena boilerplate tidak selalu sulit untuk ditulis, itu hanya rumit untuk sebagian besar kasus penggunaan yang tidak memerlukan semua fleksibilitas Redux mentah.

Jika terserah saya, saya ingin melihat ini:

• Subset ramah Flow/TypeScript yang lebih mudah diketik daripada vanilla Redux.
• Tidak terlalu menekankan konstanta (buat saja penggunaan string literal lebih aman).
• Mempertahankan independensi dari React atau pustaka tampilan lainnya tetapi membuatnya lebih mudah untuk menggunakan binding yang ada (misalnya menyediakan implementasi mapStateToProps ).
• Mempertahankan prinsip-prinsip Redux (tindakan yang dapat diserialisasi, perjalanan waktu, dan pemuatan ulang panas harus bekerja, log tindakan harus masuk akal).
• Mendukung pemecahan kode dengan cara yang lebih mudah.
• Mendorong kolokasi reduksi dengan pemilih, dan membuatnya tidak terlalu canggung untuk ditulis bersama (pikirkan bundel pemilih-pereduksi yang mudah ditulis dan disusun).
• Alih-alih menempatkan pembuat tindakan dengan reduksi, singkirkan pembuat tindakan sepenuhnya, dan buat pemetaan banyak-ke-banyak dari tindakan-ke-pereduksi menjadi alami (daripada menghindarinya seperti yang dilakukan kebanyakan perpustakaan).
• Membuat default kinerja yang masuk akal sehingga memoisasi melalui Pilih ulang "hanya berfungsi" untuk kasus penggunaan umum tanpa pengguna menulis kode itu.
• Berisi pembantu bawaan untuk pengindeksan, normalisasi, koleksi, dan pembaruan optimis.
• Memiliki dukungan aliran async bawaan yang dapat diuji.

Di atas inti, tentu saja, meskipun tidak apa-apa untuk mencapnya sebagai hal Redux resmi.
Juga, saya tidak akan menulis ini. Tapi kamu bisa.

Bagi saya, beberapa bulan yang lalu ketika saya belajar redux ,saya membaca dokumen tetapi tidak begitu mengerti,Jadi saya menghabiskan 2 hari untuk membaca kode src , kemudian setiap deskripsi tentang api dari doc menjadi jelas .

Dan kemudian, pemikiran tentang "desain negara", "divisi peredam", "desain middleware", "solusi async"...... bab menjadi jelas juga dengan saya mengembangkan proyek bulan depan.

Jadi, saya pikir membaca kode src adalah langkah yang paling tepat untuk mempelajari redux , dan hanya setelah itu, Anda dapat memahami dan menjelajahi lingkungan redux dengan lebih lancar.

dukungan async secara default.

Maksud saya tidak perlu menggunakan plugin lain seperti redux-thunk, redux-saga .

dukungan async secara default

Memang, hanya saja orang melihatnya selama 0,5 detik sebelum mencari sesuatu yang lebih baik. Tidak ada yang menghentikan Anda untuk memanggil API di dalam komponen Anda dan kemudian memanggil pengiriman dalam resolusi panggilan balik/janji. Hanya saja orang ingin segera mengeksternalisasinya (termasuk saya). Tetapi Anda dapat melakukan async dengan baik tanpa middleware apa pun.

Komentar @gaearon sempurna, karena menyoroti seberapa luas sapuan yang ada. Saya sangat menyukai dan menghargai ketepatan dan keanggunan dan kekuatan Redux 2.0 yang dia usulkan, namun hampir tidak ada peningkatan yang relevan bagi saya!

Saya benar-benar menemukan itu menarik.

Pustaka abstraksi Redux saya sendiri hampir seluruhnya kebalikannya. Saya menemukan nilai luar biasa dalam tindakan peredam tunggal, dalam menggabungkan fungsi peredam atom dengan kode tindakan dan pemilihnya, dalam mematikan string sepenuhnya demi kunci objek. Ini solusi 90% saya sendiri, lebih mirip dengan CRA dalam sikap daripada yang lainnya.

Hal yang menarik adalah tentang: masalah apa yang kita coba pecahkan? Ada banyak masalah, dengan beberapa ruang solusi yang tersedia. Jika Dan membangun Redux 2.0 seperti yang dia gambarkan, saya akan membangun kembali perpustakaan abstraksi saya sendiri di atas itu juga!

@jbellsey Redux Hebat dalam memberikan tindakan dan status ke aplikasi secara global — tetapi dalam lingkup yang ditentukan — Anda dapat memiliki instance redux store yang tak terbatas tetapi Anda dapat menggabungkannya. Pada dasarnya ini berguna untuk perpustakaan. Jika Anda melihat perpustakaan berbicara tentang redux di dalamnya, Anda bisa mendapatkan keuntungan dari...

masalah apa yang kita coba selesaikan?

Keadaan global Aplikasi. R eliable E sthetics D elivered U nified e X tensible: hati:

Tidak ada yang menginginkan global. Tapi semua orang butuh satu :tm:

Tolong, buat redux tetap sederhana seperti sekarang. Ini adalah pola. Buku masak akan selalu muncul sekitar :100:

@markerikson Apakah ide yang baik untuk memulai dokumen / spreadsheet untuk mengatur pemikiran ini? Sudah ada beberapa ide luar biasa dan ini baru 48 jam

Bagi saya, saya tidak akan merekomendasikan orang untuk menggunakan thunks atau saga. Sebagai gantinya, pelajari teknik injeksi ketergantungan dalam JavaScript.

Redux menjadi lebih mudah setelah saya memperlakukannya sebagai database biasa:

• Saya memberi tahu Redux status awal, dan bagaimana suatu tindakan (peristiwa) memengaruhi status aplikasi. (Seperti skema database dan prosedur tersimpan.)
• Kemudian Redux menangani pengelolaannya dan memberi tahu pendengar, dan menyediakan cara untuk memeriksa dan men-debug status.

Bagi saya itu saja Redux bagi saya (saya tidak mengharapkan database melakukan panggilan HTTP). Untuk I/O dan hal-hal asinkron, saya melakukannya di luar Redux. Ini membuat toko Redux saya dapat diprediksi. Jenis tanda tangan selalu store.dispatch(actionObject) . Tidak ada fungsi pengiriman dan tidak ada makna tersembunyi di dalam tindakan (mis. mengirim tindakan tidak akan membuat panggilan API).

@tannerlinsley : Ya,

Satu kelemahan saya memulai diskusi ini: Saya sudah punya banyak hal yang perlu saya kerjakan dan tulis. Sebagian besar dipaksakan sendiri, tetapi itu berarti saya tidak punya cukup waktu untuk mengerjakan beberapa topik terkait Redux yang ingin saya selidiki, apalagi menangani hal-hal seperti perombakan dokumen besar atau membangun toolkit baru dari menggores.

Saya benar-benar ingin terlibat dalam upaya yang memungkinkan ini, tetapi akan membutuhkan orang lain untuk bergabung dan bekerja sama. (Kata-kata terakhir yang terkenal dari setiap pengelola OSS... :))

Redux menjadi lebih mudah setelah saya memperlakukannya sebagai database biasa

Ini yang saya rekomendasikan!

• Jaga agar toko Anda tetap normal
• Anda dapat menyiapkan data — seperti tampilan. Lakukan ini dengan reduksi khusus — Anda tidak perlu reselect . Mempertimbangkan.
• Tindakan seharusnya tidak memicu tindakan lain — ini terlihat mudah. Tetapi sulit jika Anda memiliki kait componentDidMount . Saya tidak tahu bagaimana menyelesaikan ini. Menggeser ini dalam hierarki tidak selalu mudah

FWIW, saya telah menggunakan Redux dengan D3.js (tanpa Bereaksi) dan itu berjalan dengan baik. Beberapa contohnya tercantum dalam d3-component .

Hal yang paling saya rindukan tentang binding React Redux adalah connect . Poin yang paling saya minati dari garis besar/visi di atas dari @gaearon adalah "menyediakan implementasi mapStateToProps ".

Anda dapat menyiapkan data — seperti tampilan. Lakukan ini dengan reduksi khusus — Anda tidak perlu memilih ulang. Mempertimbangkan.

Ya, inilah yang dilakukan Twitter di tokonya, setidaknya saya pikir begitu - mereka memiliki cabang entities yang berisi id tetap untuk peta data dan yaitu tampilan timeline yang pada dasarnya adalah umpan utama Anda lihat yang menyimpan referensi id ke cabang entitas tetapi sudah dihitung sebelumnya.

Dan itulah yang saya inginkan dalam refactors yang akan datang, karena memilih kembali daftar yang sangat dinamis adalah ... tidak terlalu berkinerja; satu-satunya downside yang saya lihat adalah Anda agak berakhir dengan data yang diduplikasi, dan juga memanipulasi pembaruan dan penghapusan pada tampilan mungkin cukup rumit dalam jangka panjang karena Anda harus sering mengingat sekitar 2 tempat (atau lebih).

@stefensuhat ketika saya mencoba mengimplementasikan Redux sendiri, saya menggunakan loop Promise untuk memungkinkan tindakan async. Anda dapat memeriksanya di https://github.com/iddan/delux

@gaearon sangat setuju dengan daftar Anda! Kami telah mengerjakan boilerplate redux mengikuti 90% dari daftar di organisasi tempat saya bekerja (juga, mengikuti prinsip bebek). Ini adalah rilis awal saat ini, tidak siap untuk diterbitkan.

Saya pasti ingin berkontribusi pada ide bagus ini!

@markerikson @tannerlinsley

Untuk mengatur ide-ide ini, saya menyarankan agar setelah Anda membuat spreadsheet, Anda membuat masalah Github di repo yang sesuai untuk melacak perkembangannya. Anda kemudian harus berkomentar di sini dengan daftar masalah tersebut.

Ini tidak menjamin bahwa apa pun secara khusus akan dikirimkan dengan redux, tetapi itu memberi orang yang tertarik pada hal tertentu itu kesempatan untuk mengikuti diskusi dan bekerja sama untuk mewujudkannya.

Beban untuk mewujudkan saran-saran ini ada pada kita semua yang tertarik pada setiap fitur atau pendekatan baru. Meskipun Mark memulai diskusi, saya yakin tidak ada yang mengharapkan dia untuk pergi dan menerapkan semuanya. :)

Ya, daftar @gaearon sangat ideal, tetapi seperti yang sudah disebutkan beberapa orang, itu banyak hal. Siapa pun yang mencoba mengatasinya secara langsung akan menghadapi bikeshedding hingga terlupakan. Saya ingin melihatnya terjadi, tetapi saya pikir potongan-potongan yang lebih kecil harus diserang pada suatu waktu, daripada membangun lapisan penuh di atas (sekali lagi mendorong contoh saya dari toko pemula yang telah dikonfigurasi sebelumnya ;))

Dengan itu, ketika/jika seseorang mencoba menyerang seluruh daftar itu, ingat juga alat dan kerangka kerja lain apa yang ada di luar Redux, dan bahkan di luar React. React/Redux memiliki serangkaian manfaat menarik dibandingkan vanilla Flux, lebih dari MobX, lebih dari VueJS dan ekosistemnya, di atas Angular. Apa pun yang dilakukan komunitas, komunitas mungkin ingin tetap fokus pada beberapa manfaat ini (beberapa di antaranya adalah bagian dari daftar @gaearon ), dan memastikan bahwa lapisan apa pun yang dibangun di atas tidak menjadi berlebihan sama sekali. Banyak hal seperti debugging perjalanan waktu, ekosistem middleware, dll tersedia di tempat lain.

Contoh yang saya buat: mungkin tergoda untuk membuat modul yang memungkinkan Anda membuat fungsi yang secara otomatis memperbarui peredam yang dibuat secara otomatis. Tapi begitu Anda melakukannya, Anda mereplikasi MobX, jadi itu tidak terlalu berguna untuk dilakukan.

@Phoenixmatrix ya yang saya maksud adalah redux memiliki middleware default, jadi kami tidak perlu menggunakan yang eksternal. 😄

Saya tidak melihat ada yang salah dengan implementasi Redux saat ini. Boilerplate ada tetapi sebenarnya bukan masalah besar jika Anda memiliki sistem tipe.

Satu masalah utama bagi saya adalah orang-orang tampaknya tidak mengerti bahwa kami sedang membangun aplikasi frontend yang jauh lebih kompleks daripada beberapa tahun yang lalu. Jika kita sedang membangun aplikasi yang lebih besar, lebih kompleks, dengan tim besar, itu normal bagi saya bahwa kesulitan meningkat secara signifikan, pola baru muncul, namun orang menolak kesulitan itu.

Saya tidak mengatakan bahwa kita tidak boleh mencoba membuat segalanya lebih sederhana, atau mengurangi boilerplate, tetapi orang-orang tidak boleh mulai menggunakan Redux dan mengeluh tentang boilerplate yang terlibat tanpa memahami pengorbanan yang dibuat dan melihat gambaran besarnya.

Ketika Redux dibuat, banyak orang (termasuk saya) mencoba membangunnya, dan @gaearon mendapatkan implementasi terbaik dan melakukan pekerjaan yang sangat baik pada perkakas/demo. Ini (dan juga Flux) mendapat banyak daya tarik pada awalnya, bukan hanya karena perjalanan waktu, tetapi juga karena konsepnya yang tidak baru bagi banyak orang dan langsung terasa alami.

Orang-orang melihat Redux sebagai mainan baru yang mengkilap (yang tampaknya tidak mudah dalam praktiknya). Namun tidak ada yang benar-benar baru di Redux kecuali fakta bahwa seseorang melakukan porting konsep-konsep itu dengan cara yang elegan ke frontend. Pola Redux dan ekosistemnya sudah digunakan dalam sistem terdistribusi, aplikasi backend yang bersumber dari peristiwa, desain berbasis domain, dan orang-orang yang memiliki latar belakang ini akan memahami Redux dengan sangat mudah.

Sayangnya, orang ingin melewatkan langkah dan menggunakan Redux tanpa mengetahui apa pun tentang pola yang lebih umum yang terlibat. Secara pribadi saya akan merekomendasikan siapa pun yang ingin membangun sesuatu yang serius di Redux untuk memiliki latar belakang minimal dalam sistem terdistribusi. Itu mungkin tampak aneh tetapi saya pikir memiliki latar belakang seperti itu dapat memberi Anda keuntungan yang sangat serius saat ini, dan di tahun-tahun mendatang.

Apa yang sebenarnya kita bangun ketika kita membangun aplikasi frontend?

• Kami membangun anggota sistem terdistribusi
• Anggota itu hanya menyimpan sebagian data dari sistem yang lebih umum
• Anggota itu memiliki kapasitas yang cukup terbatas (penyimpanan, bandwidth, stabilitas jaringan ...)

Jadi, kami mencoba membangun sesuatu yang sangat kompleks. Kami memiliki kendala yang lebih sulit untuk ditangani daripada pengembang basis data, namun kami ingin itu menjadi lebih sederhana, tanpa menggunakan kembali pengetahuan sebelumnya dari orang-orang yang benar-benar berpikir keras tentang masalah ini selama bertahun-tahun. Tidakkah Anda berpikir bahwa orang sudah memikirkan bagaimana menyusun negara di dalam DB? bagaimana cara menanyakannya?

Saya tidak mengatakan kita tidak boleh pragmatis, mengirimkan aplikasi hari ini dan membuat kesalahan dengan pengetahuan kita saat ini, tetapi lebih memahami dan mengakui bahwa apa yang kita bangun tidak sederhana lagi dan membutuhkan pengetahuan tambahan. Redux mungkin jalan yang baik untuk mendapatkan pengetahuan ini, dan Anda dapat menggunakannya secara pragmatis pada awalnya, tetapi jangan meremehkan seberapa banyak pengembangan frontend akan membuat Anda tidak nyaman di tahun-tahun mendatang.

Sayangnya, orang ingin melewatkan langkah dan menggunakan Redux tanpa mengetahui apa pun tentang pola yang lebih umum yang terlibat.

Baik atau buruk, Redux pada dasarnya telah memenangkan pertempuran untuk manajemen negara Bereaksi. Dengan itu muncul kemampuan untuk membentuk ekosistem. Akan selalu ada pengembang yang hanya menginginkan sesuatu yang berfungsi, dan ada banyak aplikasi sederhana di mana hanya itu yang diperlukan. Entah orang akan terus menggunakan lapisan abstraksi lain, atau mereka dapat diperkenalkan ke pola umum yang benar melalui perpustakaan sederhana.

Secara pribadi saya akan merekomendasikan siapa pun yang ingin membangun sesuatu yang serius di Redux untuk memiliki latar belakang minimal dalam sistem terdistribusi. Itu mungkin tampak aneh tetapi saya pikir memiliki latar belakang seperti itu dapat memberi Anda keuntungan yang sangat serius saat ini, dan di tahun-tahun mendatang.

Inilah inti masalahnya. Redux apa adanya sangat cocok untuk orang yang memahaminya. Ini tidak selalu merupakan hal yang buruk namun untuk menyederhanakannya. Kebanyakan orang tidak lagi menulis kode rakitan, meskipun memahaminya biasanya membantu Anda menulis kode yang lebih baik. Itu bukan di mana kebanyakan orang mulai.

Banyak lagi komentar bagus di sekitar. Ada banyak ide di sini yang bisa dan harus kita jelajahi lebih jauh.

Mari kita lihat apakah kita dapat mulai menemukan beberapa ide yang berpotensi dapat ditindaklanjuti. Saya akan mulai, dengan membuang konsep dasar kecil:

Buat paket baru bernama, saya tidak tahu, redux-starter atau sesuatu. Paket itu mungkin bergantung pada redux-actions , redux-thunk , dan redux-logger , dan mungkin middleware berbasis janji. Itu akan menyediakan fungsi dengan tanda tangan function createReduxStore({reducers, middleware}) {} (berdasarkan komentar @Phoenixmatrix sebelumnya ). Mungkin tidak mau repot-repot menerima middleware?

Fungsi createReduxStore() akan menangani penanganan applyMiddleware dan menyiapkan hot reload untuk root reducer, serta mengonfigurasi ekstensi Redux DevTools. Jika tidak ada middleware yang disediakan, itu akan mengonfigurasi yang disertakan secara default. Ini mungkin terlihat mirip dengan kode penyiapan layanan toko di ember-redux atau fungsi configureStore di aplikasi sampel "Project Mini-Mek" saya .

Ini setidaknya akan meminimalkan jumlah penyiapan yang diperlukan untuk memulai, dan menyediakan serangkaian fungsionalitas berguna yang sederhana.

Ya, saya suka itu (well, tidak suka tindakan redux dan middlewares berbasis janji untuk pengguna yang lebih baru, tapi saya akan membiarkan Anda bersenang-senang dengan bikeshedding yang satu itu). Tidak perlu repot menerima middleware, cukup buatStarterStore(reducer).

Bahkan mungkin mengganti combineReducer, jadi Anda cukup melakukan:

const store = createStarterStore({
   foo,
   bar,
   baz
});

di mana foo bar baz adalah reduksi.

Drat. Baru menyadari bahwa "fungsi perpustakaan yang menyiapkan HMR untuk peredam akar" mungkin tidak akan berfungsi, karena meskipun kami mengizinkan pengguna untuk meneruskan jalur ke file peredam akar mereka, salah satu atau keduanya dari module.hot.accept() API dan langkah impor ulang require(path) menginginkan jalur yang dapat dianalisis secara statis pada waktu pembuatan dan bukan variabel. (Saya pikir... saya bisa saja salah.) Oh, baiklah.

Tapi ya, createStarterStore() dapat menerima peredam root atau objek irisan.

Secara pribadi saya akan merekomendasikan siapa pun yang ingin membangun sesuatu yang serius di Redux untuk memiliki latar belakang minimal dalam sistem terdistribusi. Itu mungkin tampak aneh tetapi saya pikir memiliki latar belakang seperti itu dapat memberi Anda keuntungan yang sangat serius saat ini, dan di tahun-tahun mendatang.

@slorber Saya setuju dengan Anda di bagian itu.

Sayangnya, orang ingin melewatkan langkah dan menggunakan Redux tanpa mengetahui apa pun tentang pola yang lebih umum yang terlibat.

Tapi tidak benar-benar untuk yang satu ini. Beberapa orang tahu tentang pola yang terlibat dalam Redux, dan inilah tepatnya mengapa mereka memilih untuk menggunakannya. Ingin menggunakan sesuatu yang sederhana (atau setidaknya lebih sederhana) tidak berarti pengguna tidak mampu menggunakan implementasi yang lebih sulit. Itu hanya menghemat waktu dan tenaga.

Di tempat saya bekerja, kami telah menggunakan Redux selama satu tahun sekarang, dan mendapati diri kami menyalin/menempelkan kode yang sama (hanya memodifikasinya sedikit) untuk menambahkan sumber daya baru ke toko, itulah sebabnya pada titik tertentu kami merasa kebutuhan untuk menerapkan lapisan di atas Redux, untuk mengabstraksi boilerplate yang berlebihan ini.
Menurut pendapat saya, ide ini tidak hanya menyederhanakan penggunaan Redux, tetapi juga mengurangi boilerplate untuk bagian yang paling umum (dengan cara yang sama react-redux mengurangi boilerplate saat menggunakan Redux bersama dengan React).

Diskusi yang sangat menarik. Dua sen saya sebagai pengguna redux sejak awal:

Pada awalnya, seingat saya, redux lebih dipandang sebagai protokol atau kumpulan konvensi yang masuk akal daripada kerangka kerja untuk membangun aplikasi. Penghematan ini adalah bagian dari mengapa redux bisa menjadi luar biasa bagi orang baru dan membosankan untuk diukur tanpa menggulirkan abstraksi Anda sendiri. Tetapi cara sederhananya memotong kekacauan pengelolaan negara pada tahun 2015 juga merupakan alasan mengapa ia lepas landas, dan minimalis telah memungkinkan kerangka kerja yang luar biasa seperti Apollo untuk mendukung pekerjaan yang dilakukan untuk berbagai proyek (terutama alat dev) dan memberikan cara yang akrab untuk "turun ke tingkat yang lebih rendah" dalam manajemen negara bila perlu.

Saya pikir sudah jelas bahwa sebagai redux perpustakaan "tingkat rendah" telah sukses besar, dan sebagai kerangka kerja yang kaya fitur untuk membangun aplikasi, itu belum cukup. Satu hal yang harus diperhatikan adalah bahwa ketika redux berevolusi, redux tidak merusak perannya sebagai "protokol" standar industri untuk proyek-proyek seperti Apollo.

Untuk tujuan ini, mungkin redux saat ini dapat menjadi paket seperti redux-core , dan redux itu sendiri meningkatkan level abstraksi untuk memberikan cara yang direkomendasikan untuk membangun aplikasi. Tentu saja, ada sejumlah alternatif level yang lebih tinggi untuk redux (seperti Apollo, atau sesuatu yang menggunakan saga?) menggunakan redux-core...

Menyatakan kembali hal-hal untuk klarifikasi dan penekanan:

Pekerjaan apa pun dari utas ini tidak akan menyertakan perubahan besar pada pustaka Redux yang ada :) Perubahan dokumen sangat mungkin dilakukan, dan mungkin ada beberapa penyesuaian kecil, tetapi paket redux yang ada akan tetap apa adanya.

Apa pun seperti paket redux-starter yang baru saja saya jelaskan, atau pendekatan "kerangka"-y yang dijelaskan Dan, akan menjadi paket baru yang bergantung pada redux .

Saya memilih kami membuat paket seperti yang disarankan @markerikson . Setelah kita memiliki basis kode, kita dapat mulai membahas api, cuplikan kode, dan ide yang lebih mendalam. Kami kemudian akan memiliki tempat untuk membuat masalah untuk fitur tertentu.

Anda dapat menggunakan Delux sebagai starter (jk)

Sebagai pengguna berat Jumpstate @tannerlinsley (dan sekarang salah satu pengelolanya), saya sangat senang dengan ini. Alasan saya menggunakan Jumpstate diuraikan dengan sangat ringkas dalam posting asli @gaearon . Mengatakan itu, itu bukan solusi lengkap (tidak pernah dimaksudkan). Saya sedang memikirkan beberapa hal yang dapat ditambahkan di atas ini pagi ini dan kemudian saya menemukan utas ini dan menemukan kalian sudah memikirkannya.

Cara bertele-tele untuk mengatakan: Kedengarannya luar biasa, saya ikut, tidak yakin berapa banyak saya dapat berkontribusi (saya akan mencoba) tetapi Anda pasti memiliki seorang pemandu sorak.

Saya telah menggunakan Jumpstate untuk mengajar Redux beberapa kali sekarang dan dapat dengan yakin mengatakan bahwa itu telah sangat memperpendek kurva belajar. Saya memikirkan Redux seperti HTTP dan Jumpstate seperti fetch. Saya suka Redux dan telah menulis beberapa (konyol) hal-hal rumit dengan itu, tetapi saya juga tahu bahwa 90% kasus lebih dari cukup untuk mengajarkan banyak hal.

Ketika Anda memikirkannya, ini adalah tempat yang bagus. Salah satu keluhan utama tentang pengembangan frontend dan javascript secara umum adalah "kurangnya perpustakaan standar." Soalnya, ini adalah hal yang sangat baru (TM) , bisa mengembangkan aplikasi penuh di browser. Tekanan akhirnya meningkat untuk membutuhkan perpustakaan standar. Di situlah kita sekarang.

Re: Kurva pembelajaran, opini dan abstraksi:

Ajax tampaknya menjadi area di mana pelajar baru terjebak, apakah mereka belajar menggunakan thunk, saga, atau epos. Satu area di mana mereka tampaknya tidak mengalami banyak kesulitan adalah membuat tindakan - karena mereka hanyalah objek Javascript lama, dan kami memiliki kejelasan tambahan yang disediakan oleh spesifikasi Tindakan Standar Flux. Garis pemikiran ini membawa saya ke pertanyaan - Mengapa tidak mengembangkan Tindakan Ajax Standar Flux ?

Misalnya

function fetchPosts(page) {
  return {
    type: 'FETCH_POSTS_REQUEST',
    // Ajax request setup
    ajax: {
      url: `/api/posts`,
      method: 'GET',
      data: { page },

      // Optional ajax meta attributes
      meta: {
        // Amount of time to debounce the execution of the request
        debounce: 400,
        // Amount of times to retry the request on failure
        retry: 2,
        // Amount of time before timing out
        timeout: 10000,  
        // The action type that cancels the request
        cancelType: 'CANCEL_FETCH_POSTS',
        // Strategy when multiple FETCH_POSTS_REQUESTs are in flight
        resolve: 'LATEST'
      }
    }
  };  
}

Tindakan ajax akan ditangani oleh middleware (yang akan bereaksi terhadap kunci ajax dalam tindakan).

Saya telah mencoba memikirkan alasan mengapa pendekatan ini menjadi ide yang buruk, tetapi belum memikirkan pemecah kesepakatan.
Beberapa manfaat menurut perkiraan saya:

• penurunan dramatis dalam jumlah tindakan asinkron yang diperlukan dalam aplikasi rata-rata Anda (karena tindakan asinkron terkait ajax akan hilang)
• mudah dimengerti karena kita hanya berurusan dengan objek javascript lama biasa
• itu deklaratif, detail implementasi tidak penting
• implementasi yang berbeda dapat ditukar masuk/keluar tanpa kerusakan
• itu Redux idiomatik (log tindakan masih masuk akal, serializable dll)

Saya dapat mendengar beberapa orang mengajukan argumen pemisahan kekhawatiran, tetapi saya berpendapat bahwa itu adalah perpanjangan alami dari apa yang sudah dilakukan oleh tindakan permintaan ajax kami. Saat ini mereka sedang menyiapkan tindakan dengan konteks yang cukup jelas, 'FETCH_POSTS_REQUEST' , tetapi dengan konteks yang terlalu sedikit untuk mengabstraksikan implementasi permintaan ajax. Meninggalkan sedikit pilihan selain melakukan permintaan ajax secara manual di tempat lain.

Hal lain yang terlintas dalam pikiran adalah rantai tindakan async yang saya lihat di beberapa dokumen. Kami tidak membutuhkan permintaan rantai dengan cara ini, jadi saya tidak yakin seberapa luas penggunaan rantai ini, tetapi firasat saya adalah bahwa itu akan berada di luar cakupan dari apa yang saya usulkan di sini (dan mungkin tidak 't termasuk dalam kasus penggunaan 90% yang disebutkan dalam diskusi ini).

Kesimpulannya - tampaknya sangat mungkin bahwa abstraksi seperti ini akan membantu memudahkan kurva belajar dan jumlah kode yang diperlukan untuk menulis aplikasi Redux umum. Adakah yang punya pemikiran tentang pendekatan ini - pemecah kesepakatan apa pun yang dapat Anda pikirkan? @markerikson @gaearon

Karya sebelumnya: redux-axios-middleware

Banyak hal yang terjadi di thread ini.

Mengenai pembahasan tentang kompleksitas Redux. Secara pribadi saya tidak setuju dengan orang-orang yang mengeluh tentang Redux yang rumit dan bertele-tele. Ini adalah pertukaran yang Anda lakukan saat menggunakan perpustakaan tingkat rendah berdasarkan arsitektur Flux & Elm. Dinyatakan di halaman beranda Redux bahwa Anda mungkin tidak membutuhkannya. Tapi kami masih memiliki orang yang mengeluh tentang hal itu menjadi rumit.

Redux ditemukan apa adanya. Beruntung tim inti menyadari fiturnya lengkap dan tidak mau mengubahnya. Abstraksi yang dibangun di atasnya luar biasa dan masing-masing memiliki kasus penggunaannya sendiri. Inilah yang Anda harapkan untuk perpustakaan tingkat rendah yang baik dan dirancang dengan baik.

Saya melihat masalahnya bukan pada Redux itu sendiri tetapi pada kurangnya cara yang progresif dan praktis untuk mempelajarinya. Seperti yang disebutkan beberapa orang, React sendiri memiliki masalah yang sama dan create-react-app adalah solusinya.

Mungkin itu bukan masalah karena ada sumber daya yang luar biasa untuk itu (yaitu seri egghead Dan). Mungkin orang yang ingin menggunakan perpustakaan yang memecahkan masalah kompleks tanpa kurva belajar adalah masalahnya.

Bagaimanapun, ini bukan tentang topik ini.

@markerikson Saya pribadi siap membantu mengembangkan redux-starter .

_Saya ingin nama yang lebih keren_ :stuck_out_tongue:

Pelat ketel yang diperlukan dalam menghasilkan banyak tindakan adalah satu-satunya kelemahan yang saya lihat dengan redux.

Levelnya sangat rendah, tapi saya pikir itu bagus. Itulah salah satu alasan mengapa saya lebih memilih paradigma gaya Redux daripada MobX misalnya, meskipun saya memahami kegunaannya dan akan menggunakan MobX. Tapi saya hanya akan senang melakukannya sekarang karena saya mengerti Redux. Karena Redux (atau pola Redux secara umum), data tidak terlalu "di belakang layar". Umumnya, di mana pun kode sedang diproses, Anda yang menulisnya, dan jika tidak, Anda dapat memahaminya (jika Anda telah meluangkan waktu untuk mempelajarinya, lebih lanjut tentang itu nanti).

Soalnya, saat pertama kali belajar tentang Redux, banyak yang harus dipahami, tetapi juga sederhana. Sesuatu bisa menjadi sulit dan sederhana. Namun karena itu, saya berpikir, "Wow konsep ini sangat logis! Sangat masuk akal, saya yakin saya bisa melakukannya sendiri!" Jadi untuk proyek pertama saya, alih-alih menggunakan paket Redux, saya membuat toko Redux kecil saya sendiri.

Melakukan itu tidak hanya membantu saya memahami konsep Redux, tetapi juga meningkatkan pemahaman saya tentang Javascript itu sendiri! (Ini dari perspektif seseorang yang hampir tidak tahu apa-apa tentang konsep pemrograman fungsional sebelum ini, jadi jarak tempuh Anda mungkin berbeda.) Konsep Redux benar-benar sangat brilian dalam kesederhanaannya, namun juga sangat kuat.

Saya pikir masalahnya adalah karena Redux sangat populer, itu, uhh, "buzzwordy-ness" dapat mengalihkan pendatang baru dari betapa hebatnya kerjanya di Javascript. Jadi mentalitas mereka mungkin "ok saya punya React, Redux, dll dll, sekarang saya akan menjadi programmer yang luar biasa dan membuat aplikasi yang hebat!" Bukannya ada yang salah dengan itu. Tetapi mereka mungkin fokus hanya ingin menggunakan alat baru yang mengkilap untuk mempercepat proses pengembangan, tanpa memahami apa yang membuat alat itu berfungsi.

Setelah konsepnya dipahami, menjadi sangat mudah untuk membuat Redux (atau pola seperti Redux apa pun) untuk melakukan segala macam hal. Saya menyukainya karena alasan yang sama saya suka Bereaksi daripada alat lain (masih bagus) seperti Angular. _Ini hanya Javascript._ Beginilah cara kerja Javascript!
Jika boilerplate yang diperlukan dapat dikurangi melalui beberapa paradigma itu akan bagus, tapi saya pikir itu harga yang kecil untuk membayar powaaaaaa tanpa batas.

IMO semua ini "bertele-tele adalah tradeoff" hanyalah masokisme; verbositas tidak melayani apa pun, itu adalah pengorbanan yang Anda buat untuk menggunakan Redux sama sekali. Saya tidak menyalahkan Redux atau javascript, saya hanya ingin menunjukkan bahwa ini bukan kompleksitas yang esensial. Elm mengelola semua yang dicapai Redux dalam lebih sedikit baris dan kode yang lebih sederhana.

Jadi kami secara mekanis menulis pelat ketel. Jumpstate dan sejenisnya membuat hidup lebih mudah, tetapi ada batasan untuk apa yang dapat Anda lakukan saat runtime, dan dengan TypeScript/flow jumpstate tidak banyak membantu. Tetapi codegen itu sulit, dan tidak ada yang ingin menambahkan satu hal lagi ke sistem build mereka yang sudah terbebani.

Jika saya bisa memiliki sesuatu seperti kode Elm yang diterjemahkan ke dalam Redux idiomatik... Tetaplah detak jantung saya.

Berikut adalah beberapa ide saya, semoga saya tidak mengulangi komentar sebelumnya:

Pembuat tindakan dapat digunakan sebagai jenis tindakan

tindakan.js

export function increase() {}

peredam.js

import { increase } from './actions.js';
export default handleActions({
    [increase]: (state) => state + 1
}, 0);

Karena fungsi memiliki referensi unik, kami dapat memperlakukannya sebagai pengidentifikasi untuk tindakan. Tidak kompatibel dengan FSA tetapi menyimpan banyak kode dan mencegah kesalahan.

Tindakan dapat dikirim secara tidak sinkron

async function a() {

}
async function b() {
}
store.dispatch(a());
store.dispatch(b()); // b() will be dispatched after a() resolves

Dengan cara itu pembuat tindakan dapat menjadi fungsi asinkron namun mengirimkan satu demi satu. Seperti yang saya lihat dalam banyak situasi, orang tidak perlu menggunakan solusi berbasis middleware dan itu akan menghemat banyak kode boilerplate.
Konsep ini diimplementasikan oleh pabrik janji di Delux

redux === boilerplate

https://github.com/Emilios1995/redux-create-module

tapi saya pikir fungsi ini benar-benar dapat menyelamatkan hidup Anda.

Layak untuk membedakan antara dua rangkaian ide yang berbeda yang terjadi di utas ini:

• kerangka kerja berbasis redux "layanan lengkap"
• fitur tambahan di redux core

Saya setuju dengan @markerikson bahwa inti

Redux memiliki area permukaan API yang cukup kecil: createStore , applyMiddleware , combineReducers , bindActionCreators , dan compose . Tetapi sebagian besar dari ini adalah fungsi kenyamanan. Hanya createStore yang benar-benar diperlukan agar Redux berfungsi. Mengapa semua ini termasuk dalam inti?

• applyMiddleware membuat antarmuka yang disederhanakan untuk menyimpan enhancer. Tetapi yang lebih penting, applyMiddleware mendukung middleware _interface_ sebagai cara standar untuk menambahkan efek ke redux store. Ekosistem middleware dimungkinkan karena applyMiddleware memiliki antarmuka yang relatif sederhana dan memungkinkan pengguna menjalankan banyak middleware sekaligus.

• combineReducers menyediakan bentuk komposisi peredam yang nyaman. Ini jauh dari satu-satunya cara untuk membuat reduksi, tetapi ini tentu saja salah satu pola yang lebih berguna. Tetapi kehadirannya di inti redux berarti tidak hanya umum tetapi _di mana-mana_. Setiap aplikasi Redux nontrivial yang saya temui menggunakan combineReducers untuk membuat peredam root. Kebalikannya adalah karena combineReducers adalah satu-satunya bentuk komposisi peredam yang disertakan dengan Redux, banyak pengguna tampaknya percaya bahwa ini adalah satu-satunya bentuk komposisi peredam yang ada.

• bindActionCreators mengurangi beberapa boilerplate di sekitar tindakan pengiriman. Tapi anehnya, bindActionCreators juga secara tidak langsung bertanggung jawab atas beberapa reputasi Redux untuk boilerplate. Ini karena keberadaan bindActionCreators mendorong penggunaan pembuat tindakan. Ini terutama terlihat ketika seseorang membandingkan prevalensi pembuat tindakan (yang "didukung" oleh bindActionCreators ) versus pemilih (yang didokumentasikan tetapi tidak memiliki fungsi inti yang setara). Saya telah melihat banyak basis kode menggunakan react-redux mana mapStateToProps selalu penyeleksi "dipesan lebih dahulu" tetapi mapDispatchToProps selalu merupakan peta objek pembuat tindakan yang telah ditulis sebelumnya.

Tak satu pun dari ini penting untuk fungsionalitas Redux namun semuanya penting untuk kegunaannya. Tak satu pun dari fungsi-fungsi ini membatasi fleksibilitas yang melekat pada Redux, tetapi dengan mengubah pola umum menjadi fungsi yang dapat dipanggil, mereka membuat pilihan menjadi tidak terlalu menakutkan. Dan masing-masing fungsi pembantu ini menimbulkan pertanyaan lebih lanjut:

• Jika middleware adalah penyederhanaan dari peningkat toko, apakah ada penyederhanaan lain yang dapat berguna secara luas?
• Apa bentuk komposisi peredam lainnya yang dapat diterapkan selain hanya didokumentasikan? Objek peredam ? Pengurang ketergantungan ? komposisi linier ?
• Apakah mengintegrasikan pemilihan ulang akan mengarahkan orang untuk membuat dan menyusun penyeleksi di tempat yang belum pernah mereka lakukan sebelumnya? Apakah ini akan menjadi positif bersih?

Bahkan jika jawaban untuk semua ini negatif, saya pikir kita merugikan diri kita sendiri dan masyarakat dengan menolak untuk mempertimbangkan premis mereka.

@modernserf : Pertama, terima kasih atas komentar Anda, serta pemikiran terbaru Anda lainnya tentang Redux. Semuanya _sangat_ berharga dan informatif, dan mungkin harus dibaca oleh siapa pun di utas ini. Jadi, saya akan menautkannya di sini:

• Pos utama: Apa Hebatnya Redux?
• Versi bertingkat dari utas Twitter yang mengarah ke pos: https://storify.com/acemarke/redux-pros-cons-and-limitations
• Beberapa pemikiran tambahan setelahnya: https://twitter.com/modernserf/status/886426115874717697

Sangat menarik bahwa Anda harus membicarakannya, karena sejarah yang terlibat (yang baru saja saya habiskan banyak waktu untuk meneliti posting saya The Tao of Redux, Bagian 1 - Implementasi dan Intent . Secara khusus, redux-thunk adalah awalnya dibangun langsung ke Redux , dan react-redux hanya dipisahkan nanti juga .

Anda benar bahwa utilitas tersebut memang mengkodifikasi pola penggunaan tertentu. Yang mengatakan, utilitas tersebut disertakan karena mereka mengkodifikasi pola penggunaan _intended_: komposisi pengurang irisan, pipa middleware untuk perilaku async dan perilaku terpusat lainnya, dan pembuat tindakan terikat untuk menyederhanakan proses pengiriman tindakan dari komponen (terutama melewati fungsi di sekitar untuk komponen anak). Agak mirip, sementara Reselect tidak ada di intinya, Dan secara eksplisit mendorong pembuatannya .

Jadi ya, siapa pun "bisa" menulisnya, tetapi dengan membangunnya, kami mendorong orang untuk menggunakan alat khusus itu dengan cara tertentu. Pasti setuju itu.

Per tiga pertanyaan terakhir Anda:

• Saya _menebak_ Anda dapat mengatakan bahwa middleware adalah "penyederhanaan dari penambah toko", meskipun saya tidak berpikir itu adil bagi mereka. Sebaliknya, ini adalah penambah toko untuk tujuan yang sangat khusus. Sejauh pekerjaan terkait penambah toko lainnya: Dan telah mengatakan bahwa satu bagian utama dari inti Redux yang masih ingin dia modifikasi berkaitan dengan bagaimana penambah diinisialisasi. Sebenarnya ada dua PR "bersaing" untuk mengubah implementasi penambah toko yang telah dibuka untuk waktu yang sangat lama: versi @acdlite di #1706, dan versi @jimbolla di #2214. Menarik juga untuk dicatat bahwa Jim menyusun daftar semua peningkat toko yang dikenal untuk membantu menganalisis bagaimana komunitas sebenarnya menggunakannya. Saya tahu bahwa proposal Jim dimaksudkan untuk membantu penulis penambah menyederhanakan perilaku yang umum terlihat. Jadi, itu arah yang bisa dieksplorasi lebih jauh.
• Pasti ada banyak pola lain untuk komposisi dan struktur peredam di luar sana. Saya tidak yakin persis apa yang bisa kami lakukan sejauh reduksi "tergantung", karena itu lebih banyak kasus penggunaan khusus dan tampaknya cukup khusus untuk aplikasi. Pada catatan terkait, untuk waktu yang lama, Dan telah menutup semua PR yang mengusulkan penambahan semacam argumen ketiga ke combineReducers (dan sudah ada _lot_ dari mereka), tetapi akhirnya mengizinkan #1768 untuk maju untuk ketika. PR itu juga terhenti.
• Kasus penggunaan yang paling umum untuk penyeleksi tampaknya secara langsung mengekstraksi bit status dan meneruskannya sebagai props bernama. Kami juga memiliki PR terbuka untuk React-Redux untuk menambahkan sintaks singkatan objek untuk mapState , dan memiliki banyak permintaan untuk itu meskipun Anda dapat melakukan hal yang sama dengan createStructuredSelector Reselect.

Seperti yang saya dokumentasikan dalam posting "Tao of Redux" itu, tujuan yang dinyatakan adalah untuk menjaga API inti Redux seminimal mungkin , dan mendorong ekosistem di atasnya . Selain itu, di awal pengembangan Redux, Andrew membuat komentar tentang niat untuk "memberkati" plugin tertentu :

Seperti yang pernah dikatakan gaearon, (saya tidak ingat di mana... mungkin Slack) kami bertujuan untuk menjadi seperti perpustakaan Koa of Flux. Akhirnya, setelah komunitas lebih matang, rencananya adalah untuk memelihara koleksi plugin dan ekstensi yang "diberkati", mungkin di bawah organisasi GitHub reduxjs.

Sebelumnya, saya telah mengusulkan semacam lib abstraksi "pengaturan Redux yang mudah", atau sesuatu seperti itu. Apakah sesuatu seperti itu, atau setidaknya daftar add-on yang "diberkati", cukup sesuai dengan yang Anda pikirkan? (Dan, sebenarnya, Anda juga melakukannya di komentar pertama utas ini.) Jika tidak, ada usulan atau ide tambahan?

Akhirnya, setelah komunitas lebih matang, rencananya adalah untuk memelihara koleksi plugin dan ekstensi yang "diberkati", mungkin di bawah organisasi GitHub reduxjs.

Inilah yang akan saya lakukan juga, meskipun saya mungkin akan mengambil langkah lebih jauh: Saya akan merestrukturisasi proyek menjadi monorepo, di mana paket redux menjadi sesuatu seperti @redux/core , diberkati library seperti reselect dan redux-action dibawa ke dalam repo dan namespace, dan paket redux itu sendiri hanya mengekspor ulang semua paket ini ke dalam satu namespace.

_sort of_ itu memenuhi batasan untuk tidak memodifikasi inti redux. Selain itu, versi yang diperluas akan menjadi superset yang ketat dari -- dan karenanya kompatibel dengan -- inti. Fitur-fitur baru akan murni opt-in dan tidak memiliki akses khusus ke private state. Sejauh "mengembang" berjalan - masing-masing perpustakaan ini kecil untuk memulai, dan mereka ditulis sedemikian rupa sehingga akan sepele untuk menggoyangnya.

Kami juga memiliki PR terbuka untuk React-Redux untuk menambahkan sintaks singkatan objek untuk mapState, dan memiliki banyak permintaan untuk itu meskipun Anda dapat melakukan hal yang sama dengan createStructuredSelector Reselect.

Saya pikir ini harus memberitahu Anda sesuatu.

Struktur monorepo yang saya sarankan pada dasarnya adalah struktur yang digunakan oleh Lodash. Sekarang -- Lodash adalah perpustakaan yang menarik untuk dijadikan model: ini adalah kumpulan fungsi yang sangat banyak, banyak di antaranya sepele untuk diterapkan sendiri. Hampir setiap fungsi di lodash bisa lebih fleksibel sebagai "resep" -- bagaimanapun juga, groupBy sebenarnya adalah _pattern_; siapa kita untuk mengatakan struktur data apa yang Anda gunakan?

Dan setiap fungsi lodash juga tersedia di perpustakaan _a la carte_ sendiri. Tidak ada manfaat _fungsional_ untuk import { groupBy } from "lodash" lebih dari import groupBy from "group-by" . Mengapa saya harus berurusan dengan guncangan pohon ketika saya hanya dapat menginstal apa yang saya butuhkan?

Tetapi pengalaman menggunakan Lodash pada dasarnya berbeda dengan menggunakan resep atau perpustakaan nano. Anda tahu bahwa jika Anda melakukan sesuatu dengan array dan Anda merasa seperti sedang mengulanginya sendiri, mungkin ada fungsi Lodash untuk melakukannya. Anda tidak perlu mencari resep, Anda tidak perlu menginstal apa pun -- kemungkinan Anda bahkan tidak perlu menambahkan baris impor lain ke file. Ini hanya menghilangkan sedikit gesekan tetapi hari-hari kita dipenuhi dengan saat-saat seperti ini dan itu bertambah.

Saya harap Anda tidak keberatan saya menambahkan 2 sen saya sendiri, dari perspektif yang berbeda.

Aliran pemikiran CQRS , Event Sourcing , dan akhirnya Domain Driven Design adalah nenek moyang yang lebih besar yang melahirkan Flux dan Redux . Sementara pengaruh ini kadang-kadang dikutip , Redux dan perkakas keturunan yang mengambil sebagian besar mereka API terminologi dari Flux dan Flux implementasi yang populer pada saat itu. Ini baik-baik saja, tetapi saya pikir kami kehilangan beberapa peluang untuk mendapat untung dari eksposur yang mungkin dimiliki pengembang yang ada terhadap ide-ide itu.

Untuk memberikan dua contoh perbedaan: Dalam sebagian besar diskusi Sumber Acara yang pernah saya lihat, Tindakan Redux akan disebut sebagai Acara . Redux ActionCreators akan disebut sebagai Commands . Saya pikir ada beberapa kejelasan dan semantik tambahan yang datang secara gratis dengan terminologi ini juga. Peristiwa dapat dicatat, data serial. Peristiwa menggambarkan apa yang terjadi dalam bentuk lampau. Acara dapat diputar ulang. Acara tidak dapat dibatalkan perekamannya. Perintah memiliki suasana hati yang imperatif. Perintah memicu Acara .

Saya menduga bahwa Sumber Acara sebagai pola arsitektur akan mendapatkan popularitas selama dekade berikutnya, dan saya pikir Redux dapat memperoleh beberapa kegunaan, kejelasan, dan kemudahan penggunaan menang dengan menyelaraskan API dan diskusi lebih dekat dengan komunitas yang lebih luas.

Saya pikir diskusi ini sudah dipukuli sampai mati: https://github.com/reactjs/redux/issues/351

Oh, saya tidak menyadarinya, terima kasih! :+1:

Sepertinya #351 ditutup karena pada saat itu tidak ada tindakan yang bisa dilakukan. Jika kita berada di titik di mana kita mempertimbangkan kembali keputusan API dan bahasa yang kita gunakan, ini sepertinya waktu yang tepat untuk memunculkan kembali ide itu, bagi saya.

Saya bisa lebih konkrit.

Inilah ide saya tentang seperti apa API yang terinspirasi oleh idiom Sumber Acara :

Konsep

• Aliran Acara yang Dapat Diamati
• Aliran Acara memiliki serangkaian Acara yang didukung dengan baik
• Pengiriman perintah ke Aliran Acara
• Satu atau lebih Klien menggunakan Aliran Acara

API

import { createEventStream, createProjection } from 'redux';

// Initialize the event stream separately from the store.  This becomes the one
// true source of truth for your application.
const eventStream = createEventStream({
  // Commands are the only thing that we want to couple to the eventStream.  The 
  // set of events which may end up in an eventStream should be easy to predict.
  //
  // A definition like this supports static analysis inference well for 
  // consumers that can leverage it.
  increment: () => ({ type: 'INCREMENT' }),
  decrement: () => ({ type: 'DECREMENT' }),
});

// Multiple stores with disjoint or overlapping data can be used to consume the 
// same event stream.
const store = createProjection(eventStream, reducer, init);
const adminStore = createProjection(eventStream, adminReducer, init);

// We don't need a jargon term ("Middleware"), or a dedicated hook to handle 
// async anymore.  We just register more subscribers to the eventStream.
eventStream.subscribe(myCustomMiddleWare);
eventStream.subscribe(sendEventsToAnalytics);
eventStream.subscribe(logEventsForPlayback);

// Calls to commands can be wrapped with React Providers or container components 
// in the same way that Redux currently does.  They can also be called directly.
eventStream.increment();

@ajhyndman : sementara saya sangat menghargai saran dan diskusi, bahwa gudang sepeda telah sepenuhnya dicat dan kuda telah melarikan diri dari gudang (untuk sepenuhnya mencampur metafora). Dan memilih untuk menggunakan terminologi Flux daripada istilah CQRS/ES, dan tidak ada rencana untuk mengubah API inti atau istilah yang digunakan untuk konsep Redux.

(Juga, sementara saya tidak memiliki statistik untuk mendukung ini, saya kira pada titik ini ada lebih banyak orang yang akrab dengan penggunaan "tindakan" dan "pembuat tindakan" Redux daripada dengan terminologi CQRS/ES, setidaknya dalam komunitas JS. )

Saya pasti mendapat kesan bahwa percakapan ini telah terjadi sebelumnya, dan ada keinginan kuat untuk tidak membukanya kembali. Saya tidak akan menekan terlalu keras di sini. (Saya akan tertarik untuk membaca atau melanjutkan percakapan ini di tempat lain, jika ada titik kontak yang lebih baik.)

Tentu saja, Anda juga benar bahwa ada faktor penguatan, dan mengubah seluruh permukaan API dan terminologi akan memakan biaya pada saat ini.

Saya masih berpendapat ada peluang bagi komunitas Sumber Acara dan Redux untuk saling belajar.

• Apa abstraksi yang mungkin dapat dibuat yang menyederhanakan proses pembelajaran dan penggunaan, tetapi tanpa benar-benar menyembunyikan Redux (dan diharapkan akan memberikan jalur migrasi/pembelajaran ke "dasar" Redux)?

Bahkan tanpa meminjam terminologi atau mengubah API, saya pikir ada kemenangan yang bisa kita temukan. Misalnya, saya telah berhasil memperkenalkan orang ke Redux dengan menggambarkan toko sebagai "wadah keadaan di mana currentState adalah "fungsi murni" (berasal dari, atau dikurangi dari) daftar tambahan saja (atau aliran) dari Tindakan".

Melihat lebih jauh ke masa depan, saya pikir sangat mungkin untuk menerapkan dan mengabstraksi infrastruktur server seperti redux (lihat: pekerjaan lain dari tim teknik LinkedIn). Jika kita menginginkannya, maka seharusnya juga dimungkinkan untuk menggunakan abstraksi serupa untuk manajemen status klien dan server! Jika kita dapat mencapainya, mengapa bukan toko Redux yang isomorfik dan persisten?

Konsep apa pun yang dapat disatukan oleh komunitas JavaScript dan Infrastruktur, atau dengan mudah dipetakan di antaranya, semakin cepat saya berharap peluang ini menjadi jelas dan abstraksi yang lebih ekspresif.

Saya kira saya hanya mendapatkan sedikit bersemangat tentang beberapa ide ini! Saya harap Anda akan memaafkan saya untuk kata dump.

Catatan tambahan: Tampaknya mungkin untuk membuat API pembungkus seperti aliran acara untuk Redux yang mengimplementasikan permukaan yang saya sarankan di atas!

https://github.com/ajhyndman/redux-event-stream

@ajhyndman Saya pikir pembungkusnya adalah cara yang tepat untuk mengikuti ide Anda di sana 👍

Terkait dengan pekerjaan rekayasa samza dan linkedin yang Anda sebutkan, Jika orang lain belum membaca/menonton pembicaraan yang luar biasa Mengubah database luar-dalam dengan Apache Samza, maka silakan cari waktu satu jam untuk melakukannya kapan-kapan! Saya pikir saya melihat dan menyebutkannya di readme atau tweet di beberapa titik, Pembicaraan ini mengubah cara melihat database dan manajemen negara selamanya dan merupakan sepupu idealis redux yang sangat dekat.

Video itu luar biasa! Ini juga sebenarnya item kedua dalam daftar Terima kasih pada README repo redux repo.

Hai semuanya!

Tanpa menyadari keberadaan thread ini, saya telah mengembangkan sebuah perpustakaan yang dengan cara jawaban langsung untuk @markerikson 's pertanyaan asli dan mengetuk off kebanyakan hal dari @gaearon' s daftar .

Perpustakaan itu bernama Kea :

Ini adalah abstraksi atas redux, redux-saga, dan pemilihan ulang. Kecuali untuk lem yang menghubungkan mereka bersama-sama, Kea tidak berpura-pura membuat sesuatu yang baru dan memperlihatkan pembuat dan reduksi tindakan redux mentah, saga redux-saga mentah, dan pemilih pemilihan ulang mentah sesuai kebutuhan. Itu tidak menciptakan konsep baru.

Kea mendukung banyak mode operasi yang berbeda: Anda dapat menggunakannya secara mandiri, terhubung ke komponen React, digariskan di atas komponen React atau bahkan terhubung secara dinamis ke komponen React di mana input ke pemilih bergantung pada prop dari komponen React.

Saya pribadi menggunakannya dengan dua aplikasi besar: satu pasar untuk les privat dan dalam satu perangkat lunak pelacakan armada besar. Plus saya tahu orang-orang yang telah membangun aplikasi mereka sendiri dengan itu. Karena sangat berguna bagi kami, saya menghabiskan banyak waktu untuk membersihkannya dan menulis dokumentasi .

Bagi saya perpustakaan ini selalu sangat mengurangi boilerplate, sambil tetap setia pada inti redux itu sendiri.

Ngomong-ngomong, cukup bicara, ini beberapa kode. Ini adalah contoh dari apa yang saya sebut "inline kea" - di mana logika dilampirkan ke komponen Anda secara langsung. Mode ini sangat bagus ketika Anda baru memulai atau sebagai alternatif dari setState React.

import React, { Component } from 'react'
import PropTypes from 'prop-types'
import { kea } from 'kea'

@kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

Jika aplikasi Anda berkembang dan lebih banyak tempat memerlukan akses ke tindakan increment dan decrement atau prop counter , Anda dapat membagi kode seperti ini:

// counter-logic.js
import PropTypes from 'prop-types'
import { kea } from 'kea'

export default kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})

// index.js
import React, { Component } from 'react'
import { connect } from 'kea'

import counterLogic from './counter-logic'

@connect({
  actions: [
    counterLogic, [
      'increment',
      'decrement'
    ]
  ],
  props: [
    counterLogic, [
      'counter',
      'doubleCounter'
    ]
  ]
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

Silakan coba dan baca dokumen untuk melihat lebih banyak tentang efek samping melalui redux-saga dan fitur lain yang dapat Anda gunakan.

Umpan balik untuk Kea sangat positif sampai sekarang, mengutip dari sebuah masalah : "Lebih banyak orang harus menggunakan KeaJS karena membuat dunia redux menjadi tempat yang lebih baik! 👍" :)

Terima kasih atas waktu Anda dan telah membaca sejauh ini! :)

Terlihat bagus! tidak terlalu menyukai senar ajaib 'increment'

Apakah diskusi ini bergerak maju di tempat lain? Apakah Kea merupakan hasil yang paling benar yang diterima secara umum?

@lucfranken : tidak, diskusi gagal.

Jika Anda mencari abstraksi tingkat tinggi di atas Redux, maka Kea mungkin merupakan pilihan yang baik. Jika Anda sedang mencari "Redux starter pack" yang menyederhanakan proses penyiapan toko, Anda mungkin harus melihat-lihat beberapa. Saya tahu saya telah melihat beberapa hal seperti itu di alam liar, tetapi kami tidak memiliki lib resmi seperti itu sekarang.

Melempar topi saya di atas ring di sini. Inilah cara saya mengatasi masalah ini: https://github.com/HenrikJoreteg/redux-bundler

Saya pribadi berpikir ini adalah penyederhanaan besar dan pengurangan boilerplate.

Begitulah cara saya membangun semua yang saya bangun baru-baru ini.

Kira itu akan membantu:
https://github.com/anish000kumar/redux-box

Hei, di perusahaan saya, kami baru saja membuka perpustakaan sumber yang mengelola lapisan jaringan dan menghapus banyak boilerplate dari Redux. Ini telah terbukti berhasil bagi kami, tetapi cobalah sendiri: https://github.com/Brigad/redux-rest-easy/ (artikel menengah: https://engineering.brigad.co/introducing-redux-rest-easy -6e9a91af4f59)

inilah pendekatan saya untuk mengurangi boilerplate redux

https://github.com/zhDmitry/restate

Sebagai necroing thread yang sangat terlambat, beberapa waktu lalu saya meminta umpan balik di Twitter tentang apa arti "boilerplate" bagi orang-orang:

https://twitter.com/acemarke/status/96904835508604929

Kembalinya Necro-Thread!

Per suntingan saya pada komentar pertama di utas ini, ide-ide yang dibahas di sini telah diubah menjadi paket Redux-Starter-Kit kami . Silakan mencobanya dan lihat seberapa banyak itu dapat membantu menyederhanakan penggunaan Redux Anda!