northwesternmutual/regent

'right' should allow arrays

Closed this issue ยท 6 comments

It would be nice if I could do something like this:

const rule = { left: '@value', fn: 'equals', right: [1,2] }

If value equals 1 or 2 rule would evaluate to true else false.

Having to combine rules to achieve the same thing is extremely verbose. It would be nice to simply into one rule that is still just as readable as the combination.

Regent 1.0 actually used to work like this. We would now implement that logic like this in Regent 2.0.

const rule1 = { left: '@value', fn: 'equals', right: 1 }
const rule2 = { left: '@value', fn: 'equals', right: 2 }
const composedRule = regent.or(rule1, rule2)

Basically, we're trying to keep each pieces as small as physically possible.

If that becomes burdensome you could pretty quickly write a custom predicate that did what you needed, and name it orEqual or something.

Actually, thinking about it more, if this is something people want I would write a predicate that did it, but we have been trying to keep the interface light so far. Maybe we could add a directory of canned custom predicates that could be optionally included. So you could do something like this.

import regent from 'regent'
import { orEquals } from '../node_modules/regent/predicates' // maybe this is it's own npm module
const king = regent.crown({ orEquals })

const rule = { left: '@value', fn: 'orEquals', right: [1,2] }

Thoughts?

You can do it thusly:

const rule = { left: [1, 2], fn: 'includes', right: '@value' }

@eisenivan: I am not sure I like hiding predicates in some mysterious folder that you need to know about to use. I think it should be a decision on the direction the library is going. If it is something the team decides is not in the direction the library would like to go then it probably should not be part of the library and more a custom predicate.

@aLittleTooQuiet is that an intended use of a rule definition or more of a hack? It seems to make sense to me but want to make sure that is an intended use rather than a workaround.

@ajzozakiewicz yep, that's the intended functionality of the includes predicate. No hackery.

Awesome. I'll close the issue in favor of that solution. Thanks!