Add an API to control certain Hajk features programmatically

[jacobwod]

Edit: Scroll down to read on about the methodology I'm thinking of for this issue.
A common use case for Hajk is to be embedded, as an IFRAME, on another website.

This has been known for a while, and the #192 Clean mode has been around ever since.

We now see an increasing demand for allowing programatic control of certain Hajk features, including:

• zoom level (z param)
• x and y coordinates (x and y)
• search query string (q param)
• layer visibility (l and gl params)

(Add more ideas!)

---

UPDATE 2023-02-08
How to enable

• For now this functionality can only be activated on a per-map-basis using the setting in Admin UI
• If you want to try it out on an entire instance, there's the possibility of adding ?enableAppStateInHash to your query string (e.g. https://localhost:3000/?enableAppStateInHash). This will force the functionality on all maps running on this instance, no matter the setting in Admin UI.

What it does

• Hajk reacts to changes in hash portion of the URL string
• Hajk keeps the hash updated
• The following parameters work:
  • m (map config)
  • x, y (coordinates)
  • z (zoom level)
  • q (search query)
  • l (layers)
  • gl (sublayers [for group layers]
  • p (visible plugins)

DEMO
This demo also showcases how to embed (and control) Hajk programatically by modifying the hash part of IFRAME's SRC attribute.

Skarminspelning.2023-01-24.kl.14.55.43.mov

---

I will create a branch where we can work upon this, complete with a nice example with an embedded Hajk:

Skarminspelning.2022-12-01.kl.13.43.10.mov

---

Methodology

This feature can be broadly broken up into the following three components:

1. Retrieve app state and show an updated list of hash params in URL
2. Ensure that initial app state is derived from hash params too
3. Act when any of the hash parameters' value changes

1. Retrieve app state and show an updated list of hash params in URL

This is quite easy as we already have a mechanism in place that reads out the "relevant" parts of app state and encodes them into a string: we do exactly this in AnchorModel.js. So the only thing needed is to update window.location.hash when any parameter changes.

2. Ensure that initial app state is derived from hash params too

This part is not consolidated, as opposed to part 1. Some parameter values are read in AppModel.js, some are read in their respective plugins (e.g. Search looks for values on q). And some are on even different places (index.js reads out the m parameter to know which map should be loaded).

3. Act when any of the hash parameters' value changes

This part is, just as part 2, not consolidated. Each layer has a listener where it looks out for its' own id in the list of l parameter. Search doesn't care about q other than for the initial load. And so on.

So we need to set up a lot of listeners to act upon relevant changes. Some will go into bindHandlers in AppModel.js (perhaps those related to the Map state, such as x, y and z. Some will go into layers. Some will go into respective plugins.

[Hallbergs]

Fantastic!!

[jacobwod]

We should really built in a state management into the URL hash.

Ooops, it's here already… what!? 😄

Skarminspelning.2022-12-06.kl.12.00.27.mov

[jacobwod]

An example of what could be possible if we publish the globalObserver object:

Skarminspelning.2022-12-13.kl.13.06.48.mov