Closed haggholm closed 8 years ago
Refers to #64 (apparently the commit comment didn’t do the trick, sorry).
I’m not sure whether adding methods like this is really the right thing to do, but I followed to the model of merge
. Perhaps it would be better to follow a lodash
-like model of exported functions to avoid conflicts with named properties.
Generally looks good! Sorry I took so long reviewing it.
I left a couple of comments, and there's also a merge conflict to resolve.
Sorry I took even longer getting back! Added to README, changed a few random values to use JSC, not sure if that’s precisely what you meant: haven’t used JSC before (though if it’s inspired by QuickCheck, I expect to do so again).
Could this also be made to work with arrays as well? Currently it's cumbersome to update an item in an array.
It can be done with arrays; I added it to arrays. I also found some weird edge cases where the object versions didn't work properly (with nested paths); I didn't nail it down, as my main concern was making the tests pass for my added methods, but wonkiness seemed to ensue sometimes when e.g. merging a complex object with a {foo: NaN}
value. The new version is a bit more straightforward (IMO) and doesn't use merge()
, so it's not affected, but it could use more digging. I can't take more company time for it right now, though!
Thanks for this! :tada:
Add simple implementation of set and setIn by constructing a path and invoking merge, which already does all the hard stuff, checking, managing mutability, &c.