Sebagai catatan: Saya telah membaca dokumen untuk Redux (Baobab, juga), dan saya telah melakukan bagian yang adil dari Googling & testing.
Mengapa sangat disarankan bahwa aplikasi Redux hanya memiliki satu toko?
Saya memahami pro / kontra dari pengaturan satu toko vs beberapa pengaturan toko ( Ada banyak T&J di SO tentang hal ini ).
IMO, keputusan arsitektur ini adalah milik pengembang aplikasi berdasarkan kebutuhan proyek mereka. Jadi mengapa sangat disarankan untuk Redux, hampir sampai terdengar wajib ( meskipun tidak ada yang menghentikan kita dari membuat banyak toko )?
EDIT: umpan balik setelah mengonversi ke satu toko
Setelah beberapa bulan bekerja dengan redux pada apa yang banyak orang anggap sebagai SPA kompleks, saya dapat mengatakan bahwa struktur toko tunggal telah menjadi kesenangan murni untuk bekerja dengannya.
Beberapa poin yang mungkin membantu orang lain memahami mengapa satu toko vs banyak toko adalah pertanyaan yang bisa diperdebatkan dalam banyak kasus penggunaan:
- itu dapat diandalkan : kami menggunakan penyeleksi untuk menggali status aplikasi dan mendapatkan informasi yang relevan dengan konteks. Kita tahu bahwa semua data yang dibutuhkan ada dalam satu toko. Ini menghindari semua pertanyaan tentang di mana masalah negara bisa terjadi.
- itu cepat : toko kami saat ini memiliki hampir 100 reduksi, jika tidak lebih. Bahkan pada hitungan itu, hanya sedikit reduksi yang memproses data pada pengiriman yang diberikan, yang lain hanya mengembalikan keadaan sebelumnya. Argumen bahwa toko besar / kompleks ( nbr reducers ) lambat cukup banyak diperdebatkan. Setidaknya kami belum melihat adanya masalah kinerja yang berasal dari sana.
- ramah debugging : sementara ini adalah argumen paling meyakinkan untuk menggunakan redux secara keseluruhan, itu juga berlaku untuk satu toko vs beberapa toko. Saat membuat aplikasi Anda pasti memiliki kesalahan status dalam proses ( kesalahan pemrogram ), itu normal. PITA adalah saat kesalahan tersebut membutuhkan waktu berjam-jam untuk debug. Berkat satu toko ( dan redux-logger ) kami tidak pernah menghabiskan lebih dari beberapa menit untuk masalah negara yang diberikan.
beberapa petunjuk
Tantangan sebenarnya dalam membangun toko redux Anda adalah ketika memutuskan bagaimana menyusunnya . Pertama, karena mengubah struktur di jalan hanyalah rasa sakit yang besar. Kedua, karena sebagian besar menentukan bagaimana Anda akan menggunakan, dan menanyakan data aplikasi Anda untuk proses apa pun. Ada banyak saran tentang cara membuat struktur toko. Dalam kasus kami, kami menemukan yang berikut ini ideal:
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}Semoga umpan balik ini akan membantu orang lain.
EDIT 2 - alat bantu toko
Bagi Anda yang telah bertanya-tanya bagaimana cara "dengan mudah" mengelola satu toko , yang dapat dengan cepat menjadi rumit. Ada alat yang membantu mengisolasi dependensi / logika struktural toko Anda.
Ada Normalizr yang menormalkan data Anda berdasarkan skema. Itu kemudian menyediakan antarmuka untuk bekerja dengan data Anda dan mengambil bagian lain dari data Anda dengan id, seperti Kamus.
Tidak mengenal Normalizr pada saat itu, saya membangun sesuatu di sepanjang jalur yang sama. relational-json mengambil skema, dan mengembalikan antarmuka berbasis Tabel ( sedikit seperti database ). Keuntungan dari relational-json adalah bahwa struktur data Anda secara dinamis mereferensikan bagian lain dari data Anda ( pada dasarnya, Anda dapat melintasi data Anda ke segala arah, sama seperti objek JS normal ). Ini tidak setua Normalizr, tetapi saya telah menggunakannya dengan sukses dalam produksi selama beberapa bulan sekarang.