Queries on "Decoupled Editor for Plone Headless" project

1

I submitted an initial on the project "Decoupled editor for Plone Headless" about a week ago, despite having a few doubts. Apparently, I got caught up with a few things which is why I was unable to follow up on them. I sincerely apologize for that. It may seem that most of these doubts are based on the implementation details, however, I would highly appreciate some insights.

Based on the POC Decoupled WYSIWYG Editor UI for Plone Headless · Issue #5767 · plone/volto · GitHub issue it is mentioned that Volto would be split into 2 code bases:

A reference implementation of a frontend (called Volto) which can be built on top of and themed. But this can be easily replaced.

An Admin UI which is deployed as is and rarely needs to be customized. This could be built in anything but still has a customization story. Initially based on Volto code

As per my understanding, the iFrame bridge would act as a link between the 2 while having the ability to display certain features like block selection. I might be wrong, but from what I understand the iFrame bridge may be overly complicated to implement from scratch.

QUERY 1: Can we model the iFrame bridge as a package (instead of a stand-alone script as done by StoryBlok) that divides the functionalities into a more modular and reusable version? Would that make add-on development simpler (also the implementation of the iFrame itself simpler) by keeping all the logic in one place? Since the existing codebase is huge, it is a bit tricky to make such an assessment.

Another small detail mentioned:

handle shortcuts being typed inside an editable field, including enter to create a new text block and slash to change the current block

QUERY 2: As there is also a rich-text editor involved, can we make the shortcuts 2-stroke based like Ctrl+Enter, Ctrl + / etc?

P.S: I know these questions are more or less based on the implementation details, and not so much the approach, however, I would like to have these doubts cleared. Any further clarification or correction in my judgment/understanding would be highly appreciated. @djay

2

There are existing packages that impliment a 2 way communcation channel over an iframe which would make a good starting point.

Note the idea of splitting the code base in two is not the only way to achieve the end goal. The end goal is a keep the functionality of volto which handles the admin UI working while allowing the frontend to be written in anything. Using volto versions of the frontend blocks is not needed for this, it's just a suggestion that it might save time to resuse that part of volto. However it would be just as valid to another framework and some other design system and block implementations that are similar to those used in base volto and use them as a demonstration front end.

I'm not really sure what the difference would be. The code base of the iframe would be relitively small. It's main jobs would be

  • scan the frontend html and hook into elements to listen for event
  • allow any frontend code to register callbacks for admin UI update events
  • only very basic visual augementation of the frontend such as putting a bounding box on the currently selected block
  • ideally most of the complex UI elements such as the actions bar and slate line inline edit bar would be rendered by the admin UI over top of the iframe rather than inside it by the bridge code. The more complex the UI code the more harder it is to write in a way that works well mixed in with various frameworks. The only UI that most liekly needs to be rendered by the bridge code is UI that can't be hidden during scrolling.

The idea is to make it as usable as the current inline edting. That means that if you press enter you create a new block below which is selected and you can start to type text immediately. If you type "/" as the first char of a text block then you get a menu of blocks to turn this empty block into.

But this is a proof of concept. If this is not possible or can't be done reliably. then we can look at what the compromise for UX that is possible. If you know now this is not possible then it would useful to show this in your application. The idea however is to try and see how far is possible to get great UX and great DX.

1 Like
3

Yes, I agree, something like protoframe or anything similar would be of great help to get started with.

I also have the same view, the core functionalities will not alter much concerning how the implementation is being carried out. I simply wanted to know whether it is a flexible choice or not. I guess it will be clearer once the coding phase begins to decide what will be the best fit.

Thank you for clarifying this. I misunderstood the initial bit, hence the somewhat weird query. Extremely grateful for your quick reply