Split addRule into addSimpleRule and addReactiveRule

[stephenh]

Today we have a single config.addRule method that configures both "simple" and "reactive" rules. I.e.

// simple rule, fired any time author is changed
config.addRule(a => a.firstName)

// reactive rule, only fires if time author.firstName changes or books.title change
config.addRule({ firstName: {}, books: "title" }, a => ...);

It seems confusing to have a single method setup rules that are very different in runtime behavior, so we're considering removing addRule and replacing it with two methods:

• addSimpleRule
• addReactiveRule

Pros/cons:

• Pro: More clear which semantics you're getting
• Pro: Matches the new "reactive" terminology for "reactive rules" & "reactive fields"
• Con: addReactiveRule is a longer name, simplicity of addRule is nice :-/
• Con: Unclear when simple rules should be used over reactive rules? (See alternative)

---

Alternative 1

What if we kept addRule, but made all rules be reactive rules, i.e. all callers must pass a reactive hint? Basically remove simple/non-reactive rules.

• Pro: Simpler mental mode, just one type of rule (reactive)
• Pro: Seems like all rules should be reactive anyway?
• Con: Harder to do authorConfig.addRule(newRequiredRule("firstName")), would probably change to addRequiredRule(authorConfig, "firstName").