Tagged template literals support#638
Conversation
There was a problem hiding this comment.
I did a quick test and stumbled on the fact that if the tag function's first argument is not typed as TemplateStringsArray (could be any[], string[], etc...), getResolvedSignature fails and so no context parameter is passed to the function in the resulting lua. I'm not sure off the top of my head how to best handle that, but we'll need to do something or the code breaks at runtime.
|
I did some more tests: Works:
Doesn't work:
So it seems Perhaps we should just require the type of that parameter to be |
|
Turns out |
|
|
|
Is there still anything weird to fix up with the |
|
|
| joinRawResult: "hello \\`", | ||
| }, | ||
| { | ||
| callExpression: "obj.func`hello ${'propertyAccessExpression'}`", |
There was a problem hiding this comment.
Looks like it always calls functions with global context:
const obj = {
func(strings: TemplateStringsArray, ...expressions: any[]) {
console.log(this === obj); // `true` in JS, `false` in Lua
},
};
obj.func`hello`;local obj = {func = function(self, strings, ...)
print(self == obj)
end}
obj.func(_G, { -- should be `obj`
"hello",
raw = {"hello"},
})Also there is a case where obj isn't pure:
getObj()["func"]`hello`;In call expressions it's handled like that:
(function()
local ____TS_self = getObj(_G)
return ____TS_self.func(____TS_self, {
"hello",
raw = {"hello"},
})
end)()There was a problem hiding this comment.
Good find! Took a bit to understand what to do here, I've added transformContextualCallExpression in an attempt to preserve this left hand side behaviour to call-like expressions which includes these template literals.
4 participants
Closes #611
Raw strings are usable too.
Equivalent output code does look hard to read.