The CHT Core Framework makes it faster to build responsive, offline-first digital health apps that equip health workers to provide better care in their communities. It is a central resource of the Community Health Toolkit.
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.
Is your feature request related to a problem? Please describe. Currently the
contact-summary.templated.jsconfig file exports an object containing the contact summary config. The currentcontact,reports, andlineageare 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.