Custom component for text node including special characters

Hi @malonecj I'm not sure how exactly you would expect to see and manage those components (especially when you combine templates inside conditions) but I think your current approach in isComponent is not properly correct as you have to deal with text nodes. Inside your liquid handle isComponent you use el.textContent which I think should be similar to liquid condition with el.nodeValue as it's only available on text nodes (probably it would be better to check if it's actually a text node el.nodeType === 3). As a first step try to update your custom components in this way, as currently are skipped from the parser due to this condition

editor.Components.addType("liquid-condition", {
    isComponent: (el) => {
        const { nodeValue } = el;
        const isComponent = nodeValue?.trim().includes("{%");
        // This probably will help you understand better how the parser processes nodes
        console.log('isComponent liquid-condition', { el, nodeValue, isComponent });

        if (isComponent) {
          return {
              tagName: 'liquid-condition-el',
              components: { type: 'textnode', content: nodeValue },
          }
        }
    },
    ...

editor.Components.addType("liquid-handle", {
    isComponent: (el) => {
        const { nodeValue } = el;
        const isComponent = nodeValue?.trim().includes("{{");
        console.log('isComponent liquid-handle', { el, nodeValue, isComponent });

        if (isComponent) {
          return {
              tagName: 'liquid-handle-el',
              components: { type: 'textnode', content: nodeValue },
          }
        }
    },
    ...

But I don't think this approach will work once you start to mix templates with conditions as from the HTML parser perspective you receive something like this:

* div
  * textNode - containing content starting from '{% case...' to '{% endcase %}'
  * div - containing 'Hello World!!!'
  * textNode - containing `{{ some_content }}`

So probably another approach would be to use one custom component as a parser of the template engine

Components.addType("liquid-case-condition", {
   // no need for isComponent here, only the parser will output components for the engine
    model: {
        toHTML(opts) {
            return `{% case ${this.get('conditionName')}  %}
                ${this.getInnerHTML(opts)}
            {% endcase %}`;
        }
    },
});

// ... other components to handle better the template engine

Components.addType("template-engine", {
    isComponent: (el) => {
        const { nodeValue } = el;

        if (nodeValue?.trim().includes("{%")) {
          const parsedTextNode = parseEngineText(nodeValue);
          // transform parsed stuff in components for the editor, eg.
          return {
              type: 'template-engine',
              components: [
                  {
                      type: 'liquid-case-condition',
                      conditionName: 'shop.subscription.currentPlanName',
                      components: [
                          // ... other template engine components
                      ]
                }
                // ...
              ]
          };
        }
      },
});

I'm closing this one as there are no issues with the core itself, if you have any other questions @malonecj let me know.

Thanks for reporting this, @malonecj.

Great suggestion about Custom component for text node including special characters! While this specific feature isn't yet in the core API, there are several ways to achieve similar behavior.

Using the event system:

editor.on('component:update', (component) => {
  // your logic here
});

Alternative approaches:

• Listen to selector:add for CSS selector changes
• Use selector:custom for custom rules
• Tap into the change:* events for fine-grained tracking
• Build a plugin that extends the editor with this capability

Making it official: If this feature would benefit many users, consider opening a formal Feature Request on the GrapesJS repo with:

• A detailed use case
• Code example showing the desired behavior
• Why this matters for your workflow

The core team is receptive to well-motivated feature requests backed by real use cases.