I was playing recently to create an ionic framework app using elm (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.
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?
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!
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
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.
