corollary
v0.0.2
Published
A framework for defining and evaluating complex logical systems. (A cool bool rule tool.)
Downloads
1
Readme
corollary
An alternative boolean framework for complex logical systems. More succinctly: a cool bool rule tool.
This is very experimental and a work-in-progress. Just use for fun.
Usage
The basic usage is to define rules using callbacks. Then, you compose rules
using the names of the rules in combination with boolean primitives, like
and
, or
, and not
. Eventually, you have a heirarchy of rules that you
can query using ask()
.
const { and, not, createRule, ask } = require('corollary');
createRule('isSkyBlue', weather => weather.skyColor === 'blue');
createRule('isSkyRed', weather => weather.skyColor === 'red');
createRule('isSunOut', weather => weather.cloudCoverage < 0.5);
createRule('isRainy', weather => weather.precipitation > 0.25);
createRule('isNice',
and(
'isSkyBlue',
'isSunOut',
not('isRainy')
)
);
const today = {
skyColor: 'blue',
cloudCoverage: 0.2,
precipitation: 0.2
};
const tomorrow = {
skyColor: 'blue',
cloudCoverage: 0.8,
precipitation: 0
};
console.log('Is today nice?', today);
if (ask('isNice', today))
console.log('Yes!');
else
console.log('No...');
console.log('\nWill tomorrow be nice?', tomorrow);
if (ask('isNice', tomorrow))
console.log('Yes!');
else
console.log('No...');
Roadmap (Future Features)
Where to go from here? The end goal of this module is to simplify and centralize the often thousands of business rules that usually accumulate as spaghetti code if unchecked. With that goal in mind, there are a few features that would be nice to have. Since this is an early project, the API will need to be refined such that the module encourages a good programming style that supports the features.
Dependency Graph Generation
It's easy to get lost in the thousands of relationships between object types
and their associations. The corollary
API should expose a dependency
graph-generator that shows the relationships between rules. An explicit rule
system would be necessary define this dependency graph.
Dependency Graph Enforcement
We can take this a step further and enforce dependency graph restrictions.
What makes dependency graph hard to completely infer would be the use of
ask()
in a callback. One approach is to have callback rules declare their
dependencies, which are evaluated and passed to the callback.
Heirarchical Naming Convention
A heirarchy based on object types and dependencies could help users better locate and understand their rules. A convention-based API that supports a heirarchical pattern would encourage this type of rule definition and potentially make a dependency graph easier to infer.
Non-Boolean Rule Types and Lots of Primitives
It makes sense for rules to calculate non-boolean return values. The more
primitives that corollary
can provide to support this, the better. Think
sum()
, isIn()
, isDeepEqual()
, set operations, etc. These can be
optimized. The primitives could just be rules, and more primitives could be
added by the user if needed. It would be helpful to corollary
for the
user to provide the arity of rules. Maybe this could be part of the
dependency API.