User-provided error handler to catch errors in template commands

[speedpro]

Rather than preventing the document from being generated, I'd like to ignore "undefined" errors, and either 1) leave the original placeholder intact, OR 2) display a placeholder inside the document.

I know I can use javascript code, (e.g: case && case.owner && case.owner.name ? case.owner.name : 'YOUR NAME HERE'), but I need to make a system that "non-technical" people can use.
Ideally we would just say +++ case.owner.name +++, and it would ignore undefined errors and leave the original text as is.

I hope that makes sense.

Is this scenario possible, or should I be using something in the additionalJsContext to achieve this?

Also, I'm happy to create a pull request if you can point me in the right direction for setting up a dev environment.

Thanks!

[jjhbw]

Thanks for your suggestion. Just to explore this idea further, what do you propose the API would look like? One thing that comes to mind is providing a callback to rejectNullish instead of a boolean...

I think this is behaviour that we want to push to userspace as much as possible to avoid cluttering the API.

Throwing an error when a field is undefined (rejectNullish) makes sense to me, and so does returning an empty string (rejectNullish == false).

Adding more flavors to handle undefined results is possible, but may end up complicating everything more than necessary.

[speedpro]

Hey, sorry for the late response.

I agree with pushing to userspace. As I've thought about it, I think just being able to include a custom error handler would be the way to go. That way the developer has the flexibility to handle any use case that might come up.

I would imagine a callback function like the following:

function(
  error:ErrorObject , // the error object
  expression: String, // or Object. The actual expression (e.g. "case.subject.firstname" or "query(abc)") or an object with details of the expression, and the type of operation performed. In any case, it would be nice to have access to the original string so that we can put it back into the template if there's an error.
) {
  return content : String; //the content to display
  //OR
  throw error :  Error; //throw the error, and prevent template generation
} 

If no error handler is supplied, then it would keep the current functionality of halting template generation.

Now, I don't know whether the catch function should be async or sync, or whether it would easy to make it optional, but what do you think?

[jjhbw]

Good idea!

I think we can extend the rejectNullish type to be boolean | ErrorHandler where ErrorHandler is the callback with a signature similar to the one you suggest.

This touches upon the code in processTemplate.ts (basically every occasion where a NullishCommandResultError is thrown. E.g. here:

docx-templates/src/processTemplate.ts

Line 498 in af2017e

throw new NullishCommandResultError(cmdRest);

I'll get to this at some point as i'm likely to need similar functionality in the future. Feel free to send a PR, though.

[jjhbw]

Thanks again for your PR. I played around with it a bit and tried a few cases. See the custom-errorhandler branch. Does this solve your use case?

[speedpro]

Yep, I just tested it on your branch, and it works perfectly.

Thanks!

[jjhbw]

See https://github.com/guigrpa/docx-templates/releases/tag/v4.4.0

Let me know if I missed something.