It seems to be a problem with nested function calls as well.

I have two helpers:

• i18nLookup which takes a lookup section, a lookup key, and a field to get the translated value from
• enclose which takes a value, a prefix and a suffix. If the value is blank, no prefix and suffix will be applied

I want to lookup a language title by searching for a language code.

Input: 'sv'
Output: '(Swedish)'

If the language title is not found I will get an empty string, i.e. not '()'

{{enclose (i18nLookup 'languages' languageCode 'title') '(' ')'}}

This does not work with async functions. Instead of the language title, I get '{#AsyncHelperResult ABCDEF}`.

I need to call i18Next to translate a parameter for my pdfCreatePagesGroup. As per suggestion from Jan I'm now instantiating i18next in a promise. It works superbly everywhere but not in pdfPagesGroup.

pdfPagesGroup does not cope with async functions. In this case I could work around it by creating a special synchronous version of t(), since I know that i18Next has already been instantiated.

Please make pdfPagesGroup handle async functions as well. It's a great concept to be able to use async helper functions.

// title will be empty
// title2 will get the correct translation
{{{pdfCreatePagesGroup title=(t 'encasementList.title') title2=(tSync 'encasementList.title')}}}

const i18next = require('i18next').createInstance()

const initI18next = (i18nMeta) => i18next.init({
  //initialisation params..
})   

function tSync(key) {
  return i18next.t(key);
}

async function t(key, options) {
  await initI18next(options.data.root.i18n);
  return i18next.t(key, options.hash);
}

Hi again.
Most of my reports share a global CSS, but sometimes I don't use it. In those cases I have to remember to add the page-item and page-group classes, which I will most certainly miss sometime in the future.

Would it be possible for you to prepend every report with those classes by default in the next jsreport release?

Great bug catch! I can imagine some hair-scratching went into this hunt.

I don't quite follow why i and f would be skipped. But I'll happily change font and call it a day.
I think I'm ready to put 2.10 into production now.

Oh, and there seems to be a bug in the forum as well. The above code came out of this original text in the post:

The index variable (prepended with @} is exchanged for a zero by the forum.

I think I have found the problem now. My solution is to do this in a better way, but the problem might point to a bug in jsreport.

I have a child report which needs some data. I used to send this data via childTemplateSerializeData, which has served me well for all my reports. The problematic report did call this subreport many more times than any other report. In this particular example the child was called 66 times and the call was done with two separate childTemplateSerializeData like this:

{#child child_blueprint_with_controlpoint @template.recipe=html @data.drawing$={{{childTemplateSerializeData ../this}}} @data.controlpoint$={{{childTemplateSerializeData ./this}}} @data.zoomSize={{getBlueprintZoomSize ../this}} }

I have now refactored the child report so it can be called like this:

{#child child_blueprint_with_controlpoint2 @template.recipe=html @data.drawingIndex={{@root.drawingIndex}} @data.controlpointIndex={{5}} @data.zoomSize={{getBlueprintZoomSize ../this}} }

I haven't encountered the bug since this refactoring. My new way of calling the child report is of course much better, but I do wonder why I got into trouble with childTemplateSerializeData.

• Could there be a problem when two separate parameters are using childTemplateSerializeData?
• Or does childTemplateSerialize data leak in some way that prohibits two consecutive renders?

Jan, if you want to investigate this I could guide you to recreate the problem in the template export you already got earlier today. As for me, I'll keep a healthy distance to childTemplateSerializeData =)

Answering this myself: It works like a charm!
Thank you Jan, for an elegant way to initialise i18n directly in the helpers instead of tampering with req.data from beforeRender.

That seems like a great solution. It always felt a bit awkward to put functions in the data object.

Q: How would I pass information to initPromise? I have resources, lng etc in req.data, as seen in my code above. When inside of a helper function I can use the extra last argument to get to my data object (options.data.root..)

Would this solution be ok?

const initPromise = (meta) => i18next.init({
        lng: meta.languageCode,
        resources: meta.resources
    })   

async function myHelper(options) {
    await initPromise(options.data.root.i18nMeta)
    return i18next.t('key')
}

Maybe a stupid question, but here goes: Will {{myHelper}} in the template actually make an await myHelper() call? I suppose it wouldn't make sense to make the function async if it wasn't awaited for, but I want to understand.

Also, I assume calling an already resolved promise for every translation won't take any noticeable time?

Oh, I forgot to mention, the code with the error is in the "toc" child template. But I don't think the code is very relevant. The intermittent nature of the problem seems to indicate that it comes from below in the call chain.