Use an existing IFrame?

[bernesto]

This is more of an edge case hypothetical. Say you have an existing IFrame with a page loaded into it, and you wanted to attach the editor to that frame and make some edits. Is that plausible?

[artf]

If the content of the iframe is accessible (eg. not a cross-origin one) currently what would be possible now is to take its HTML and create a new page from it.
If your question is more about whether it's possible to mount grapesjs components on top of the existing DOM elements, I'd say no, at least not at the moment.

[bernesto]

This was really to ensure I wasn't making more work for myself if there was an existing pattern for using an outside iframe.

We have a bit different use case than what GrapesJS was designed for. For us, we are not working with the full document as one atomic structure. We have a master design layout, and zones within that master layout are used to contain server components when that design is used in page generation. And those server components can contain one or more editable blocks of HTML to be manipulated by GrapesJS and the RTE.

We are modifying GrapesJS to be used in three general scenarios.

1. In the design phase of the master layout (aka theme). Here, we are working with the outer document used in page creation. This is pretty close to the original design ethos of GrapesJS, just with some custom blocks for zones, navigation, etc.
2. In the the layout phase for pages derived from the master page. This is the scenario, as I described earlier, the master page/theme is locked, and users can only manipulate the server components within zones, and edit HTML content in the editable regions of the server components. (Note components extend their own blocks, and are responsible for their own data persistence.)
3. Lastly, in email template design. This has a master layout similar to No. 1.

Regarding page editing in No. 2. Inline editing is critical for us due to inheritance of CSS styles, as well as a feedback loop to the user on how their changes in one component will effect the rest of the layout. For us, we use GrapesJS to enable the sorting of server components in their master layout zones, and the editing of the HTML within editable regions in a block like format. We then export just the HTML from the component's block to persist back to the server for that component. Server Components are atomic, they store their own HTML, CSS, and javascript, and can be move page to page, or shared among a number of pages. The server is then responsible for merging and optimizing per page CSS.

We have this working now.

Note, while the JSON data is nice to have for restoring state in the editor when HTML can not carry the necessary state data, for us, an HTML region for us is just that, HTML only, as the source may not have been created with GrapesJS. We have millions of HTML parts that this has to work with out of the box. So, the hydration of the editor from raw HTML, and the export of raw HTML out is critical to us without the requirement of a JSON model. Note 2, there are instances where we'll likely use JSON too after an import, and to support blocks that need it, like in the master layout or email templates.

Back to the original comment. Right now, we read out the HTML from the main frame, which is decorated with gjs types from the server, we sanitize out any JS, and feed this HTML into the GrapesJS editor. The editor has special blocks for server components that then sync up their editable regions with the data stored on the server (just in case we copied rendered (JS or server) content vs. source code). Again, this is working now, and functional, but the dual frames feels redundant. The idea of Being able to pass an ID to GrapesJS of "use this frame and content" would be handy and an interesting way of working with content.

[artf]

Well, as long as you understand what issues/limitations you might incur with loading directly HTML/CSS, that's up to you to manage your use case.

Anyway, if we're able to find a way to make "DOM to GrapesJS components" work via a pluggable way, I'm open to adding it but the budget of changes to the core should be reasonable (as this is quite an exception).

[bernesto]

Yes, I understand that it is imperfect. There are factors outside of our control, such as CSS DOM. That said, we've lived with CKEditor rewriting code for a decade. I think this may be an upgrade...

I agree with the budget. I am shooting for "good enough", and honestly, I think it's close to that mark right now. We'll see as we roll into testing.

What sort of issues have you seen so far with HTML-in - HTML-out? That way we know what to look for and focus on.

[artf]

What sort of issues have you seen so far with HTML-in - HTML-out? That way we know what to look for and focus on.

I'd say the most common one is with text components, as it's not obvious for the editor to understand when the editable text component starts (eg. think about text components with tables added via CKEditor), so if you can, keep at least data-gjs-type prop with HTML that will help the editor.

[bernesto]

Okay, we are doing that now at the editable block, and it seems to be working well. Thank you!