Possible bug in the readme example (entityToHTML)

[Nasicus]

The readme has the following example:

  entityToHTML: (entity, originalText) => {
    if (entity.type === 'LINK') {
      return <a href={entity.data.url}>{originalText}</a>;
    }
    return originalText;
  }

This works fine, however the originalText appears to be already HTML encoded and therefore if it contains special characters like an ' it will be double encoded.

E.g. originalText = my'url will result in the HTML <a href="https://google.ch">my&amp;#x27;url</a>

As a workaround I changed the function to that:

    if (entity.type === 'LINK') {
      return <a href={entity.data.url} />;
    }

    return originalText;

Now the resulting HTML will be <a href="https://google.ch">my&#x27;url</a> (because of the way the getElementHTML function works).

Not sure if this workaround is correct and can be used like this but it appears to work. I guess if the getElementHTML will never change I can leave my workaround...

Also not sure if I'm doing something wrong or if this is an actual bug.

[karldanninger]

Experienced this recently.

@Nasicus Your workaround works, thank you! Yet, this makes me a little uncomfortable since I'm unsure why this works the way it does.

Is there any way to not encode originalText supplied to entityToHtml? Perhaps that would defeat the purpose of the function since it's goal is to convert an entity to encoded valid HTML... 🤔

[hgezim]

@karldanninger

I looked into why this works and let me see if I understand it:

In entityToHTML, even when you return only <a href='...' />,

When that is converted to HTML, the above is only used to generate the tags (line 35

draft-convert/src/blockEntities.js

Line 35 in 1b78ab1

const entityHTML = getEntityHTML(entity, originalText);

).

In line 36 (

draft-convert/src/blockEntities.js

Line 36 in 1b78ab1

const elementHTML = getElementHTML(entityHTML, originalText);

), getElementHTML is called with originalText which actually ends up being used as the child node of a tag:

[Nasicus]

@karldanninger @hgezim
thanks. We're using my "workaround" in production since bascially I wrote this post. No issues.

The only thing I'm a little afraid is that the suddenly change this in the future ;)

[karldanninger]

@Nasicus Haha! I have that exact same fear - but we've made a note of this issue in our repo. 👍

Thank you for the explanation @hgezim !!!