-
Notifications
You must be signed in to change notification settings - Fork 647
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type-checked templates #325
Comments
/CC @philidem @mlrawlings @tindli Thank you for the detailed write up, @nicolashery! This seems completely doable with some tweaks to the compiler and runtime. For example, we would need to modify the Personally, I am not yet using TypeScript. I'm not opposed to TypeScript, but I also haven't had a strong desire to start using it. Because of that, I may not be the best person to work on this. I would rather someone who is actively using TypeScript to do the coding, but I can definitely help point you in the right direction. As long as the code changes are clean and well-tested then I have no objections to this proposal. Regarding open questions:
That may be nice and I think that is also doable without drastic changes. For example, the compiler would need to attach source mappings to parsed expressions. It's definitely something I have thought about, but we haven't had any time to come up with a formal proposal or implement it. With that said, I have found source maps to be somewhat problematic and often end up disabling them (e.g. when doing Atom plugin development with CoffeeScript). Instead, we have focused on making sure the compiled output is extremely readable. For that reason, supporting source maps has been a low priority.
I would have to take a look at how TypeScript autocompletion works for other files, but I suspect this will be challenging. Maybe the template can be compiled to TypeScript and source maps could be used to generate autocompletions as the user is editing the Please let me know if you are interested in contributing and we can discuss a plan of action. Any thoughts from others? |
@patrick-steele-idem @mlrawlings I haven't gotten a change to explore this much, but I saw that Marko v4 is just around the corner (congratz btw! 😄). I definitely don't expect this to make it to v4, but I did want to see if there were any changes in v4 that would make it hard to add TypeScript support in the future (should we want to of course), without any breaking changes. I've quickly put this together: https://github.com/nicolashery/explore-marko-typescript You can take a look at how I had to change the original Marko output (src/components/search-results-item.marko.js) to make it useful with TypeScript (src/components/search-results-item.marko.ts). There are a couple things in there, but the main one that caught my attention is probably Marko's Off the top of my mind, one option could be for the Of course I don't want to distract, I know you guys are focused on shipping v4 and that's the most important. But I thought it could be worth thinking about this now, even if just a little bit. |
I think this will be possible once the changes here are hashed out: microsoft/TypeScript#6508 . They are solving some angular-2-specific problems that should also make it easier to typecheck |
Thanks @mindeavor, I hadn't seen that. From skimming through it, I think this will help with the question of editor integration (ex: VSCode Angular Language Service). I looks like it's been open for a while though. What I had in mind as a first step is more along the lines of Angular's Ahead of Time (AOT) compilation, which outputs TypeScript code that can be used when type-checking the whole app (business logic code + templates):
|
I haven't looked closely, but looks like the plugin support released in TypeScript 2.3 may be of help for type-checking |
+1 |
Is there any new progress with this? |
any update? |
Svelte works with TypeScript ad type-checks its template files using |
This is now fully supported. Documentation: See:
|
Summary
Adding type annotations to JavaScript in order to get compile-time guarantees has become popular with tools like TypeScript and Flow. Would it be feasible to get the same benefits in Marko template files?
Rationale
View engines that are "just JavaScript" like React can easily be type-checked (both TypeScript and Flow actually have out-of-the box support for React).
When working with templates though, you loose the benefit of type-checking as soon as you cross the boundary into the template file. In a type-checked project, this can make refactoring trickier, for example you rename a property but forget to update the template.
On the other hand, templates have the advantage of compile-time optimizations (ex: server-side rendering performance). Being able to have type-checked templates could be a big win. I don't think this has been done yet in the JavaScript community.
Note: My knowledge of compiling templates or type-checking is close to none, so I don't even know if this is feasible :) This issue is intended to start a discussion.
What it could look like
(I'm using TypeScript in my examples but this could very well be translated to Flow.)
Say I have declared these types:
A TypeScript file would immediately tell me if I'm accessing wrong properties:
But a Marko template wouldn't:
What if I could declare the type of the data my template expects?
And tell Marko to generate type-annotated files?
The TypeScript compiler would then catch the errors on the generated JavaScript:
And as I use the template in my type-checked project I would get auto-completion and type errors:
Open questions
.marko
file that caused it?.marko
file?Relevant links
The text was updated successfully, but these errors were encountered: