Pada bab Mendesain Bentuk Status, dokumen menyarankan untuk mempertahankan status Anda dalam objek yang dikunci oleh ID:
Simpan setiap entitas dalam objek yang disimpan dengan ID sebagai kunci, dan gunakan ID untuk mereferensikannya dari entitas lain, atau daftar.
Mereka melanjutkan ke negara bagian
Pikirkan status aplikasi sebagai database.
Saya sedang mengerjakan bentuk status untuk daftar filter, beberapa di antaranya akan terbuka (ditampilkan dalam popup), atau telah memilih opsi. Saat saya membaca "Anggap status aplikasi sebagai database", saya berpikir untuk menganggapnya sebagai respons JSON karena akan dikembalikan dari API (yang didukung oleh database).
Jadi saya memikirkannya sebagai
[{
id: '1',
name: 'View',
open: false,
options: ['10', '11', '12', '13'],
selectedOption: ['10'],
parent: null,
},
{
id: '10',
name: 'Time & Fees',
open: false,
options: ['20', '21', '22', '23', '24'],
selectedOption: null,
parent: '1',
}]
Namun, dokumen menyarankan format yang lebih mirip
{
1: {
name: 'View',
open: false,
options: ['10', '11', '12', '13'],
selectedOption: ['10'],
parent: null,
},
10: {
name: 'Time & Fees',
open: false,
options: ['20', '21', '22', '23', '24'],
selectedOption: null,
parent: '1',
}
}
Secara teori, itu tidak masalah selama datanya dapat diserialkan (di bawah judul "State") .
Jadi saya pergi dengan pendekatan array-of-objects dengan senang hati, sampai saya menulis reducer saya.
Dengan pendekatan object-keyed-by-id (dan penggunaan liberal sintaks spread), OPEN_FILTERbagian reducer menjadi
switch (action.type) {
case OPEN_FILTER: {
return { ...state, { ...state[action.id], open: true } }
}
Sedangkan dengan pendekatan array-of-objects, itu lebih verbose (dan fungsi pembantu bergantung)
switch (action.type) {
case OPEN_FILTER: {
// relies on getFilterById helper function
const filter = getFilterById(state, action.id);
const index = state.indexOf(filter);
return state
.slice(0, index)
.concat([{ ...filter, open: true }])
.concat(state.slice(index + 1));
}
...
Jadi pertanyaan saya ada tiga:
1) Apakah kesederhanaan peredam motivasi untuk menggunakan pendekatan object-keyed-by-id? Apakah ada keuntungan lain dari bentuk keadaan itu?
dan
2) Sepertinya pendekatan object-keyed-by-id membuatnya lebih sulit untuk menangani JSON standar masuk / keluar untuk API. (Itulah mengapa saya menggunakan array objek di tempat pertama.) Jadi jika Anda menggunakan pendekatan itu, apakah Anda hanya menggunakan fungsi untuk mengubahnya bolak-balik antara format JSON dan format bentuk negara? Sepertinya kikuk. (Meskipun jika Anda menganjurkan pendekatan itu, apakah bagian dari alasan Anda bahwa itu kurang kikuk daripada peredam array-objek di atas?)
dan
3) Saya tahu Dan Abramov mendesain redux agar secara teoritis menjadi status-data-struktur agnostik (seperti yang disarankan oleh "Berdasarkan konvensi, status tingkat atas adalah objek atau koleksi nilai kunci lainnya seperti Peta, tetapi secara teknis dapat berupa apa saja type , " tekankan milikku). Tetapi mengingat hal di atas, apakah hanya "disarankan" untuk menyimpannya sebagai objek yang dikunci oleh ID, atau adakah poin nyeri tak terduga lainnya yang akan saya hadapi dengan menggunakan berbagai objek yang membuatnya sedemikian rupa sehingga saya harus membatalkannya merencanakan dan mencoba untuk tetap dengan objek yang dikunci oleh ID?