Open idlehands opened 11 years ago
+1 for this old comment. I'm attempting to build a library of preset swatches for a project, but the instance being returned in the Caman() callback is always the same. Let's hope someone else out there has seen/resolved this?
@aghouseh I am of no use for this, as it was over 4 years ago and one of my first code projects, but here is our code that got around the issue. Again, I don't remember anything about it, and I am not sure if it will help. https://github.com/idlehands/filters.io/blob/master/app/assets/javascripts/filters.io.js.coffee#L71-L75
I've been working with sandbochs and we're coming across an unexpected behavior.
Looking at the code, it seems that the behavior comes from an intentional design decision.
We are writing simple photo filter site and are interested in keeping as seamless a customer experience as possible. To do so, we are keeping a clone of the DOM element that we are converting to a Caman canvas on hand. The idea is to swap it out for the current canvas instead of reverting the image if the user has decided to apply a different filter.
When we swap the element in, we're giving it the same class and id properties as the previous element that was converted to a canvas in order to make the system infinitely repeatable. The behavior that we are encountering is that once we've written a line to replace an image with a Caman canvas, we can never use the same identifier, whether it be the class or id, again.
Looking at the Caman code, it appears that the previous identifiers are being stored and if a CamanInstance has already been created using that identifier, that CamanInstance is returned instead of one created from the new DOM element with the same identifiers. This seems like it is a performance optimization, but it has led to us creating a work around to never use the same identifier twice. However, when we comment out caman.coffee line 36:
it behaves as we had expected, allowing us to re-use the same identifiers for the replacement DOM element.
We're adding this issue because we were hoping to either better understand the advantage that this store provides or to find out if commenting this line out will cause us additional issues.