Redux: Mengapa status tidak bisa dimutasi ....
Hai,
Saya membaca dengan minat tentang kekekalan, dan bagaimana Anda seharusnya tidak mengubah keadaan Anda. Saya mengerti sampai taraf tertentu mengapa itu, namun, sisi "prihatin tentang waktu yang dihabiskan untuk membuat objek baru" dari saya adalah tidak memahami di JS seberapa cepat / lambat ini, atau saya kehilangan sesuatu yang lain.
Biasanya, membuat objek baru, kurang lebih mengkloning objek lama ke yang baru ditambah penambahan status baru (atau pengurangan) menurut saya akan lebih memakan waktu daripada hanya memodifikasi status yang ada. Jadi saya mencoba untuk memahami mengapa hal yang kekal begitu penting dan apakah itu mempengaruhi sesuatu yang lain dalam rantai yang tidak saya lihat?
Selanjutnya .. Saya akan berpikir bahwa banyak dari apa yang ditawarkan Reduct dapat ditambahkan ke react-core, dan bahkan mungkin memanfaatkan mesin DOM diffing-nya ... bahkan mungkin untuk membantu menentukan apakah status harus bermutasi atau tidak. Saya tidak yakin apakah proses mutasi keadaan akan lebih cepat atau lebih lambat daripada membedakan keadaan dengan keadaan baru dan mengubah (mutasi) hanya bagian dari objek keadaan sebenarnya yang harus berubah?
Saya relatif baru dalam semua ini jadi maafkan saya jika saya kehilangan sesuatu di sekitar gagasan tidak bermutasi. Saya menyukai gagasan bahwa komponen seharusnya hanya membuat data yang tidak dapat diubah ... tetapi sekali lagi, ke komponen, tidak peduli atau tahu apakah itu tidak dapat diubah atau tidak .. itu hanya data yang diteruskan dari suatu tempat, jadi saya sedang berjuang bit dengan seluruh status tidak berubah vs bisa berubah.
justjacksonn
Semua 13 komentar
evgenyrodionov
pada 20 Sep 2015
Ini semua tentang prediktabilitas dan keandalan.
Pengurang dalam redux adalah fungsi murni, yang berarti tidak memiliki efek samping. Segera setelah Anda mulai melihat beberapa kondisi eksternal untuk fungsi tersebut, fungsi tersebut tidak lagi murni. Dan jika mereka tidak murni, mereka tidak bisa diandalkan. Dan itu menyebabkan bug, banyak di antaranya yang _very_ sulit dilacak.
Saya telah menemukan melalui penulisan fungsi murni, saya menghasilkan lebih sedikit kesalahan dalam kode saya dan saya lebih produktif. Dan pemuatan ulang modul panas (diaktifkan dengan menggunakan fungsi murni) adalah turbocharger di atas produktivitas itu.
timdorr
pada 21 Sep 2015
Dan Anda menerima fitur gratis seperti perjalanan waktu yang sangat berguna.
evgenyrodionov
pada 21 Sep 2015
Menutup sebagai duplikat dari # 328.
gaearon
pada 21 Sep 2015
Hanya untuk memperjelas: negara tidak terlalu klon pada setiap tindakan. Hanya bagian yang berubah yang di-kloning (sekali lagi, tidak terlalu dalam — bergantung pada apa yang berubah). Misalnya, ketika rencana diedit di aplikasi TodoMVC, hanya objek rencana itu yang digandakan. Sisa objek rencana lainnya sama. Tentu saja, root larik daftar rencana baru dibuat, menunjuk ke objek baru, tetapi objek itu sendiri tidak digandakan jika belum diubah. Oleh karena itu tidak semahal kelihatannya. Lebih lanjut, ketika menjadi mahal (misalnya perubahan larik yang cepat), Anda dapat mulai menggunakan pustaka seperti Immutable.js yang memiliki penyalinan sangat cepat berkat berbagi struktural. Dengan Immutable.js, menyalin bahkan array yang besar tidak terlalu mahal karena potongan besar dari memori digunakan kembali. Terakhir, baik dengan atau tanpa Immutable.js, immutability membantu kita merender aplikasi secara efisien karena kita tahu _apa sebenarnya_ yang telah berubah berkat objek yang tidak dimutasi.
gaearon
pada 21 Sep 2015
Ahh .... lihat bahwa bit terakhir masuk akal sekarang ... Saya berasumsi dengan ini Anda mengatakan bahwa karena komponen render berubah karena hanya keadaan apa yang berubah, mesin react diff / redraw lebih cepat sebagai hasilnya? Mirip saya kira dengan shouldComponentUpdate
justjacksonn
pada 21 Sep 2015
Saya berasumsi dengan ini Anda mengatakan bahwa karena perubahan render komponen karena hanya status apa yang berubah, mesin react diff / redraw lebih cepat sebagai hasilnya? Mirip saya kira dengan shouldComponentUpdate
Tepatnya, react-redux menggunakan shouldComponentUpdate agresif berkat jaminan keabadian.
gaearon
pada 21 Sep 2015
@gaearon Maaf untuk necro yang ini sedikit! tetapi komentar Anda tentang pembaruan array cepat:
Lebih lanjut, ketika menjadi mahal (misalnya perubahan larik yang cepat), Anda dapat mulai menggunakan pustaka seperti Immutable.js yang memiliki penyalinan sangat cepat berkat berbagi struktural.
Saya sedang menggunakan redux untuk menangani pembaruan ke sebuah array yang naik ke posisi 8000 dan mengharapkan throughput berada di wilayah 10-100 perubahan per 100 md. Apakah saya berjuang untuk kalah dalam mencoba mengelola keadaan seperti itu menggunakan redux?
Kami berencana untuk mewakili negara bagian melalui kanvas daripada DOM, tetapi saya ingin memahami apakah menurut pengalaman Anda frekuensi pembaruan akan menyebabkan masalah bagi kami atau tidak.
dougajmcdonald
pada 5 Des 2017
@dougajmcdonald : Pertanyaan pertama saya adalah, dapatkah pekerjaan itu digabungkan dengan cara tertentu? Apakah Anda _really_ perlu merepresentasikan setiap update sebagai gambar ulang UI yang terpisah?
Selain itu, saya menyarankan Anda untuk melihat sumber daya ini pada kinerja terkait Redux:
- Entri FAQ Redux tentang kinerja dan penskalaan , meminimalkan pemberitahuan langganan , dan penggunaan pemilih
- Posting saya Redux Praktis, Bagian 6: Daftar, Formulir, dan Kinerja yang Terhubung
- Bagian Kinerja Redux dari daftar tautan React / Redux saya
Saya juga akan senang membicarakan hal ini lebih lanjut di saluran obrolan Reactiflux .
markerikson
pada 5 Des 2017
@markerikson Sayangnya ya, konsep permainan ini melibatkan banyak pembaruan cepat ke struktur data yang relatif besar.
Saya menyadari saya tidak sepenuhnya jelas dalam komentar asli saya, ketika saya mengatakan 10-100 perubahan, ini tidak semua akan memicu penggambaran ulang. 10-100 perubahan adalah perubahan status yang akan diwakili oleh gambar ulang tunggal per 100 md.
Jadi pertanyaan saya adalah, jika saya mengumpulkan pembaruan saya menjadi 10-100 perubahan status per 100 md, akankah manajemen keadaan dalam redux dapat memproses ini secara efektif dengan cara yang akan diselesaikan secara bijaksana dalam jendela 100 md ke memungkinkan menggambar ulang tanpa hal-hal yang mulai tertinggal.
Pembaruan status pada dasarnya akan melibatkan perubahan 3-4 properti dalam larik berukuran 8000, jadi kita akan berbicara tentang membuat larik baru 1-10 kali per md (dengan asumsi kami ingin menjaga agar semuanya tidak berubah) dengan beberapa perubahan pada salah satu objek dalam indeks array. Objeknya cukup kecil (3-4 properti, beberapa angka dan beberapa string kecil)
Inilah sebabnya saya bertanya-tanya tentang manfaat menggunakan immutable seperti yang disarankan Dan, seolah-olah kita dapat menggunakan kembali array sebanyak mungkin, ini kemungkinan akan meningkatkan kinerja.
dougajmcdonald
pada 5 Des 2017
@dougajmcdonald : ya, "manajemen status di Redux" sebenarnya hanya satu fungsi peredam root _ Anda telah_ disediakan :)
Immutable.js bukanlah senjata ampuh yang meningkatkan kinerja. Itu bisa membuat beberapa hal lebih cepat, dan hal-hal lain lebih lambat. Saya punya banyak artikel tentang pertimbangan kinerja terkait Immutable.js yang mungkin ingin Anda lihat.
Sejujurnya, berdasarkan kasus penggunaan Anda, secara teori Anda _dapat_ lolos dari mutasi langsung jika Anda mau. Per posting saya Idiomatic Redux, Bagian 1 - Implementasi dan Maksud , inti Redux itu sendiri tidak benar-benar peduli dengan mutasi sama sekali - itu terutama lapisan UI React-Redux yang melakukannya, serta DevTools. Sekarang, mutasi bukanlah cara Anda _ dimaksudkan_ untuk menggunakan Redux, tetapi mungkin saja.
Saran pribadi saya adalah memulai dengan sederhana. Cukup gunakan objek dan array JS biasa. Perbarui mereka selamanya, baik "dengan tangan" atau menggunakan salah satu dari banyak pustaka utilitas pembaruan tetap yang tersedia. Lihat seberapa baik kinerjanya untuk Anda.
Kemudian, dari sana, Anda dapat melakukan pekerjaan pengoptimalan tambahan dalam hal pengelompokan, mengurangi pengiriman, memperbarui logika, dan sebagainya.
markerikson
pada 6 Des 2017
@markerikson hinaan halus diambil di hidung! : p Ya Anda benar, sisi peredam dari hal-hal saat ini pada dasarnya adalah pembuatan dan penghancuran array yang cukup besar tetapi saya pikir masalah sebenarnya adalah lebih mungkin reaksi komponen siklus hidup bit dan bobs ketika tujuan akhirnya akan menjadi elemen kanvas idealnya dirender pada FPS 60ish.
Terima kasih atas poin tentang kekal dan poin tentang mutasi langsung, saya akan membaca sedikit dan mempertimbangkan ini juga.
Saat ini, proses pemikiran saya adalah memutuskan status redux dari kanvas dan hanya meneruskan pesan ke sana melalui pub / sub (begitulah cara kami menghubungkannya) hanya dengan lebih banyak bagian yang bergerak
Saya berpikir untuk mengubah dari:
pubsub> dispatch ()> reducer> status redux> reaksi barang komponen> render kanvas.
Untuk:
pubsub> status komponen lokal> rendering kanvas
Saya masih akan menggunakan redux untuk UI lainnya, mungkin saja bukan bagian kanvas dari aplikasi.
dougajmcdonald
pada 6 Des 2017
Pertanyaan Anda sepenuhnya valid. Sebenarnya implementasi vuejs dari redux yang disebut vuex bekerja di bawah konsep mutasi. Jadi 'pereduksi' sebenarnya disebut mutasi dan selama Anda memodifikasi keadaan di tempat terpusat semuanya akan baik-baik saja. Ini terjadi karena vue menambahkan pengamat dan hal-hal lain ke status aplikasi sehingga seperti yang Anda sebutkan, lebih masuk akal di cae of vue untuk memodifikasi daripada mengganti objek. Redux tidak dapat diubah dan pada akhirnya kinerja kedua pendekatan react VS vue virtual DOM update sebagian besar sama pada titik yang tidak mungkin untuk mengatakan bahwa untuk semua kasus, satu lebih baik daripada yang lain
jscontreras
pada 24 Apr 2018
Masalah terkait
mickeyreiss-visor
·
3Komentar
vslinko
·
3Komentar
ms88privat
·
3Komentar
ilearnio
·
3Komentar
benoneal
·
3Komentar
Komentar yang paling membantu
Hanya untuk memperjelas: negara tidak terlalu klon pada setiap tindakan. Hanya bagian yang berubah yang di-kloning (sekali lagi, tidak terlalu dalam — bergantung pada apa yang berubah). Misalnya, ketika rencana diedit di aplikasi TodoMVC, hanya objek rencana itu yang digandakan. Sisa objek rencana lainnya sama. Tentu saja, root larik daftar rencana baru dibuat, menunjuk ke objek baru, tetapi objek itu sendiri tidak digandakan jika belum diubah. Oleh karena itu tidak semahal kelihatannya. Lebih lanjut, ketika menjadi mahal (misalnya perubahan larik yang cepat), Anda dapat mulai menggunakan pustaka seperti Immutable.js yang memiliki penyalinan sangat cepat berkat berbagi struktural. Dengan Immutable.js, menyalin bahkan array yang besar tidak terlalu mahal karena potongan besar dari memori digunakan kembali. Terakhir, baik dengan atau tanpa Immutable.js, immutability membantu kita merender aplikasi secara efisien karena kita tahu _apa sebenarnya_ yang telah berubah berkat objek yang tidak dimutasi.