Use BlockNote syntax directly instead of going through Cristal's UniAst

Development
1

Hi everyone,

We recently added a new rendering syntax (server-side), called UniAst. See New UniAst syntax . This is currently used as input / output for the BlockNote editor. While working on adding macro support to BlockNote we discovered some problems with UniAst and Macro AST, which lead to Remove client-side Macros AST in favor of UniAst . Furthermore, the discussion from Cristal's Universal AST lead to the conclusion that going through UniAst is actually not needed for XWiki. As @ClementEXWiki and @mleduc explained in that thread, UniAst was designed as a client-side equivalent of the XDOM, useful for Cristal backends that don’t have a rendering engine (e.g. file system, Nextcloud) but also for offline editing. XWiki has its own (server-side) rendering engine, so we could use directly BlockNote syntax. One benefit of this, besides speed (since we remove an intermediary layer), is that this should give us access to block metadata, which is required in order to ensure compatibility with the XWiki syntax. On the other hand, as I understand, it could make offline editing harder to implement for XWiki, but with a server-side rendering engine that’s already hard to achieve anyway.

I have two questions for you:

  1. Is anyone against using BlockNote syntax directly instead of going through UniAst?
  2. What do we do with the UniAst parser and renderer we already implemented? Is it worth keeping them, even if not used, and adding a new parser / renderer for BlockNote, or should we refactor them into the new BlockNote parser / renderer (knowing that UniAst syntax is close to BlockNote syntax)?

One reason for keeping the UniAst parser / renderer alongside the new BlockNote parser / renderer may be to import, in the future, content from Cristal instances that use a different backend. The problem is though that the client-side specification of the UniAst syntax may evolve (it’s unstable currently) so the server-side parser / renderer can easily become outdated. Moreover, there might be other ways to import the content, like going through Markdown, so it’s not clear that we will ever need the UniAst parser / renderer server-side.

WDYT?

Thanks,
Marius

1 Like
2

ok for me (since I’ve proposed it ;)).

Re UniAST I have proposed to move it to the Cristal Standalone codebase since it’s needed there but not in XS. Or do you mean the UniAST parser/renderer for XWiki Rendering? I’d personally remove the later, but save the work somewhere (in a snippet, in a contrib project, etc), so that it’s easy to find it later on. We could also find it back in the git history but we’d need an easy pointer to find it.

Thanks!

3

+1 for the general proposal, thanks.

+1 for this as well.