[solved] re-mount & render App + child components after DOM "destruction" by (external) .innerHTML

[WebMechanic]

Hello,

we're about to subsequently replace parts of our site with Vue components, currently on Vue 2.
One page features a complex search script written in jQuery we can't replace yet (tech dept), that uses XHR to load new page contents from the server and dumps the HTML into a #content div using .innerHTML (see outline below). One could call it an old-fashioned SPA.

For layout reasons my App and its Child Components also live inside this #content element. On first page load everything is fine, as all the Vue code and their templates comes with the page and it does its thing. But after the user clicks on some search result links to get different contents, it all gets literally destroyed with the .innerHTML call.

I used a MutationObserver to get notified if the #content change (which I do) and used the :key "trick" on my App incrementing the value to force a re-render. And Vue reacts: according to various console outputs all life-cycle events fire again for the App and the inner component. So they're not completely dead.

Although some HTML of the App part reappears (a form) -- presumably because it is part of the HTML that is replace the old one --, the custom element name of the inner component inside is visible in the DOM of the browser devtools. It's not re-rendered and it's <template> element and doc fragment are intact and of course not shown by the browser.

Here's a simplified outline of the relevant markup. I can't post a link as it's not public.

<main>
  <header></header>
  <div id="search-results">
     list of links and abstracts to click on and thereby replace 100% of #content
  </div>

<!-- fully replaced by the jQuery script -->
  <div id="content">  
    <article class="entry"></article>
    <article class="entry"></article>
    <div class="stuff"></div>

    <section id="myapp" :key="stayinAlive">
      <form> this plain form HTML reappears after the :key trigger </form>

      <my-sfc ref="MySFC" :key="revive">
         <!-- this custom element and its children is not rendered -->
         <template #panel></template>
      </my-sfc>
    </section> <!-- /#myapp -->
  </div>
<!-- /#content -->

  <footer></footer>
</main>

From the console dumps I can see that the old markup still sits in the formerly mounted and rendered $el properties of both, but they're now "disconnected" from the newly created DOM, i.e. the usual target-icon to select the element is missing (not the real dump):

So my question would be: how can I re-render or re-mount the App, its child component and that component's children (there are 3 levels of nesting) once it's been disconnected from the DOM.

From within the handler of my MutationObserver that sees all this happening, I tried running App.$mount('#myapp') again, but to no avail. The observer handler has (short time) access to all the elements that were replaced in the old #content element, and the new ones that took their place.

I'm currently working on a simplified test case to examine the behaviour and play with "lazy loading", a more controlled :key usage, and maybe place a v-if on the children.

Any hints and ideas on how to proceed are highly appreciated!!

[WebMechanic]

Ok, so the solution was annoyingly simple.

Since Vue can't/won't tell it lost its connection to the real DOM, using a MutationObserver is key to the solution.

The $el property of each component is still holding a fully functional copy of the "original" element in its rendered state incl. all the children, read: their connection to the actual document might be broken, but it's still intact within the "subtree" owned by the application's top level $el.

When the MutationObserver's handler is called, all you need to do is put the app's element back into the DOM, replacing the new but vanilla DOM element that was created due to the innerHTML result.

Here are the essential bits in the application code (or index.js) that need customizing for the element ids.

data() {
  observer: undefined
},
methods: {
  observe(mutationList, observer) {
    // on the initial page load the MO might trigger, but nothing was removed yet
    if ( !mutationList[0].removedNodes.length ) {
        return;
    }
    // disable the observer
    this.observer.disconnect();

    // put the App's $el back into the LIVE DOM where the new #app sits
    let elt = document.getElementById('content');
    elt.querySelector('#myapp').replaceWith( this.$el );

    // start observing for the next DOM attack
    this.observer.observe(elt, {childList: true, subtree: true}); // adjust options to your situation
  }
},
mounted() {
  let elt = document.getElementById('content')
  this.observer = new MutationObserver(this.observe);
  this.observer.observe(elt, {childList: true, subtree: true});
},

// if you tear down the app programmatically, make sure to also
// disconnect and release the MutationObserver from its duty.

Not only are all the event handlers intact, the state of each child component is exactly as it was when the DOM was ripped apart.

Hope this helps anyone who happens to have the same bizarre problem.