We talked about finding ways to share code between Cristal and XS, to reduce the cost of development, and to align both products. We mentioned that the way to go is to share them through components (either web components or vue.js components, with a preference for web components as it’s more standard and doesn’t tie us to vue.js on the usage part).
I’m proposing to move forward with this idea and to do a POC by selecting a simple component that we could share. Then the idea would be to put in the Cristal roadmap (for example) to develop it, and then to integrate it inside XS. This would allow to validate the full chain.
Note that we have 2 options: reuse at code level or reuse a distributed component. FTM I’m just proposing that we do a reuse at code level. We would need to discuss in the future if we need some common repo to store these components, whether it could go in xwiki-commons, how the packaging would be done, etc.
So, the question is: does anyone have an idea of smallish component that we could try to share?
The following are obvious ideas but they’re far from small:
Breadcrumb (not easy with the trees)
Navigation tree
LiveData
Block Editor
Notification area
Maybe an idea could be the status line under a page title:
While the editor is definitely a huge thing, we know it’s important to replace our ckeditor one ASAP and XWiki Standard is already designed to allow installing alternative editors and switching between them. If we try this, it should most probably be provided as a contrib extension for now so that it’s easier for devs working on it to update and release it and for XWiki Standard users to try the latest version whatever version of XWiki they have.
Why not as a first step. What’s limiting is that the component only reads content from XWiki/Cristal and does not allow sending content back to XWiki/Cristal
Two other ideas:
the comments section
the history section (which is interesting as we already have a minimal version on Cristal as well).
Whatever we migrate, I think it is important to make sure that the client-side component is visible on first render, and doesn’t only load slowly such as Live Data or the current navigation tree as this creates bad usability. Further, we also need to ensure that the component loads again when going back in the browser history (currently not the case for async). For parts that should be indexed by search engines, I think we should also ensure that the information is displayed without JavaScript. For example, the history shouldn’t be indexed, but the “last modified” should be I think. One way to achieve all (or most?) of this is to still render the content server-side but to put it inside a custom (or customized) element that is then enhanced using JavaScript. That way, the content is there even without JavaScript and can be easily enhanced using a web component.
Of course, in a contrib extension we can experiment as we want to, I just wanted to note what I think would be important if we want to integrate and enable anything by default in XWiki.
Regarding the history, shouldn’t the history be moved to Live Data?
Comments are tightly integrated with annotations I think so they might be a bit difficult to share unless we also share annotations.
The editor is of course the one important thing we definitely need to work on.
Definitely, this is a point we should not overlook.
I discovered Декларативный теневой DOM | web.dev last night, which seems like a good way to have rich components while preserving a reasonable behavior when JavaScript is disabled or not loaded.
An imperative API like this works fine for client-side rendering: the same JavaScript modules that define our Custom Elements also create their Shadow Roots and set their content. However, many web applications need to render content server-side or to static HTML at build time. This can be an important part of delivering a reasonable experience to visitors who may not be capable of running JavaScript.
