React-ing to the need for a modern MapGuide viewer (Part 10): The end goal of this refactoring

This post is a little backstory as to why I needed to do some behind-the-scenes refactoring.

It is so we can finally bring across this important feature from Fusion and cross off another TODO list item in the process: Support for multiple maps!

To finally support multiple maps, we had to re-structure our redux state tree so that:

1. All map-specific state (selections, layer/group toggling state, current view/scale, etc) now exist in individual branches under the mapState reducer. Each branch is keyed on the name of the respective runtime map.

2. A new active map name property is added to the configuration state branch. We then simply change our respective mapStateToProps implementations in these components to interrogate this new property to determine which map state sub-branch to read their required map state from. The beauty of this is that the state that these redux-aware components pass down to child components is mostly un-changed. They are all insulated from having to know anything about the current map.

3. To service the MapMenu component, we store the array of available map names along side the new active map name property. The entries in the MapMenu component are bound from this array. Any change from this component dispatches an action to update the active map name, and all map-related components will then auto-magically update and re-render themselves to reflect the state of the new active map.

With this set up we get a nice encapsulation of map state as everything map-related now drives off of the active map name (that the MapMenu component has the sole responsibility of toggling), as best demonstrated by this animation below

The above animation demonstrates that map-specific state like selections, layer/group visibility, current view, external base layers, etc are all perfectly isolated within their respective redux state branches and the mere act of switching maps is just deciding which particular state branch we consider to be the "active" map. It is not possible for states in other maps to "bleed over" into the current map. We never got this kind of encapsulation or safety guarantees with the current Fusion implementation and no doubt is the cause of many bugs with Fusion and AppDefs with multiple Map Groups.

There's still some aspects of the viewer that still need verification under a multi-map configuration, but for the most part this is working pretty well.