Upgrade to latest Vue and Framework7

[ThaDaVos]

The problem

It's actually a re-open of an existing issue as it was closed due being stale: #1069

Your suggestion

Check if we can do the upgrade - I am happy to look into this to get Openhab's MainUI up to date.

Your environment

Additional information

[florian-h05]

Hello @ThaDaVos,

thanks for picking this up.
Since Vue 2.x is going to reach EOL, we should IMO upgrade to Vue 3.x.

So: Any help with upgrading is highly appreciated.
I guess it is much work since there is a number of breaking changes both in Vue and Framework7, and in addition our dependencies also need to be compatible with Vue 3.

@gyhs WDYT?

[ThaDaVos]

It will mostly be a single-day-a-week effort I can put in, because of work, but at least it will be worked on!

I will focus on the org.openhab.ui - this way I can also learn a bit how it works and maybe look into my feature request for supporting custom widgets and also look into the reactivity from the back-end too - as there's a lot which may be improved there too to make it lighter and easier to work with

[florian-h05]

It will mostly be a single-day-a-week effort I can put in, because of work, but at least it will be worked on!

Sounds great!

MainUI is inside the org.openhab.ui bundle in the web folder, the Java parts of that bundle shouldn’t really matter.
Backend is the openHAB REST API & SSE event stream provided by openHAB Core (https://github.com/openhab/openhab-core) by the org.openhab.core.io.* bundles.

I would recommend to focus on getting MainUI starting with Vue 3 and latest Framework7 first, then check that all features relying on dependencies still work/upgrade the dependencies.

I think working on the backend the same time could be quite overwhelming, and if your UI PR does not only contain the upgrade, but also changes to backend calls etc., it will get bigger and bigger and therefore more difficult to review.
So splitting upgrade and improvements would help.

[ThaDaVos]

I will start with the pure upgrade first - saw there are tests or at least a framework for it - so will check that out first

A question though, why was there chosen for SSE and not Websockets? Just curious
Or maybe even Web gRPC 🤣

[florian-h05]

A question though, why was there chosen for SSE and not Websockets?

I don‘t know, that was before my time as maintainer (and even as contributor).
But given that openhab/openhab-core#3345 (SSE log endpoint) was closed in favour of openhab/openhab-core#3859 (WebSocket log endpoint) and the addition of an event WebSocket in openhab/openhab-core#2891, I would say the goal is to switch to WebSockets in MainUI or add least add WebSocket support and keep SSE as an alternative.

[ThaDaVos]

Ah good to know - when I have time I'll go through the code (created a fork) and sum up what to do in a pull request so we can keep track and verify it's the correct steps

[florian-h05]

As the MainUI code needs to be changed anyway when switching from SSE to WebSocket, it could probably be done in a way where the MainUI code itself does not know about the implementation details of the event connection, i.e. whether it is SSE or WebSocket (or probably something different in the future?), this only matter for the implementation of that event connection. In the Java world I would say create an Interface for the event stream and then have two implementations, one for WebSockets and one for SSE.
That would be really nice IMO, but is nothing to take care of now.

[ThaDaVos]

As the MainUI code needs to be changed anyway when switching from SSE to WebSocket, it could probably be done in a way where the MainUI code itself does not know about the implementation details of the event connection, i.e. whether it is SSE or WebSocket (or probably something different in the future?), this only matter for the implementation of that event connection. In the Java world I would say create an Interface for the event stream and then have two implementations, one for WebSockets and one for SSE. That would be really nice IMO, but is nothing to take care of now.

That was I thinking too - as I probably have to rewrite stuff to be more Vue 3 - I could also take a small detour and check that out - but first I'll check what components are used and how stuff is done - then I can write up a detailed list of steps and tasks to undertake

[ThaDaVos]

Quick question, maybe I missed it - but is there a contribution guide?

[florian-h05]

Yes, there is:

• https://www.openhab.org/docs/developer/contributing.html for general stuff like sign-off etc.
• https://github.com/openhab/openhab-webui/blob/main/bundles/org.openhab.ui/CONTRIBUTING.md explicitely for MainUI, this takes care of the more technical aspects

[ThaDaVos]

Is it within scope of this to also move to the latest recommended build stack for Vue? So move from webpack to Vite?
n.v.m. that - I will first do a straight up upgrade - migration to different buildstack should be done after that

[J-N-K]

If you find something missing in the web socket part on server-side, feel free to tag me.

[GiviMAD]

I just saw these, I have upgraded webpack in these PR #2267

[ThaDaVos]

I just saw these, I have upgraded webpack in these PR #2267

Oh that's great! Will take it into consideration @GiviMAD

[florian-h05]

@ThaDaVos FYI: I have merged #2267, so Main UI is now using webpack 5.

[jimtng]

I have about 2-3 weeks experience in Javascript / Vue / Framework7, but I'd be happy to help. I have a lot of free time.

[ThaDaVos]

I am first working on indexing all the needed changes and steps to be made - when I've done that, I can may be split off some work - finally getting some time again, so will be picking it up again soon, first of merging the above mentioned PR and then continue indexing the changes - will create a PR with a check list

[florian-h05]

@ThaDaVos FYI I upgraded to the latest Vue 2.7.x version and upgraded most dependencies to their latest version compatible with Vue 2.7.x.

[ThaDaVos]

@florian-h05 thank you! Due to work I haven't been able to work on it, so this helps a lot!

[florian-h05]

Yeah, this removes some of the burden of upgrading to Vue 3 because most dependencies are now very close to their Vue 3 compatible versions, but I fear it still is a lot of work.

[ThaDaVos]

Yeah, the first step I would have done the same, first upgrade to last minor versions and then go major by major - hope I'll get time soon as I already have experience with Vue 2 to Vue 3 upgrades

[florian-h05]

@ThaDaVos Any updates on your work?

[ThaDaVos]

@florian-h05 - slow progress - as I had some really busy days - I hope to be able to give an update within the next two weeks as my schedule is finally clearing up and I finally get some time to tinker with it

[florian-h05]

Thanks for the update, sounds good 👍

[miloit]

@ThaDaVos any updates?

[florian-h05]

@ThaDaVos Still on it?

[florian-h05]

is there a reason Vuex (now Pinia) was used?

Framework7 v5 didn't include a store so Vuex was needed.
Having no submodules support IMO takes out Framework7 store as the future store.

If you want to migrate from Vuex to Pinia, this would be nice I think, but if you don't want that additional effort we can keep Vuex and migrate later as well.

BTW, maybe instead of convoluting the issue - is there a better channel for communication regarding OpenHAB WebUI upgrades?

I would say this channel is a good place for it, but if we want more features like replies to specific messages, we can switch to GitHub discussions.

[ThaDaVos]

I'll migrate it to Pinia - thinking about using the same pattern I used in other projects to decouple the logic from the views and get a more MVVM structure (this eases development and eases upgrades in the future, also shrinks the logic inside the components, especially with the new composition api)

[ThaDaVos]

@florian-h05 - would it be a good idea to, while rewriting it, write it more Object-Oriented, perhaps use something like Pinia-ORM see to create an abstraction based on the models used in OpenHAB itself?

Just thinking out loud here, looking into what approach is to best to keep maintainability the lowest and ease upgrading in the future. Also, keeping testing feasible easily, preferably without a running OpenHAB instance needed.

[ThaDaVos]

@florian-h05 - do you perhaps know what OpenHAB uses for Websockets? Seeing as there was talk about migrating from SSE to Websockets - I also found this: https://github.com/Atmosphere/atmosphere
Or is it SockJs based?

Below seems nicest solution:
https://socket.io/how-to/use-with-vue

[florian-h05]

would it be a good idea to, while rewriting it, write it more Object-Oriented, perhaps use something like Pinia-ORM see to create an abstraction based on the models used in OpenHAB itself?

Pulling in @ghys, please comment.

do you perhaps know what OpenHAB uses for Websockets? Seeing as there was talk about migrating from SSE to Websockets

We are using the vanilla WebSocket API of the browser, that’s absolutely enough for us. I have recently refactored the WS logic that was added with the new log viewer to ws.js, and have a PR open to make use of topic filtering (I have a core PR for that). My plan is to migrate from SSE to WS step-by-step, but have a switch where users can switch back to SSE during an initial phase.

[ThaDaVos]

@ghys - any comment?

[ThaDaVos]

@florian-h05 - do you mean this PR?
#2997

[florian-h05]

Yes, this one and openhab/openhab-core#4550 server-side.

[ThaDaVos]

Ah, as files will be moved etc - I'll try to incorporate your PR into the upgrade itself, else you'll probably get many conflicts when merging

[florian-h05]

Should I hold back merging PRs so you can work on the upgrade without getting conflicts?

[ThaDaVos]

Could be useful - else I would need to check afterwards what's been changed an re-apply it, while everything is rewritten in Typescript en probably in a different place - so you can make the PR's, but perhaps I should manually merge them in?

[florian-h05]

I am currently busy so I won’t create many PRs, but I have merged a few small but nice bug fixes and enhancements.
Please don’t merge any PRs manually into your branch, I don’t want too loose oversight what has been added when. IMO it’s better to postpone merging PRs until you are finished.

WDYT how long will it take?

[ThaDaVos]

I can't really give an estimate as I mostly only have one or maybe two days a week I can try to squeeze some hours in sadly.

When is the release of OpenHAB 5 planned?

[florian-h05]

It is planned for summer, probably at beginning of July.
I cannot stop merging PRs until then, so I guess we have to find a solution to continue development without causing too many conflicts.

I have thought about a few things, and I think this upgrade doesn‘t need to be „over-engineered“:

• Whilst I understand that MVC/MVVM and Pinia ORM have their benefits, I think that at the same time they also add complexity to the codebase. I like the status quo where the business logic needed to run a single component only is part of that single component itself with the API calls needed for the component being performed by the component. For code duplication about multiple components, duplicates should of course be removed, either through mix-ins or refactoring into Pinia/Vuex (take the semantic model as an example).
• TypeScript definitely is a no-brainer that should be used.
• For data that is used at various places, like the Items list, I am actually against using a store for it, as the current approach (relying on caching through HTTP headers) already minimises network footprint and avoids that we have to deal with „how to keep our local data up-to-date“.

I have to admit I have never worked on a large frontend project in the industry (in fact I have actually never worked before, just starting my career), so my thoughts might be wrong, but I think there is a difference between us OSS and industry. We don‘t need a 100 percent test-coverage for the frontend (it‘s nice though), I personally focus rather on frontend features.
Please let me know what you think @ThaDaVos.

@ghys Would be great if you could give your opionion.

[ThaDaVos]

@florian-h05 - I really get your points - about the MVC/MVVM I am thinking the same, but using Vue 3's Composables where necessary

About the data loading - I was thinking about using https://github.com/posva/pinia-colada - as this automatically ties the store and data together
Secondly, I was looking at https://github.com/stephenjason89/pinia-plugin-state-persistence or https://github.com/kirillsavelov/pinian/tree/main/packages/persistent-state - due the usage of LocalStorage I saw (this makes Pinia the only data layer, which eases maintenance)
Also if required this can be added to keep the state in sync between tabs/windows: https://github.com/kirillsavelov/pinian

[florian-h05]

Wrt to the data loading:
I am concerned about adding dependencies in such a critical area that are effectively developed by two or less people, I would like to avoid that.

About the data loading - I was thinking about using https://github.com/posva/pinia-colada - as this automatically ties the store and data together

What would be the benefit of using it?

For data loading its basically the same as with other things: I would like to keep it as simple as possible to not push off potential contributors and ease maintenance. We don't have full time devs and I suspect most of our contributors are doing web not as their day job, those shouldn't be overwhelmed.
Data that has to be shared across the app and has to undergo some extensive processing, like the semantic model, or like the semantic tags that very likely never change can be put into a store, but for example the Items list in the Items picker IMO is fine to be requested every time the picker is opened, because it is cached and the browser handles the state for us - we don't have to take care of keeping it up to data, and data consumption of sending the 30x Not Modified response is nearly nothing.

[ghys]

@ghys Would be great if you could give your opionion.

Sorry yes, stay tuned.
Gotta collect my thoughts on all this.

[jimtng]

Is this currently blocking all the PRs from being merged?

[florian-h05]

No, not really.
What‘s blocking though is that I currently don‘t have the time to review those PRs …

[florian-h05]

@ThaDaVos I have seen you updated your upgrade branch using merge. Better use rebase to keep thr commit history clean, using merge GitHub will display foreign commits as your changes in a PR.

[ThaDaVos]

@ThaDaVos I have seen you updated your upgrade branch using merge. Better use rebase to keep thr commit history clean, using merge GitHub will display foreign commits as your changes in a PR.

@florian-h05 - I'll see if I can re-do it as rebase to resolve this

[ThaDaVos]

@florian-h05 - it should be resolved now - I re-did the merge as rebase and re-added my commits I did after

[coolrunning-art]

Any progress on this?

[jsjames]

@florian-h05, @ThaDaVos - Just wondering what the status/plan is for this update.

• Is there a way to divide and conquer the work here?
• Is the plan to restructure things at the same time as updating to the new framework? Or, is the plan to just get the current UI working in the new framework?

[ThaDaVos]

I am sorry for the silence

The process has stalled due to another work related project taking priority - this will be finished soon (hopefully this weekend).
After that I will full focus on this again (after work of course)

To answer @jsjames

• Is there a way to divide and conquer the work here?
  I am not really sure, as it has to be done stepwise - if it was a simple package update with a following refactor for the upgrade, then it was

• Is the plan to restructure things at the same time as updating to the new framework? Or, is the plan to just get the current UI working in the new framework?
  I tried the upgrade first, but due to the nature of what needs to be upgraded to make it function correctly, a complete restructure was decided to be better, hence why I am rebuilding it in my fork, swapping out libraries/tools where needed - and creating a good base to work further on in the future - the thing is, we're going from Vue 2 to Vue 3 - which mostly means a complete rewrite to many deprecated or replaced packages, but also a major version number contains almost always breaking changes

But, just for my info - when is the release for OpenHAB 5 expected?

[jimtng]

when is the release for OpenHAB 5 expected

Usually June or July

[florian-h05]

It is very likely July 20.

[florian-h05]

@ThaDaVos I would rather plan the upgrade for openHAB 5.1, for 5 we should deliver some new features, for 5.1 we can slow down on the feature side and focus on the upgrade.

[ThaDaVos]

@florian-h05 - that's good - as it also eases the implementation as the PR's related to WebUI will probably also slow down a little

[florian-h05]

Yeah, I could also imagine pausing merging PRs for a few weeks after the release, activity usually already is lower during the summer.