Closed Nikey646 closed 4 years ago
@Nikey646 can you please provide an example or more details to reproduce this behaviour?
@Nikey646 Ok, I still don't see the component sitting in DOM since it's replaced with empty comment when VSnackbar
value
is false
, but I did check some memory snapshots and I can see that number of VueComponent
was growing with each toast call. This commit fixes that by calling $destroy()
for each instance. But empty comments are still there and I didn't find a way to remove them yet.
It seems that you found something.
As far as my own personal use case, i had a scenario where user interaction caused an Ajax Request, and i was using a toast to show both successful and error responses. When the user did a large number of those interactions, without reloading the page, the whole page would crawl to a stop quite quickly.
I went to check something in the Vue Dev Tools, and noticed multiple
These tests were done in vue.js dev mode, which may not have helped performance.
A quick google later, and it appears to completely remove a vue.js object from the dom, you need to first call .$destroy() and then .$remove() forum thread, api docs. You can also optionally do .$destroy(true)
to have it remove at the same time.
@Nikey646 docs seems to be from older versions. Vue 2.6 don't have params for .$destroy()
and there is no .$remove()
. Can you please test if you see components in Vue Dev Tools after updating to 0.6
?
Ahh poop, I didn't realize that I was viewing older versions of the docs... That's annoying.
I'll check it out when i next get a chance!
This appears to at least reduce how badly the impact is. I no longer see multiple <Root>
elements in Vue devtools either. I'll close this issue for now, thanks for the prompt fix!
Thanks for your assistance!
This library adds a new snackbar every time the $toast method is called. When this method is used extensively, it creates a lot of snackbar elements that just end up sitting in the DOM.
Maybe these should be removed, for performance reasons?