FEAT: Further Decomposing GrapesJS

[bernesto]

Right now GrapesJS has a great modular architecture. I really appreciate how @artf architected this project into blocks, panels, canvas, etc. It is very easy to work with and shows a lot of foresight.

The beauty of GrapesJS lies in the block based DOM manipulation. Pair that with a layers view of elements and the ability to manipulate their styles in an intuitive way, and you have a very powerful component.

Let me start by saying that as we evaluated this for our platform, I appreciate having a fully functional demo as an example. But I find myself in a reductive process, where by I am removing a few superfluous components from the core editor that we don't need, or plan to implement in our own way. These add extra weight and complexity to the editor that is seems unnecessary.

As I think about each of these, I can imagine that I'm not the only one facing these steps. This thread is intended as a starting point for open discussions on what is included in GrapesJS, why, and what should/could be broke out and optionally loaded instead as a module or config.

Here are my initial items:

1. Editor layout: As described in the documentation (https://grapesjs.com/docs/getting-started.html#start-from-the-canvas), the developer is instructed to override styles for panels and tool bars to remove them when implementing their own UI. I believe that this is backwards, it should be additive and broken out into a default configuration that can be loaded.
2. Export: Does anyone use this functionality? I think the expectation that the user would want to download the results of their work and upload it somewhere is a very limited use case. After viewing many other implementations of the editor; 99% are posting the results to a server somewhere.
3. That leads me to CodeMirror: Without export, CodeMirror is unnecessary dead weight, and adds 231k to the minified version (25% of the editor). While I do think the editor should retain management via CodeManager for plugins, I think the editor should be added via a plugin or external reference instead. For instance, in our SPA platform, we already have Monaco loaded for other purposes. There is no need for have CodeMirror along for the ride. That said, this is trivial cut, but a cut none the less.
4. Lastly, the default RTE: This is also dead weight as well (albeit much less, but every kb counts). As we discovered recently, using a full RTE like CKEditor or TinyCTE is not optional, even for the most basic edits due to inconsistencies in how browsers implement contenteditable. Addressing these is a non-trivial task, and outside of GrapesJS core value, especially when robust solutions exist already. Additionally, GrapesJS lacks the ability to unwrap inline elements (breaking links, merging spans, etc), which honestly belongs in the domain of the RTE anyway. The default RTE is good enough for basic demonstration purposes, but there is a reason those other RTEs unfortunately have to exist. Bundling this into a default config is probably a good idea. That said, this appears more complicated to cut out, for less gain. My OCD side cringes at leaving it in, but my practical side says "this is definitely going to bite me later don't let it be".

I know these all would be breaking changes. But, that said, I think they are all valid points, and could be shimmed in with a config for the few who need them.

Ultimately, my goal is to write as little code as possible to get the job done 😂 (and ship as little code as necessary to the client). Your's probably is too. Unwinding code out of a codebase can be tricky, can break things, and isn't a good use of time.

I'd like to hear your thoughts!

[bernesto]

One more:

Asset manager: It is a good implementation, but this also seems like something that people would already have in their own file management system. And if they did use it, it would likely be a jumping off point for their own, as it would need to be styled to match the rest of their system.

[artf]

Thanks @bernesto for starting this discussion. I'm actually on the same page about everything here.

My next plan is actually to make the core completely independent from UI as grapesjs itself could be used outside of the browser context (eg. using headless mode on server/WebWorker).
The plan is to remove completely the usage of Backbone View for the UI and switch to web components. This would allow reusing/extending the same components (eg. panels, buttons, inputs, etc.) without even worrying too much about the existence of FE frameworks as it's all about rendering standard web components.

So there will be a new @grapesjs/core-ui (tree shakable) package covering everything about Editor Layout in general, stuff like Export/CodeMirror (eg. by default we could render a simple textarea that you can extend with a code editor of your choice), Asset Manager UI etc..

• Built-in RTE, I think it would make sense to have in the core just a simple usage of contenteditable (no UI), @grapesjs/core-rte with the current, deprecated, implementation of execCommand, recommended only if used for super basic stuff. Next would be to have a new package by integrating something solid and extendable (eg. TipTap/ProseMirror) and recommend it as the best choice.

Other stuff that would make sense to remove:

• Components like Map, Video (should be refactored to basic <video/> element, without the context of platform providers like Youtube/Vimeo/etc.). The rule of thumb would be to stay close only to native HTML elements, we can also think about creating @grapesjs/html that would cover most of the native HTML constraints (eg. the current implementation of table related components)

[bernesto]

@gankairen What did you end up using for your RTE? We are using CKEditor 4 right now, but investigating ProseMirror for the task.

[gankairen]

Ah we're just using the default for now. We originally went the CKEditor route before TipTap because there were good integration docs/examples for Grapes. But I think someone made the decision that the licensing didn't align or some such.

[bernesto]

Okay. They must have been looking at CKEditor 5. They switched licensing with that version, and it is pretty much unusable for many now. v4 is GPL though, but is officially unsupported now. TinyCTE is a good alternative as well. But, both are designed with the intent of being the sole HTML editor, and as such, are sort of a sledgehammer approach to the RTE, since much is handled by GrapesJS. ProseMirror seems like the most logical option, since you can funnel it to just the functionality needed. The issue for us with just using contenteditable are the nuanced cross browser consistency issues. The virtual DOMs in these editors aim to normalize the experience.

[artf]

Thanks @gankairen

I would very much like to see headless server/worker support

The headless option is already available (eg. usage in a worker #5232) and should work for most of the cases. One thing that I believe is still a miss is the ability to process HTML strings (the HTML parser heavily relies on DOM elements) but that would be close to a breaking change as we'll also need to move away from isComponent (which relies on parsed DOM elements).

Agree about the default RTE, I'd only recommend it as it is, trying to extend and leverage the execCommand is a waste of time (as already mentioned by @bernesto cross-browser consistency is a nightmare). I'd like one day to try the integration of TipTap but also agree that ProseMirror is a leaner and "safer" alternative.

[jogibear9988]

@artf if you need a html parser, you could also try: https://github.com/node-projects/node-html-parser (or the original project).
We also use that in our designer framework (https://github.com/node-projects/web-component-designer)

[hazho]

"isComponent" is doing a great job so far, if you are about to get rid of it, then, what would be an alternative to it? of course the loaded html template would never be recognized by grapesJS as a component if there is no such checking like how "isComponent" does..!

[artf]

Yeah, good question, I didn't explain my plan better.
It's not about just removing isComponent but providing a new alternative that doesn't rely on DOM, for example:

addType('cmp-id', {
   isParsedNode(node: ParsedNode) => ... // same return of `isComponent`
  // ...
})

interface ParsedNode {
  tagName: string;
  attributes: Record<string, string>;
  children: ParsedNode[];
}

for a slight retro-compatibility, we can leave isComponent and provide a SyntheticNode instead of the DOM, which might allow old plugins/components to work for most of the cases.

addType('cmp-id', {
   isComponent(el: SyntheticNode) => ... // same return
  // ...
})

interface SyntheticNode extends  ParsedNode {
  getAttrbute: ... 
  // + other common DOM element methods
}

[hazho]

I am thinking of shoelace components, can we make the coming gJS depend on it or adapt it and replace some of its functionalities to fulfill the core needs of gJS..?

[artf]

Are you referring to editor UI or components you build/export?

[hazho]

Also, isn't possible we make the gjs have a base/core that is very tiny, it's only job to accept a wide range of customization-as-plugins, following a common Spec? not sure what spec would be best, but of course should be future proof (something that can be flexible for future changes in web technologies)

[jogibear9988]

Don't know if you have looked at my designer framework (https://github.com/node-projects/web-component-designer), it is something simmilar (but also different) to grape js. I've created addons wich are normally not included and can be loaded: https://github.com/node-projects/web-component-designer/tree/master/packages
I've also a infrastructure of different services wich you could use (if you register them) (see: https://github.com/node-projects/web-component-designer/tree/master/packages/web-component-designer/src/elements/services), or not. They could also be moved to extra packages, but I did not do it, cause also a bundler could treeshake them away.

Maybe this could be interesting or usable for you.

[jogibear9988]

What mine is missing (in comparison to grapejs), is the positioning for static layout. This is something I#m working on and hopefully release it in the next weeks.

[hazho]

@jogibear9988
I remember I did test your project, but there were some thing made me not like it (to be honest with full respect for your efforts) but I really forgot what was that thing, will try it again later and feedback to you here

[jogibear9988]

Yeah, would be interesting to know ;-)

[artf]

isn't possible we make the gjs have a base/core that is very tiny

Well, that's the goal @hazho 😅

[hazho]

@artf I am ready to rebuild the gjs from scratch if you are willing to we team up for this, I can give this project daily up to 2 hours, assuming this would be best way to collaborate..!
I really don't want us to rely on any framework/lib, just vanilla JS build a class to register all needed parts of the gJS as the core, and create a hooking mechanism for plugins.
in All cases I was about to start something like this alone, but as I saw you folks you want to refactor gjs, I would be happy to work and collab on this together, this will benefit every parties (hopefully)

[jogibear9988]

There's also another version wich is rewritten on base off grapejs: https://github.com/saasquatch/raisins
I've not yet tested it (has no live sample), so I don't know what it is capeable off.

[artf]

I really don't want us to rely on any framework/lib, just vanilla JS build a class to register all needed parts of the gJS as the core, and create a hooking mechanism for plugins.

I'm on the same page 👍

@hazho sent you a message to your email (the public one from your GH profile).

[jogibear9988]

Maybe I could also help or get ideas to the project.
I'd love if I could use parts (or more) in my designer, I sadly found this one at first a few moths ago.

But for example, my designer works in a shadowRoot, wich is needed for our usecase, cause every javscript webcomponent does not need to be reloaded in the iframe (wich could take a while).
And also, my designer has also a zero dependecy strategy. the base project has no dependecies, onla the addons like a special html pasrer, the code editors, ...
It would be nice for example to have a reusable property grid, or at least the editors.

I've for example created a service container, in wich you can replace the services with your own, or for some services (for example property providers) you can register more than one, and then there are conditions wich decide wich service to use.
Wich this modularity I created for example a designer for ZPL labels with my framework: https://node-projects.github.io/web-component-designer-zpl-demo/index.html

I also thought on how for example webcomponent librarys could be better supported in designers. So for example I created a tab-webcomponent, wich has special addons for my designer: https://github.com/node-projects/tab.webcomponent/blob/main/src/designer/ElementInteractionService.ts
But I would like if we have a more universal way of adding such support for all designers

[hazho]

@jogibear9988 let's meet to put some common ground to a standardized Drag&Drop Page and Component (Editor and builder), hopefully as a base for all other editors and builders as an open source that support vanilla JS classes and objects, everything that a plugin does to be appended to the related Array of that (thing/function/action ...etc.) for example, the Editor.Components to be an array of Component objects that follows a specific structure, the same mechanism for Editor.Pannels, Editor.Blocks, ...etc.

we can say a plugin can do so by simply defining an object or a new instance of each of the Editor's properties.

as for the Canvas (Editor area), to be set to actual Canvas element only if the user want to freely create 2D and/or 3D Components, or using the WebGPU, or otherwise the default to be a DOM element wrapper/container instead of iframe element