Removing the jstree dependency: overhaul of the tree macro

Development
1

Good afternoon!
When looking at the accessibility on XWiki, I quickly came up upon some issues in the Navigation panel:

Those issues are concerning for accessibility, but also just basic HTML standards: duplicate ids prevents the page from being correct HTML (usually browsers will find a correct solution to display the page even with these issues, but we should probably handle it on our hand).

JsTree has been used to replace YUI Tree since 2020, but this ticket was kept open in the hopes of finding a HTML+CSS replacement someday.

JsTree is an ‘old’ project, maintained by one person, almost inactive, and with a very poor code quality. I looked a bit to try and contribute to it, but the one ticket I opened was dismissed and closed quickly, and my request for help on the community forum did not get an answer in months.
I could not find proper tests for this dependency (the test folder did not get an update in 8 years), and I’ll let you check the formatting with this snippet from the source:

rtl = this._data.core.rtl;
w = this.element.width();
this._data.core.focused = tmp.id;
a = obj.children(‘.jstree-anchor’).trigger(‘focus’);
s = $(‘’);

JSTree is used in the tree macro, the module name being xwiki-platform-tree-webjar. The tree macro (and the document tree macro) are used everywhere in XWiki, from the breadcrumb dropdowns to the navigation panel and the XAR export UI. I think keeping XWiki so heavily reliant on such a dependency is not a good idea.

I propose to replace this dependency with our own tree module made from CSS and HTML, with a bit of Javascript (jquery).

If this proposal is accepted I can take care of making sure it advances, with a design page to record research and conclusions on the subject, further forum proposals to detail more the content of these changes, and updates to the xwiki-platform-tree-webjar module.

Thank you in advance for your feedback! :slight_smile:

2

Developing our own library must be a last resort option imho. I’m really in favor of looking for a suitable alternative library first.
Having a design page for the migration to another library is interesting though. To list the current use cases and feature we want to preserve, etc.

1 Like
3

To me, that depends on the amount of code we need. If the amount of code is low or mostly styling that we want to control, anyways, to provide a consistent look, I think maintaining our own tree library could be the better option. The problem with libraries, in particular on the UI side and in particular also with small libraries is that they frequently don’t provide the long-term support we expect in XWiki. An alternative could of course be that we use an existing library that has good code quality with the expectation that we might have to take over maintaining that library some day. An important point here would also be that this library doesn’t have too many/uncommon dependencies.

4

I searched for a bit for a web dependency to handle trees, and as far as I searched, JSTree looked like the most popular one. All other projects seemed at least as dead as JSTree…

5

Do you have any idea what CryptPad is using?

6

AFAIK CryptPad has developed their own tools, but I’m not sure it’s really reusable.

Now I know @mflorea started to investigate on the alternatives.

1 Like
7

I talked a bit with Yann last week, who works on Cryptpad and was in charge of their navigation tree.
He couldn’t give me a precise amount of work needed to implement the tree feature in Cryptpad (it’s been in here for a long time since the start of the project), but told me it wasn’t that much difficult / long.

About the tool being reusable, he told me that it was not yet properly set in a module, but he could do it without much time. I’ll get back to him to know when he can take a bit of time to release a proper tree module.

Some core code to the Cryptpad tree functionality: cryptpad/www/common/cursor-treesome.js at 7cc5a6c31f3c846a06c3e54964b6b70b7c19ac6b · cryptpad/cryptpad · GitHub

8

Note that Cryptpad is AGPL 3.0 so inherently incompatible from a license point of view but if all authors of the code agree they could of course re-license this module under a license compatible with XWiki’s license. I hope that was the intention of Yann, I just wanted to mention it in case it hasn’t been clear.

2 Likes
9

I must insist that we need to be very careful to check if Cryptpad tree lib is matching our needs before reaching a conclusion.
I just saw this improvement request Loading... (Allow sorting by specified field for Document Tree macro).
And I guess this could me one more subtlety on top of the many we have introduced over the year.

The conclusion might still be that we want to have our own tree lib, but we need to be aware of what that entails.
On the other hand, we have the experience of the Livetable to Live Data ongoing work to know what it takes to migrate to a new library for a front-end component.

10

I agree with Manuel. We must search for an existing and well-maintained lib before even thinking about developing our own or using Cryptpad’s one. I would be very wary of using Cryptpad’s one because it’s not their “business” to develop a tree macro either and if you think about them as any other tree lib, you should check how many developers are contributing to it, how many releases of that tree lib over the years, their issue tracker for the tree lib, etc.

11

I doubt that sorting is handled in jsTree.

If we’re otherwise happy with jsTree (no idea if we are), there might be some other options:

  1. Try contributing actual code fixes to jsTree
  2. Fork jsTree and gradually improve it in case contributing fixes upstream is not working for whatever reason
  3. Ask XWiki SAS if it would be a possibility to sponsor the developer of jsTree to fix the issues we’re having.

If not, I suggest starting with a collection of the requirements we have regarding a tree to see which options are suitable and how difficult it would actually be to have our own tree. We seem to be using features like checkboxes, drag&drop, selection using keys, and maybe even a context menu from a short look so a simple HTML and CSS tree might not be sufficient.

1 Like