Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm opening this PR as a draft first as it is still incomplete, but want to get feedback on the overall approach before proceeding.
Summary
This PR introduces a wider set of basemaps that will cover most examples.
The MapLibre demo tiles work for some examples, but are not great at showcasing MapLibre's full capabilities. As such, MapLibre GL JS examples currently use tiles from several providers (the vast majority being MapTiler, which whitelists the example traffic). Since MapLibre is a vendor-neutral project and most examples are not specific to any particular provider, it makes sense to be able to switch examples between several options. This will result in greater awareness for MapLibre and better examples, since tile providers are incentivized to improve and update the examples, and link directly to them from their own sites.
Where possible (some examples may justifiably be limited to specific providers), I propose that the Americana stylesheet should be the default where we need a more "full" basemap. Other providers will be listed in alphabetical order (full disclosure: I'm affiliated with Stadia Maps, and the proposed sorting puts us at the bottom of the current list).
My reading of the Americana Tile Usage Policy is that MapLibre usage falls under the acceptable usage policy. Though I think we probably need to reach out as the maplibre.org domain, while (I think) hosted on GitHub pages, seems to use CloudFlare in front.
Technical discussion
Deciding when to display a style switcher
Examples that meet some criteria (at doc generation time) will have a style switcher. Currently, the criteria is "does the example use the OSM Americana style URL, since I'm proposing that as the default. I have updated a handful of examples to illustrate this. The rest of the examples will be addressed one-by-one after we agree on the approach.
An alternative would be to include some metadata at the top of the example (more on that later). I have opened this draft without that, as I think it unnecessarily complicates the majority of examples.
Examples that do not pass the "should we have a switcher" check are displayed as they were before. This allows for examples that are provider-specific or only make sense with a single style.
Style switcher implementation
The style switcher is currently a select box added via a map control. We could devise something that looks a bit nicer perhaps, but I opted for this as it's simple and looks reasonably good. The control is injected into the documentation (iframe component) if the generator determines that the example should have a style switcher. This JavaScript is obviously not included in the copyable sample code; it's localized to the iframe.
Changing the selection map style will update the URL with a query string parameter with a style slug. This parameter will be consulted on page load so that copying a URL will let the recipient see the same style.
Changing the map style will also update the example code! The way this currently works is admittedly a bit hackish, since we have to work with a loaded DOM. I believe the method is sufficiently robust, but am open to alternatives. The only MkDocs-native methods I could think of (generating a bunch of tabs with code fences that are 99% duplicate code) would multiply the size of the examples, and would be difficult if not impossible to sync with the map view.
Customizing the set of displayed styles
The set of available map styles can be overridden per example.
The examples are currently plain HTML files, so in the interest of keeping it that way and localizing overrides, I've opted for parsing a leading HTML comment as a JSON configuration (sort of like YAML frontmatter, but we can't have nice things like that in HTML). The generator removes the parsed comment from the example.
This is admittedly hackish, but I believe it's robust enough. We already use similar approaches when parsing JS plugins in the doc from the awesom-maplibre repo. The other idea I've considered so far is putting the overrides directly in
generate-docs.ts
. This is worse in my opinion, since you would need to look at the generator script to understand how an example behaves. That felt wrong.Known issues
Screenshots
Before
After
Launch Checklist
CHANGELOG.md
under the## main
section.