FEAT: Enhanced Shadow DOM Support

[AStoker]

What are you trying to add to GrapesJS?
Better Shadow DOM support, allowing developers to render GrapesJS inside a Shadow element without having to specifically pass in elements rather than selectors in the configuration.

Describe your feature request detailed
When currently using element selectors, GrapesJS simply uses the document query selector. This does not work when rendering inside a Shadow DOM, as the document isn't the shadow root. I would like to be able to define a shadow root so that anything GrapesJS does/needs is contained within the shadow root.

Example of using GrapesJS inside a ShadowDOM: https://jsfiddle.net/theandybob/s9bnhw30/

Is there an alternative at the latest version?

• Yes (describe the alternative)
• No

Is this related to an issue?

• Yes (Give a link to the issue)
• No

[artf]

Hi @AStoker I don't understand what is the real issue with your example (aside not loading GrapesJS styles inside your shadow dom). If you're attaching shadow dom, obviously, you can't do this container: '#gjs', but you're still able to pass HTMLElements as you're already doing in your example, so what is the issue?

[AStoker]

The issue is that I must pass HTML elements everywhere and cannot use selectors. This can become cumbersome to write as I must now use the shadow Dom's query selector for every panel, every element, anything that we hook into GrapesJS.
Additionally, if there were the concept of a container, it would significantly help isolate GrapesJS from accidentally interfering with other parts of an application. As more applications make use of components and custom elements, proper isolation between components is important. The fact that GrapesJS automatically pulls in font-awesome (from a CDN too) into the root of the page isn't ideal, as there could very easily be conflicting styles. If you are using Shadow DOM, you could pass the container to GrapesJS and it would put font-awesome within the Shadow DOM, appropriately isolating styles from other parts of the application.

[AStoker]

I updated the JSFiddle so you can see what we need to do to get styles within Shadow DOM. But unfortunately the CSS that's automatically added by GrapesJS exists on the body and is both polluting the global stylesheets and pointless due to GrapesJS being inside the Shadow DOM.

[artf]

Well about the font-awesome, the issue is clear, you can actually disable it from the config with a false value and import it manually as you do it already.
So, about styles, I think that is the only way to do it correctly, as you're creating a custom component with a third-party library that requires an external stylesheet.

What is not yet clear to me is this part:

This can become cumbersome to write as I must now use the shadow Dom's query selector for every panel, every element, anything that we hook into GrapesJS.

What exactly do you need to? Can you show me an example of how would you expect it to work?

[AStoker]

Didn't know that about the CSS, that's helpful, thanks.

Here's an example repo of what I'm having to do: https://github.com/AStoker/grapesjs-aurelia/blob/main/src/my-app.js
One way or another, I'm having to get a reference to a DOM element rather than just using selectors. With Aurelia, I can do this with the ref binding, but if it were vanilla JS, then I'd use the query selector. In either case, we're essentially doing shadowRoot.querySelector('#MySelector') everywhere rather than just '#MySelector'.

How I would envision it working, we'd essentially need some kind of shadow root option. "container" would be great, but it's being used for a different purpose (container of the form rather than the container for GrapesJS). So, we'd have some config, let's just call it 'shadowRoot' for now (but maybe just 'root' is better?), and with that you would pass in an HTML Node. This node is the root for GrapesJS, and therefore any selectors that are being used, any DOM elements being created, they all would be contained inside this root, effectively isolating it from the outside, and enabling isolation from within.
In the framework itself, it means rather than using a document.querySelector, you'd be using something like shadowRoot.querySelector. Heck, you could simply do a quick check to see if we have a root passed into the config and default to the document if we don't.

let root = config.shadowRoot || document;
root.querySelector(someSelector);

[artf]

We have already editor.getContainer() which returns the main editor root element of the editor, so you can use that if you want to query an element.

I'm still not getting your statement here:

I must now use the shadow Dom's query selector for every panel, every element, anything that we hook into GrapesJS

Which panels/elements are you talking about?? There are something like 5 modules that allows rendering stuff externally by using appendTo option, and that's all.
So, are there real conflicts with some document.querySelector usage in the framework (which should be quite limited anyway) you're able to indicate?