Component Evaluation Hook

jsnevely-tempest

Hello,

I'm working on an in-house extension that would allow us to "hot swap" components of a report based on incoming context, i.e. one client might have a custom version of a component for a specific report stored elsewhere (not just the fs-store).

I've got a working version right now where I'm using the beforeRenderListeners hook to make the content swap on disk using the documentStore.update function and then reverting it back in the afterRenderListeners hook if an update was made.

This approach works, but I don't like the idea of modifying the component temporarily even if it is for a short period of time. Is there a hook I'm missing which could be attached to the Component Evaluation event? I've been through the jsreport-components code pretty thoroughly but I don't see how the evaluate call used by the proxy would trigger anything, but hopefully I'm missing something?

If this isn't present is it something that would make sense on the roadmap? Ideally I would be able to intercept a pre-render of a component and modify the req on that specific call if needed and leave the documentStore alone. Alternatively I suppose we could use child reports but that feels like a lot of extra overhead compared to just dynamic components.

admin

Maybe you can implement your own helper "dynamicComponent" that receives the component code and returns the evaluated result.
It would be up to you where you download the component implementation.

https://playground.jsreport.net/w/anon/CQZ_3bC4


const jsreport = require('jsreport-proxy')

async function dynamicComponent(content, helpers) {
    return await jsreport.templatingEngines.evaluate({
      engine: 'handlebars',
      content: content,
      helpers: helpers,
      data: this
    }, {
      entity: jsreport.req.template,
      entitySet: 'templates'
    })
}

{{{dynamicComponent "some dynamic content {{myData}}" "function aHelper() {}"}}}

jsnevely-tempest

Thanks for the follow-up, I like that idea because this way I wouldn't be polluting the default behavior of existing reports with components already. I'll try this approach for sure!