glorious-codes / glorious-demo

The easiest way to demonstrate your code in action.
https://glorious.codes/demo
MIT License
3.4k stars 106 forks source link

HTML vs Plain Text Handling #119

Open WadeWaldron opened 1 year ago

WadeWaldron commented 1 year ago

Here's a quick sample of a demo:

const animator = new GDemo('#container');
animator.openApp('editor');
animator.write('class Test extends Base<T>');
animator.write('<span></span>class Test extends Base&lt;T&gt;');

This particular demo creates some issues.

The first line renders exactly as written with the &lt; and &gt; being rendered as is. The second line actually decodes the &lt; and &gt; into < and >.

So there is an unexpected difference in how it renders the two lines of code.

I would expect it to either always decode the symbols or never decode them, rather than sometimes as it is right now.

rafaelcamargo commented 1 year ago

Hello, @WadeWaldron!

Here's a link to the possible solution.

As you see, it's recommended that you use some syntax highlighter when writing code in the editor. It will work even mixing languages like in the example above.

WadeWaldron commented 1 year ago

Actually, the code highlighter is kind of where the problem comes from.

I've set up a bit of Javascript that loads some code, runs it through highlight js and then renders it.

The problem is that Highlight JS will encode symbols like < and >. However, it doesn't always add HTML tags to the output. It depends on the language, code etc.

So for example, it might add tags for something like:

class Child extends Parent<T>

However, it might not add tags for something like:

Child instance;

However, whether it adds HTML tags or not, it always encodes the symbols.

So when I feed the code through highlightjs and then into glorious, sometimes it gets HTML and sometimes it gets plain text, and then it interprets the encoded symbols differently depending on the situation.

I've been able to hack it by adding <span></span> to the beginning of the highlighted code so it forces it to interpret it as HTML, but that feels dirty.

It might be nice if I could explicitly tell Glorious whether the code is encoded or not.

rafaelcamargo commented 1 year ago

Hmm... Okay. I think I now understand what you mean.

The code that determines whether or not to escape HTML is located here: https://github.com/glorious-codes/glorious-demo/blob/master/src/scripts/services/type/type.js#L21

To make this decision, the code attempts to identify the presence of any closing HTML tag: https://github.com/glorious-codes/glorious-demo/blob/master/src/scripts/services/dom/dom.js#L18

So, it seems that you need a way to explicitly set which lines of text should have their HTML characters escaped and which lines should not. By doing so, Glorious Demo would bypass the condition present in the type service and consider the option you've set. Is that correct?

WadeWaldron commented 1 year ago

I would suggest that instead of explicitly setting which lines should have the HTML characters escaped, and which ones should not, it should be possible to simply turn off the autodetection.

I.E. It would be nice if there was a setting such as {escapeHTML: true} or something to force it to always escape the HTML character codes. Or {escapeHTML: false} would never escape. If that flag isn't set, it could default to the normal behavior.

WadeWaldron commented 1 year ago

Or, actually, looking at the code, perhaps it should be something like:

{content-type: 'html'} {content-type: 'plain-text'} {content-type: 'auto'}

Then the code would update to something like this:

function getSpecificTypeService(text){
  if(contentType=='html')
    return typeHtmlTextService;
  else if(contentType=='plain-text')
    return typePlainTextService;
  else if(domService.containsClosingHtmlTag(text))
    return typeHtmlTextService;
  return typePlainTextService;
}