a) My intent with ~=/~== is very simple needle/haystack string search, allowing a program using jspath to supply a concatenated list of values as a single string, into which a single property value must match. Tested with string and numeric properties, nothing more complex.
This was the simple approach; the alternative is actually searching arrays provided by caller. My suggestion is to add ~=/~==, then later consider array search support, perhaps with an "in" operator.
b) Multiline strings are allowed using a single backtick char, in es6/node 4+. My patch simply extends jspath's definition for whitespace to include newline, return, tab -shouldn't harm anything else. Writing long jspath queries is nicer now, since concatenation isn't needed so much. Really basic example-
> var a = ["Abc","def","GHI"].join(";");
> jspath.apply(`
.{.id ~= $a}.id
`,
[{id: "abc"}, {id:"ghi"}],
{a: a});
[ 'abc', 'ghi' ]
@dfilatov,
a) My intent with ~=/~== is very simple needle/haystack string search, allowing a program using jspath to supply a concatenated list of values as a single string, into which a single property value must match. Tested with string and numeric properties, nothing more complex.
This was the simple approach; the alternative is actually searching arrays provided by caller. My suggestion is to add ~=/~==, then later consider array search support, perhaps with an "in" operator.
b) Multiline strings are allowed using a single backtick char, in es6/node 4+. My patch simply extends jspath's definition for whitespace to include newline, return, tab -shouldn't harm anything else. Writing long jspath queries is nicer now, since concatenation isn't needed so much. Really basic example-
Cheers, Kevin-Prichard