Skip to content

Operator decorators #376

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

Merged
merged 2 commits into from
Oct 15, 2024
Merged

Conversation

chris-pardy
Copy link
Collaborator

@chris-pardy chris-pardy commented Oct 9, 2024

Operator Decorators are a new feature for the JSON rules engine. This resolves a number of issues including #374

How do they work?
A decorator, or decorators are declared in the operator name using the colon ":" character to separate it from the main operator. For instance "everyFact:lessThan" would decorate the lessThan operator with the everyFact decorator.

What Decorators are Included
By default the following decorators are included

  • someFact/someValue - uses Array.some to determine if some of the facts or some of the values match the decorated operator.
  • everyFact/everyValue - uses Array.every to determine if all of the facts or all of the values match the decorated operator.
  • not - applies a boolean not to the result of the decorated operator
  • swap - swaps the factValue and jsonValue.

swap and not are useful when you're working with custom decorators. The default operators are already symetrical eg. (in / contains) and negated eg. (in / notIn) but when creating a custom decorator this means writing 4 instances. For instance a endsWith operator can now become a not:endsWith, swap:endsWith - effectively "ending of" and not:swap:endsWith

return this.decorators.delete(decoratorName)
}

get (name) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CacheControl this method is a bit more hairy than it needs to be since it's caching the decorated operator in the operators map.
Specifically if you do something like everyFact:equal then something like not:everyFact:equal we won't create the everyFact:equal operator the second time. There may be a complexity / performance tradeoff if we want to avoid caching all the incremental steps.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

peaceful with the complexity so long as we're robust with test coverage

@chris-pardy
Copy link
Collaborator Author

@CacheControl this needs a bunch of documentation written. I can do that if we're going to add the feature.

These methods currently return void so don't mark their return type as map
@CacheControl
Copy link
Owner

@chris-pardy nice, very flexible! I'm good with this. LMK when you'd like a final review

Operator Decorators "decorate" an operator and return a new operator.
Create defaults:
- someFact -> for fact values that are arrays return if one of the values matches the decorated operator
- someValue -> same but for json values that are arrays
- everyFact
- everyValue
- not
- swap
@chris-pardy
Copy link
Collaborator Author

@chris-pardy nice, very flexible! I'm good with this. LMK when you'd like a final review

@CacheControl I added documentation, and the swap decorator (would love a better name for that) this should be good to review now.
I think I'll have some time in the next few days address all the bug-fix PRs on this repo and probably put them all together in a new PR that we can push for a new point release.

@chris-pardy chris-pardy merged commit 194ebdb into CacheControl:master Oct 15, 2024
3 checks passed
@chris-pardy chris-pardy deleted the operator-decorators branch October 15, 2024 13:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants