Feat pb 1383 layers module
Implementing the layers in a new module called @geoadmin/layers.
Switching from having classes (which aren't ideal in the store) to simple interfaces that determine the structure of the various layers. Since this takes away the constructors, I added utility functions to construct the layers, so that we don't have to always specify every bit of information. I also moved the capability parsers of wmts and wms to the new module. Maybe some other parsers could follow too, I don't know that yet. There's some coupling to defaults which are in mapviewer, we need to figure that out first.
The advantage of this change is clearly not very impactful yet. We'll have to switch the Vue components to TS to leverage the interfaces, for instance. I rather think as of now this module is just a step in the right direction. Maybe we'll also refactor the layers structure, I heard ideas about simplifying some stuff, for instance to merge GeoAdminWM(T)S with ExternalWM(T)s. Maybe we could, in the future, organize the layers around traits, like "FileBased", "wmtsBased" etc.
Maybe we now have a starting point to consider what else should be done around the layers of the mapviewer.
web-mapviewer
Run #5396
Run Properties:
Failed #5396 •
da2ac11a9a: WIP fix tests
| Project |
web-mapviewer
|
| Branch Review |
feat-pb-1383-layers-module
|
| Run status |
|
| Run duration | 06m 01s |
| Commit |
|
| Committer | Pascal Barth |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
|
|
4
|
|
|
0
|
|
|
20
|
|
|
0
|
|
|
248
|
| View all changes introduced in this branch ↗︎ | |
Tests for review
importToolMaps.cy.js • 1 failed test • e2e/chrome/mobile
| Test | Artifacts | |
|---|---|---|
| The Import Maps Tool > Import external WMTS layers |
Test Replay
Screenshots
|
|
print.cy.js • 2 failed tests • e2e/chrome/mobile
timeSlider.cy.js • 1 failed test • e2e/chrome/mobile
Let's start with a partial review...
General comment : As we are now moving to TS, should we decide if the absence of something should output
undefinedornull? I'm a bit more forundefined, as I think it behaves better with TS?optional op. in interfaces, do you have any preference?
Hehe funny you should say this. I had the same idea and naively started implementing the interfaces with optional properties like foo?: <type>, but this lead me to a ton of problems down the road with code that expected it to be null if it's not set. So after weeks of fixing bugs because of this, I decided to revert to the existing behavior. Although in hindsight I don't quite understand why these bugs weren't caught by the typing system, maybe not enough is in TS yet
Maybe we should first start to transform more of the code to TS before trying this again. All the vue-components that interact with the layers are still in JS, for instance.