json path

Hi, I am writing a custom operator to compare two arrays. I have a requirement where I want to select an array of strings from an array of objects in my fact (like json path $.phoneNumbers[*].type).

{
  "firstName": "John",
  "lastName" : "doe",
  "age"      : 26,
  "address"  : {
    "streetAddress": "naist street",
    "city"         : "Nara",
    "postalCode"   : "630-0192"
  },
  "phoneNumbers": [
    {
      "type"  : "iPhone",
      "number": "0123-4567-8888"
    },
    {
      "type"  : "home",
      "number": "0123-4567-8910"
    }
  ]
}

Expected output : ['iPhone', 'home'] My understanding is that selectn does not support this and I do not want to use dynamic facts to do this, since I want to keep the rules configurable. Is there a work around we can use? One solution is to define json path in a fact as shown below and use https://www.npmjs.com/package/jsonpath to evaluate.

{
   fact: 'person',
   operator: 'containsAnyOf',
   value: ['home', 'office'],
   jsonPath: '.phoneNumbers[*].type'
}

Thanks

[CacheControl]

Hi all,

just wanted to give a heads up that I’m actively working on this feature, in case anyone wanted to provide some early feedback on my plan of attack.

After surveying the options, it’s clear that selectn syntax is fundamentally unable to express the full breadth of object traversal use cases desired by users. As such, it’s in the best long term interest of this library to move forward with json-path as the primary supported syntax of the path feature (this is, after all, a json based library).

deprecated support for selectn

I’m planning to deprecate support for selectn path syntax. If you want to continue using that format, you will have to install selectn as a direct dependency of your application, and json-rules-engine will detect its presence, path syntax, and use it to parse relevant condition paths. This will be a breaking change because of the new requirement of adding selectn as a direct dependency, but it won’t force anyone to convert all their rules before upgrading to v5. In fact, you can technically continue to use the selectn syntax for old rules, and express json-path for new ones.

By removing selectn as a dependency, we’ll save ~20% of the overall package size of json-rules-engine, and making the addition of jsonpath-plus fairly negligible (see below).

which json-path library to use?

As discussed above, there was initial concern around having jsonpath as a dependency due its large package size. For this reason, I’m planning to use jsonpath-plus instead. This library checks several important boxes:

• Only 4kb gzipped. After removing the 2.4kb of space required by selectn, this means we’ll be providing the flexibility offered by the json-path specification at the bargain price of 1.6kb
• Runs in browser
• Supports the json path syntax, plus some additional features for expressing more challenging cases (these non-specification features may be used optionally, of course)
• Zero dependencies
• Very strong performance relative to competitors

eta

Once the above research was done and the way forward was clear, this isn’t looking very difficult at all. Mainly I need to test a few cases and update the documentation, but I’ve got the proof of concept working.

[CacheControl]

@phstc Solving for the particular data structure you posted is likely do-able (the code change you suggested might work). The tricky part I think is solving this in a way that will support everyone else’s data structures as well. Although the most common case represented in this thread is an array of objects, there’s no limit to the ways a user may choose to structure their data.

I’m a bit short on time these days, but ultimately I’d like to solve this in a comprehensive way.