Thanks Zach. For what its worth here’s my thoughts:
1) If I’m understanding correctly, I think the “basic” approach wouldn’t add much value. You’d get one crack at giving an “answer” and then its true or false from there on out.
2) Having the snippet return metadata in some way would work. It could return an object { answer: true, [ { model: m, row: r, fields: [‘myfield__c’, ‘yourfield__c’]]} that could be registered for event subscription and force a re-evaluation of the snippet.
3) The snippet could be on its own for subscribing to events and then there could be a callback to skuid that tells skuid - hey, I changed, re-render anyone that cares about me. It would be a kin to the way skuid currently detects when conditional rendering needs to be re-evaluated, just a new source of where those notifications come from.
4) Page Composer properties - This one seems the cleanest to me and likely would work best. In the composer, have a properties tab with a set of options similar to the current conditional rendering options. However, instead of using that set of data for conditional rendering itself, it would be a multi-pick that page developer could add and then skuid would treat those just like it does if it was a normal condtiional rendering rule, sinking events, evaluating and firing as necessary.
Thanks!
