I have created a web component, and would like to access the elements from within the component.
Am using .attachMode({mode:'closed'}), so the parent has no access.
<template id='hello-world-template'>
<span id='inside'>Unchanged,</span> <span id='outside'>Unchanged</span>
<script>
document.querySelector('#inside').innerHTML = 'Changed';
// Ideal, but does not work - no such element
</script>
</template>
<hello-world></hello-world>
<script>
customElements.define('hello-world',
class extends HTMLElement {
constructor() {
super();
var template = document.getElementById('hello-world-template')
var clone = template.content.cloneNode(true)
const shadowRoot = this.attachShadow({mode: 'closed'}).appendChild(clone);
}
connectedCallback() {
this.shadowRoot.querySelector('#outside').innerHTML = 'Changed';
// Not ideal, and also does not work - this.shadowRoot has no querySelector
}
});
</script>
Some attempts:
- Within the document fragment - this, self, window, and document all refer to the parent window. And none can access the shadow root.
- Tried to store the shadowroot in a global variable and access it from inside the fragment or connectedCallback.
Even if that worked, it would defeat the point of using {mode:'closed'}, but anyways it did not work.
I have a hack that works, but cannot imagine that I have to use it.
The whole point of encapsulation is that things can be self contained, but what good does that do us if the JS cannot act on the other items in its container?
If this is the solution, would love a tip to explain the logic of the way components where implemented.
Here's the hack, though: include an image that runs the JS onload.
<template id='hello-world-template'>
<span id='inside'>Unchanged,</span> <span id='outside'>Unchanged</span>
<script>
function runner(img){
let doc = img.parentNode;
doc.querySelector('#inside').innerHTML = 'Changed';
}
</script>
<img src='data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs=' onload="runner(this)">
</template>
<hello-world></hello-world>
Note regarding similar questions (25048359, 16633057, 55101967, etc.) - those answers will not work when mode is closed, which I need.
Looks like you have errors in both Element references and
thisScope (in<script>)appendChildis your Nemesis here.It returns the inserted element... not a shadow-root but a
#document-fragment(cloned template)fixed with:
Then:
mode:closedwill not assignthis.shadowRoot..which you can not re-use because it still is a read-only property
fixed with:
You can now do:
I do not understand why you consider this not ideal
this.Rootis accessible from all/any methods inside the ComponentA good resource for all DOM methods is: https://javascript.info/modifying-document
<script>inside a<template>(this scope)You injected the template into a Component
documentcan not access elements inside any Component shadowDOMdoesn't matter if the shadowDOM is
mode:closedormode:openThe
<script>scope will bewindow(since it wasn't assigned a scope)(I do not think you can set the this scope for a SCRIPT)
To get the Component scope inside that
<script>you have to be creative ..and use your
img onload='hack'With the
onloadon the<style>element makes it a bit less of a hack (IMHO)one major issue: will only execute for the first used
<hello-world>element!!I didn't write this of the top of my head,
(Work in progess) JSFiddle playground (also showing referencing Component methods) at:
https://jsfiddle.net/CustomElementsExamples/zpamx728/
Update #1
Chromium (Edge/Chrome) and Opera are fine, FireFox
v72.0.2misbehaves:the
onloadon a<STYLE>element will only fire for the first elementI changed the JSFiddle to use your first hack using an
<img>, and it fires for every elementtemplFunc()is loaded/scoped in shadowDOM, so is callable from component methods (see JSFiddle)but.. only in FireFox is NOT defined/available for the first element
For now I consider this a FireFox bug... will investigate further... (to boldly go where...)
!!! Update #2 !!!
OOPS! Played some more with it.
Turns out all variables and functions from a cloned and imported SCRIPT
are hoisted to the global
windowscopeSo above code works, but has a major side-effect...
That is also why FireFox complains about re- declaring
letvariables