To-Dos wrt Vue 3 and Framework7 v7 upgrade

[florian-h05]

After #3350 is merged, the following tasks need to be tackled:

High Priority

• (BUG) Blockly multi drag/drop not working - recommended solution is upgrading the library, but it requires blockley v11 -> will be fixed by Moved to blockly v11 and respective plugin versions #3398
• Take care of TODO-V3.1 comments
• Refactor to use Vue router instead of F7 Router as F7 Router has serious bugs with navigation??
• (BUG) Duplicate entries in model treeview on drag & drop sometimes, see To-Dos wrt Vue 3 and Framework7 v7 upgrade #3378 (comment) => fixed by Model: Show non semantic children in model tree #3476??
• Write down which manual changes are required for swiper
• (BUG) ECharts localisation not working
• (BUG) Model drag & drop not working
• Store menu pinned state.
• (BUG) on initial loading of setup-wizard, the UI is unresponsive. Corrects itself on reloading
• Test floorplan pages
• Test map views with markers
• Test embedded SVG state tracking
• (BUG) slider does not appear for dimmer items on item-detail page on ios devices.
• Test masonry layout
• (BUG) back button from settings/items, settings/things - the URL in the address bar does not change.
• (BUG) Item state preview is missing in production build
• (BUG) Add link and edit link not working on Items details page
• Test Web Audio Support
• (BUG) on item-detail->oh-label-card->oh-trend - the width setting is only correct AFTER the page is display - doesn't seem to be reactive
• oh-swiper: Automatically map parameters object properties onto config object to ease transition => manual changes are needed anyway

Low Priority

• Run Prettier & enable prettier format checking in CI
• Upgrade marked: 13 -> 14 breaks markdown list rendering, to be investigated
• Clean up tabs - there's a lot of unecessary code that is handled automatically by Vue, e.g. @click=switchTab
• Clean-up command emits/listening for generic-widget-component, I haven't found a place 'command' is emitted from
• Refactor $oh.api from using Framework7 Requests to:
  a. Use the fetch API directly
  b. use a typed API client, e.g. hey-api/openapi-ts
  and take care of MainUI on Vue 3: Beta testing bug reporting #3381 (comment)
• Document common coding practices:
  • v-?? should show up first in any html element
  • use vue3 principles of reactivity where possible (vs. direct DOM manipulation)
  • new components should use typescript & composition API where possible
  • import components through <script setup> to make sure Vite "sees them as used" and doesn't three shake
  • Props are one-way down data binding from parent to child and should not be mutated by the child component
  • for conditional HTML attributes on elements: Use condition ? true : null to unset them if condition is false
  • use computed values instead of method calls for getting prop values in template => methods re-evaluated on every rerender, computed values cached if dependencies didn't change
• Convert i18n to non-legacy mode since this is deprecated

[jsjames]

FYI - this is done in the current codebase so can be removed: Convert i18n to non-legacy mode since this is deprecated

[jsjames]

• (BUG) back button from settings/items, settings/things, settings/model - the URL in the address bar does not change.

@florian-h05 - I've had issues all along with the back-link and back-link-url in the navbars during the port, hence I specifically implemented the navbar-left with a specific link. There seems to be either a serious error in framework7 OR in how we are configuring/using routes/etc. I've spent quite a bit of time examining the framework7 code here, but was unable to make progress. If we can find out the core issue here, we might be able to revert the navbars to the simpler format using back-link and back-link-url. If/when you have time, I'm hoping you can investigate as well to see if we can better address this.

[Nadahar]

I've had issues all along with the back-link and back-link-url in the navbars during the port, hence I specifically implemented the navbar-left with a specific link. There seems to be either a serious error in framework7 OR in how we are configuring/using routes/etc. I've spent quite a bit of time examining the framework7 code here, but was unable to make progress. If we can find out the core issue here, we might be able to revert the navbars to the simpler format using back-link and back-link-url. If/when you have time, I'm hoping you can investigate as well to see if we can better address this.

The issue isn't new with this port. There are some serious problems with this also in the current MainUI. I've tried to understand what goes wrong, but ultimately failed. What I can remember is that I found that the manipulation of the browser history is flawed. If you have the browser history open while you navigate, you can see that it doesn't contain what it should. When you then use "back", you sometimes end up somewhere completely wrong. It's actually one of the most annoying bugs with the current MainUI in my opinion, I've been trying to find some logic that enables me to "work around it", to no avail.

[jsjames]

[] (BUG) Localisation for echarts

[florian-h05]

I think I found a solution for the back navigation issue: Implementing my own navigation 😂

[florian-h05]

f7.width seems to not be reactive anymore. The developer dock icon and the widget-expression-mixin at least get no reactive width or height value.

[jsjames]

f7.width seems to not be reactive anymore. The developer dock icon and the widget-expression-mixin at least get no reactive width or height value.

Correct. according to the docs f7.width was "never" reactive but clearly it was in v5.

[jsjames]

I think I found a solution for the back navigation issue: Implementing my own navigation 😂

that's crazy that we have to do that though - this is a pretty serious bug in f7!