Accessing variables in Object with key containing a dot

[tatarysh]

I encountered an issue related to accessing variables within an object where the key contains a dot. The logical query looks like this:

{
    "var": "hello.world"
}

And the payload is:

{
    "hello": {
        "world": "i'm here!"
    },
    "hello.world": "ups!"
}

Currently, there is no access to the hello.world variable. I believe it would be beneficial to adopt the convention used in the dot-prop package, where access to such a key is possible by including a double backslash before the dot in the key. Therefore, for the mentioned query, it should look like this:

{
    "var": "hello\\.world"
}

[TotalTechGeek]

Hey @tatarysh, I believe I've seen this issue pop up before in the original json-logic-js repo:
jwadhams/json-logic-js#127

And semi-related:
jwadhams/json-logic-js#110

The suggestion to use the dot-prop convention is a solid recommendation.

I may take a peek into issue 110 from json-logic-js with a bit more intent after merging this in.

[TotalTechGeek]

Hi, I've published 1.3.0 to introduce the escape syntax for paths.

Please let me know if you run into any issues / have any recommendations! (I will need to update the documentation to include this information)

[tatarysh]

great job, thanks 🙏

[TotalTechGeek]

Hey @tatarysh,

I'm working with some other project maintainers to try to consolidate JSON Logic behaviors across different implementations.

How significantly would it impact y'all if we changed how escaping works in var, and made it more akin to RFC6901 (JSON Pointer) with a slight modification (making . and / equivalent, and ~2 become .)

This change would let y'all use JSON Pointer to access your variables, while maintaining backwards compatibility with most logic.

It would change how you escape dots though, so instead of hello\\.world it'd be hello~2world

Sample test suite here:

• https://github.com/TotalTechGeek/json-logic-engine/blob/75365ec135f48917b947341f2a43edf4d4e7662d/suites/vars.json

We're also maybe considering offering another operator that wouldn't have any path parsing:

• https://github.com/TotalTechGeek/json-logic-engine/blob/75365ec135f48917b947341f2a43edf4d4e7662d/suites/val.json

Which would make it easier to access awkward keys.

If we changed this, would you be able to make the necessary adjustments?

[TotalTechGeek]

@tatarysh False alarm; preferences have swung back the other way for the dotprop notation.

Instead, the iterator syntax ../ is on the cutting board 😂

Instead of ../../ we might end up changing that with @2 or something (to communicate "Go up two scopes").

[TotalTechGeek]

@tatarysh Double false alarm.

So here's the deal:

• https://github.com/orgs/json-logic/discussions/16

I did not want to break backwards compatibility with JSON Logic.

I feel it's pretty important that we avoid breaking user's logic. I was okay with potentially interrupting non-standard extensions, like my handlebars syntax, but I felt it was important to not invalidate every implementation of JSON Logic across the ecosystem.

After some discussion, we decided that it might be best to move certain operators into a Legacy "Extension" for JSON Logic Core. The legacy extension will be in our recommended baseline, the operators won't "break", and will be present in our compat tables, but for the purposes of developing a stronger core, we planned to define replacements.

The follow up to this proposal was this guy:

• https://github.com/orgs/json-logic/discussions/18

Folks can keep their implementations of var, and the extension spec for var will remain simple. var, missing and missing_some become "legacy" operators.

And we encourage folks to start using val going forward, and provide a migration path for folks to val.

While the scope syntax has not quite yet been voted on, I believe it will look like the following:

{ "val": [[2], "name"] }

Which ascends 2 scopes, and gets name

tl;dr

No breaking releases will occur for this library.

var will continue to be supported, with the same setup it had before, however, the handlebars syntax / dot-prop will not be portable across implementations.

val is getting the portable improvements.

[tatarysh]

thanks for the info, I'll keep that in mind when updating the package to the latest version, we're currently on 1.3.9 - so we're a bit behind.