Found a bug when pickr is destroyed before initialization is complete

[mardikarifqi]

I'm now using this library to create a CAD app using Electron. I really appreciate this library due to its easiness to be config'ed. But since my app uses more requestAnimationFrame, FPS kind of become important here.

I found that the constructor is coded using requestAnimationFrame, maybe this is due to get the Pickr offsetWidth. But, if somehow the element was not rendered by the javascript EventLoop and Picker element is destroyAndRemove() for some reason, the constructor will get stuck in an infinite loop of a requestAnimationFrame.

Here is how to reproduce. Open devtools console, then type:

var el = document.createElement('div')
document.body.append(el)
var a = Pickr.create({useAsButton:true, el});
a.destroyAndRemove();

and record the performance profile from chrome dev-tools. You will see a lot of useless 100us requestAnimationFrame call tree.

My solution, give the flag _destroyed and set it to true when destroy() called.

[simonwep]

This is somewhat related to #229 - I'll take a look at it in the next days! Thanks for your submission :)

[simonwep]

Confirmed, but keeping the frame-id is cleaner - see f820ed9111a5747045296e4d51314e8957ac9fbb.