Create React App linter does not like new template syntax.

[WieserSoftware]

Line 91:41: Unexpected template string expression no-template-curly-in-string

I know I can turn it off with a local override, just raising it here for visibility.

[WieserSoftware]

For reference, to remove the warning from your template area, surround your template definitions with:

/*eslint-disable no-template-curly-in-string */ ... template definitions go in here... /*eslint-enable no-template-curly-in-string */

[matthidinger]

Hi @WieserSoftware, unfortunately I'm not super up to speed on Create React App. Can you provide a little more context here?

[WieserSoftware]

Sure. When you use create-react-app you get a bunch of boilerplate configuration. It dumps errors into the console (of your web app) for lint errors that are very likely to be errors. While you can override these errors in local configuration for use in your IDE, it's not easy to do so for the console. You'd need to "eject" which means you lose all of the benefits of a curated webpack setup.

Unfortunately, the new template syntax really looks like an error to javascript/typescript, as well as c#. I'm guessing the $ was added to remove the warnings in c#?

The problem is that when you have template syntax in those languages, you're expected not to have it in double quotes.

In C# you'd generally have an error if you didn't prefix these template strings with $, so $"some interpolation of results {here}" would try to interpolate the variable here into the string. In JS/TS you use back tick and $ on the expressions, so `some interpolation of results ${here}`

By hijacking the same syntax for your templating, it actually makes it more likely that you'll have created an error in your code somewhere else in JS land

I've added the local override to turn this behavior off in my templates in JS by adding this /*eslint-disable no-template-curly-in-string */

However, I'm now operating without a safety net in that file.

[WieserSoftware]

I wonder if it would be possible to make the template prefix configurable in the template description itself as an extra field that defaults to $.

It could then be redfined with something like

{
    "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
    "type": "AdaptiveCard",
    "version": "1.0",
    "interpolationMarker": "^",
    ...
}

Which would allow my templates to look like "$when": "^{!author.isVisible}", or "$when": "%{!author.isVisible}",

This would then not impact existing templates, but would allow flexibility going forward.