Closed nolanlawson closed 8 years ago
I'd file that on Ember - modifying global prototypes (outside of a spec-compliant shim) is pure insanity, and the instant a lib does it, all bets are off.
Does Ember use node-extend?
However, if you can provide a PR that doesn't break this functionality but makes it more robust in a crazy irresponsible prototype-modifying world, I'll be happy to merge it in :-)
Yeah, that's exactly what I suspect I don't have the patience to do. :) In any case, yeah, the fault is really on Ember for modifying the prototype (tisk tisk!), although they probably had a good reason for it, since they need some way to observe objects without Object.observe.
I'm no longer checking for nodeType
or setInterval
here, so can you give this another try with v2.0.0
?
@nolanlawson ping
Hey @ljharb, this issue is super old and PouchDB has actually since implemented an aggressive object-cloning logic in order to work around subtle IndexedDB issues, so it's probably not even reproducible anymore. I dunno what the status of Ember is.
I'm happy just to close this issue! :)
Not sure how much you care about this, but there's a really tricky bug caused by this module if you try to use Ember.js and IndexedDB in the same application. In short, Ember.js does some modifications to the global String and Array prototypes, so if you try to
put()
some extended objects into IndexedDB, IndexedDB throws an error saying "an object could not be cloned."We fixed it in https://github.com/pouchdb/pouchdb/pull/2270 by rolling back to an older version of this function ripped from jQuery 1.9.0. I'm not sure what's been modified in the interim or even what precisely causes the bug. I may be able to open a PR on my end, but it seems tricky enough that I'm not really sure where to start. Thought you might like to know.