-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Data is not used by "some" #48
Comments
thaaaat sucks. That's a design flaw, all the example cases I considered only used literal and the value being tested inside the test. I'm open to suggestion on how to design a fix for this. One way would be to make the data being used inside the test actually a copy-and-extend of data. Like if data = }else if(op === 'filter'){
scopedData = jsonLogic.apply(values[0], data);
scopedLogic = values[1];
if ( ! Array.isArray(scopedData)) {
return [];
}
// Return only the elements from the array in the first argument,
// that return truthy when passed to the logic in the second argument.
return scopedData.filter(function(item){
var item_and_globals = beget(data);
item_and_globals.item = item;
return jsonLogic.truthy( jsonLogic.apply(scopedLogic, item_and_globals));
}); (Beget implementation is something like and your rule changed to: {
"and": [
{
"some": [
[
"x",
"y"
],
{
"===": [
{
"var": "item"
},
{
"var": "input"
}
]
}
]
}
]
} This is based in part on how reduce uses named parameters (For parity I'd also be open to using |
This seems reasonable to me. I don’t really have a horse in the game as to whether the API should expect Thanks for the speedy response! |
One other thought: I do like the terseness of |
Or wouldn’t you get the same effect yet be able to use return scopedData.filter(function(item){
var item_and_globals = beget(data);
item_and_globals[''] = item; |
Seems like you should be able to explicitly name the iterator. That way you could do multiple levels of nesting. Here's the operation for "non-empty intersection":
|
@mhelvens does it work for you? Or it's just a concept for improvements? |
I am running into this exact problem as well. I see that this issue is still open, has anyone been able to come up with a workaround (other than defining custom operators)? |
I expected the following to evaluate to
true
:Data:
Rule:
If I use a literal value instead of
"var": "input"
, it does evaluate totrue
:The text was updated successfully, but these errors were encountered: