Support Vue 3 for Single-File Components (SFC)

[DaelonSuzuka]

Description

I want to write a Vue Single-File Component (SFC). There are several Vue features I want to use that have to be imported.

The Vue documentation very clearly prescribes using import statements inside the <script> block in the SFC.

The Quasar docs also very clearly use imports. Here's a link to an SFC example from Quasar's documentation:

https://github.com/quasarframework/quasar/blob/dev/docs/src/examples/QTable/PopupEditing.vue#L48

I combine that .vue file with these python files:

table.py

from nicegui.element import Element

class Table(Element, component='table.vue'):
    def __init__(self) -> None:
        super().__init__()

main.py

from nicegui import ui
from table import Table

@ui.page('/')
def index():
    ui.label('hello')

ui.run(port=8081)

When I try to load that page in the browser, I get Uncaught SyntaxError: missing ) after argument list. This error points to the following generated code (only the first line is important):

index.html

//                                                            v---------------v this is not correct
var table = app.component('nicegui-table', {template:'#tpl-t', ref } from 'vue'

const columns = [
  {
    name: 'name',
    required: true,
    label: 'Dessert (100g serving)',
    align: 'left',
    field: row => row.name,
    format: val => `${val}`,
    sortable: true
  },
  { name: 'calories', align: 'center', label: 'Calories', field: 'calories', sortable: true },
  { name: 'fat', label: 'Fat (g)', field: 'fat', sortable: true, style: 'width: 10px' },
  { name: 'carbs', label: 'Carbs (g)', field: 'carbs' },
  { name: 'protein', label: 'Protein (g)', field: 'protein' },
  { name: 'sodium', label: 'Sodium (mg)', field: 'sodium' },
  { name: 'calcium', label: 'Calcium (%)', field: 'calcium', sortable: true, sort: (a, b) => parseInt(a, 10) - parseInt(b, 10) },
  { name: 'iron', label: 'Iron (%)', field: 'iron', sortable: true, sort: (a, b) => parseInt(a, 10) - parseInt(b, 10) }
]

const rows = [
  {
    name: 'Frozen Yogurt',
    calories: 159,
    fat: 6.0,
    carbs: 24,
    protein: 4.0,
    sodium: 87,
    calcium: '14%',
    iron: '1%'
  },
  {
    name: 'Ice cream sandwich',
    calories: 237,
    fat: 9.0,
    carbs: 37,
    protein: 4.3,
    sodium: 129,
    calcium: '8%',
    iron: '1%'
  }
]

export default {
  setup () {
    return {
      columns,
      rows: ref(rows)
    }
  }
});

I don't fully understand how index.html is being generated, but I believe I've tracked this block of code to here: https://github.com/zauberzeug/nicegui/blob/main/nicegui/dependencies.py#L65.

vbuild.VBuild() is from another package, and it looks (to me) like the root cause of this problem is how vbuild is parsing the .vue file?

I know you guys don't control vbuild, but this issue caused me several days of confusion as I tried to use official examples from Vue and Quasar docs to build a custom component in NiceGUI and nothing worked for vague reasons.

I did finally get a .vue SFC working with no import statements, so I'm not blocked by this today, but imports will be required if I want to use many of Vue's features in the future.

[falkoschindler]

Hi @DaelonSuzuka, thanks for reporting this problem!

We are very sorry for the trouble you went through. We have used SFCs only sparingly so far, therefore we didn't noticed this shortcoming of vbuild.

After #1187 this is already the second issue related to vbuild this week and I'm wondering how to proceed. Pulling the source code into our own repo and fixing the deprecation warning is one thing. But repairing import statements sounds far more complicated.

Of course, we could fork the repo, study and update the Python code, fix the most pressing bugs, setup a proper testing and deployment system with GitHub actions and finally release a separate PyPI package as a successor for vbuild. Well, before doing that, we could ask @manatlan for admin access to the vbuild repo.

[falkoschindler]

I just created a new issue over at vbuild to discuss its further development: manatlan/vbuild#11

[DaelonSuzuka]

sorry for the trouble

I'm sorry to have thrown this much extra work on the pile! Hopefully my post didn't sound too aggressive, because NiceGUI has been absolutely fantastic overall and very, very productive, so losing a couple of days to this issue really isn't that bad.

I suppose I could have followed NiceGUI's examples and written my component as a .js file, but I really wanted to use the Vue extension to get syntax highlighting and autocompletion in the template/html as well as the javascript.

Fun side note

I hate writing html in strings so much that I actually started writing a NiceGUI VSCode extension to make it a little nicer to add slots to things:

[falkoschindler]

Oh wow! That side note looks awesome! I'm very much looking forward to seeing more of it once it's ready. 🤩

No, your post didn't sound aggressive. But this kind of frustration is exactly what NiceGUI is trying to avoid. Sure, that's not always possible once a project reaches a certain complexity. And the overall feedback is great. Thanks for that! 🙂

[falkoschindler]

I just noticed that vbuild doesn't support Vue 3 (manatlan/vbuild#8). And (according to ChatGPT) the code in question is Vue 3:

The line import { ref } from 'vue' is a Vue 3 concept. This is part of the Composition API introduced in Vue 3. The ref function is used to create a reactive reference to a value.

So I guess we can't do anything about this issue - besides re-implementing vbuild for Vue 3, which we don't have the knowledge and resources for.

[DaelonSuzuka]

Good to know. Maybe I'll take a look at it.

[falkoschindler]

I converted this issue into a feature request, since it's not really an issue with the existing feature set and we're currently not working on it. To be honest, I still don't know how we can achieve it given the stale vbuild project.

[simontaurus]

I understand the motivation using vbuild to not rely on a node-js stack, but I guess any pure-python reimplementation of a popular moving-target js-based framework will always outdate sooner or later if the communities behind each are significantly unbalanced.

@falkoschindler : Using node-js for dependency management is already part of some examples. Any chance to add also support for a node-js build environment, e.g. vite?

[falkoschindler]

I understand the motivation using vbuild to not rely on a node-js stack, but I guess any pure-python reimplementation of a popular moving-target js-based framework will always outdate sooner or later if the communities behind each are significantly unbalanced.

I totally agree.

@falkoschindler : Using node-js for dependency management is already part of some examples. Any chance to add also support for a node-js build environment, e.g. vite?

Absolutely. I'm not too familiar with Node.js and build environments like Vite. I started experimenting a little bit with NPM in signature pad and node module. As an ultimate goal I could imagine some kind of package.json or runtime configuration to define custom or third party Vue/JS dependencies that are fetched, compiled, bundled and integrated automatically. But at the same time, NiceGUI should still work with a simple pip install nicegui. Maybe the Node stack can be an optional dependency. And built-in components like ui.plotly and ui.joystick can be pre-built when publishing new NiceGUI versions, so everyone can use them without extra build steps.

Long story short: We're open to explore new ways to integrate Vue and JS components. But we can definitely use some help from people with more Node experience. 🙂

[evnchn]

Hey.

While attempting to work on Server-Side Rendering, I stumbled upon nodejs-wheel https://pypi.org/project/nodejs-wheel/

Could be useful in replacing vbuild altogether.

[evnchn]

I'd imagine you would eventually use nodejs-wheel to use NodeJS to invoke https://github.com/vuejs/core/tree/main/packages/compiler-sfc, which is the "official" way to "turn .vue into something that can be understood by others", which is doing what vbuild does, but better and Vue3 supportive

[simontaurus]

nodejs-wheel looks like a thin python wrapper around npm-cli.js
https://github.com/njzjz/nodejs-wheel/blob/4dfd45dbffbe412dc216746eb71ec1fc73d8ed50/nodejs_wheel/executable.py#L182
So we still rely on a node.js environment but we can call it directly from python

[depley]

Super interesting topic!
One of the main features got me interested in nicegui was using Vue instead of React or others.

As @simontaurus mentioned the popular js-frameworks are moving quickly.
Did a bit research on vuejs build setup based on @evnchn. Reading between the lines I'm not sure how long compiler-sfc will be the way to turn vue into html,css,js.
The current standard build process for vue is no longer dependant on compiler-sfc.
https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue

By invoking nodejs from python via nodejs-wheel it should be possible to set up any build process based on vite by pass in a proper vite config file.
Asked myself what are the needs/scenarios within nicegui to replace vbuild? Quasar, vanilla js, Vue3, (also Vue2?)

I would like to bring up this discussion at an vue/vitejs user group as example if it's okay @falkoschindler?
Maybe someone is interested to help setup a vite based build, served by fastapi.

[falkoschindler]

Sure! Getting more people involved that are more fluent in modern web technologies would be a big win for NiceGUI.

I'm not sure if replacing vbuild has anything to do with Quasar. Basically we want to split an SFC into HTML, JS and (scoped) CSS code. This should be agnostic of the surrounding NiceGUI framework.

What we need to consider, though, is whether the "compilation" runs on dev or user machines. Currently, we run vbuild at runtime on the user machine. This way you can modify your SFC and hot-reload it directly into your browser. If you'd need extra dependencies (node, vite, ...) and a build step, it would increase the barrier for NiceGUI users to work with SFCs.

[depley]

Sure, Vite would only be nice on a dev machine.

Maybe it's possible to run the native vue compiler-sfc somehow with 'nodejs-wheel'.
Node should be in the wheel, vuejs a dependency.
Had to correct myself @evnchn: compiler-sfc seems not get deprecated. plugin-vue uses it.

Going to play around with it and talk to the user group guys.

[xaptronic]

Unless I am missing something, it sounds to me like we're talking about building javascript (e.g.; with nodejs, vite, etc) and splitting an SFC file into style/template/script and handling that in NiceGUI, interchangeably.

I did a quick and dirty test where I modified vbuild to just return whatever it found in <script></script> (instead of parsing for the first { and last }) and then changed NiceGUI dependencies.py code so that it injects the template/styles the same way, but instead of using vue_scripts, it just adds the script to js_imports - same way that is done with js components, and then updated the _nicegui/{__version__}' + '/components/{key:path} so that it will also check if the "component.vue" key is in vue components, and returns the text content script portion of the SFC. This essentially results in js_component and the script portion of an SFC being handled the same way on the front end.

Is there another angle I'm not understanding related to nodejs builds?

I can try and pull this into a PR if it helps - but just looking for what I'm missing or if we're conflating what is missing to be able to use import syntax in SFCs..

[evnchn]

Can you maybe do a draft PR on what you have done?

Seems interesting

[xaptronic]

#4673

[xaptronic]

but it does not appear that Quasar currently supports being run as ESM from a CDN

I made an ESM build of Quasar that has all the same setup as the UMD version and got NiceGUI to run using ESM imported Vue/Quasar objects - since nicegui.js is written to expect there to be a global Vue/Quasar object, I just assigned the ESM imports to window - but it now works, and I think one could plausibly write normal looking Vue3 / ESM based custom vue components.

This PRa above (#4673) will stay focused on ESM in SFC for NiceGUI, but if the above sounds interesting to project maintainers, I could take a stab at refactoring nicegui.js and put up a PR that could demonstrate ESM based NiceGUI.

[evnchn]

I could take a stab at refactoring nicegui.js and put up a PR that could demonstrate ESM based NiceGUI.

Seems interesting. However "old"* browsers (like Pale Moon) are going to suffer more. It'd be fine, though, since they are dying regardless.

*May not be old in terms of update, but old working principle.

[FabianGoessling]

Hi @xaptronic would your suggestion allow to do local imports via ESM? If yes, this would allow to use 3rd party packages without npm using only the raw.js files? I am thinking about flattening a package and resolving all deps by hand, but maybe id better wait until your PR is accepted?

[xaptronic]

In theory yes, anything available in the import map would be importable into a component. So local modules and cdn or otherwise remote hosted modules would work.

I am trying a few different ways to work with JS which I'll try to post here for thoughts soon.

[falkoschindler]

Note that in PR #5255 we just moved (the relevant parts of) vbuild into the NiceGUI repository. Now it should be much easier to fix bugs and to add new features.