Closed gemhtcr closed 5 months ago
Having async methods would mean that the entire render code path would have to become async. I don't think that's particularly appropriate for how the engine works. What I would do is just to call runtime.block_on
in the method call. There are various patterns that could be done around it to make this better/more efficient if needed.
https://docs.rs/minijinja/latest/minijinja/value/trait.Object.html
Is it okay to add a
async
version forcall/call_method
inObject
trait ?I understood that it might be difficult to add it because of the lifetime issue, but there are some cases where we have to query from database inside call/call_method to proceed
Proposal
By supporting
async
above, it'd be more extensive and natural for minijinja to interact with databasePossible workaround
A possible workaround is to use undeclared_variables to query before calling
render
but that required extra complexity to parse those variables