Compatibility efforts with friendsoftypo3/headless

[thopra]

Hey!

I'm following this project with a lot of interest. Visual editing is THE missing feature in TYPO3 so I appreciate any effort going into that direction very much.

However, a lot of us have moved away from the traditional coupled approach to frontend templating with fluid and are instead building on top of the API provided by friendsoftypo3/headless, for example by using vue.js for frontend rendering (using the nuxt/typo3 package or other implementations).

Since this extension heavily relies on ViewHelpers to wrap web components and load the required JS, I would be very interested if there are any plans or thoughts of making this extension compatible with a frontend that is not using fluid (and if so, if there are already any ideas how that could look like) or if you would rather see both extensions to be mutually exclusive.

I can imagine that while porting/integrating the components to something like vue and making requests to match what's expected by the middleware could easily be done, integration of RTE could especially prove very difficult in this scenario because it requires its configuration/plugins coming from the backend.

I'd be interested in your general approach to this.

[Kanti]

I have not though about this in depth, maybe we can talk about how this could look like.
I send you a DM in typo3 Slack.

[Kanti]

From that we talked about @thopra:
a public API that would facilitate headless installations.
Services that help build the information for custom HTML elements:
ve-content-area, ve-content-element and one for both: ve-editable-text and ve-editable-rich-text
And also for the window.veInfo Information that will be rendered into the body.

The visual_editor can provide this API to others.
This would enable internal visual_editor refactorings without causing too many issues in headless setups, since the public API only involves returning a PHP object representing the custom HTML elements. We could also rename the component and the custom properties, without breaking the public API.

[thopra]

Hey, as discussed, here's the link to a repo with rough demo setup: https://github.com/thopra/demo-visual-editor-headless

Most of the changes I have done are just quick and dirty prototyping, just to get to a point where there's a real blocker.

I've included my findings of what each included package would need to change for this to have a chance of working out in the readme file, here's what I've wrote down for visual_editor:

Provide one or more classes as public API to other extension developers

We need some public service class(es) that will provide the following data:

• Page information (currently written to inline Javascript in PageRenderer)
• Attributes of custom elements ve-editable-text, ve-editable-rich-text and ve-content-area (In this demo, I've used the EditModeService class for this and added some methods that return arrays with the required data, but it probably makes more sense to return the TagBuilder directly)
• a list of resources (JS and CSS) that need to be loaded from the assets directory to initialize editing

Not required, but would be nice: Event / Callback when changes require a reload

It would be nice to have an event being dispatched that we can use to reload the pagedata from the api or react to changes to tha page that require to update state in the frontend

Proper CORS support or documentation of the limitations

This demo uses a single domain setup (see nginx config). Cross domain setup also works up to a certain point, but due to limitations in the TYPO3 core, messaging between frames in the backend module will never work, unless major changes are coming to TYPO3 itself.

While we CAN do this (by reverse-proxying anything other than /typo3 /_assets and /fileadmin to nuxt) this also means that effectively this excludes multi-domain setups in general. I have not found a way around this so far.