Moqui 4.0 - Vue 3 Quasar 2 Upgrade

Technical Discussion
1

@f.karim @newmannhu @shahbaz @zhangwei

Current status of Vue 3 Quasar 2 is:

The main thing that needs to be done is to test and fix existing apps and screens.

If each of you can run the vue3quasar2 branches on your current Moqui setup and either report OR fix submit a pr of the fixes that would be a great first step.
To run use the vue3quasar2 branch of:

  • moqui-framework
  • moqui-runtime
  • SimpleScreens
  • MarbleERP

If one of you would like to volunteer applying changes similar to Comparing master…vue3quasar2 · moqui/SimpleScreens · GitHub for HiveMind and PopCommerce that would be great.

Also if you’re adventurous, let me know and you could give the implementation of rendering qvue2 a shot.

2

Thank you for the update. I will proceed with testing the vue3quasar2 branches for the specified repositories and report or submit PRs for any issues found.

1 Like
3

@michael
Upgrading vue2 to vue3 and quasar1 to quasar2 mainly solves the following problems:

  1. Differences between Vue3 and Vue2 in creating root instances and registering components
  2. The router management methods in Vue3 are different, Quasar requires the router to support the ‘to’ attribute
  3. Upgrading http-vue-loader

I used a different approach than you when dealing with router upgrades. After testing, such changes have minimal impact on the original code and have passed basic tests on components such as tools, Marble ERP, PopCommerce, HiveMind, and example.

Please review the PR to see if it is feasible.

update qapps/vapps to vue3 and quasar2 by newmann · Pull Request #235 · moqui/moqui-runtime

1 Like
4

@newmannhu See my comment here: update qapps/vapps to vue3 and quasar2 by newmann · Pull Request #235 · moqui/moqui-runtime · GitHub

5

If it is decided to add a new rendering mode, corresponding modifications are indeed necessary. The PR I submitted is not much different from the original approach, so it is recommended to use the original solution.

Since qvt2 is merely an upgrade of qvt, why should qvt be retained? Wouldn’t it be better to upgrade them together? Or are there other plans?

6

The main reason to have qvt is because we know it works and to keep backwards compatibility. The current state of qvt2 is not 100% compatible with all the screens yet.

This is how it was done from apps to vapps and vapps to qapps.

7

hmm, maybe qvt3 is a better name to reflect that it’s vue version 3. Or maybe altogether a new name like qsr food for thought

1 Like
8

Agreed. That is a better name

9

I pulled the vue3quasar2 branch a week ago and have been familiarizing myself with the code. It looks like in the qapps2/tools/Entity/DataEdit/EntityList?filterRegexp=credit&viewOption=all tool screen it does not react to the query parameters.

I’ve been looking into it and it seems like in WebrootVue.qvt2.js loadComponent callback (line 2554) that ‘addRoute’ is being built with the same path (qapps2/tools/Entity/DataEdit/EntityList) but different component value because the component was built using different query data. So there is new data for the same path. I think that in loadComponent callback, the addRoute call should look like:

vm.$router.addRoute({
path: qvt2FullPath,
name: qvt2FullPath,
component: comp
});

It needs the “name” member so that it can remove the old route. I made that change and it seems to work.

I haven’t done a lot of maintenance contributions. Should I be doing a PR to submit this? I’ll assume so and will get started.

1 Like
10

We got this figured out.