2016-04-29 38 views
1

當檢索具有不同搜索參數的域對象時,一個結構Redux應該如何處理。通過域構造Redux狀態?

在我的應用程序中,我在表格中顯示用戶過濾的organisations列表。在同一頁面上,我還會顯示一個用戶所屬組織的較小列表,並且可能在未來顯示同一頁面上僅顯示來自另一個用戶的組織的另一個小列表。

我這樣做:

{ 
    list_organisations: [ 
     { id: 1, name: 'foo1' //... }, 
     { id: 2, name: 'foo2' //... }, 
     { id: 3, name: 'foo3' //... }, 
     { id: 4, name: 'foo4' //... }, 
     { id: 5, name: 'foo5' //... }, 
    ], 
    user_one_organisations: [ 
     { id: 6, name: 'foo' //... }, 
     { id: 2, name: 'foo' //... }, 
    ], 
    user_two_organisations: [ 
     { id: 4, name: 'foo' //... }, 
     { id: 6, name: 'foo' //... }, 
    ], 
} 

或本:

{ 
    users: [ 
     { id: 1, organisations: [7,3,8], name: 'billy' }, 
     { id: 2, organisations: [3,6,1], name: 'sam' }, 
    ] 
    organisations: [ 
     { id: 1, name: 'foo', //... }, 
     { id: 2, name: 'foo1', //... }, 
     { id: 3, name: 'foo2', //... }, 
     { id: 4, name: 'foo3', //... }, 
     { id: 5, name: 'foo4', //... }, 
     { id: 6, name: 'foo5', //... }, 
     { id: 7, name: 'foo6', //... }, 
     { id: 8, name: 'foo7', //... }, 
     { id: 9, name: 'foo8', //... }, 
    ], 
} 

如果我們有備選方案二,我們該怎麼做的,我們需要查找一個單一的情況下出於某種目的的組織「檢查一個組織內是否存在用戶電子郵件」 - 這一切似乎都如此複雜......特別是在做出一次請求時呢?應該甚至生活在還原狀態?

這將使像這樣:

{ 
    users: [ 
     { id: 1, organisations: [7,3,8], name: 'billy' }, 
     { id: 2, organisations: [3,6,1], name: 'sam' }, 
    ] 
    organisation_signup_form: { 
     doesUsersEmailExist: true/false/null, 
    } 
    organisations: [ 
     { id: 1, name: 'foo', //... }, 
     { id: 2, name: 'foo1', //... }, 
     { id: 3, name: 'foo2', //... }, 
     { id: 4, name: 'foo3', //... }, 
     // ... 
    ], 
} 

回答

3

其實我建議在一個完全不同的方式組織你的數據。你想確保你所有的模型都很容易獲得,所以把它們放在一個數組中可能會很棘手。

我建議一個國家結構是這樣的:如果一個用戶的電子郵件的組織中存在

users: { 
    1: { id: 1, organisations: [7,3,8], name: 'billy' }, 
    2: { id: 2, organisations: [3,6,1], name: 'sam' }, 
}, 
userList: [1,2], 
organisation_signup_form: { 
    doesUsersEmailExist: true/false/null, 
}, 
organisations: { 
    1: { id: 1, name: 'foo', //... }, 
    2: { id: 2, name: 'foo1', //... }, 
    3: { id: 3, name: 'foo2', //... } 
} 

我從丹這個question

檢查了這個建議

您在用戶模型中沒有電子郵件,但尚不清楚,因此回答該特定問題非常困難。

我想給出的一點建議是,您需要以數據庫類型的方式構建狀態,但它不必與實際數據庫或api端點具有相同的結構。

+0

嗯,我喜歡它。雖然我使用這種結構從我的API服務器響應嗎?或者在減速器中構建它?我寧願保持我的API非REDX具體:) – AndrewMcLagan

+0

確切地說,保持你的API真實。客戶端實現應該定義你如何返回你的數據。它可以影響它,但不能定義它。 – Clarkie

+0

很酷。最後一個問題!是否有一個巧妙的竅門,用它們的ID來鍵入實體?我不想要重型減速器? – AndrewMcLagan