A `global.sdk_mapzen_api_key` set inside a scene file will be deleted by Mapzen.js
louh opened this issue · 6 comments
Steps to reproduce:
- Create a new scene file, importing a Mapzen base map
- Set
global.sdk_mapzen_api_keyin my scene file to my API key - Use mapzen.js to load this scene file. Do not provide an API key to mapzen.js (because it is already set in the scene file.)
- mapzen.js will delete the API key set in my scene file.
Expected: the API key I provided in my scene file should remain in use.
Simple test case files are in this gist:
https://gist.github.com/louh/c209ae0ccc424c74d64538ef88f891d4
Thinking through the logic to address this use case:
--> Has a key been set in mapzen.js (via L.Mapzen.apiKey or options.apiKey)?
-
YES: Inject the key into the scene object for any sources using Mapzen vector tiles (NOTE that this will overwrite any existing keys in the scene file)
-
NO: Issue warning (because key is used by other mapzen.js components, as well) and check if:
--> Does a key already exist in the scene object?-
YES: Carry on with the existing key
-
NO: Issue (second) console warning
-
--
Sanity checks welcome! cc/ @hanbyul-here @louh @meghanhade
Also, I'm still debating that first warning...
I like it. Re: that first warning: since the other mapzen.js components are opt-in, would it be feasible to throw the warning only if those components are initialized while the api key is not provided?
Yes, it would be possible. Having the single early warning was an easy fix, but we can (and should) add individual warnings to the components.
Just to be clear : so we are not going to carry the api key from scene to mapzen.js , right? (which seems to be a right approach for now)
Correct. Any global key set in mapzen.js (via L.Mapzen.apiKey or options.apiKey) will overwrite the key set in the scene file. If no global key is set, but the scene has a valid key, mapzen.js will allow the scene to be initialized with that key. It will not, however, use that key for any other mapzen.js component.
For the record, Tangram Play/Frame is the only use case (so far) requiring this change.