Map-specific scopes with layer-group extensions

[allthesignals]

Thought this could work here - I wonder if we can have map-specific scopes:

/maps/zola
/maps/citymap
/maps/applicant-maps-project-edit-muted (map without tax lots visible)

This would introduce a new resource, maps, which would be collections of:

1. references to other layer-groups
2. extensions of other layer-groups

why?

Across our map-based apps, we're slowly distilling an abstraction which separates behavior from data. This is good because then we can test only the abstraction's behavior with a given set of parameters. Currently, all we can do is test behavior which is domain-specific. For example, when clicking on a zoning district in ZoLa, it needs to route to a zoning district page, but it should zoom to that feature, but not all zoning districts of that type. Suddenly we must write dozens of tests for specific domain concerns.

Having a map resource would keep all configuration in one place. Maps may then simply pull down a map object from the server and can no longer override certain properties.

Originally, we needed need to be able to start from existing layer-groups and potentially change one or two things. The map resource should allow this same functionality, but keep those overrides in one spot.

is it flexible enough?

I'm proposing some changes to mapbox composer which would allow for overriding behavior or controlling behavior on a domain level. For example, we could extend mapbox-gl to behave in a few ways:

1. Render all passed layer groups:

{{#mapbox-gl composerMap=model as |map|}}
	{{map.layer-groups}}
{{/mapbox-gl}}

layer-groups are explicitly invoked here for a mapbox-gl map. They won't be invoked otherewise.

2. Render all layer-groups but configure certain layer-group behavior:

{{#mapbox-gl composerMap=model as |map|}}
	{{#map.layer-groups as |layerGroups|}}
		{{#layerGroups.tax-lots
			onLayerClick=(action 'lotClickHandler') as |lots|}}
			{{#lots.tooltip as |tooltip|}}
				Owner: {{tooltip.feature.properties.owner}}
			{{/lots.tooltip}}
		{{/layerGroups.tax-lots}}

		{{layerGroups.zoning-districts}}
		{{layerGroups.commercial-districts}}
	{{/map.layer-groups}}
{{/mapbox-gl}}

When passing a block to the layer-groups context component, only explicitly invoked layer-groups get rendered onto the map all layer groups are still rendered for that map, but you may now call out specific layer-groups. This allows for finer-tuned control and more explicit expression of functionality that may be very closely tied to a given layer-group. If a layer-group should not appear on that map, either a new map object should be created in layers-api, or the existing one should be modified.

what about global state?

In NYCPlanning/ember-mapbox-composer#24 I talk about the store. Since there can exist multiple maps for an application, a global store might not make the most sense - sometimes the ephemeral state of a layer-group (which is store on that layer-group) needs to reset across maps. Yet, we still need a service of some sort to contain references to layer-groups.

I think a mapRegistry service might help us get around this problem. A mapRegistry can behave much like a data store, but simpler.

The problem is that the application may expect map objects in the registry when they aren't registered yet. This may be a hiccup at first, I'm not sure it's a huge problem. Sibling or unrelated UI, however, would still be able to manipulate what it finds inside the mapRegistry:

// my toggle switch
{{labs-ui/layer-group-toggle layerGroup=mapRegistry.mainMap.layerGroups.tax-lots}}