[chore] refactor Rule be more opinionated on how it should be used

[cannawen]

• [ ] Kind of finicky tests where if you don't pass the params in the correct order, they will trigger the rule when the state is not set up properly yet
• [ ] How to handle if statements being difficult?

---

Refactor to something like

Rule ({
label: string,
trigger: Topic[],
given: Topic[]
when: ([trigger values], [data values]) => boolean
then: ([trigger values], [data values]) => Fact[] | Fact | void,
defaultValues: Fact[]
})

Break up the rule done into when/action -> #62 Use map to construct rule and get rid of getFn in favour of having [trigger] and [given] values passed back to the when and then -> #64

[cannawen]

In passing back the trigger and given in an array, we lose any semblance of typing. Can this be fixed?

[cannawen]

I've noticed one problem with writing rules like this is if logic for state

In one rule it's very easy to write if-else or if-early-return but in little rules, you have to write the if statement in a when block and then the else statement in a separate when block (or the !if & return logic in a separate block because you can't early return). This creates some duplication and can easily lead to missed logic

[cannawen]

Maybe one solution to ^ is that Rules can hold onto other Rules that are only run when the parent rule is true. Is this getting too deep!?

[cannawen]

The lack of typing caused a bug in #129 where the data structure was a set, but we used it as an array.