FEAT: Create the canvas from a URL

[ianef]

I've been playing with GrapesJS and trying to integrate it into a Symfony 5 project. In particular I want to be able to edit templates in the editor based on Bootstrap 4 and other components like FontAwesome Pro and custom blocks based on these.

I use Symfony's Webpack-Encore bundle to generate the scripts and style files for the application which leads one heck of major headache trying to get the current iframe canvas system to work using the same versioned components like Bootstrap etc.

Currently I can only inject style and script URLs into the canvas via the init configuration like so:

grapesjs.init({
    ...
    canvas: {
        styles: [url1, url2, ...],
        scripts: [url3, url4, ...],
    },
});

The problem is that I want to keep exactly the same version of included components as I am using in the main application. If I upgrade these I want it to be reflected in the components used by the canvas, this may also include custom code and styles.

In Symfony, and other major frameworks, it's really not good practice to link to root resources outside of the public area, they are generally created and compacted into the public area during a build process.

Webpack creates build files in different ways for different circumstances. In development mode they are served form a local hot-plug server, in production mode from static build files that may or may not include versioning in the file name. Plus the common code can be split out to reduce overhead. You generally reference the files you need using an entry name, this then pulls in as many files as required from the webpack build structure.

Essentially it's a total pain in the rear trying to pick through this to get to the root files needed for a particular view which will likely be very different on the next build.

I would like to propose that we could optionally provide a URL as the base document for the iframe. In this case GrapesJS would load the iframe using the URL and then replace the entire body content, or the contents of an element specified by an id. The latter in many ways is preferable as script elements can then be appended to the bottom of the body element.

This would allow a view, in Symfony or whatever framework, to be created that pulls in whatever files are required and mangled via webpack, thus providing a nice and straightforward way of providing whatever support libraries are needed within the iframe using exactly the correct versions as the rest of the application.

This is not just an issue with Symfony. Any application using a Javascript and CSS compilation and reduction system is likely to suffer the same headaches.

[artf]

Hi Ian, if you need to load HTML content from a URL I can only suggest fetching it server-side and initialize the editor with that content (loading external resources in the browser would mostly hit the cross-origin issue), so, for how browsers work I don't see any good reason in adding such a feature.

[ianef]

That's a real shame. I didn't say anything about fetching from another site, what I wanted to do was keep it consistent with the rest of the project.

Oh well, I'll keep looking elsewhere for an editor that integrates better with the current way larger application are built. Webpack and other transpilers really are they way forward for larger projects, even small benefit too.