You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm loving jsonata and working with it, but it has a few limitations that I'm running into. These issues would be resolved if jsonata supported the optional chaining and/or nullish coalescing operators.
For example, I have a tree of similar objects (lets say books) which have a sub-tree of author objects (this is not the real use case I am working with; the data I am using is frequently updated and the structure has been chosen to allow easy mutation)
{bookA: {// ...key: "bookA",authors: {authorA: {// ...key: "authorA",address: "777 Made Up Ln."}}},// ...}
For my purposes I am trying to construct a query that will compile all of the authors from every book into a single object.
**.authors.*{key: address}
This works great unless the book dictionary is empty. In that case, jsonata complains that key is undefined when it should be a string, because there are no author objects. As such, to handle the case where the dictionary is empty, I have to use a ternary operator:
**.authors ? **.authors.*{key: address} : {}
Fine. It certainly works. It feels clunky, however, and would be much improved if we had support for the optional chaining operator in particular.
**.authors?.*{key: address}
I would love for this to be viable, but I understand it may be a challenge to differentiate between this and the ternary operator.
I don't have a good use-case for nullish coalescing, but it seems appropriate to mention alongside optional chaining. Given just nullish coalescing, the above becomes something like:
(**.authors ?? {}).*{key: address}
The text was updated successfully, but these errors were encountered:
I am working on a PR to add some default operators. It seems this request is primarily for the optional chaining operator, which I have never found a need for because JSONata does that behavior intrinsically. At least it has since I've used it (v1.8.2).
I used the exerciser to replicate that error when the book dictionary is empty, and indeed it fails but only in versions prior to 1.8.6. Actually the thing that changed is that as of 1.8.6, the grouping operator will not fail if the grouping key is empty. I have to conclude that by upgrading to a current version your preferred expression will work.
I'm loving
jsonata
and working with it, but it has a few limitations that I'm running into. These issues would be resolved ifjsonata
supported the optional chaining and/or nullish coalescing operators.For example, I have a tree of similar objects (lets say books) which have a sub-tree of author objects (this is not the real use case I am working with; the data I am using is frequently updated and the structure has been chosen to allow easy mutation)
For my purposes I am trying to construct a query that will compile all of the authors from every book into a single object.
This works great unless the book dictionary is empty. In that case,
jsonata
complains thatkey
is undefined when it should be a string, because there are no author objects. As such, to handle the case where the dictionary is empty, I have to use a ternary operator:Fine. It certainly works. It feels clunky, however, and would be much improved if we had support for the optional chaining operator in particular.
I would love for this to be viable, but I understand it may be a challenge to differentiate between this and the ternary operator.
I don't have a good use-case for nullish coalescing, but it seems appropriate to mention alongside optional chaining. Given just nullish coalescing, the above becomes something like:
The text was updated successfully, but these errors were encountered: