# Web-components interop (childNode issues)
**URL:** https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730
**Category:** Learn
**Created:** [June 2, 2019, 8:29pm UTC](https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730 "2019-06-02T20:29:04Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@ciekawy](https://discourse.elm-lang.org/u/ciekawy)
#### Post date: [June 2, 2019, 8:29pm UTC](https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730/1 "2019-06-02T20:29:04Z")
in regard to childNodes issue raised in the past (i.e. [JavaScript Exception: Cannot read property childNodes of undefined, with extension Dark Reader](https://discourse.elm-lang.org/t/javascript-exception-cannot-read-property-childnodes-of-undefined-with-extension-dark-reader/2748)) I believe thats something worth to at least figure out reasonable proposal.
I was playing recently to create an ionic framework app using elm ([https://github.com/ciekawy/diegy](https://github.com/ciekawy/diegy)). As new ionic is based on web componets some of them are (i.e. `ion-item`, `ion-header`) complex in the way the internal effective DOM may change based on data binded into the web component. This lead to elm loosing traction of original DOM structure and raising `"Cannot read property 'childNodes' of undefined"`. It perfectly make sense for elm to its principles and architecture. OTOH with rise of new standards and frameworks would be great to have some common way to coexist. That was great move from ionic framework to become framework-agnostic and leverage web-componets as one factor to acheive the goal - unfortunately there is still a blocker to integrate well with elm-lang.
---
### Author:  [@matt.cheely](https://discourse.elm-lang.org/u/matt.cheely)
#### Post date: [June 4, 2019, 8:29pm UTC](https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730/2 "2019-06-04T20:29:45Z")
We’ve done some proof-of-concept experiments embedding web components in Elm apps at work and haven’t seen this, but I’m wondering if we missed a use case. Do you have any examples of specific ionic components that cause issues?
---
### Author:  [@ciekawy](https://discourse.elm-lang.org/u/ciekawy)
#### Post date: [June 7, 2019, 10:01am UTC](https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730/3 "2019-06-07T10:01:25Z")
as mentioned above - `ion-header` or `ion-item` are the examples. Also here is ionic ticket for reference.
>
To solve this issue I believe some conversation would help between ionic and elm devs. Would be awesome to make it working.
---
### Author:  [@matt.cheely](https://discourse.elm-lang.org/u/matt.cheely)
#### Post date: [June 15, 2019, 3:30pm UTC](https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730/4 "2019-06-15T15:30:34Z")
Oh, sorry! I don’t know how I missed your examples in the original post. My mistake. That issue was quite enlightening though. It looks like the problematic elements are altering their external-facing DOM, which was originally written by Elm. I’d consider that a bit of a web component anti-pattern, but it’s good to see how it happens in iconic. We’re using Stencil to build web components at work, and I expect some of them to be used with Elm. Now I know to watch out for uses of `hostData` in PR’s. Thanks for the details!
---
### Author:  [@ciekawy](https://discourse.elm-lang.org/u/ciekawy)
#### Post date: [June 24, 2019, 1:23pm UTC](https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730/5 "2019-06-24T13:23:22Z")
Great there seems to be quite well defined where the problem lays. I know this is not the highest priority unless someone become interested using elm and ionic together. The issue got accepted on the ionic side (as interop feature-request). Hopefully this should be doable to provide a PR removing confusion elm faces with DOM 😉
---
### Author:  [@luke](https://discourse.elm-lang.org/u/luke)
#### Post date: [June 24, 2019, 8:19pm UTC](https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730/6 "2019-06-24T20:19:23Z")
> [@ciekawy](#):
>
> OTOH with rise of new standards and frameworks would be great to have some common way to coexist.
This is supposed to be achieved through shadow DOM. Shadow DOM isn’t perfect and there are certainly legitimate reasons not to use it right now, but it’s not clear to me why `ion-header` and `ion-item` would need to do so.
Unfortunately there’s no way Elm’s virtual DOM can detect and import DOM changes from outside the system without sacrificing its rendering speed, so I wouldn’t expect it to change to accommodate this use case. Something you might be able to try as a workaround is to declare your own custom element which renders your `ion-header` component within its own shadow DOM tree to hide its behavior from the Elm virtual DOM.
---
### Author:  [@system](https://discourse.elm-lang.org/u/system)
#### Post date: [July 4, 2019, 8:19pm UTC](https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730/7 "2019-07-04T20:19:26Z")
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.