Menu
If I load my app and take a Chrome memory heap snapshot straight away, I get the following results.
If I click around my web app and then return to the original page loaded, and take another memory heap snapshot I get the following results.
From this, we can see there are now ~10x the number of VueComponents and an increase in the number of Vue instances.
This is having a big impact on memory usage of the app.
What tools/methods are available to track down the culprit components that are not being destroyed?
970
v-if is “real” conditional rendering because it ensures that event listeners and child components inside the conditional block are properly destroyed and re-created during toggles.
Vue Single-File Components (a.k.a. *.vue files, abbreviated as SFC) is a special file format that allows us to encapsulate the template, logic, and styling of a Vue component in a single file.
The best way to force Vue to re-render a component is to set a :key on the component. When you need the component to be re-rendered, you just change the value of the key and Vue will re-render the component.
Vue gives you a bunch of good ways to hide the element on the screen. When using v-if="false" the element isn't rendered at all in the DOM. When using v-show="false" the element is rendered in the DOM, however, Vue applies the inline style display: none that hides the element completely.
As the question suggested, I was pretty sure these memory issues were caused by orphaned Vue components that were not being cleaned. It is possible to look through the source for circular references etc... and fix manually.
I was looking for a way to find the specific Vue components so I could narrow my search in the code.
The best method I have found does require some manual effort but works pretty well.
From the Chrome dev tools Heap snapshot we can search for detached
N.B. You must compile Vue for dev, not production, or this will not work
This will show a list of elements that have been detached from the DOM.
We can now click on one of these items to highlight it.
Then we can head over to the Chrome dev tools console and type $0 to get the element.
From this I can see that the email input from my login page is the culprit and so I should investigate why this is not being destroyed.
While this does provide a good way to track down components that are not being destroyed, please note that not all detached nodes are bad, apply the context of your app to decide whether it is a memory leak or not.
127
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
