The situation
I have a React/Redux app that displays markers on a map, and groups them into clusters based on their proximity given the current zoom level (similar to this example - my app differs from this example slightly in that the clusters on the map will display specific data from their child markers, and not simply a total number of child markers).
I anticipate having new markers added frequently, and the app will update to show the new markers in real-time.
The React component structure looks something like this:
<Map>
<Cluster markerIds=[...] />
...
</Map>
So the map re-renders the appropriate clusters every time a) new markers are added to the map, and b) the map's zoom level changes.
I'm trying to determine the best way to organize this data in a Redux state tree.
Option 1: Simple approach
One option would be to keep the state tree very simple, and let the UI handle all of the clustering logic as needed:
{
markers: {
1: { name: 'Bob', location: [-40.08, 37.62] },
2: { name: 'Steve', location: [51.08, -25.62] },
...
}
}
If I organize state in this way, the UI will have to go through every marker and recalculate the visible clusters every time the zoom level changes. With a high number of markers, that could turn out to be a lot of recalculations, and I anticipate that users will be doing a lot of zooming in and out while using this app.
Option 2: Store cluster groups for each zoom level
Another option would be to keep the cluster organization in the state tree for each zoom level (e.g. 1 through 19):
{
markers: {
1: { name: 'Bob', location: [-40.08, 37.62] },
2: { name: 'Steve', location: [51.08, -25.62] },
...
},
clustersByZoomLevel: {
1: {
clusters: [
{
clusterLocation: [22.59, -21.54],
markers: [2, 11, 4]
},
...
]
},
...2-19: {...}
}
}
In this case, the cluster calculations would only happen when new markers are added to the map, and would only be run on the new markers, not on the entire set. Zooming in or out would not require recalculating, as the cluster organization would already be stored in the state.
The question
So, which option makes more sense?
On the one hand, I am compelled to keep it simple and avoid premature optimization (i.e. go with Option 1).
On the other hand, I can see that Option 1 could easily result in tons of recalculations happening very frequently. And Option 2 provides a state tree that translates more directly into my React component structure.
Which option would you suggest, and why? Are their other approaches I'm not considering that may work better?