Conversation
| height: 400px; | ||
| order: 4; | ||
|
|
||
| @include govuk-media-query($from: desktop) { |
There was a problem hiding this comment.
Is this specific sizing, to support lbh-map within the lbh-contact-block? If so I would rather target this behaviour from lbh-contact-block styling. Making it the full width behaviour by default.
There was a problem hiding this comment.
full width is the default now and the size of the contact-block is managed in the contact block scss
| } | ||
| } | ||
|
|
||
| &__map-container_full_width { |
There was a problem hiding this comment.
Following BEM this should be a modifier, so &__map-container--full-width. Thats if it's still necessary with the above comment.
There was a problem hiding this comment.
Removed - it is no longer necessary with the above change
| this.moduleId = this.$module.getAttribute("id"); | ||
| this.accessToken = this.$module.getAttribute("data-access-token"); | ||
| this.moduleId = this.$module.getAttribute("lbh-map"); | ||
| //this.accessToken = process.env.OS_BASEMAP_TOKEN; //Process env not working yet. Please copy/paste the OS_BASEMAP_TOKEN in the meantime |
There was a problem hiding this comment.
Is the idea that the env is available at build time? Once this is compiled, process is not available in the browser.
There was a problem hiding this comment.
I've removed the .env comments
| if (this.uprn){ | ||
| //Process env not working yet. Please copy/paste the ADDRESSES_API_PROXY_URL in the meantime | ||
| //fetch(process.env.ADDRESSES_API_PROXY_URL+"?format=detailed&uprn="+this.uprn, { | ||
| fetch("ENTER_THE_ADDRESS_API_PROXY_URL_HERE?format=detailed&uprn="+this.uprn, { |
There was a problem hiding this comment.
Is there a reason we don't hardcode this url? Feels like the query parameters are tied to the url (unless this is an open standard)?.
| fetch("ENTER_THE_ADDRESS_API_PROXY_URL_HERE?format=detailed&uprn="+this.uprn, { | ||
| method: "get" | ||
| }) | ||
| .then(response => response.json()) |
There was a problem hiding this comment.
What happens if there is a 400-500 response status? Can we handle that exception?
| } | ||
| } | ||
|
|
||
| &__map-container { |
There was a problem hiding this comment.
The repetition of map here seems unnecessary as the scope is lbh-map. I think this was just carried over from lbh-contact-block.
There was a problem hiding this comment.
Yes, it was carried over from the contact-block. It has been updated.
| overflow: hidden; | ||
| } | ||
|
|
||
| &__title { |
There was a problem hiding this comment.
I don't see this being used in the example html? Is this necessary or can we update the html?
There was a problem hiding this comment.
Removed. It was not necessary
…e contact block scss
…the contact block
…e contact block scss
|
Hi @LBHMVillalobos, I totally forgot about this. Seeing as MMH has no immediate need for this it might be worth reaching out to other members that have implemented the previous iteration to review? I wouldn't know who that would be unfortunately. |
3 participants
1. If uprn is provided, the lat/long will be taken from the addresses API. If not provided, it uses the provided lat/long
2. New basemap and attribution
Please contact me to get the OS_BASEMAP_TOKEN and the ADDRESS_API_PROXY_URL for testing.