Is there a way to programatically stop using the editor, so it removes the bindings, and frees memory without creating leaks?
Something like:
editor = new Quill('#text')
editor.remove()
I tried with delete editor but lots of errors start appearing on the console whenever I try to do anything with it.
There isn't a specific api call for this yet.
Is it really necessary to track all editor instances inside Quill.editors array? It's only used for incrementing ids and causes a memory leak for every editor, even after all DOM nodes are removed.
It's not required but I've found the editors array useful for debugging. When we add a proper editor destroy function it will definitely remove itself from this array.
Any idea how to destroy or reinit an editor instance?
@chrismadrigal it's not currently implemented, but once it is, it wouldn't make sense to add a reinit method, you'd need to just init a new one.
What would a destroy method do? Would it completely remove the UI and content leaving only the original element in place?
Yeah @jbrooksuk that sounds nice. I guess a good behaviour would be to leave the things how they were before Quill was applied. I think is up to the user to decide what they want to do with it.
It could also make sense to update the original element with the content of the editor, but I am not completely sure of that.
But in any case, what in my opinion would be most critical is to free all memory (so it doesn't leak) in a way that would let me create and destroy Quill's all over the place :)
Are there any plans on this enhancement? I have an issue that my project requires me to shift blocks of html around, the actual dom manipulation is done with React.js. But when the block containing the quill instance is moved, the iframe loses its contents. I am fairly sure it is the same iframe instance as the quill.editor.renderer.iframe points to the exact same object. However, the document's head and body become empty tags.
I was able to get content to display by dropping this iframe and create a new Quill instance on the same container element. But after multiple operations like this, memory use sums up as those dropped quill instances are not getting gc'ed.
Either I have to find a way to keep the content of the document when the iframe gets detached and moved somewhere else, or the quill instances needs to be able to get property destroyed.
edit:
Or perhaps being able to use contenteditable div instead of iframes could also solve this issue. I am not exactly sure why the document contents get wiped out though.
We definitely want to fix this but haven't had the time yet. I did try to scope it out a few weeks ago to see if there was a quick fix but wasn't able to find all the leaks. I'll take another look in the next couple of weeks but am currently focused on deltas.
Leaving out the cleanup for modules I think the only two things that need to be done to clean up the editor instance are:
clearInterval(quill.editor.timer)Obviously you would need to empty the DOM element to remove all the things Quill created and attached events to.
For the modules, that is a case by case basis, for example the toolbar module should remove the event listeners attached to the toolbar element, which is outside the editor itself. That could be handled by making quill call each module's destroy function (if it exists) when the destroy function is called in the editor instance.
Hey @jhchen I'd be able to issue a PR for this, starting with what I sent above. In a quick peek do you think that's reasonable? Is there anything big you think it's missing?
The concern I have is I'm not sure the two clean up task listed will be sufficient to clean up all memory used. I'm not sure where the gaps are but I imagine hunting them down would be the majority of the work for this issue. I'm happy to take a look at a PR but one of the things I will do is look at the memory profile in the Chrome inspector and make sure memory usage before initialization and after destruction is the same.
Yeah I did this in my own wrapper around Quill for a project I am working on, created several thousands of it and it seems to have been cleaned up. Anyway will try this and check it again. Also I will take a look at the modules, but perhaps it could be a separate PR for those, and I'll include here a way to optionally have a destroy method to be called on them.
Okay I might be mistaken then. If you submit a PR I can take another look at the memory profile.
+1
awesome! you guys are the best! thanks!
Most helpful comment
+1