Topics on the backend that only specified the selectedLayers without activatedLayers
were not added.

Due to previous commit that set the topic layers in one dispatch, we must make
sure that the layer list to set has no duplicate.

…rsing

This should also be done for all actions, but for the time being only added
it to the url parameter related actions.

This new generic parameter gives the possibility to do different actions in the
store plugins depending on the source of the event. This avoid bulky/flaky tests
using local closure flags.

During the startup we had several issues with the topic selections.

- the main issue is that we first loaded the default language and topic at startup
  and change them later by parsing the URL. One of the drawback was that the
  layerconfig and topics would have been loaded twice from the backend and
  that the default topics layer would have been set before the current topic
  layers resulting in a lot of store mutations for nothing.
  Now we use the lang and topic from the url if they are available at app startup.
  In order to do this as quickly as possible we now keep in store only the topic ID
  as current instead of a link to the current topic.
- the topic management plugin was a bit buggy and not clear with flag to do stuff
  in different mutation trigger. Now we make use of the dispatcher which make
  the code much clearer. In this plugin for example we only want to set the layers
  when the topic has been changed by the user and not by the URL parsing. Url
  parsing event should takes layer from the URL layers param.

This fixed some bugs of topics management introduced in later PR commits and
make the startup procedure clearer by clearly separated concerns.

Now the store plugins don't have any more special code for the startup. The
startup is by the application management router plugin which does the application
startup routing.

Also removed duplicated topics management events which slightly improve startup
time.

This is based on vuex docu.

Vuex mutation are costly and sending in a loop a lots of event is not a good
idea. When changing the languages we need to reload the layer config and
reset all active layers in order to have them translated instead of doing this
in a loop we all set them in one event.
This improve greatly performance with long active layer list.

Instead of an arbitrary name for the dispatch value, uses a convention as follow:

- Use the same keyword as the one in the store
- Some exception for URL parameter which uses the url parameter for simplification

PB-285: Added `dispatcher` to  store actions and improve startup procedure (language  change)

…erformance

The external layers were always put at the top during startup even if they
were in the middle of the layers parameter.

Changed the order of the expected query parameter in legacy test.

In external wmts layer, somehow the Get capabilites are called twice at startup
which made the test failing because the second wait on capabilities when
reloading did not wait due to previous request.

In a separate PR we should investigate why the get capabilities is called twice.

PB-293: Corrected external layer order at startup and improve a bit performance

PB-259: Added best practices docu

…ering

PB-238 : drag&drop reordering of active layers

Load the topics in parallel with layer config

…topic

PB-259: Improve topic parsing at startup

…s_app

PB-282: Location share Whats App

PB-259: Added dispatcher to all store events

Use the new dispatcher in sync router to ignore dispatch made by router instead
of some local buggy flags.

If a layer as a matching default opacity in the layer url, in the new url
we should to remove the opacity. This was not the case.

`expect` doesn't do retry and therefore the instance the `isLoading` flag could
have not yet been set to false and the test would failed. Now we use cy.wrap
and should that does retries with time out.

PB-259: Store sync router clean up

trying to fix the issue we have that only happen on the CI e2e tests

Fix Drag&Drop e2e test on CI

…duction

PB-259: Converted topic section into composition API

…active layer rendering

The rendering of catalogue is very costly and store events would re-trigger it
therefore wait that the map has been rendered before rendering the catalogue,
it is anyway not visible at startup until the user click on the menu entry.
It still needs to be always rendered once the application has been started, otherwise
the toggling of the menu would be too slow.

Also differ the rendering and opening of the active layers for the same reason
and also because if the menu contains external layer (e.g. kml, gpx, ...) the
application needs to load its metadata/data before rendering the correct name
in the list. For kml and GPX it would use at startup the default KML or GPX
name until the name has been loading. By defering the active layers list
we avoid having the name changing.

The drawing test `keeps the kml after a page reload, ...` was flaky and failed
due to a race condition. This test has been improved to avoid race condition.

Other tests using the cy.reload() have been also slightly improve by waiting
the mapIsReady before continuing avoiding race condition.

Do not log for non watched mutation because this is missleading in the logs.

There is already anther global mutation watcher that logs all mutations.

PB-259: Improve startup performance by rendering menu section only when the map is rendered

devices/os

On some device and os the mouse zoom wheel was unusable (one scroll step
would result to full zoom in or out). A user reported this per email and
I had the issue on my private windows machine with its touchpad and with
2 different mouses. Strangely the same mouse were working fine with
my HP Zbook on linux.

See also openlayer issue openlayers/openlayers#15423

…wheel

However keep the swisstopo closest zoom for the button.

PB-277: The mouse wheel zoom constraint had some issues with different