Roadmap for Wegue v3

[chrismayer]

This discussion should act as a kind of roadmap to collect things, which have to be done on the way towards Wegue v3 supporting Vue 3 and corresponding Vuetify.

Thanks to @sronveaux we have (near) complete port of the Wegue code base to Vue v3 and Vuetify v3 in #411.

The general strategy would be the same as we had in the upgrade process towards Wegue version 2. The last released version (currently v2.1.0) will be the base for a v2 legacy maintenance branch, which will be supported and maintained for a while, so devs can upgrade to the upcoming Wegue v3 without a hassle. The master branch will be the v3 development branch afterwards.

TODOs before merging #411

• Create v2 branch for legacy maintenance ➡️ v2
• Clean code following the addition of the map composable
• Update comments following the addition of the map composable
• Fix the unit tests following the addition of the map composable

v3 must-have

• Replace Vue-CLI and Webpack with Vite
• Update Versions section in the project's README
• Fix for: Base maps cannot be switched using the keyboard anymore
• Update Material Design Icons and Material Icons libraries to latest versions
• Rename DragDop to DragDrop
• Update documentation following changes made in Migration to Vue3 and Vuetify3 #411
• Update workshop following changes made in Migration to Vue3 and Vuetify3 #411
• Update migration guide

v3 nice-to-have

• Fix for: Layer properties not reactive anymore
• Add a custom icon example in the workshop
• Replace Karma with Web Test Runner
• Add unit tests for new composables and WguEventBus

@sronveaux @fschmenger @JakobMiksch Please fill in other points in the different bullet lists, which you might consider as must-have or nice-to-have for a Wegue version 3.

[JakobMiksch]

unfortunately I currently do not have a project where I can use Wegue, but I nevertheless follow the development. However, I also worked an other environment with Vue and OpenLayers and have some ideas that could be implemented in Wegue as well.

The most central one is to handle the state of the OpenLayers map. This is a must have because the previous approach with the mixin is not supported in Vue3 anymore. For me it worked fine putting the map in an Vue composable or a Pinia store (which is basically a composable with more features). An example how this is implemented can be found here: https://github.com/JakobMiksch/vue-ol-comp and a demo here: https://github.com/JakobMiksch/random-geodata It is really convenient to have the map properties as fully reactive variables in Vue. This can keep the code clean and easy to understand.

[chrismayer]

Thanks for your valuable input @JakobMiksch. Mixins are still supported in Vue3. They might be no more the recommended way of doing things but they are alive and not marked deprecated, not least because they are so popular and widespread. But maybe a deprecation will come up in the future. I personally would be fine to stick with the "Map Mixin" approach, but surely not veto the "composable" approach, if someone volunteers to do this. I'd see 2 preconditions to switch to a map composable: 1) No functionality should be lost and 2) it should be implementable in a reasonable amount of time, so the Wegue v3 is not blocked too long by that (whatever "too long" means ;-) )

Nevertheless the decision how we proceed on that should be done before we release v3 and IMHO even before we merge #411.

[JakobMiksch]

Good to know that mixins are acutally still supported. I remembered that wrongly. Then it might not be necessary to switch to another approach(like composable) to handle the OpenLayers state.

[sronveaux]

Hi @JakobMiksch and thanks for the valuable input. In fact, migrating the mapable mixin to a composable was something I thought doing at first. The other mixin of Wegue (themeable) had to be converted to a composable as this is how it works now in Vuetify. So uniformising this would be a good thing.
However, as the idea was to change as least as possible in a first run and as the migration was becoming quite huge, I thought sharing first and getting feedback would be a good idea before adding some more changes.

Following @chrismayer comment, I implemented a basic composable which can be upgraded in the future to replace the current mixin. I personally think this is a nice and clean way to go on and it gives back reactivity to layers list without needing to register callbacks as I did lately to have something functional to share. Layer properties are not yet reactive though... however this is already the case in current version of Wegue. I hope this will be solved in a not too distant future but is really way harder than expected to be done cleanly.

By looking at those latest changes, I hope we can take the decision whether we keep this composable or whether we revert and postpone this for a later version.

[sronveaux]

As #411 is already getting quite big, I really think new changes should be limited on this one now... I just updated it with a map composable and what to write here will depend whether we keep it or revert it. However, I'll make a proposal as if the composable was kept.

A simple thing which could also be nice is correcting a typo in the config files where the drag'n'drop functionality is configured through the DragDop keys. Changing this would imply the users to modify their config files but as Vuetify3 will imply to do one or two tweaks, perhaps it would be a good moment to do it.

I think two other things would need to be tested and included if time permits.

First, I personally think replacing Vue-CLI and Webpack by Vite should be a must-have, but only if things go on well fast which I hope they will. I haven't tried to update yet but would like to give it a try when #411 will be finished. There is a plugin for Karma which would hopefully gives the opportunity to keep our current unit tests tool suite and minimize changes. However, this would imply removing Babel and not supporting legacy browsers anymore. I don't know if this would be an issue for you or not... there is a plugin to support transpiling in Vite but I'm not sure it is often used in practice...

Second, replacing Karma, which is now flagged as deprecated, for something else could be a nice-to-have. But what to replace it with is not easy as there are not so many options if we want to keep an in-browser test runner. Jest and Vitest are both using jsdom instead (Vitest has an experimental browser mode though) which would certainly imply to rewrite many if not all the current tests. Karma recommends to move to Web Test Runner which keeps the same in-browser philosophy. However, how to use it to test a Vue app is not quite clear. I think giving it a try would be great though. And if it doesn't work as expected or implies too much work, then postponing this to V4 would be wiser...

Given those thinkings, here's what I'm thinking about for the roadmap. This is just a proposal and I let @chrismayer take and adapt at will:

TODOs before merging #411

• Create v2 branch for legacy maintenance
• Clean code following the addition of the map composable
• Update comments following the addition of the map composable
• Fix the unit tests following the addition of the map composable

v3 must-have

• Replace Vue-CLI and Webpack with Vite
• Update Versions section in the project's README
• Fix for: Base maps cannot be switched using the keyboard anymore
• Update Material Design Icons and Material Icons libraries to latest versions
• Update documentation following changes made in Migration to Vue3 and Vuetify3 #411
• Update workshop following changes made in Migration to Vue3 and Vuetify3 #411
• Update migration guide

v3 nice-to-have

• Rename DragDop to DragDrop
• Fix for: Layer properties not reactive anymore
• Add a custom icon example in the workshop
• Replace Karma with Web Test Runner
• Add unit tests for new composables and WguEventBus

[chrismayer]

I updated the bullet lists for the roadmap based on the suggestions of @sronveaux.

I created a v2 maintenance branch based on version 2.1.0 and prepared a PR #424 giving information about the changing scope of the master branch after #411 has been merged.