Hyperhtml: Safari (Mac/iPad/iPhone): hyperHTML.wire() with static template does not guarantee the same generated element
Tagged template function is not guaranteed to receive the same instance of a template array on Safari, even if it is used with the same template literal. It causes hyperHTML.wire() to generate a different instance of an HTMLElement.
Due to this issue it is not possible to make a component without adding wrapping element.
Here is the simplest example reproducing this issue.
https://codepen.io/anon/pen/QYwoRy
Run it on Safari and wait for some time. On our devices it usually takes less than minute to see an alert.
It seems that Safari needs the _templateLiteral function fix similar to fix for Firefox<55.
ikabirov
All 15 comments
I have removed all the unnecessary stuff to reproduce the issue, and I am going to file a bug to WebKit.
https://codepen.io/WebReflection/pen/OdVrqN?editors=0010
This is the most annoying kind of bug ever, 'cause it's impossible to feature detect.
However, are you sure you want/need to retain any node reference at all? The fact nodes are preserved in hyperhtml shouldn't translate into "_feel free to reference these and retain these around_" because that's an implementation/performance detail you shouldn't care about.
In which scenario would this be an issue? I am just trying to understand if it's worth it to penalize Safari perf due random glitches on their GC.
WebReflection
on 24 Jan 2019
WebReflection
on 24 Jan 2019
In which scenario would this be an issue?
I use it for creating component without top level wrapper. E.g now:
// button with internal state
import Button from 'button.js'
document.body.appendChild(Button({
text: 'Save'
})
If result element can be changed, we must create wrapper for every component, and result DOM will be something like:
<body>
<div>
<button>Save</button>
</div>
</body>
Assumption that element should not be changed allow us to remove unnecessary wrapper and receive something like:
<body>
<button>Save</button>
</body>
could you bind a document fragment instead, as unique holder of the button?
const wm = new WeakMap;
const Button = identity => wm.get(identity) || set(identity);
function set(identity) {
const fragment = document.createDocumentFragment();
const render = hyperHTML.bind(fragment);
wm.set(identity, render);
return render`<button>${identity.text}</button>`;
}
or something similar ?
WebReflection
on 24 Jan 2019
sorry, I know I haven't really provided a solution, just a ugly work around.
Let's see what Safari/WebKit folks say about their bug, so I'll figure out what I should do here.
WebReflection
on 24 Jan 2019
Thank you! I'll try your work around.
ikabirov
on 24 Jan 2019
could you bind a document fragment instead, as unique holder of the button?
it doesn't work, cause after document.body.appendChild(fragment) all button will be removed from fragment and moved to body. So after Button re-render it will be moved back to fragment and removed from body
ikabirov
on 5 Feb 2019
it looks like they've closed the bug as duplicated, 'cause lit-html opened the same issue already.
Of course if it's Google complaining they listen and fix so ... good lit-html has the exact same issue.
I don't think I'll do anything for the time being, but I'll keep this open in case I change my mind.
WebReflection
on 5 Feb 2019
May be add option to force use/ignore _templateLiteral function fix?
For safari ES6 it would be great to always turn it on (ES6 used in our debug environment)
For production we use Closure Compiler with transpilation to ES5. it would be great to always turn it off (now property raw is enumerable, so we have unused overhead)
What about hyperHTML.forceTemplateLiteralFix?
ikabirov
on 13 Feb 2019
the template literal fix is a third part dependency, nothing affected by random properties in this or that library.
WebReflection
on 13 Feb 2019
So ... this would force Safari to the slow path, which I believe is the simplest/best option for the time being.
https://github.com/ungap/template-literal/pull/3
The ugly sniff/hack will be removed once they fix it in a future Safari version.
Your production code will still use the slow path, but:
- better safe than sorry
- iOS devices are already the fastest one out there, it won't hurt
- this might put more pressure in WebKit/Apple folks to fix this properly, since they care about being slowed down
Please try to use that patch in your env and tell me if everything is fine, thanks.
WebReflection
on 13 Feb 2019
thank you
ikabirov
on 13 Feb 2019
@ikabirov don't thank me yet, it's not planned to go out until you confirm it works as expected 馃槄
WebReflection
on 13 Feb 2019
@WebReflection it seems everything is fine
ikabirov
on 13 Feb 2019
So I've published it as 0.2.0 'cause even if it's a patch it changes slightly the behavior of the utility.
Whenever I'll find time to update all related projects, I will, meanwhile you can force-use that version.
WebReflection
on 13 Feb 2019
Related issues
jaschaio
路
3Comments
moebiusmania
路
6Comments
jaschaio
路
5Comments
varunkumar
路
6Comments
BentleyDavis
路
8Comments
Most helpful comment
So I've published it as
0.2.0'cause even if it's a patch it changes slightly the behavior of the utility.Whenever I'll find time to update all related projects, I will, meanwhile you can force-use that version.