object-path
object-path copied to clipboard
Sparse arrays are being created when using objectPath.set
Need to report it, I was using version 0.7.0 on my angular app (it's really complex, and use objectPath extensively), and it uses JSON responses as well. sometimes, JSON string numbers get translated to number literals coming from PHP. this makes objectPath.set/get (on version 0.8.0) a nightmare. Now I'm randomly getting sparse arrays on my app, so I'm having to explicitly use objectPath.set(obj, [somewhere, someId.toString()]); everywhere =/ and now it sometimes throw, because someId might not be defined.
another example objectPath.set(sections.display.joined,[where, id].join("."), item); is creating the following item:
activities [undefined, undefined, undefined, 2 more...]
Because sometimes I have the where being a full path like "some.path", so I need to join them, so it becomes "some.path.10", but the behavior changed drastically, I have near 700 calls to objectPath throrough my app, and around 500k lines, so I'll have to stick to 0.7.0 for now. I'd have to make a objectPath.ensureExist to each intermediary object and make it an object before calling set on it, but this defeats the purpose of the module
Hi Paulo, I totally get your frustration. What we can do is adding a configuration option that enables/disables the interpretation of numbers as array indexes (at least for the creation of the intermediate objects). Do you think that would work for you?
oh I missed this one.
yeah, a configurable option would be nice. would it be global? like:
objectPath.options.numberAsArray = false | true;
or implement a constructor to objectPath, and use the instance when you need different options:
var ObjectPath = require('object-path').Constructor;
var objectPath = new ObjectPath({numberAsArray: true});
this way, the objectPath global would be a global instance of the constructor with default configurations, and would make it future proof if it ever needs additional configurations.