You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm interested in working on this. I had a local fork for the 0.9 compiler that included parser changes to allow foo strings, and was preparing to start working on emitting code.
With the new compiler work underway, what's the best way for an external contributor to help out here?
Thanks Duncan Mak (@duncanmak), a PR would be a good way to share your proposal with us. Since this is a bigger change than normal bug fixes, I would suggest sharing your changes early so that you can get feedback as you go.
Feel free to tag me, or email me directly if you have any questions.
Please follow the guidelines in CONTRIBUTING.md and submit a Contributor License Agreement (CLA) before submitting the pull request.
Unless I'm missing something, codegen for < ES6 should be just a case of removing the line-end character(s) and correctly escaping single and double-quote.
It would be especially nice if this were to support type annotations which could be determined in the lexer. So you could annotate a string as containing HTML which editors could use to provide highlighting, autocomplete etc.
There are still some details being ironed out, but we support tagged templates on ES6 emit and untagged templates on all emit targets.
Type-checking occurs in substitution expressions, however, in an untagged template expression, there is no constraint on the type of the substitution expressions.
In a tagged template, overload resolution may occur, yielding an appropriate signature. Substitution expressions are constrained by the signature's parameters' types. A synthesized value of the new TemplateStringsArray type corresponds to the first argument. Substitution expressions at position n correspond to an argument at position n+1. Contextual typing rules work as appropriate.
Language service support for signature help on tagged templates is in the works on #1204.
Hey Daniel,
This feature is a massive win, thanks for implementing.
Any chance on tagged templates getting es5 support? Is it not a more or less straightforward transformation - perhaps a __template(tag, strings, values) function emitted to package the string arrays and invoke the tag?
Thanks again!
Really glad that you've had a good experience with this feature. Downleveled ES3/ES5 tagged templates is actually on our agenda, and Ivo Gabe de Wolff (@ivogabe) has put out PR #1589 to implement them. So far, things look good, and I think we'll be able to lock it in for 1.5.
Really glad that you've had a good experience from this feature.
Downleveled ES3/ES5 tagged templates is actually on our agenda, and Ivo Gabe de Wolff (@ivogabe)https://github.com/ivogabe has put out PR #1589 #1589 to implement them. So
far, things look good, and I think we'll be able to lock it in for 1.5.
—
Reply to this email directly or view it on GitHub #13 (comment).
So we have string interpolation, and support for tagged templates coming up in 1.5 - these are great features, but has anyone thought about adding support for an alternative file extension for template files?
Basically just Typescript, but with the contents of the file being emitted or returned somehow, and you have to use a tag to escape from output - I guess basically EJS for Typescript.
There are lots of fine template engines for JS, but what I'm after is something that will receive the same excellent IDE support Typescript gets - I haven't found anything like that for JS. (we're a rather large team considering a transition from PHP towards Typescript+Node, and a key missing feature right now is views/templates with proper IDE support, e.g. auto-complete for a view-model and view helper-functions.)
Activity
duncanmak commentedon Jul 21, 2014
I'm interested in working on this. I had a local fork for the 0.9 compiler that included parser changes to allow
foostrings, and was preparing to start working on emitting code.With the new compiler work underway, what's the best way for an external contributor to help out here?
mhegazy commentedon Jul 27, 2014
Thanks Duncan Mak (@duncanmak), a PR would be a good way to share your proposal with us. Since this is a bigger change than normal bug fixes, I would suggest sharing your changes early so that you can get feedback as you go.
Feel free to tag me, or email me directly if you have any questions.
Please follow the guidelines in CONTRIBUTING.md and submit a Contributor License Agreement (CLA) before submitting the pull request.
basarat commentedon Jul 28, 2014
👍
Codeplex issue : https://typescript.codeplex.com/workitem/19
styfle commentedon Jul 28, 2014
This would be great to have in TypeScript 👍
BurtHarris commentedon Sep 15, 2014
+1: A highly desirable enhancement.
ryanbnl commentedon Sep 25, 2014
Unless I'm missing something, codegen for < ES6 should be just a case of removing the line-end character(s) and correctly escaping single and double-quote.
ryanbnl commentedon Sep 25, 2014
It would be especially nice if this were to support type annotations which could be determined in the lexer. So you could annotate a string as containing HTML which editors could use to provide highlighting, autocomplete etc.
Or better yet, something similar to Nemerle's macros (see: http://nemerle.org/About).
DanielRosenwasser commentedon Oct 16, 2014
As a heads up, I'm currently taking this on.
DanielRosenwasser commentedon Nov 21, 2014
Implemented in #960 and #1072.
There are still some details being ironed out, but we support tagged templates on ES6 emit and untagged templates on all emit targets.
Type-checking occurs in substitution expressions, however, in an untagged template expression, there is no constraint on the type of the substitution expressions.
In a tagged template, overload resolution may occur, yielding an appropriate signature. Substitution expressions are constrained by the signature's parameters' types. A synthesized value of the new
TemplateStringsArraytype corresponds to the first argument. Substitution expressions at position n correspond to an argument at position n+1. Contextual typing rules work as appropriate.Language service support for signature help on tagged templates is in the works on #1204.
hdachev commentedon Feb 11, 2015
Hey Daniel,
This feature is a massive win, thanks for implementing.
Any chance on tagged templates getting es5 support? Is it not a more or less straightforward transformation - perhaps a
__template(tag, strings, values)function emitted to package the string arrays and invoke the tag?Thanks again!
DanielRosenwasser commentedon Feb 11, 2015
Hey Hristo Dachev (@hdachev),
Really glad that you've had a good experience with this feature. Downleveled ES3/ES5 tagged templates is actually on our agenda, and Ivo Gabe de Wolff (@ivogabe) has put out PR #1589 to implement them. So far, things look good, and I think we'll be able to lock it in for 1.5.
hdachev commentedon Feb 11, 2015
Thanks, great work guys!
On Wednesday, February 11, 2015, Daniel Rosenwasser <
notifications@github.com> wrote:
mindplay-dk commentedon Mar 23, 2015
So we have string interpolation, and support for tagged templates coming up in 1.5 - these are great features, but has anyone thought about adding support for an alternative file extension for template files?
Basically just Typescript, but with the contents of the file being emitted or returned somehow, and you have to use a tag to escape from output - I guess basically EJS for Typescript.
There are lots of fine template engines for JS, but what I'm after is something that will receive the same excellent IDE support Typescript gets - I haven't found anything like that for JS. (we're a rather large team considering a transition from PHP towards Typescript+Node, and a key missing feature right now is views/templates with proper IDE support, e.g. auto-complete for a view-model and view helper-functions.)
basarat commentedon Mar 23, 2015
Rasmus Schultz (@mindplay-dk) I suspect this might just happen with angular support followed by angular support for server side next year.