You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently the contact-summary.templated.js config file exports an object containing the contact summary config. The current contact, reports, and lineage are provided to this code as global context, but there is no way to perform async operations to build the contact summary config object.
The CHT api (which is just cht-datasource under the hood) is also currently available to contact summary config code. However, none of the async functions can currently be used since there is no way to await the results.
This situation makes it impossible to support more advanced logic in the contact summary config (such as looking up the children of the current contact).
Describe the solution you'd like
Instead of directly exporting the contact summary config object, it would be nice to support exporting an async function that, in turn, would resolve the contact summary config object. Naturally, this functionality could be abused in any number of ways that could result in poor performance of the contact summary calculation, but this would be config-dependent and by default the performance would be no worse than how things are now.
Describe alternatives you've considered
If we do not have any support for async calls in the contact summary code, it would mean that any additional data we want to expose to the contact summary calculations would have to be pre-loaded each time a contact summary is calculated. For example, some deployments might want to have logic based on the children of the current contact. Currently, the only option for including this in the contact-summary is to update the cht-core code to always look up the children for every contact when loading the contact summary (regardless of whether that data is actually used. Taking things one step further, consider the likelihood that perhaps you only want to look up the children of certain contact types?!? For cases like these, pre-loading the data becomes very painful.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently the
contact-summary.templated.js
config file exports an object containing the contact summary config. The currentcontact
,reports
, andlineage
are provided to this code as global context, but there is no way to perform async operations to build the contact summary config object.The CHT api (which is just cht-datasource under the hood) is also currently available to contact summary config code. However, none of the async functions can currently be used since there is no way to await the results.
This situation makes it impossible to support more advanced logic in the contact summary config (such as looking up the children of the current contact).
Describe the solution you'd like
Instead of directly exporting the contact summary config object, it would be nice to support exporting an async function that, in turn, would resolve the contact summary config object. Naturally, this functionality could be abused in any number of ways that could result in poor performance of the contact summary calculation, but this would be config-dependent and by default the performance would be no worse than how things are now.
Describe alternatives you've considered
If we do not have any support for async calls in the contact summary code, it would mean that any additional data we want to expose to the contact summary calculations would have to be pre-loaded each time a contact summary is calculated. For example, some deployments might want to have logic based on the children of the current contact. Currently, the only option for including this in the contact-summary is to update the cht-core code to always look up the children for every contact when loading the contact summary (regardless of whether that data is actually used. Taking things one step further, consider the likelihood that perhaps you only want to look up the children of certain contact types?!? For cases like these, pre-loading the data becomes very painful.
The text was updated successfully, but these errors were encountered: