React-Redux: Haruskah semua status komponen disimpan di Redux Store

89

Katakanlah saya memiliki toggle sederhana:

Saat saya mengklik tombol, komponen Color berubah antara merah dan biru

Saya mungkin mencapai hasil ini dengan melakukan sesuatu seperti ini.

index.js

Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red

container.js

connect(mapStateToProps)(indexPage)

action_creator.js

function changeColor(){
 return {type: 'CHANGE_COLOR'}
}

reducer.js

switch(){
case 'CHANGE_COLOR':
return {color: true}

tetapi ini adalah banyak sekali kode untuk ditulis untuk sesuatu yang bisa saya capai dalam 5 detik dengan jQuery, beberapa kelas, dan beberapa css ...

Jadi saya rasa yang sebenarnya saya tanyakan adalah, apa yang salah saya lakukan di sini?

javascript  reactjs  redux 
— l2silver
sumber
6
react-redux tidak dijual sebagai sesuatu yang lebih pendek dari jquery. Ini pasti membutuhkan beberapa kode untuk mengaktifkan dan menjalankannya.
— zerkms
1
Lihat di sini: github.com/rackt/redux/issues/1287 ada banyak diskusi bagus tentang subjek ini.
— m0meni
1
terima kasih @ AR7 itu sempurna
— l2ilver
1
@ l2silver tidak masalah. Pada dasarnya idenya adalah jika warna komponen itu tidak penting bagi orang lain, pertahankan status itu internal ke komponen itu sendiri.
— m0meni
2
masalah yang disebutkan AR7 telah berpindah: github.com/reactjs/redux/issues/1287
— ptim

Jawaban:

156

Redux terutama ditujukan untuk "status aplikasi". Artinya, apa pun yang terkait dengan logika aplikasi Anda. Tampilan yang dibangun di atasnya adalah cerminan dari status tersebut, tetapi tidak harus secara eksklusif menggunakan penampung status tersebut untuk semua yang dilakukannya.

Ajukan saja pertanyaan-pertanyaan ini: Apakah status ini penting untuk aplikasi lainnya? Akankah bagian lain dari aplikasi berperilaku berbeda berdasarkan status itu? Dalam banyak kasus kecil, bukan itu masalahnya. Ambil menu tarik-turun: Fakta bahwa itu buka atau tutup mungkin tidak akan berpengaruh pada bagian lain dari aplikasi. Jadi, menghubungkannya ke toko Anda mungkin berlebihan. Ini tentu saja merupakan opsi yang valid, tetapi tidak benar-benar memberi Anda keuntungan apa pun. Anda lebih baik menggunakanthis.state dan menyebutnya sehari.

Dalam contoh khusus Anda, apakah warna tombol itu diubah untuk membuat perbedaan di bagian lain aplikasi? Jika itu semacam toggle hidup / mati global untuk sebagian besar aplikasi Anda, itu pasti milik toko. Tetapi jika Anda hanya mengubah warna tombol saat mengklik tombol, Anda dapat membiarkan status warna ditentukan secara lokal. Tindakan mengklik tombol mungkin memiliki efek lain yang memerlukan pengiriman tindakan, tetapi itu terpisah dari pertanyaan sederhana tentang warna apa yang seharusnya.

Secara umum, cobalah untuk menjaga status aplikasi Anda sekecil mungkin. Anda tidak harus mendorong semua yang ada di sana. Lakukan ketika Anda harus atau sangat masuk akal untuk menyimpan sesuatu di sana. Atau jika itu membuat hidup Anda lebih mudah saat menggunakan Dev Tools. Tapi jangan terlalu membebani kepentingannya.

— Tim Dorr
sumber
Hei, saya tahu tidak akan pernah ada jawaban pasti untuk pertanyaan ini, tapi saya pikir logika Anda sangat kuat di sini
— l2silver
3
Sejujurnya saya sama sekali tidak mengerti apa gunanya menggunakan hal flux / redux itu. Apa masalah dengan model berbasis peristiwa?
— jayarjo
IMO, ini bukanlah jawaban yang sempurna. Tergantung. Menyimpan status ui ke dalam status react akan membuat redux store bersih tetapi akan berakhir dengan komponen non-fungsional yang sulit untuk diuji. Saat menyimpan status ui ke dalam status react akan menambah banyak upaya pada dev, karena kita harus menulis reduksi ekstra. Namun, ada banyak paket yang dapat membantu Anda menempatkan status ui Anda lebih mudah untuk penyimpanan redux , periksa redux.js.org/docs/faq/OrganizingState.html untuk lebih jelasnya.
— Ron
19

FAQ Redux: Status Pengorganisasian
, bagian dari dokumen resmi redux ini menjawab pertanyaan Anda dengan baik.

Menggunakan status komponen lokal tidak masalah . Sebagai pengembang, tugas Anda adalah menentukan jenis negara bagian yang membentuk aplikasi Anda, dan di mana setiap bagian harus berada. Temukan keseimbangan yang sesuai untuk Anda, dan lakukan.

Beberapa aturan umum untuk menentukan jenis data apa yang harus dimasukkan ke dalam Redux:

  • Apakah bagian lain dari aplikasi peduli dengan data ini?
  • Apakah Anda harus dapat membuat data turunan lebih lanjut berdasarkan data asli ini?
  • Apakah data yang sama digunakan untuk menggerakkan banyak komponen?
  • Apakah ada nilai bagi Anda untuk dapat memulihkan keadaan ini ke titik waktu tertentu (mis., Debugging perjalanan waktu)?
  • Apakah Anda ingin menyimpan data ke cache (yaitu, menggunakan status apa jika sudah ada, bukan meminta ulang)?
— chuck911
sumber
6

Untuk tujuan menyoroti tautan bagus yang disediakan oleh @ AR7, dan karena tautan itu dipindahkan beberapa waktu lalu:

Gunakan React untuk keadaan singkat yang tidak penting bagi aplikasi secara global dan tidak bermutasi dengan cara yang rumit. Misalnya, tombol beralih di beberapa elemen UI, status input formulir. Gunakan Redux untuk status yang penting secara global atau dimutasi dengan cara yang kompleks. Misalnya, pengguna yang disimpan dalam cache, atau draf posting.

Terkadang Anda ingin berpindah dari status Redux ke status React (saat menyimpan sesuatu di Redux menjadi canggung) atau sebaliknya (ketika lebih banyak komponen perlu memiliki akses ke beberapa status yang dulunya lokal).

Aturan praktisnya adalah: lakukan apa pun yang tidak terlalu canggung.

Dan Abramov: https://github.com/reactjs/redux/issues/1287#issuecomment-175351978

— ptim
sumber
-8

Ya, ada baiknya berusaha menyimpan semua status komponen di Redux . Jika Anda melakukannya, Anda akan mendapatkan keuntungan dari banyak fitur Redux seperti debugging perjalanan waktu dan laporan bug yang dapat diputar ulang. Jika tidak, fitur tersebut mungkin tidak dapat digunakan sepenuhnya .

Setiap kali Anda tidak menyimpan perubahan status komponen di Redux, perubahan itu benar-benar hilang dari tumpukan perubahan Redux dan UI aplikasi Anda tidak akan sinkron dengan penyimpanan. Jika ini tidak penting bagi Anda, tanyakan pada diri Anda mengapa menggunakan Redux? Aplikasi Anda tidak akan terlalu rumit tanpanya!

Untuk alasan kinerja, Anda mungkin ingin kembali ke this.setState()apa pun yang akan mengirimkan banyak tindakan berulang kali. Misalnya: menyimpan status kolom input di Redux setiap kali pengguna mengetik kunci dapat mengakibatkan performa yang buruk. Anda dapat menyelesaikan ini dengan memperlakukannya seperti transaksi: setelah tindakan pengguna "dilakukan", simpan status akhir di Redux.

Posting asli Anda menyebutkan bagaimana cara Redux adalah "sangat banyak kode untuk ditulis". Ya, tetapi Anda dapat menggunakan abstraksi untuk pola umum seperti status komponen lokal.

— kumar303
sumber
Debugging yang ditingkatkan adalah tujuan yang berguna dan fitur bagus dari redux, tetapi menurut saya rasio signal to noise juga penting. Seseorang dapat mencatat setiap variabel dalam basis kode, tetapi itu akan menambahkan banyak kode tambahan yang membuat kode sebenarnya lebih sulit untuk dibaca dan pencatatan akan sulit untuk dicari. Saya rasa hal yang sama berlaku untuk penggunaan redux. Memiliki semua status di redux dapat meningkatkan proses debug, tetapi ada biaya dalam kode tambahan dan abstraksi yang dapat membuat kode lebih sulit dibaca dan bahkan membuat beberapa tugas debug lebih sulit. (Dan ketika alat pengembang redux macet, banyak keuntungan debugging hilang.)
— JD Sandifer
1
Lalu mengapa menggunakan Redux? Jika Anda tidak meletakkan semuanya di Redux, Anda kehilangan semua fitur, seperti devtools. Itu benar-benar semua atau tidak sama sekali. Jika Anda menggunakan setState () untuk menu dropdown seperti di jawaban atas posting ini, Anda tidak dapat menggunakan devtools untuk men-debug masalah apa pun yang mungkin ditemui pengguna Anda dalam menu dropdown. Lebih buruk bila Anda menggunakan setState () untuk hamparan karena tidak ada cara untuk menjelajah waktu sebelum dan sesudah hamparan ditampilkan. Menyemprotkan setState () di sana-sini sangat rawan kesalahan karena pengembang harus terus memikirkan apa yang mungkin rusak.
— kumar303
Sebagai jawaban yang lebih spesifik, mencatat setiap variabel dalam basis kode bukanlah metafora yang membantu karena pertanyaannya adalah tentang apakah akan menggunakan this.setState()atau dispatch(action...). Seseorang tidak perlu menggunakan di this.setState()mana-mana tetapi ketika Anda perlu, saran saya adalah menggunakan Redux sebagai gantinya untuk 99% kasus, kembali ke this.setState()1% berdasarkan masalah kinerja.
— kumar303
Mencatat setiap variabel menurut saya mirip dengan meletakkan semuanya di Redux dan sama-sama tidak disarankan sebagai aturan umum. Meninggalkan beberapa hal dari Redux tidak meniadakan fitur untuk semua yang ada di Redux selama statusnya terpisah. Yaitu saya masih bisa men-debug logika panggilan API saya yang disalurkan melalui Redux bahkan jika status kotak pilihan tidak. OP ada benarnya - ini membutuhkan lebih banyak kode di banyak tempat untuk menggunakan Redux dan mungkin itu tidak dibenarkan dalam contoh spesifik yang mereka daftarkan.
— JD Sandifer
Sebenarnya Anda mungkin tidak dapat men-debug logika API Anda. Itu maksudku. Sangat sulit untuk meramalkan skenario di mana Anda akan menghentikan perjalanan waktu jadi lebih baik meletakkan semua status (termasuk status kotak pilihan) di Redux sampai ada masalah kinerja.
— kumar303
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.