I was stunned by the reults described in this answer and supported by this two benchmarks that compare that solution (native JavaScript) with the one I proposed (Lodash).
I’ve also compared the proposed solution:
const obj = {
name: undefined,
age: 15,
school: 'Some school'
}
const hasOnly = (obj,props) => {
var objProps = Object.keys(obj)
return objProps.length == props.length && props.every(p => objProps.includes(p))
}
console.log(hasOnly(obj,['name','age'])) //return false
console.log(hasOnly(obj,['name','age','city'])) //return false
console.log(hasOnly(obj,['name','age','school'])) //return true
with one where I truly simply switch from every native function to the corresponing function in Lodash,
hasOnly = (obj,props) => {
const objProps = _.keys(obj)
return _.size(objProps) == _.size(props) && _.every(_.includes(objProps), props);
}
and the result is still disappointly in favour of the native solution.
Now, the one above might be a silly example, but still… > 90% slower? Then what am I using Lodash for? I mean, in different scenarios it can improve readability, expecially when funtions have to be partially applied and passed around, where Lodash saves you from a lot of x => x.
(classic example arrayOfarrays.map(_.map(fOnTheElements))
instead of arrayOfarrays.map(arr => arr.map(fOnTheElements))
), but if the peformance is so low, then it’s a bit hard to make the expressivity enough to choose Lodash over native code.
I’m new to JavaScript and Lodash (just not totally new to functional programming), so I don’t even know the reliability of the benchmark tool that was used in the linked answer, but I can’t believe it makes such a bad job that reverses the result.