Would like to see the following enhancements to conditional rendering:
1) Ability to write a conditional rendering rule based on the “mode” of the component (e.g. edit, read, readonly)
2) Ability to write a conditional rendering rule based on the “editability” of the field (e.g. field.editable)
This would go a long way towards being able to make components that support view/edit/new simultaneously.
In the past, there was discussion of adding a “call snippet” feature to conditional rendering. This would allow a conditional rendering rule to be written in anyway that one could imagine. The snippet would return true/false and could even not allow promises (to avoid long waiting async calls). Having this added would be my personal nirvana 
Thanks!
Component Mode and Field Editability would very much make sense.
The Call Snippet feature has been prototyped but the holdup right now is determining what triggers the re-evaluation of the Snippet. We could easily have the “basic” use case work, where the Snippet is only evaluated when the component is rendered, but we’d like to make it possible for the Snippet to be re-evaluated when appropriate, which is not at all obvious for a generic snippet. We’ve considered off-loading this to the Snippet, requiring the snippet to return a more complex metadata object defining when it should be re-evaluated, or allowing for some configuration in the Page Composer of certain Model / Component events that would initiate a re-evaluation of the Snippet.
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, e { 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!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.