feat: provide OS API keys as properties, rather than env vars #29
Conversation
|
✔️ Deploy Preview for oslmap ready! 🔨 Explore the source changes: 8e55654 🔍 Inspect the deploy log: https://app.netlify.com/sites/oslmap/deploys/6113b09e7950c400075686a0 😎 Browse the preview: https://deploy-preview-29--oslmap.netlify.app |
| @@ -84,17 +85,27 @@ export class MyMap extends LitElement { | |||
| @property({ type: Number }) | |||
| geojsonBuffer = 12; | |||
|
|
|||
| private useVectorTiles = | |||
| Boolean(import.meta.env.VITE_APP_ORDNANCE_SURVEY_KEY) && | |||
| osVectorTileBaseMap; | |||
There was a problem hiding this comment.
this was a bit confusing: I originally thought useVectorTiles could use lit's @state() decorator and be an internal reactive property, but since it now references other configurable property values, it has to be defined within firstUpdated() to evaluate correctly!
|
Netlify failing because env vars have been renamed & are not yet updated under "deploy settings" -- will fix after review depending if we decide to keep env vars as default prop values or remove them altogether! |
|
Update: now using I realized a big perk of not removing env vars all together is that then we can set them in Netlify & maintain preview links with full OS styles and features. End users should still specify all keys as props. I cleaned up the readme examples to remove mention of env vars! |
Adds configurable properties for specifying OS API keys.
Also cleans up naming throughout to hopefully make OS-related services a bit more clear & consistent. I've defined a property per OS API for now, even though some end users may have a single key that can access both/any.
Closes #21