Vue.js adoption

Development
#1

Dear all,

I’d like to propose to the community the adoption of a modern front-end web framework: Vue.js.

Why do we need a new font-end web framework ?

Currently, we are mainly using jQuery (and keep maintaining legacy propotype.js). And I have identified two main paint points: our front end code is difficult to reuse and to test.
There are aspect where modern front-end frameworks have made significant progress.

Why Vue.js

Vue.js is a well-maintained framework that has many advantages the major one being that we have experience with it with the development of the Live Data macro, proving its worth to:

  • allow the development of large front-end components
  • being easy to test
  • being able to integrate in a large and heterogeneous legacy code base

Additionally, Vue provides tool support in the browser (firefox and chrome) to help debugging the UI.

Note: Vue.js is also the framework of choice for Mediawiki and Wikijs.

What are the consequences of officially adopting Vue.js

We’ll work to provide tools to develop using Vue.js on XWiki (core and extensions).
We’ll define guidelines to decide when using Vue.js (or migrating to it) is relevant.

Challenges ahead

  • Uniformization of the version of the dependencies (same version of vue / npm dependencies for all extensions)
  • Scaling the use of Vue from one module (Live Data) to many, and allow to reuse components between modules
  • Work on guides and tooling to ease using Vue during development for all XWiki contributors
  • Provide reusable components to ease the development of XWiki UIs
  • Provide even more rest endpoints and clients for existing modules (for instance, the development of Live Data lead the in introduction of rest endpoints for the icons and the localization)
  • Define a strategy to deal with the migration from Vue 2 to Vue 3
  • Ease the modification of Vue.js components. Currently, it is possible to modify javascript code stored in XObjects or in the server. Due to the way Vue.js code is packaged, this is not true anymore. This can make “hacking” XWiki more difficult and we’ll need to introduce new features to allow it again

Let me know what you think and fell free to share you concerns and questions.
Thanks,
Manuel

1 Like
#2

Thanks for working on that!

Define a strategy to deal with the migration from Vue 2 to Vue 3

I don’t know at all about Vue 2 and 3 and their planning, if Vue 3 is already out or not. But, wouldn’t it be safer to start performing the migration of LiveData to Vue 3 before adopting it in more modules?

Ease the modification of Vue.js components. Currently, it is possible to modify javascript code stored in XObjects or in the server. Due to the way Vue.js code is packaged, this is not true anymore. This can make “hacking” XWiki more difficult and we’ll need to introduce new features to allow it again

So what you’re saying is that you cannot express a JSX using VueJS is that right? There’s already ideas for fixing this? Or maybe the right call is to not fix it: we could consider that using Vue is for large projects / UIs and JSX are only for hacking it using jQuery ?

#3

Maybe also (could be included in one of your bullet points but I think it’s good to make it explicit):

  • Provide a simple and automated way to bind xproperties from HTML/JS. It should be extremely easy to say, when writing some HTML code that you want this content to be the value of such xproperty and it would get it and update it live.
#4

That’s a point I’m interesting in. JQuery is very generic and can be used for anything. Is that the case for vue.js too or is it better used only for “largish” application with a single view? I think that should be one of the first question to answer: when should we continue to use jquery and when should we use vue.js?

Thx!

#5

Vue 3 is the new default since Vue 3 as the New Default | The Vue Point
It’s indeed probably safer (and easier) to migrate LiveData first. Note that there is two paths there:

  1. A full rewrite (I can’t guarantee how complex it can get as of today)
  2. Using the Migration Build. The Vue team provide an adaptation layer between Vue 2 and Vue 3. This can make things easier (but some some code change as still required) and I doubt this is worth in the long term.

It’s definitely not impossible, and Vue application can be written 100% in vanilla Javascript, but I doubt this is a pleasant experience.
In my exprience, Vue apps are written using Single File Complements (SFCs), where the view, logic and style for a given component and developed in the same file (and compiled to Javascript under the hood).
We could also improve this by adding support for SFCs for instance.

+1

That’s the point where I’m not sure how to formulate a general rule. In my option, Vue becomes interesting:

  • whenever jQuery is used to manipulate the dom (i.e., a template system is needed)
  • whenever the dom needs to be updated according to some external events (e.g., ajax response, websocket message, user interaction…)
  • whenever some UI component needs to be reused

Here are some examples of existing parts of XWiki that would fit these criteria if they were to be developed today:

  • the comments: move of the implementation works by moving around pieces of dom received from ajax queries
  • the quick search panel
  • a lot of the UI oriented macros (file tree…) as they are meant to be reused by other UIs
#6

Great to see work on this kind of thing.

It indeed sounds like a very bad idea to standardize on the previous version of Vue.

#7

To answer myself, I made a quick test by declaring an XClass with three fields (template, script, and style), to align with the three main section of a single file component and added a class sheet binding to return a valid single file component by aggregating the values of the XObject on the get action.
image

In combination with vue3-sfc-loader (which supports Vue2!), I have a PoC where Vue components defined as XObjects can be rendered inside wiki pages. And everything is defined as wiki pages.

The PoC XAR: Up1

2 Likes
#8

FWIW, Nextcloud is using Vue and have replaced / been replacing their JQuery based code with it too.

#9

Update: vue-tippy will soon be compatible with Vue 3 (see upgrade to tippy v6 · Issue #257 · KABBOUCHI/vue-tippy · GitHub)

#10

We use vue-tippy?

#11

Yes, that’s the component we use for the popover (e.g., to display the edit action) on LD cells.

#12

Do we have an umbrella ticket, or a list of things to wait for to be able to perform the migration?

#13

Not yet.