-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Carto: fetchMap to support custom basemaps #8856
Conversation
f03cd54
to
e683c7b
Compare
c794f07
to
0f04eb6
Compare
modules/carto/src/api/basemap.ts
Outdated
'basemap-tile-source': { | ||
type: 'raster', | ||
tiles: [basemap.settings.url], | ||
tileSize: 256 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
256 seems like a pretty small tile size, is that correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is some magic number that we agreed upon and that works well for most sources we tested.
Anyway, i think we should make it confiruable.
I'll try to make it part of protocol, so it's already part of keplerMapConfig
and we don't have to hardcode it here.
Good point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally, i've decided that it's better to keep whole style, so app that generates keplerMapConfig
has complete control over what style is in basemap (as side-effect, we don't need code that generates style in this module).
4d038e5
to
bb64b83
Compare
4972f03
to
7adbf11
Compare
b709e7a
to
4960483
Compare
@@ -90,9 +90,13 @@ When the map was last updated. | |||
|
|||
The [view state](../../developer-guide/views.md#view-state). | |||
|
|||
#### `mapStyle` (string) {#mapstyle} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Old mapStyle
was actually an object with various internal properties (like styleType - an actual id of style).
New api is more robust and thus i propose to completly hide mapStyle
in documentation.
(it's still returned for backwards compatibility, but it can be considered deprecated now)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good hiding it! Shouldn't we also remove it or comment it from example in line 27?
I understand the API still returns it for compatibility but using it in the example without context looks confusing to me
4960483
to
fc64562
Compare
fc64562
to
f8ec0c8
Compare
cbc6838
to
9291c3f
Compare
modules/carto/src/basemap.ts
Outdated
|
||
if (visibleLayerGroups && someLayerGroupsDisabled(visibleLayerGroups)) { | ||
try { | ||
const originalStyle = await fetch(styleUrl, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than using fetch
directly, use requestWithParameters
if possible along with an APIErrorContext
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
requestWithParameters
does lots of things, like passing ?v=
(deck version), falling back to POST
not allowing setting mode
.
I guess that using just fetch
is simpler than artificially extending requestWithParameters
to become another fetch-like univeral API.
(added usage of errorContext though)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other major thing requestWithParameters provides is caching of repeated requests, but in all the current examples this doesn't matter and we only call fetchMap once, so I think it's optional here. 👍🏻
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, we do have browser cache already. If we really want to use current cache, i would factor-it-out as separate "fetchWithCache" (and only with cache), but without carto-specific features (?v=..., fallback to POST ...),
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And when trying to see how requestWithParameters
can be adapted/simplified, i've found that its cache is not-configurable and doesn't have any means to clear it - i think we should improve it.
Anyway i guess that in current state of affair it's better to rely on browser cache.
de1954c
to
b1eec58
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the additional unit tests!
modules/carto/src/basemap.ts
Outdated
|
||
if (visibleLayerGroups && someLayerGroupsDisabled(visibleLayerGroups)) { | ||
try { | ||
const originalStyle = await fetch(styleUrl, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other major thing requestWithParameters provides is caching of repeated requests, but in all the current examples this doesn't matter and we only call fetchMap once, so I think it's optional here. 👍🏻
8171205
to
bf1d5e5
Compare
f37124c
to
0fda237
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a few optional suggestions, then LGTM, thanks!
4c0969b
to
bf40a2a
Compare
bf40a2a
to
1be5fc6
Compare
Support for custom and google basemaps in
fetchMap
.Change List