bodymovin
commented
1 year ago Hi, I picked this validation because this code is part of the critical path of execution of the engine, and runs on every frame. From my benchmarks, this comparison in more efficient than invoking the toString method, which makes sense.
I'm hesitant on changing and affecting performance in general.
It's an interesting case the one you shared, but I'm curious as to why node wouldn't identify the type as an array. Is it being created in another javascript context?
DSalman
This is not a bug per se, but rather a Javascript compatibility issue when using Lottie in a NodeJs environment. It may also apply to other situations as well. I traced some strange behavior to conditionals based on object type checks failing, e.g. "if (keyData.o.x.constructor === Array) ...", referring specifically to line 3472 of version 5.10.2. I'm far from a JS expert so I had to research why this might happen. It seems that a more robust method would be do something like:
if (Object.prototype.toString.call(someVar) === '[object Array]'){ // do something based on Array type } There's some in depth explanations here: https://stackoverflow.com/questions/332422/get-the-name-of-an-objects-type#332429 https://stackoverflow.com/questions/4775722/how-can-i-check-if-an-object-is-an-array
It looks like it falls under the issue of "will not work cross-frame and cross-window". Do you think the code should be updated using this method? I found multiple places where "constructor === Class" comparisons are used, but they don't seem to be problematic for me. I recon they could be depending on the features of the particular animation. Once I changed line 3472, my issue was cleared up.