Kesulitan bekerja dengan Redux dan solusinya

Redux di antara kita

Ini adalah salah satu manajer negara yang paling populer.

Mudah digunakan, transparan, dan dapat diprediksi. Dengannya, Anda dapat mengatur penyimpanan dan modifikasi data. Dan jika kita mengasumsikan bahwa action `dan reducer` adalah bagian dari redux` a, maka kita dapat mengatakan tanpa berlebihan bahwa dia adalah pemegang semua logika area subjek (alias logika bisnis) dari aplikasi kita.

Apakah semuanya begitu cerah?

Untuk semua kesederhanaan dan transparansi, menggunakan redux memiliki sejumlah kelemahan ...

Data dalam keadaan ` redux` dan terletak di objek javascript sederhana dan dapat diperoleh dengan cara biasa, Anda hanya perlu tahu jalannya .

Tetapi bagaimana kita mengatur data ini? Hanya ada 2 opsi: daftar datar dan model hierarkis .

Daftar datar adalah pilihan yang bagus untuk aplikasi yang hanya ada, misalnya, penghitung ... Untuk sesuatu yang lebih serius, kita memerlukan struktur hierarkis. Selain itu, setiap level data akan memiliki lebih sedikit pengetahuan daripada yang sebelumnya. Semuanya logis dan dapat dimengerti, tetapi jalur menuju data menjadi komposit .



Kehadiran struktur data hierarkis dan kurangnya pendekatan modular untuk data ini mengarah pada fakta bahwa di setiap tempat di mana data ini digunakan, perlu untuk mengetahui jalur lengkap untuk itu. Dengan kata lain, ini menciptakan kohesi struktur penyimpanan data dan struktur tampilan dan menyebabkan kesulitan dengan refactor jalur dan / atau reorganisasi struktur data.




Tantangan lain adalah pengujian. Ya, ada artikel terpisah dalam dokumentasi untuk pengujian redux , tetapi sekarang ini bukan tentang menguji artefak individu seperti peredam dan pembuat tindakan .

Data, aksi , dan peredam biasanya saling berhubungan. Dan satu pohon data yang berhubungan secara logis sering dilayani oleh beberapa reduksi , yang perlu diuji termasuk bersama-sama.

Tambahkan ke daftar pemilih ini , hasil yang tergantung khususnya pada karya peredam ...

Secara umum, Anda dapat menguji semua ini, tetapi Anda harus berurusan dengan banyak artefak yang hanya saling terhubung oleh logika dan konvensi.

Dan bagaimana jika kita menemukan struktur, misalnya, dengan data pengguna, termasuk daftar teman, lagu favorit, dan yang lainnya, serta fungsi mengubahnya melalui pengurang aksi . Mungkin kami bahkan menulis banyak tes untuk semua fungsi ini. Dan sekarang di proyek selanjutnya kita membutuhkan hal yang sama ...

Bagaimana cara membuat kode murah?

Cari solusinya

Untuk mengetahui cara mempertahankan manfaat redux dan menyingkirkan kelemahan yang dijelaskan, Anda harus memahami apa yang tergantung pada siklus hidup data:

• Acara melaporkan aksi , kebiasaan, dan lainnya
• Peredam bereaksi terhadap aksi dan mengubah atau tidak mengubah status data
• Perubahan data adalah peristiwa itu sendiri dan dapat menyebabkan data lain berubah.

Pengontrol dalam hal ini adalah abstraksi yang memproses tindakan pengguna dan perubahan data di toko . Dia tidak harus menjadi kelas yang terpisah sama sekali, sebagai suatu peraturan, dia tersebar oleh komponen.

Gabungkan seluruh kebun binatang redux dalam kotak hitam

Tetapi bagaimana jika Anda membungkus aksi , peredam dan pemilih dalam satu modul dan mengajarkannya untuk tidak bergantung pada jalur spesifik untuk lokasi datanya?

Bagaimana jika semua tindakan pengguna , misalnya, dilakukan dengan memanggil metode instance: user.addFriend (friendId) ? Dan data diperoleh melalui getter: user.getFriendsCount () ?

Bagaimana jika kita dapat mengimpor semua fungsionalitas pengguna dengan impor sederhana?

 const userModule from 'node_modules/user-module'; 

Apakah itu nyaman? Terutama mengingat bahwa untuk ini Anda tidak perlu menulis banyak kode tambahan:
Paket npm redux -module-creator menyediakan semua fungsionalitas untuk membuat modul redux yang dapat digabungkan, digunakan kembali , dan diuji secara longgar .

Setiap modul terdiri dari pengontrol , peredam, dan aksi dan memiliki fitur berikut:

• terintegrasi ke dalam toko melalui panggilan ke metode integrator, dan untuk mengubah tempat integrasi, Anda hanya perlu mengubah tempat panggilan integrator dan parameternya
  
  
  
• controller memiliki koneksi dengan bagian data di toko , mengingat jalur yang dilewatkan ke integrator () sekali. Ini menghilangkan kebutuhan untuk mengetahuinya saat menggunakan data.
  
  
  
• controller adalah pemegang semua penyeleksi, adaptor, dll yang diperlukan
• untuk melacak perubahan, dimungkinkan untuk berlangganan perubahan pada data Anda sendiri
• reducer dapat menggunakan konteks panggilan - sebuah instance dari modul dan mendapatkan actionType milik modul itu. Ini menghilangkan kebutuhan untuk mengimpor banyak tindakan dan mengurangi kemungkinan kesalahan.
• action mendapatkan konteks penggunaan, karena mereka menjadi bagian dari contoh modul: sekarang ini bukan hanya trainingFinished , tetapi readingModule.actions.trainingFinished
• action `s sekarang ada di namespace modul, yang memungkinkan Anda untuk membuat acara dengan nama yang sama untuk modul yang berbeda
• setiap modul dapat dipakai beberapa kali, dan setiap instance diintegrasikan ke dalam berbagai bagian toko
• action`s untuk instance modul yang berbeda memiliki actionType yang berbeda - Anda dapat menanggapi peristiwa dari instance tertentu

Akibatnya, kami mendapatkan kotak hitam yang dapat mengelola datanya sendiri dan memiliki pegangan untuk berkomunikasi dengan kode eksternal.

Pada saat yang sama, itu adalah redux yang sama, dengan aliran data searah, transparansi dan dapat diprediksi.

Dan karena ini semua redux yang sama dan semua reduksi yang sama, Anda dapat membangun struktur apa pun dari mereka yang diperlukan oleh logika domain aplikasi.