Plumb through hash

[dabreegster]

When constructing the map, hash syncs the viewport to the URL. We could add this to MapLibre.svelte. But the center and zoom in maplibre's constructor override the initial URL state. So I usually set these two params, unless window.location.hash is defined. I'm not sure how hash in the component should work, because it looks like you're reacting to any changes to the zoom and center props: https://github.com/dimfeld/svelte-maplibre/blob/ad6bb3eafaccfa53ca13e3e099c8743383da9f7b/src/lib/MapLibre.svelte#L162

Maybe maplibre's own hash functionality should be ignored, and if this prop is set, something in the component could instead keep the URL fragment synced up?

[dimfeld]

The approach you've suggested here is similar to what I've done in other projects at work (using Leaflet, which doesn't have native support for this, but basically the same idea).

If this can actually be made to work well with MapLibre's internal hash functionality that would be great, but I also have a feeling that it would end up working better to just reimplement it inside the Svelte code.

Off the top of my head, something like this might work well:

• Add a hash property to MapLibre.svelte. Don't pass it through to the MapLibre JS library though.
• If it's false, ignore all the below steps.
• If there's already a valid hash value in the current URL when initializing the map, pan/zoom to that hash location instead of using the initial value for zoom/center/bounds.
• In the moveend event handler, update the hash in the same place that currently updates center, zoom, and bounds.
• If we started with a valid hash, then don't use zoom/center/bounds at the start. This can probably be done by just setting zoom/center/bounds to the values parsed out from the hash when initializing, to override any initially-passed-in values. But it may require some tinkering to get this just right.

I should be able to play with this later this week if you don't get to it first. Thanks for the suggestion!