Durum Şeklini Tasarlama bölümünde , dokümanlar durumunuzu ID ile anahtarlanmış bir nesnede tutmanızı önerir:
Her varlığı anahtar olarak bir ID ile depolanan bir nesnede tutun ve diğer varlıklardan veya listelerden buna referans vermek için ID'leri kullanın.
Eyalete giderler
Uygulamanın durumunu bir veritabanı olarak düşünün.
Bazıları açılacak (bir açılır pencerede görüntüleniyorlar) veya seçili seçeneklere sahip olan bir filtre listesi için durum şekli üzerinde çalışıyorum. "Uygulamanın durumunu bir veritabanı olarak düşünün" ifadesini okuduğumda, bunları bir API'den (kendisi bir veritabanı tarafından desteklenen) döndürüleceği gibi bir JSON yanıtı olarak düşünmeyi düşündüm.
Ben de bunu şöyle düşünüyordum
[{
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',
}]
Ancak dokümanlar daha çok şuna benzer bir format önermektedir
{
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',
}
}
Teoride, veriler serileştirilebilir olduğu sürece ("Durum" başlığı altında) önemli olmamalıdır .
Bu yüzden, redüktörümü yazana kadar mutlu bir şekilde nesne dizisi yaklaşımına gittim.
Nesne anahtarlamalı kimlik yaklaşımı ile (ve yayılma sözdiziminin liberal kullanımı), OPEN_FILTERindirgeyicinin parçası
switch (action.type) {
case OPEN_FILTER: {
return { ...state, { ...state[action.id], open: true } }
}
Nesne dizisi yaklaşımında ise, daha ayrıntılı (ve yardımcı işlev bağımlıdır)
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));
}
...
Yani sorularım üç yönlü:
1) Redüktörün basitliği, nesne-anahtarlı-kimlik yaklaşımıyla gitme motivasyonu mu? Bu devlet şeklinin başka avantajları var mı?
ve
2) Nesne anahtarlamalı kimlik yaklaşımı, bir API için standart JSON girişi / çıkışı ile başa çıkmayı zorlaştırıyor gibi görünüyor. (Bu yüzden ilk etapta nesneler dizisine gittim.) Yani bu yaklaşımı kullanırsanız, onu JSON formatı ve durum şekli formatı arasında ileri geri dönüştürmek için bir işlev mi kullanıyorsunuz? Bu hantal görünüyor. (Yine de bu yaklaşımı savunuyorsanız, bunun yukarıdaki nesneler dizisi indirgeyicisinden daha az hantal olduğu gerekçenizin bir parçası olabilir mi?)
ve
3) Dan Abramov'un teorik olarak durum veri yapısından bağımsız olacak şekilde yeniden tasarlandığını biliyorum ( "Geleneksel olarak, en üst düzey durum bir nesnedir veya Harita gibi başka bir anahtar-değer koleksiyonudur, ancak teknik olarak herhangi biri olabilir yazın " vurgu benim). Ancak yukarıdakilere bakıldığında, onu kimliğe göre anahtarlanmış bir nesne olarak tutmam "önerilir" mi, yoksa onu sadece iptal etmem gereken bir dizi nesne kullanarak karşılaşacağım öngörülemeyen başka sorunlar var mı? ID ile anahtarlanmış bir nesneyi planlayıp buna bağlı kalmaya mı çalışıyorsunuz?