develwoutacause’s avatardevelwoutacause’s Twitter Archive—№ 1,695

                    1. Can #WebComponents Twitter help me out with this one? I found some baffling upgrade behavior. It seems that creating a custom element in a different document *deletes* existing non-defined properties on the element during upgrade. stackblitz.com/edit/typescript-gd8pn1?file=index.html,index.ts @develwoutacause/1569222741462777856
                      Permalink On twitter.com Twitter logo develwoutacause’s avatar ❤️ 1 Favorite Mood +2 🙂
                  1. …in reply to @develwoutacause
                    This behavior is consistent for Chrome and Firefox so it's *probably* WAI, but I don't see anything in the custom elements upgrade spec which implies this and have no idea how to effectively work around it (aside from defining every property). html.spec.whatwg.org/multipage/custom-elements.html#upgrades
                    Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +1 🙂
                1. …in reply to @develwoutacause
                  customElements.upgrade(el) prior to assigning the property *feels* like it should work, but doesn't actually do anything from elements from other documents. Otherwise I need to attach the component to the DOM *and then* assign the prop, which I shouldn't have to do?
                  Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +2 🙂
              1. …in reply to @develwoutacause
                I discovered this note that customElements.upgrade() requires the element to be adopted first. Adding this actually fixes the Stackblitz example, but not my real use case. Clearly something else is going on here and I need to keep digging... github.com/WICG/webcomponents/issues/946#issuecomment-999322180
                Permalink On twitter.com Twitter logo develwoutacause’s avatar ❤️ 2 Favorites Mood +1 🙂
            1. …in reply to @develwoutacause
              Also I don't think this would work for my real use case anyways: document.adoptNode(el); customElements.upgrade(el); el.prop = 'test'; The CE definition is lazily loaded after insertion, so the upgrade call is a no-op the first time its invoked.
              Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood 0
          1. …in reply to @develwoutacause
            The plot thickens, apparently if you assign properties *and then* upgrade the custom element, they are deleted during upgrade. But if you upgrade the element *and then* assign the properties, they remain. stackblitz.com/edit/typescript-gd8pn1?file=index.html,index.ts
            Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood 0
        1. …in reply to @develwoutacause
          This took me a while to figure out because normally an element is upgraded immediately in document.createElement(), but if an element is created in a *different* document, it doesn't get upgraded until it is appended to the main document, so properties were deleted on append.
          Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood 0
      1. …in reply to @develwoutacause
        Yep, pretty sure this ordering is the issue, among other mistakes. Apparently, you need to document.adoptNode(el); customElements.upgrade(el); *after* cloning from a template, because it uses a DocumentFragment which is considered a different document!
        Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood -1 🙁
    1. …in reply to @develwoutacause
      I still don't understand why? Why is it that upgrading an element deletes its non-defined properties? This normally isn't an issue because an element is upgraded on creation (document.createElement()). But when creating in another document, this is delayed until insertion.
      Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood -1 🙁
  1. …in reply to @develwoutacause
    Corrected minimal reproduction. If anyone can explain the reasoning behind these two failures, I will be forever in your debt. stackblitz.com/edit/typescript-gd8pn1?file=index.html,index.ts
    On twitter.com Twitter logo develwoutacause’s avatar Mood -4 🙁
    1. …in reply to @develwoutacause
      Also the obvious solution of "upgrade the element before assigning properties" actually doesn't work in a generalized case because you typically can't assume that the custom element definition has already loaded.
      Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +1 🙂
      1. …in reply to @develwoutacause
        In my particular use case, I want to be able to insert and set properties on a custom element and let it upgrade asynchronously when it's definition loads. And that definition is a <script /> tag inside the element itself, so I can't use customElements.whenDefined().
        Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +1 🙂
        1. …in reply to @develwoutacause
          Got a workaround for this by extracting <script /> tags and manually appending them to the DOM. Look forward to a blog post explaining all this nonsense and all the hacks to used to work around it. Still don't know *why* the properties get deleted though...
          Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood -2 🙁
          1. …in reply to @develwoutacause
            I did a more thorough investigation into this behavior and wrote a post going into detail on it. Turns out there are at least *three* independent behaviors coming together in this unexpected way. @develwoutacause/1573688712059359232?s=20&t=SsRXtK8wPpdDjvawy1RrNQ
            Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood 0