Details about failure

[victorlambert]

Hey there,

Thanks for this great lib.

Is there anyway to have details about condition failure.
I would like to know precisely which fact is failing in a large set.

[CacheControl]

Unfortunately that's not a feature we have right now. This is the most requested capability and currently sits at the top of the backlog. I hope to find some time to implement it sometime this quarter.

[CacheControl]

hey @victorlambert I've taken a crack at implementing this - I've just published 2.0.0-beta1. There's an example in pr #35 and some docs here and here

This a beta because I'm going to let it stew for a week or so to provide the various stakeholders an opportunity to give feedback. Please let me know if you have any input.

[victorlambert]

@CacheControl This is so great !
Thanks a lot for your reactivity, I am going to try this very soon.

[murraybauer]

hey @CacheControl I upgraded my project to version 2.0.0-beta2 - with no breaking changes.

The rule results feature works great!, including for my dynamic facts.

I keep wondering if a generic render (logging function) would be useful to include in the project for success/failure i.e. something like ${fact name} (${property path if specified}) expected value {x} was not ${operator} than {x}.

For my project I need to display rule results to the user and so will develop multiple custom renders, but from simply a debugging point view OTB it could be useful. There was previously very little info available to troubleshoot failed rule condition(s) (prior to rule results) as custom logging had to be added in other parts. Maybe not a big deal now you can easily see the rule results info, but you still need to set breakpoints and dig into it.

[victorlambert]

I can say that it works great as well, well done @CacheControl !

+1 for a generic render.

In my case, I would be very interested in having 2 other features :

• depending facts of a rules
• minimal facts required to run the rules engine
  e.g. From a ruleResult Object, compute the others facts required by the rules engine to make the rule successful.
  My approach for this feature would be to search from a ruleResult Object the different cases where there is no need to ask for a fact.
  Here are some cases that I already identified to compute this result :

1. if one children of 'all' operator condition is defined* and result is false, skip all siblings facts
2. if one children of 'any' operator condition is defined* and result is true, skip all siblings facts
3. if all children of condition are defined, skip all siblings facts
   ...
   (*by saying 'is defined', I mean that there is a factResult property)

As you may guess, I am using the rules engine to target user's profiles of my app to make the maximum rules successful. This is why I need to know the minimal facts required by a rule.
I think that this last feature is very related to my project but maybe others could be interested.

Let me know if I'm unclear.

[CacheControl]

@murraybauer @victorlambert thanks for your feedback!

Regarding the logging - I agree with you both that debugging why a rule may be failing or succeeding can be tricky. For this the engine provides DEBUG=json-rules-engine env that can be set to get output for what the engine is doing under the hood. Are you aware of this flag, and if so in what way(s) does it fail to meet your needs?

@victorlambert would you mind filing your requests as 2 separate issues (copy pasting what you have above + maybe an example use case rule for each)? I have some followup questions, and I want to keep the discussion threads somewhat organized.

[murraybauer]

@CacheControl Thanks - ironically after I wrote about debugging, I went back to check the doco :-)

I'm running the rules engine in an angular 2+ web browser and cordova mobile app so wasn't sure how to enable the debug flag on the client side. As the example was for a typical server side node.js environment I had just read over and ignored it ages ago. Originally I wasn't sure if the library would even work natively in the browser without using browserfiy (and even then some don't that use the filesystem etc). But it does work quite easily via a simple npm install as its lightweight and has minimal dependencies that all seem to work in the browser (and their child dependancies if their were any) for the functionality I use.

The deubg module the project uses seems to support web browsers via setting the debug flag in the browsers local storage localStorage.setItem('debug', 'json-rules-engine') which I tried without any luck. They do mention using browserify, maybe a requirement for the debug module. Haven't played further as I would need to customise my build chain to include browserify.

[CacheControl]

@murraybauer Nice, it's been my intention to make this library isomorphic, but I've never actually taken the time to prove it out. I'll have to update the readme.

I went ahead and did a webpack build of the package (no browserify), set localStorage.setItem('debug', 'json-rules-engine'), and opened it in chrome - works fine for me. Remember that you have to reload the page in order for the change to take effect.

[murraybauer]

thanks @CacheControl. So I went back to the test project I was using and the logs appeared! I had tried a few combinations - maybe switching between tabs and webpack auto reload something got missed.

The logging looks very useful.

I see you've already updated the readme.