Render external HTML

[lthms]

Hi everyone.

I love Halogen and try to use it for several of my projects where I need a web ui. Unfortunately, for one of them, I face an issue I have no idea how I can solve.

In this project, the UI will be used to display some HTML retreive from a REST api. I want to display this HTML, but I cannot found how this can be done using Halogen, as it protects against code injection by default. Do you have any idea how I can do that?

[garyb]

I think you'll have to do something slightly hacky with innerHTML for this:

1. Use a ref to capture the element for the container you want to display your pre-rendered HTML in
2. Ensure there is a key on it, as a hint to virtual-dom that the element should be preserved during each render cycle
3. When you get your data, set the innerHTML of the ref-captured element

I think unless we introduced a parser to produce Halogen-HTML from an input string then that's the only option at the moment.

[lthms]

Thanks for the quick answer! Just to be sure, you are saying that it is not possible to do it using the render function of a component? If you have some time, you think you could give me a minimal example? (I will search myself, but I am not familiar with virtual-dom…)

I think unless we introduced a parser to produce Halogen-HTML from an input string then that's the only option at the moment.

Why not adding a new constructor to HTML that won’t be sanitized? UnsafeText or something

[garyb]

Yeah, that is what I'm saying unfortunately. I don't have time to mock up an example right now but will try to remember to come back and do so later (I can perhaps add it to the guide for people who run into this in the future!).

The problem is down to using virtual-dom here, so even extending HTML with a constructor doesn't solve the problem: the idea of virtual-dom is:

• there's an in-memory data representation of the HTML
• every time there's a re-render this data representation is diffed against the previous tree to generate a patch
• the patch is then applied to the DOM

The idea is to minimize the amount of DOM mutation that goes on, since that's the slow part of rendering - the patch (in a perfect world) contains the minimal changes necessary to update the DOM to the desired result.

So, the problem: we have the HTML as a blob of text, so it doesn't fit into this diffable tree representation, preventing us from integrating it into the normal render process.

[lthms]

(I can perhaps add it to the guide for people who run into this in the future!).

I think it would be very valuable (at least for me! d: ) In the meantime, I will try to have a look at what you said but I am very unfamiliar with all of this.

Anyway, I have a purescript version of my parser/generator for offline and realtime preview and it is general enough to produice a HTML output. However, even that is not totally possible as I try and values such as   are also sanitized ):

Thanks again for your help and hints. I will try to write something myself, but I am definitely interesting by your mock version (:

[lthms]

Finally I was able to produce an Array of HTML and it works! Injecting HTML stiil seems like a good feature to have, however, but I found some reference to the ref-thing you were talking about, so if really I need it, I think I will be fine (and if it is the case, I will try to do a PR here to add some doc about it).

Thank you for your help!

[ibrahimsag]

@lethom i've sketched something here. hope it helps.
https://gist.github.com/ibrahimsag/e142652bcad3c8ade14a727ae952937a

[lthms]

Thank you very much! I will have a look as soon as I can.

[flip111]

I have the exact same problem.

By default, the highlighting will wrap highlighted text in <em> and </em>

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-highlighting.html

i can change the tag but it will still be html .. or i have to parse the database result and concat it together which adds unnecessary overhead.

I don't require this html to be parsed and analyzed. When the string needs to re-render it can re-render the "entire" html blog (in my case this blob is just a few <em></em> tags .. so i don't worry about this)

@lethom can you post up your solution? I would like to compare it with the one from @ibrahimsag

[prathje]

@ibrahimsag Updated (and simplified) version: https://gist.github.com/prathje/7422e49b7c809fe8236bb2f213e7076e

[flip111]

I hope that makes it into an official component !

[rnons]

A made a library for this
https://github.com/rnons/purescript-html-parser-halogen

[thomashoneyman]

Closing this as @rnons' library looks like it covers the original use case and there aren't plans to move any functionality like that into Halogen itself, but I can reopen if further discussion is needed.

[flip111]

@thomashoneyman can you re-open?

The workaround is not so great and i think there is room for better solution given caveat not to expect some features to work on the inserted html (see down below).

---

First why is the current situation not really ideal:

Problem with halogen/vdom not supporting first class HTML

1. Not all html elements are supported by halogen. (this can be fixed with effort of course)
2. Halogen can not be used with web components
3. Can not use html generated by other tools
4. VDom wants to make Node in tree for every html tag found -> This is unnecessary for static html causing overhead on runtime.
5. VDom wants to make Node in tree for every html tag found -> every tag supported means more library code to 1. maintain by library authors 2. ship to client.

Problems with component workaround:

1. Overhead from widget life cycle
2. Slot types bubble up to parent component -> Can not compose in single place. Needs HTML + slot management in different places because no encapsulation.
3. Slot types bubble up to parent component -> Can not compose safely (compile time) because of runtime warning Halogen: Duplicate slot address was detected during rendering, unexpected results may occur

---

Going back to original problem description:

So, the problem: we have the HTML as a blob of text, so it doesn't fit into this diffable tree representation, preventing us from integrating it into the normal render process.

What is the problem of not fitting in the tree representation? Slap on another data constructor on the tree node sum type. Whenever handling this constructor the entire element, including all it's children, can be removed/inserted (depending on what the vdom wants to do).

Obviously you can not use a bunch of features such as click events in this piece of the DOM. Though when reading first post

In this project, the UI will be used to display some HTML retreive from a REST api.

I don't believe that in this use case it was expected to have features like events on the html loaded from REST api. In my situation of 2017 this was not the case too. And in the new 2022 situation it's also not the case.

---

The lack of first class html is quite high friction when designing HTML first. For the website layout design it's really valuable to directly copy snippets of html, css, svg, etc of the web and work on design. The friction with the workaround is mainly due to having to manage slots and also checking runtime console to see if there was not a mistake somewhere with slot naming. Also including an entire slot clutters code more than just a simple raw function. The developer UX can be better in this scenario.