Is it possible in MainUI widgets, to store local intermediate data? I see a lot of widgets repeating certain calculations (sometimes hundreds of times) - is there really no way for a widget to store local data? I know it’s a Vue based - so maybe having access to the computed for this, may ease in writing the widgets and ease their use too
No, there is no assignment in widget expressions. Plus, since each expression is in its own context, no newly assigned variables would be shared.
There is an assignment plugin for the expression parser, but adding that and then changing the widget system to share assigned values would be a massive change. Probably technically feasible (although I can’t guarantee it off the top of my head), but almost certainly not worth it performance-wise.
Also a side note: please only use the Solutions and Tutorials category to post solutions and tutorials. It is not for questions.
I partially get it - but I don’t get why each expression is in it’s own context - allowing the widget (as these are Vue 2 or 3 based) to share and re-use a per widget context - will allow one to make more powerful widgets. Also, allowing access to more of Vue’s systems could make the widgets more powerful too if one chooses to use them - I program in VueJs daily so was really hoping one could use these features of vue to create some amazing widgets.
Thanks for the info about the assignment plugin (also, where can I find it? @JustinG ) - that means that the expression parser has plugin support - so I’ll look into that, maybe try to write up plugins for the features I think are missing (so it’s opt-in) and that way hopefully can also test the differences related to performance.
Secondly, I guess the only way to make widgets is through the Yaml based code, there’s no way to write the components raw in plain VueJs? @JustinG
Also, thanks for moving the post to the right category - mistakenly used the wrong one as I was looking at Widgets and couldn’t find a topic aimed at questions about them - note taken.
There is a balance to be struck here between what more advanced users want to be able to do and what the average user needs, taking into account the resources that the average user is putting into serving OH in the first place.
There’s an oh-webview component (and the ability to add an iframe as a direct component if you don’t like the webview’s limitations). If your preference is for full web development for OH, then you might be better off just creating your own app and visualizing it in MainUI via one of those methods. Or possibly, HABpanel is more what you’re looking for as that offers closer to a full angularJS method for creating OH interfaces.
Yes, the freedom already available in the widget system does tend to spawn increasingly complex ideas and dreams in those of us that enjoy thinking about such things. On the other hand, I also encourage you to keep in mind that part of the beauty of the custom widget system is it’s simplicity for those that want such simplicity while also already being complex enough that there is very little that cannot be done with a little creativity and the occasional workaround.
For example, my confirm button, would have been dead simple to create with a full js implementation. Or, I could have easily added the capability to oh-buttons though a PR (I may still do so eventually). But, even though it took longer, it was quite fun and a great learning experience to think through how to create it just with the available tools and css. With what function is already there, my solution is 99.9% correct (and I strongly doubt anyone else will ever find the .1% issue).
The expression parser that is used is jse-eval which is descended from jsep and compatible with the jsep plugins. There’s info on the jsep site about how to author these plugins. Right now if you look in the widgets mixin file, you will see that widgets currently take advantage of regex, arrow, object, and template plugins.
I personally don’t really see a use for the assignment plugin, but I’m just one point of view.
You can always create new vue based components and just submit them to the repo. Or, always just run your own test-server copy of the UI. Other than that, you probably know far better than I do about if vue templates can be dynamically added to a pre-built app (though I very much doubt it).
Maybe instead of having a single way of defining widgets, we could look into multiple ways, like the current basic one and a more advanced way for the advanced users.
I will look into this - as far as I know, there is a way in Vue to do this, it’s called the component component - thing is, it needs to be registered in the component store - I’ll try to work up a PoC for this - as it may enable a lot more widgets.
Quick question - does someone know when Openhab will migrate to Vue 3?
There is no roadmap. OH will implement Vue 3 when someone wants to put the time in to make it happen or Vue 2 becomes unusable for some reason, whichever comes first.
I don’t know too much about the difference, however, so if moving to Vue 3 includes significant breaking changes then perhaps it will at least be forced to wait until OH4. If you want to try to get this going, then definitely start a an issue first to get the ui maintainers on board.
Already created that issue:
It references an old issue which went stale - when I have time I’ll take a look
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.