No mechanism to directly emit a tagged template literal.
See original GitHub issueTagged template literals are a ES2015 feature which,afaict, cannot be emitted directly. Template literals have an interesting property where a function can be used as a tag. EG:
function myTemplate(strings, ...args) {
return { strings: strings, args: args };
}
var someVar = "test"
var result = myTemplate `string 0 ${someVar} string 1`
Which, result in result
having the value { strings: [ "string 0 ", " string 1"], args: ["test"]}
The application of the template literal to the function requires the abstract operation GetTemplateObject
to be invoked which performs the splitting of the template into strings and args. ( https://www.ecma-international.org/ecma-262/6.0/#sec-gettemplateobject ) This abstract operation, as best I can tell, does not have an equivalent function at runtime. The language implementation is required to perform the operation when a function is applied to a template literal.
Libraries like lit-element
rely on this feature. I’ve tried a few workarounds but none succeeded in implementing the required behavior exactly.
The closest workaround I have is using js.Function
to evaluate a function dynamically defined:
val capture = js.Function("element", s"""
function captureTemplate(strings, ...args) {
return { strings: strings, args: args };
}
function inner() {
return captureTemplate`${raw}`;
}
return inner.bind(element)();
""").asInstanceOf[js.Function1[js.Object, TemplateCapture]]
Where raw
is the template literal text and TemplateCapture
is
@js.native
trait TemplateCapture extends js.Object {
val strings: js.Array[String]
val args: js.Array[js.Any]
}
This is close enough for my purposes. Only a bit awkward.
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (4 by maintainers)
Top GitHub Comments
A good plan IMO. I’ll see about publishing a library with an equivalent.
I’m afraid we don’t add non-essential stuff in the core repo anymore. We encourage people to publish small libraries with that kind of sugar, we’re happy to advertise them on the website, and if they gain traction we can consider them for the stdlib (assuming they relate to the Scala spec and/or the ES spec, which is the case here) once they are completed vetted and super-stable.
An advantage of a separate library in this case would be that it could use macros to rewrite away all the overhead. In the core repo we do not use any macros anymore, since they are not compatible with Scala 3 in the general case.
We want scala-js/scala-js to be 100% stable, backwards binary compatible forever, so we cannot afford introducing anything non-essential.