陣營和終極版與動感的元素

我目前正在開發中的分析儀表板反應，和/終極版類似於此：陣營和終極版與動感的元素

儀表盤的用戶將能夠添加和刪除瓷磚定製儀表板以滿足他們自己的需求，並且瓦片的配置在API中存儲和檢索。

用於瓦片的配置似乎與全局狀態模型，以適應井的數據的存儲：

上的負載，儀表板組件調度「loadTiles」動作
動作取入平鋪數據並將其傳遞給「瓦片」縮減器
從那裏進入商店/全局狀態。
在mapStateToProps，數據被從state.app.tiles

然而，填充每個瓦片中的數據時出現問題訪問。瓷磚的數量和數據的性質是動態的，所以減速器不能提前設置。

這可以通過每個組件管理自己的狀態來解決（就像在使用componentWillMount的純/傳統React中一樣），但是這會違反已經爲項目其餘部分設計的一些架構原則（理想情況是，一切都是在全球範圍內進行管理）。

我可以看到存儲數據的唯一途徑是全局狀態是使用各種數據集的動態數組進行分析，這聽起來很亂。

本地組件狀態是最佳解決方案嗎？或者這可以在全球範圍內乾淨地完成？有沒有使用動態指定的查詢的Redux示例？

來源

2017-03-08 Paul T Davies

@ philipp的回答是正確的。還需要注意的是，Redux應用中的組件狀態是正常的，根據此FAQ條目：http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state。 – markerikson

你可以做的一件事就是爲每個Tile使用一個ID。所以，你的狀態可能看起來像：

{ 
    tiles: { 
    tile1: {}, 
    … 
    tile100: {} 
    } 
}

比，在mapStateToProps()功能，您可以使用自己的道具，像這樣：

function mapStateToProps(state, ownProps) { 
    //test if it exists 
    if (state.tiles[ownProps.id]) { 
    return { tileData: state.tiles[ownProps.id] } 
    } 
    else 
    { 
    return { tileData: <default state> } 
    } 
}

的重要組成部分，是交出一個唯一的ID爲每瓦，那些被創建時，一個方式可能是因爲：

<Tile id={uuid()} other="stuff" />

由此可以如所描述的要創建的uuid()方法here

我曾經有類似的問題，看看here如果你想看到一個更復雜的解決方案，使用更高階的組件（它是我自己的不被接受的答案）。總而言之，以上是最簡單的解決方案恕我直言。

來源

2017-03-08 09:25:35 philipp

這就是當我提到擁有所有數據集的動態數組時所獲得的結果。我覺得像黑客回覆而不是與它一起工作。 –

但事情就是這樣。您也可以在服務器上創建這些ID並在前端使用它們，但本質上它們是相同的。 – philipp

使用一個數據以id隔開的reducer是通過動態數據使用redux的常用方法。我會補充說，如果瓷磚的類型不同（具有不同的功能），則可以使用不同的縮減器（每個瓷磚類型1個） – OlliM

陣營和終極版與動感的元素

回答

相關問題