Undocumented property of the "docxImage" helper

[andribo]

Hello,

According to the documentation, the "src" property of the docxImage must be "the base64 dataURI string representation of the image to load or an url from which to fetch the image".

However, it turns out, that it can also be a promise fulfilled with the base64 data URI string. I suppose this is due to using the waitForAsyncHelper inside the docxImage.

Would it be reasonable to rely on this feature of the 'src' property, or is it better to strictly follow the documentation and provide a string value?

[bjrmatos]

hi!

I suppose this is due to using the waitForAsyncHelper inside the docxImage

yes, this is the main reason, we want that user is able to get src image from async executions, like HTTP requests. so that waitForAsyncHelper, makes this to work:

{{docxImage src=(getImageFromServer) ...}}

async function getImageFromServer () {
  const result = await makeYourRequestHere()
  // result should be a base64 string representation of the image
  return result
}

Would it be reasonable to rely on this feature of the 'src' property, or is it better to strictly follow the documentation and provide a string value?

we expect this to work correctly when the async execution happens between handlebars helpers, in the example, getImageFromServer is an async handlebars helper, so this is expected to work.

as long as you do the async work from an async handlebars helper, it will work.

what is your use case? or what code are you trying to make it work by passing a promise?

[andribo]

Thank you, @bjrmatos!

It turns out passing a promise was an unintentional mistake, though fortunately, it didn’t cause any issues. :)

In our setup, we prefetch images in the beforeRender script, convert them into base64 data URIs, and pass these images to the data. Recently, we introduced an asynchronous image resizer into this process but didn’t handle its output correctly.

Since you mentioned that using a promise with a URL as the "src" is expected behavior, I think we can keep our current implementation as is.

I do have one additional question: when adding promise-based properties to the template’s "data", are there any limitations on what can be passed? Specifically, does the data need to be JSON-serializable, or can it include any JavaScript variable?

[bjrmatos]

Since you mentioned that using a promise with a URL as the "src" is expected behavior, I think we can keep our current implementation as is

it depends from where the promise comes from, as i said if the promise comes from async handlebars helper it is fine, but if the promise is not coming from handlebars helper then it is just a coincidence that it works right now. i would let the promise behaviour only to handlebars helpers, for other execution like in scripts, just await the value.

I do have one additional question: when adding promise-based properties to the template’s "data", are there any limitations on what can be passed? Specifically, does the data need to be JSON-serializable, or can it include any JavaScript variable?

you can use any javascript value, jsreport wont complaint, unless you pass a value when another type was expected, but this depends on the libs you use, etc.