Hyperapp: dangerouslySetInnerHTML?

[FlorianWendelborn]

Is there an equivalent to react's dangerouslySetInnerHTML? I'm currently using onCreate{e => e.innerHTML = '...'} for this purpose.

It's not a good solution though, since it flickers when updating.

[zaceno]

I haven't really used React, but from having read about dangerouslySetInnerHTML I think hyperapp doesn't need an equivalent. From what I understand of the dom-patching algorithm, your approach ought to work. Not sure why it would be flickering (unless there's something going on with sibling nodes as well). If you have a CodePen example or something, I'd be happy to take a look!

[FlorianWendelborn]

@zaceno It happens while updating, because the "position" of the element may change, therefore it gets re-rendered due to the simple vdom hyperapp has.

I'll see if I can provide a codepen. Not sure if I can reproduce this, happens in a relatively big (700kb before minify/gzip) work (closed source) project.

[zaceno]

Ah, in that case, the flickering problem will be solved when https://github.com/hyperapp/hyperapp/pull/141 gets merged. (You'll just need to add a key: property to the node you want reused in a new position, rather than rerendered)

It happens while updating, because the "position" of the element may change

... that's what I was alluding to when I said "(unless there's something going on with sibling nodes as well)"

[FlorianWendelborn]

@zaceno It's not really about sibling nodes in my case. I think it's caused by a sibling of the parent of the node.

[zaceno]

Ah, ok well, if the parent gets rerendered so will it's children. So the solution for you (once keys are merged) will be to key the parent then.

[FlorianWendelborn]

@zaceno Let's hope this fixes it. I'd still prefer something like dangerouslySetInnerHTML though, but it'd be fine if keys fix the symptom instead of the cause.

[zaceno]

Again, I don't know much about React or dangerouslySetInnerHTML, but from a stackoverflow answer about it:

Because React uses a virtual DOM, when it goes to compare the diff against the actual DOM, it can straight up bypass checking the children of that node because it knows the HTML is coming from another source. So there's performance gains.

In hyperapps vdom at least, this would not be a concern anyway, since it is never comparing to the actual DOM, only comparing the old and new virtual-dom trees.

So the cause of your problem is not a lack of dangerouslySetInnerHTML, but rather the fact that the current patching algorithm will sometimes decide to destroy and recreate nodes (causing the flickering) when that was not intended.

The keys are an attempt to solve this, by letting you tell the patcher: "don't destroy and rebuild this dom node! It has state that I want to keep but isn't represented in the virtual dom"

[lukejacksonn]

I came across a similar issue when trying to inject some arbitrary HTML (converted markdown) into an element.. see here https://github.com/lukejacksonn/hyperapp-wiki/blob/master/index.html

I never thought about using onCreate though instead I wrote a really hacky function that effectively does dangerouslySetInnerHTML but requires a selector which makes me sick and caused weird behavior when clearing the parent or overriding content.

const htmlify = selector => {
  const $ = document.querySelector(selector)
  $.innerHTML = $.textContent
}

Hopefully the keyed vdom helps with this too.

[FlorianWendelborn]

@lukejacksonn I'm actually using it for the same thing. I need to render markdown in a hyperapp app.

[jacobtipp]

I know Vue.js uses a v-html directive which is basically doing the same thing. Seems like a common edge case that should have it's own method or at least documented on how to accomplish it.

[jorgebucaran]

@dodekeract Can you share an example?

[jorgebucaran]

@dodekeract It's difficult to process this issue as it's not clear what should be done. If you want to change the API, you must provide an example where the current API falls short, like #117 led to #141.