That's great!
I was looking for an API like this, figured it should exists somewhere.

Is there any documentation for tha jsreport-APIs?

Hmm, this wasn't implemented in the old V2 syntax. Maybe it's not implemented in V3 either?
https://github.com/jsreport/jsreport/issues/506

I strongly vote for this feature. I'm building a quite advanced concept with components (BTW. I love them). The origin for my component structures resides in a database. I would rather not rely on component names and locations, since this is not at all as reliable as real keys, i.e. shortid. If I refer to my components via name and location I could breaka a template just my moving or renaming a component.

I can not sucessfully call a component via its' shortid. How should the syntax be for this?

I have a helper for finding the correct component. The component call looks like this. I simply replaced the name parameter with shortid, but this was maybe too naive.

 return component.call({
    ...this,
    someData: 'bla bla',
  }, shortid, options)

Of course, I should have thought of that.
Thank you for explaining.

I have a helper function which returns an array. This function cannot be caller directly in a {{#each }} clause like this:

{{#each getFlattenedControlpointArray}}

In order to actually call the function I have to fake a parameter like this

{{#each (getFlattenedControlpointArray 1)}}

Is this a bug or have I misunderstood something?

Thanks.
Could you please confirm or clarify the below regarding child templates and components. I'm really starting to like the new concept, but I need to be sure of the below before taking design decisions.

I need to know if I have grasped the below correctly and if I missed anything important.

Child templates called with new syntax {{childTemplate.. }}

• In the child html I get access to this, i.e. the current data context from parent
  Example usage in child {{this.someItemData}} or simply {{someItemData}}

• child templates does NOT have access to data from outer scopes in the parent
  Example: {{../this.name}} will not work in the child

• Helpers in child templates can access the complete report data structure via this
  Example:

function() {
  console.log(this.someDataFromTheRoot)
}

• child templates can run scripts (i.e. beforeRender..)

• Global helpers are accessible from child templates

• In order to call a template which is not html recipe, I need to inject a recipe change into the childTemplate call.

• Helpers in child templates gets an options object prepended as last argument in calls. The data.root in the options object is the root of the report dataset.

Components

• In the component html I get access to this, i.e. the current data context from parent, i.e. same as child templates

• Components does NOT have access to data from outer scopes in the parent. Same as child templates.

• Helpers in components can NOT access the complete report data structure via this
  But if I need data from elsewhere in the report data structure I can prepare a special data package to deliver to the component via a wrapper as in your examples.

• Child components can NOT run scripts (i.e. beforeRender..)

• Global helpers are accessible from components

• Components are forced to html recipe, i.e. no need to inject recipe change as for child templates

• Helpers in components gets an options object prepended as last argument in calls. The data.root in the options object is the current context from the parent, i.e. NOT the root from the report dataset.

Edit:
I just realized that I can use global helpers to get hold of the report data root even from a component which operates in another context. This could make components usable in every case where I used to have child templates. Does this make sense?

const jsreport = require('jsreport-proxy');

function getUserName() {
  return jsreport.req.data.user.name;
}

The docs recommends that the new {{childTemplate ..}} is used instead of the old {#child ..}.

I need some help understanding how I can migrate.

Here is what I need to do in order to migrate with minimal rewriting of my child templates:

• change recipie to html
• marshal the complete data object (@root)
• marshal some parameters

But it seems that I will need to rewrite quite some code anyway.

Q1: Why is the new way recommended?
Q2: Will {#child ..} be deprecated?
Q3: Will {#child ..} perform badly in jsReport 3?

My child templates are built upon the fact that they always have the complete data tree available. Would it make sense to simply give them all data in order to preserve compatibility? I would probably need a wrapper in order to specify html as recipie (or is html default with new syntax?):

function prepareData(drawingIndex, options) {   
    return options.fn({
        data: options.data.root,
        drawingIndex
    })
}

function htmlTemplate(name) {
  return {
    name,
    recipe: "html"
  }
}

The helpers would be called like this:

{{#prepareData 6}}
  {{childTemplate (htmlTemplate "myTemplateName")}}
{{/prepareData}}

This seems like an awful lot of wrapping compared to the old syntax:

  {#child myChildTemplate @template.recipe=html @data.drawingIndex={{6}}}

i found two differences between my service vs runing via the Studio UI.

• pdfPassword is used in the service, but not in Studio
• pdfMeta is used in the service, but not in Studio

After remarking code I have now concluded that pdfPassword breaks my hrefs.
Is this a bug?

I think I'm loosing hair over this..

I can embed hrefs in my PDFs without problem. They render fine on my production server at AWS Fargate. The hrefs works fine when I download the report.

If I embed hrefs for svg elements it seems to break all hrefs (even the ones not in svg). I'm not sure if this is the cause, though.

If I run the exact same json dataset on the exact same server via Studio, all hrefs works fine.

Is there something href related going on under the hood when reports are rendered "headless", i.e. without using Studio?

Postman seems to have the same problem:
https://github.com/postmanlabs/postman-app-support/issues/10338