Feature Request: Add path notation.

Without a path notation it is not actually possible to edit an update spec object with an update spec since it cannot distinguish a key from an operation. Adding path notation also has the advantage that it would also provide dot notation as requested in #17.

The method to disambiguate unusual keys is to use the normal bracket notation (with escaping for at least the close bracket) optionally with quote support. With this the operation doesn’t actually need any special handling since it must always be the last element in any path.

This then gives the following:

const newData = updatePath(myData, {
  "x.y.z.$set": 7,
  "a.b.$push": [9]
});
const newCollection = updatePath(collection, { "2.a.$splice": [[1, 1, 13, 14]]});
const newPathed = updatePath(pathed, {
  "[path.with.dots][next.part].$set": true, // sets pathed["path.with.dots"]["next.part"]
  "$set.$merge.$push": [1], // pushes to pathed.$set.$merge
  "[bracket\\]prop].$set": "eugh escapes", // sets pathed["bracket]prop"]
});

As an extension if double quotes are allowed in the brackets then automatic escaping of strings can be managed through JSON.stringify(). Consider:

const newData = updatePath(myData, {
  [`[${JSON.stringify(computedName)}].$set`]: "supports primitive values",
});

[kolodny]

That seems out of scope to this library but you can use the flatulence library with this to accomplish that

const flatulence = require("flatulence")

const newData = updatePath(myData, flatulence.unflatten({
  "x.y.z.$set": 7,
  "a.b.$push": [9]
}));

[hoytech]

I should say that it’s possible that the memoisation would effectively offset the parsing overhead (from all but the first run). The problem is reconstructing a hierarchical update (as I think you’re referring to re: reduce). If efficiency is a concern, it’s simplest just to represent your update hierarchically in which case the trivial recursive implementation is optimal at using the fewest number of shallow copies.