Why return strings are iterators?

[jcubic]

Any reason why output strings are also iterators? Why can't they just be normal JavaScript Strings?

This breaks the API of vhtml.

This is the output I've got when I console log the output:

[String: '<ul><li>0</li><li>1</li><li>2</li><li>3</li><li>4</li><li>5</li><li>6</li><li>7</li><li>8</li><li>9</li></ul>'] {
  [length]: 109,
  _stringjsx_sanitized: true
}

It looks more like a String instance with additional properties, and not actually a string.

[odinhb]

I wrote about why here: https://github.com/dodoas/stringjsx/blob/11b6d223afcdff35359c5130ebdf0e60f7edba40/misc/typescript_string.md

I understand why you're saying it breaks the API but this fork was made for interacting with element.innerHtml, which accepts String objects just fine.

To summarize this fork returns String because it allows us to mark rendered strings as sanitized using the _stringjsx_sanitized attribute (which you've no doubt spotted in your output). This solved a bunch of gnarly problems with vhtml. Such as developit#34, and developit#20.

I also knew it would break some code (it did for us, we had to put some .toString() calls in our code for a while), which is why I documented this in the changelog (which begins at the fork from vhtml) and also a little further down in the documentation.

Perhaps this information should be more prominent in the README?

I'm also curious what is breaking for you? The browsers themselves don't care whether you pass string or String, but many libraries do, and the wider javascript "community" generally considers using String to be a bad idea, so it makes a lot of sense that you would encounter some friction while using this.

[jcubic]

Thanks for the explanation, the reason why it was breaking for me because I don't use element.innerHtml directly. I needed to change my library, but I don't remember, and I'm not able to find what I did to fix the issue. The question was asked about 8 months ago.