Escape sequences in handlebars string
I am trying to process some html fields in a mapping/transform and I was unable to find how to escape newlines.
For example, with the input data :
{
"id": 123,
"name": "Bob",
"age": 33,
"html_field":"<p>This is a long field<br>With some line breaks</p>"
}
and the handlebars expression:
{{regexReplace html_field '\n' '<br>' }}
I get this output:
{
"id": 123,
"name": "Bob",
"age": 33,
"html_field": "<p>This is a long field\\nWith some line breaks</p>"
}
If I don't use a handlebar expression at all, just a standard mapping, the field is preserved, including both newlines and html markup.
I know I can use triple curly braces to avoid the conversion of the html tags to their escape sequences. However, this does nothing for the newlines, they are still escaped with an additional backslash, causing them to be recognized as a “\n” literal. Using an additional replace or jsonEncode helper does not do anything, either.
Comments
Ezriah would this work for you? This is unfortunately still a bug.
Tyler Lamparter Thanks for looking that up.
It's slightly better than just using spaces, but not really ideal. The NetSuite destination field will show up variably with these line feeds (a) replaced by spaces, (b) rendered as newlines, or (c) displayed as part of the literal string, depending on the context the field is being used in.* Also, the field just looks unprofessional to have a random mix of newlines and line feeds rather than a consistent style (I could replace all newlines with line feeds, but then a and b look even worse …).
* If you're curious, (a) is on record view pages, (b) on record edit, and (c) on tooltips and sourced fields.
Ezriah would the script route work for you for now?
Tyler Lamparter Yes, a preMap script works perfectly here. I guess maybe we're just pushing the boundaries of handlebars' capabilities beyond their intended uses.
Just a thought: it would be nice would be to have the ability to register a script as a custom handlebar helper, which would improve readability of the mapping for users who aren't developers and also allow for more modular code to be reused in multiple mappings. The upstream library supports it so it shouldn't be terrible to implement: https://handlebarsjs.com/guide/#custom-helpers
Ezriah it's definitely on the list of things we want to do.
Please sign in to leave a comment.