Penafian
Pembaca yang terhormat! Jika Anda tidak tahu apa React dan Redux, membaca lebih lanjut tidak masuk akal, omong kosong teknis lebih lanjut. Saya serius, memahami untuk apa catatan ini, memerlukan kerja sama dengan perpustakaan-perpustakaan ini - meskipun saya akan mencoba menulis dengan jelas, artikel ini bukan yang masuk ke level pemula. Dan ini adalah pengalaman dan pendapat pribadi berdasarkan praktik.
Apa yang salah dengan menggunakan Redux?
Kemudian saya memutuskan untuk menulis, tetapi apa yang sebenarnya salah dengan menggunakan redux di proyek saya dan ribuan lainnya? Saya sudah menulis aplikasi reaksi / redux sejak April 2016 (tiga tahun). Sudah waktunya untuk menemukan beberapa hal menarik ... Dan kemudian ada ceramah dan laporan, terutama ditujukan untuk pemula, tetapi tidak ada orang dewasa yang melihat ke belakang dan retrospektif. Sementara itu, seseorang menaruh tanda bintang dalam paket yang memeriksa "bukan 13 jam," Saya akan mematahkan dinding stereotip yang berlaku.
Tetapi redux tidak diperlukan!
Anda berkata, dan dalam beberapa hal Anda akan benar. Anda tidak dapat menggunakannya sejak 2018 - ada banyak artikel tentang topik ini di Internet, tetapi sejauh ini dengan "tidak digunakan" Anda mendapatkan pertanian kolektif, itu akan menjadi jelas di bawah alasannya. Dan jumlah alternatif di luar skala dan bahkan lebih.
Kami menggunakan Redux, karena ini merupakan standar yang dapat diterima (setidaknya untuk bereaksi), prediktabilitas dan keandalan yang dimiliki Redux penting bagi kami. Tapi kami sangat merindukannya, sebenarnya dalam hal ini
Klaim
Mungkin, untuk memperjelas apa klaim tentang poin, pertama Anda harus kembali ke masa lalu, ke akar, seperti yang Anda inginkan, yaitu, buka dokumentasi redux yang mulia dan baca postulatnya. Saya akan mempertimbangkan hanya yang pertama dari mereka. Jika itu menarik bagi Anda - bagikan dalam komentar, saya akan menganalisis lebih banyak poin.
Satu-satunya sumber kebenaran ...
Di sini kita memiliki serangan. Tentu saja, dikatakan ada 1 cerita, redux menyatakan perbedaannya dari arsitektur fluks dengan cara ini. Tetapi jika Anda melihat lebih luas: apakah aturan tersebut diamati dalam proyek nyata? Anda akan mengatakan: cukup. Saya menyatakan (menyatakan) 1 sisi, saya mentransfernya ke penyedia dan kemudian ...
Secara teknis, prosesnya dijelaskan dengan benar. Tetapi saya dapat mengatakan bahwa orang-orang tunduk pada distorsi persepsi, logika, dan karena programmer masih manusia ... Nah, Anda mengerti apa yang saya tuju (jika Anda tidak mengerti: programmer cenderung mengalami distorsi persepsi, logika, dll.)
Distorsi utama di sini adalah bahwa saya, seperti banyak rekan saya, terbiasa dengan kenyataan bahwa jika kita tidak menggunakan istilah "toko" dalam kaitannya dengan apa pun selain redux, maka tidak ada yang lain.
Dan inilah reaksi
Salah satu fitur teknis yang disebut keadaan internal ingin meludahi postulat ini. Ini hanya membuat penyimpanan tipe keadaan internal di tempat yang nyaman. Ada komponen - ada keadaan yang memiliki mekanisme untuk memperbarui dan mempengaruhi komponen. Perbedaan penggunaan (keadaan toko, pembaruan, dan perubahan siaran) hampir tidak terlihat. Anda dapat mengajukan keberatan: tidak sepenuhnya jelas mengapa Anda tidak menyukai status komponen. Dia tidak seperti editor, bagaimana mereka bisa dibandingkan! Itu internal, baik, bendera apa yang akan disimpan di sana.
Pahami bahwa esensi tidak berubah dari fakta bahwa Anda mengganti nama item. Ada palu godam Senin, ini tidak membuatnya menjadi hari dalam seminggu. Ya, kedua hari Senin itu sulit, hari-hari lain dan palu godam lebih mudah. Namun dari namanya, palu godam tidak berhenti menjadi instrumen perkusi.
Skala komponen reaksi reduks dan keadaan berbeda, tetapi esensinya, bila digunakan hari ini, adalah satu.
Saya akan menjelaskannya dengan cara ini: dalam kebanyakan kasus data dari keadaan internal komponen pergi ke anak melalui alat peraga, tetapi, tidak peduli seberapa jelas itu, data redux, ketika terintegrasi dengan reaksi, juga masuk ke komponen melalui alat peraga. Dari sudut pandang komponen yang menerima alat peraga, tidak masalah apa yang ada di luar. Artinya, untuk pengguna akhir - toko redux itu, keadaan internal itu - adalah sama.
Juga, keadaan internal ini mungkin tidak tergantung pada alat peraga dari komponen di mana ia dinyatakan. Kemudian kita mendapatkan isolasi yang membuat keadaan internal seperti itu menjadi toko yang lebih besar dari yang Anda bayangkan.
Agar benar-benar internal, itu hanya akan mempengaruhi komponen di mana ia dinyatakan, tanpa memberikan kebocoran pada komponen anak. Apakah ini sulit? Cukup, karena maknanya hampir sepenuhnya hilang. Ini adalah tanda lain bahwa keadaan internal adalah toko. Setelah semua, kami hanya menghapus satu titik dari tujuan "menyimpan keadaan, memperbarui dan menyiarkan perubahan" - menyiarkan perubahan. Semuanya, negara hilang.
Artinya, masalah utama dengan memiliki keadaan internal adalah bahwa ia bersaing dengan redux untuk data, kehilangan dalam jangka panjang, dan omong kosong. Kami memiliki semua jenis teknik seperti mengangkat status (inilah saat saudara kandung elemen host diperlukan, sehingga bagian negara dan semua logika bekerja dengannya dibawa ke induk, menghabiskan banyak waktu menulis ulang dan menguji logika kerja), dll. Bug dan overhead muncul dalam perbaikan dan banyak kesenangan. Ini semua suara yang merusak perangkat lunak kami pada tahap pengembangan. Kami belum mencapai penjualan, tetapi perangkat lunaknya sudah seperti itu.
Yaitu, untuk semua tanda dan masalah, kami memiliki lebih dari satu cerita dan banyak masalah yang terkait dengan ini. Hal terakhir, mungkin, adalah sebagai berikut:
Saya juga suka redux untuk jenis devtools yang dimilikinya. Ketika saya mulai, kami menggunakan logger yang hanya menggabungkan semua tindakan, tanpa memberikan, gambaran lengkap tentang apa yang terjadi. Sekarang - ini adalah asisten dan teman utama. Di Bereaksi, mereka juga diwakili. Secara umum, devtools adalah alasan mengapa pubsub jauh dari Redux. Seperti semut untuk paus biru.
Masalah (tidak akan ada bukti DNA):
- mengubah keadaan internal melalui devtools reaksi terkadang tidak mengarah pada pembaruan atau hasil yang diinginkan - Saya berdosa saat integrasi dengan redux.
- keadaan internal istirahat timet di redux devtools. Fitur super dengan perjalanan waktu yang tersedia melalui arsitektur redux tidak berfungsi berkat arsitektur state internal. Keadaan internal tidak peduli tentang perubahan redux, ia memiliki kondisi sendiri. Timetravel tidak berhasil. Beberapa elemen sama sekali tidak diperbarui, diperbarui sebagian, dll. Semua epik ini dengan sinkronisasi kode asinkron.
Contohnya, tentu saja tersedot dari latihan
Anda sedang mengerjakan proyek baru untuk Anda, atau kolega Anda menulis beberapa fungsi setahun yang lalu, dan sekarang Anda perlu mengembangkannya. Secara umum, ada tugas menyelesaikan kode orang lain. Anda mulai menyelidiki, dan memahami bahwa tidak ada data di editor. Tidak ada tindakan, reduksi dalam kode yang menyimpan data yang Anda butuhkan. Dan Anda memulai perjalanan melalui pohon komponen untuk mencari yang berharga dan menemukannya (!!!) bahkan beberapa keping. Anda bertanya kepada kolega, tetapi jawabannya standar: Saya tidak ingat menulis ke negara lebih cepat, kami tidak punya waktu dan sebagainya. Anda pergi ke sumber dan memahami bahwa keadaan saat ini tidak melibatkan revisi. Anda menulis ulang yang berfungsi, kode yang diuji untuk melakukan perubahan dan menambahkan fungsionalitas baru.
Kehadiran alternatif yang merusak dalam bentuk keadaan internal melakukan tindakan kotornya. Lagi pula, sekarang ini murah, dan tidak masalah apa yang terjadi dalam setahun.Beberapa metafora
Sepertinya makanan yang buruk - rasanya enak dan murah, tetapi setelah satu atau tiga tahun - saluran pencernaan berhenti mematuhi dan menjalani hidupnya sendiri. Anda menghabiskan banyak waktu dan uang untuk mendapatkan kembali kesehatan Anda sebelumnya dan tidak selalu berhasil dalam hal ini.
Redux dan React Internal State adalah pesaing , seperti bisnis besar dan kecil dalam satu ceruk. Produk utama adalah data dan pengaruh. Perangkat lunak adalah konsumen dari produk mereka. Ada banyak analogi, tetapi esensinya tetap sama - ketika kita mengembangkan perangkat lunak - kita tidak membutuhkan persaingan.
Kami adalah "diktator" kode program dan persaingan apa pun harus ditekan, pasar bebas harus dilarang, dan ekonomi yang direncanakan serta monopoli negara harus mendominasi konsumen.Ahem, sesuatu membuatku bosan. Semuanya harus berjalan sesuai rencana, secara umum. Kami memiliki sprint, rilis, dan banyak lagi, dan perangkat lunak memiliki biaya yang terbatas dan masa pakai / masuk ke pasar. Ini sangat penting, dan kami tidak bisa membiarkan kerusuhan di kapal, pemberontakan perpustakaan.
Kesimpulannya sederhana.
Jangan gunakan repositori lain dengan redux. Pengecualian hanya dapat membuat kasus yang sangat terisolasi. Misalnya, komponen yang pada prinsipnya tidak dikontrol oleh redux tanpa lapisan yang sesuai dan tidak mempengaruhinya.
Contoh
Saya mengembangkan modul mandiri di satu cabang dan refactoring toko di yang lain - secara umum, pendekatan saya untuk mengelola toko dan negara adalah topik yang terpisah untuk publikasi. Saya mulai refactoring ke modul, tetapi pada saat awal dan akhir penulisan modul, refactoring ke tes dan ke wizard tidak hilang. Refactoring adalah besar dan membutuhkan jalan lain yang perlu direncanakan - secara umum, Anda tidak bisa hanya mengambil dan refactor.
Karena itu, mengetahui tentang perubahan yang akan terjadi di toko, saya tidak menggunakannya untuk mengembangkan fitur baru. Ini akan meningkatkan biaya memperbarui refactoring dan tes yang diabaikan di waktu.
Apa yang saya lakukan: Saya mendaftar untuk data minimum. Data dan strukturnya tidak mengalami refactoring, kode yang membuat mereka menderita, disimpan, dll. Saya tidak menulis byte ke editor. Saya memeriksa apakah pengguna login dan beberapa bidang lagi.
Untuk kebutuhan saya, saya mencuci PubSub dengan saluran dan API sederhana. Ya, ya, pubsab. Kurangnya nyeri menyakitkan yang normal. Perjalanan Waktu - Nyeri. Secara umum, saya berencana untuk menulis ekstensi untuk chrome dalam bentuk devtools dan dimungkinkan untuk menerbitkan implementasi ulang sebagai pesaing untuk redux di github. Saya punya banyak keluhan tentang redux, yang tidak akan saya bahas di artikel ini, tetapi PubSub praktis tidak memilikinya. Selain fakta bahwa saya ingat redux logger ...
Dan modul ini memiliki penyimpanan sendiri, koneksi sendiri ke server.
Artinya, redux tidak memengaruhi modul sama sekali, praktis tidak dapat memengaruhi penyimpanan ini (hanya ada tiga bidang dalam langganan), tetapi modul dan PubSub tidak memengaruhi redux dengan cara apa pun. Pemisahan ini tidak termasuk kompetisi.
Pertanyaan "di mana menyimpan data?" ketika mengembangkan modul, saya belum pernah menemukannya. Tetapi ketika datang ke redux vs internal state - bagi banyak pertanyaan ini muncul hampir secara konstan. Saya memutuskan untuk menjawab pertanyaan ini untuk selamanya.
Pendapat arsitektur saya adalah:
Simpan data hanya dalam redux (semua-semua, bahkan "internal"), jika terhubung ke proyek reaksi Anda sebagai repositori utama, jangan gunakan repositori yang akan bersaing dengannya. Ini akan meningkatkan keandalan dan dampak pustaka ini dan devtoolsnya (pelacakan waktu dan pelacakan semua data dalam langkah-langkah mempercepat pengembangan dan mencari kemungkinan masalah - perubahan sinkron lebih curam dan lebih mudah untuk disinkronkan).
Mungkin perlu menambahkan perpustakaan yang sepenuhnya mengecualikan keadaan internal dari pembangunan? Atau mengganti keadaan internal dengan seleksi dari redux, misalnya? Saya mulai menulis satu tahun yang lalu, selesai 90 persen, dan bahkan melakukan 1 laporan. Apa yang kamu katakan Butuh itu?
Saya harap Anda menikmati catatan ini :)