Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boolean values are handled as property names #46

Closed
bartbutenaers opened this issue Aug 24, 2021 · 5 comments
Closed

Boolean values are handled as property names #46

bartbutenaers opened this issue Aug 24, 2021 · 5 comments
Labels
question Further information is requested

Comments

@bartbutenaers
Copy link

Dear,

I wanted to test whether an object property is true.
Don't see booleans values mentioned on the readme page, but found an Add booleans pull request.
So I assume this is supported...

However I get the impression that it only works for a boolean as string ("true" or "false")...

Because when I use this expression:

msg.payload.open == true

Then it tries to get a property with the name "true" from my object:

image

I was wondering if you could do something like this in your code: when the property name is "true" or "false", then it is no property but a boolean. So you simply leave it untouched in the expression, without wrapping it with prop(...)?

P.S. I don't think that "true" or "false" are allowed as property names in JavaScript, when looking at this Stackoverflow discussion. When you click on the Mozilla link in that this discussion you find this:

Additionally, the literals null, true, and false cannot be used as identifiers in ECMAScript.

A JavaScript identifier is a sequence of characters in the code, that identifies a variable, function, or property...

Thanks!!!
Bart

@cshaa
Copy link
Owner

cshaa commented Sep 17, 2021

Hey Bart!

The true and false keywords aren't present in filtrex. That's because for the most part they aren't needed – since the primary use of filtrex expressions is to select which things to filter out, the expression

messageOpen == true

would have the same meaning as simply

messageOpen

For this reason, I currently don't consider including true and false – at least not by default. However, I'm aware that there are many different uses for filtrex, apart from user-facing filter expressions, and the developer should have the option to add true and false if they want to.

I'm currently working on adding constants to the language (see issue #38), I assume they will be ready to test during this weekend. I think this feature will solve your issue:

const options = {
  constants: { true: true, false: false }
}
const fn = compileExpression(`messageOpen == true`, options)

fn({ messageOpen: true }) // → true
fn({ messageOpen: false }) // → false
fn({ messageOpen: 1 }) // → false

What do you think about this solution? Does it fix your problem?


PS: true and false are invalid identifiers in JavaScript, but they are perfectly fine property names. In fact, any property name is perfectly fine as long as it's properly enquoted, see for example the JSON documentation.

@bartbutenaers
Copy link
Author

Hi Michal,
I think that would indeed sufficient to solve my issue.
Will the v3 version be published on npm in the near future?

Thanks and congratulations with your final exam results!

@cshaa cshaa added the question Further information is requested label Sep 23, 2021
@cshaa
Copy link
Owner

cshaa commented Sep 23, 2021

Published on NPM as 3.0.0-rc10, be sure to check it out :)

I expect that a stable v3 release will come soon (after I update the README and write a complete changelog).

@bartbutenaers
Copy link
Author

Hello Michal,
Sorry for the delay. This feature works fine for me (tested with 3.0.0-rc11) !
Nice piece of software ...
I consider this issue as implemented, so you can close it.
Thanks!!
Bart

@cshaa
Copy link
Owner

cshaa commented Oct 1, 2021

Good to hear! 👍

@cshaa cshaa closed this as completed Oct 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants