JSON key with dash does not work about bcx-expression-evaluator HOT 15 CLOSED

This is expected behavior.

foo-baz is not a valid JS variable, neither it works in bcx expression.

In JS, dash is not one of the chars that can be used in variable name. When you parse foo-baz through any JS syntax parser, it becomes a math expression foo - baz. The ambiguity is probably why dash is not allowed in JS (and almost all other languages) variable name.

from bcx-expression-evaluator.

Sadly accepted :-(

from bcx-expression-evaluator.

To be fair: a . (dot) is also not considered a valid char in a variable name in JS. But as part of a JSON key considered by the parser. One could argue the same case for - (dash).

from bcx-expression-evaluator.

foo.bar is not one variable, it's parsed the same way as JS, to access property bar on variable foo.

from bcx-expression-evaluator.

To the expression being evaluated, the context object is something like global name space. Comparing to JS, it's like window object in browser. That's why you can access foo as a variable.

from bcx-expression-evaluator.

BTW, if getting a path from an json is the only thing you want. It's cheaper to just use lodash.
bcx-expression-evaluator might be an overkill for that use case.

_.get(json, 'foo.bar');
_.get(json, 'foo-baz');
// it can go through array too
_.get(json, 'array[0].field.deeperField');

from bcx-expression-evaluator.

Yes, I know. But the use case is different. We operate on a given valid JSON in the context and want to do:

const context = {"foo": {"bar-baz": 23, "bar-bay": 42 } };

expect( evaluate('foo.bar-baz', context ) ).toBe(23);
expect( evaluate('foo.bar-bay == 42', context ) ).toBe( true );
expect( evaluate('foo.bar-baz > foo.bar-bay', context ) ).toBe( false );
expect( evaluate('foo.bar-bay - foo.bar-baz', context ) ).toBe(19);

from bcx-expression-evaluator.

If you want, you can modify this method to accept dash as part of identifier.

from bcx-expression-evaluator.

After you modify it, it means you can only use minus operator with space around it.

from bcx-expression-evaluator.

Thanks!

Using whitespace around identifier is our convention anyhow.

How about making this a configuration option?

from bcx-expression-evaluator.

Sorry, I am not going to support it since it differs from JS.

You need to fork.

from bcx-expression-evaluator.

That is of course your decision and I thank for your support and effort with providing this to the community - which I highly respect.

But also with respect I disagree. A dash is a valid character in a JSON object key. So allowing to use this as such wouldn't violate the standard.

from bcx-expression-evaluator.

You did not get the point, this “expression” is trying to mimic JavaScript language expression, not an another JSON path lib like XPATH for xml.

We support a subnet of JavaScript expression, not inventing anything else. foo.foo-baz is not a valid JavaScript expression.

from bcx-expression-evaluator.

A dash is a valid character in a JSON object key.

You have to calm down and understand you cannot make an argument on chars in json key. As json key is arbitrary string, including white space, dot, +, *, /, (, ...

The whole reason you want to support dash is not because json supports it. It is only for your use case.

from bcx-expression-evaluator.

I am sorry, when I let the impression I wasn't "calm". I am.

You are absolutely right in regards of arbitrary strings in in JSON keys, as well as it is our special use case that drives the request.

I still believe it would be a great and reasonable opportunity to have the ability to include "non-variable-chars" to the identifier as an option to the evaluate method. But of course I accept your decision on this.

from bcx-expression-evaluator.