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
Use our own parser for HTML (instead of browser) #4417
Comments
Couldn't we rely on parse5 here ? (AFAIR it also supports line numbers) I'm not sure if I like your "proper camel casing" point: I think we should conform to what HTML is and don't try to re-invent the wheel. |
To give more details on why I'm not keen on this idea:
|
@vicb Angular2 has already deviated from HTML. Please, don't pretend that |
@vicb looking at the current user experience / feedback there are toons of people that bump into this issue. I all for following standards, but I'm also for given users' a tool that works according to their expectation. I'm not saying that we should do one or another - I can totally live with the current system since I understand it now. But yeh, we've got trade-offs to make here.
My understanding was that we sort of do this already for the server-side compilation. I wouldn't even raise this case if not the fact that we need to parse templates on the server-side anyway. On top of this having the same parser on both sides would allow us to remove parser / compiler from the framework's runtime. All in all what I'm saying here is not "we need to absolutely do it" but rather "there are serious advantages of this approach so let's consider it seriously" |
I would love this. If you are going to set a javascript property, I feel like I should use the javascript name, not some html enforced name. About the html standards argument. It doesn't feel like the angular2 project is much into standards anyway. I mean writing the code base in Typescript. Supporting Dart. Also the Some people will not like this. But is that a problem? I think that polymer is an excellent project if you prefer using (upcoming) web standards. |
They all are valid HTML syntax.
AFAIU we use parse5 to parse templates on the server side.
As of today, we use the browser built-in parser so we already do not need to embed any kind of parser in the runtime. The situation would be even regarding the runtime footprint.
I fully agree here. We should consider it and carefully weigh the pros & cons before we jump into this or discard the idea. @mhevery only listed advantages in his original message (some of which are disputable IMO) but I think we should consider both up & down sides. The only 2 benefits I see in implementing our own non-HTML compliant parser are:
Typescript is mostly ES6 + some proposals from ES7 + types so it is close enough to the standard plus it transpiles to ES6/ES5 so the user do not have to be exposed to TS if they prefer not to. WRT Dart, I would say that 95+% of the code base is TS only, I don't see an issue here - and once again this is transparent to JS/TS developers. |
@vicb IMO there are more benefits that just camel-casing and self-closing tags:
Anyway, to be discussed / measured / decided upon. |
I am wondering if any of the new TypeScript tsx/jsx features in TS 1.6 could be leveraged with an Angular2 parser in order to allow type safe templates? |
Correct. v2.0 will come up with line/col support as well. |
@vicb I think I didn't word myself clearly. I didn't meant to say I see dart support as an issue. I love dart. As an outsider, it looks like the philosophy of angular2 is more in sense of, "no problem to go a bit off standards, if it gives big gains". Actively recommending typescript, supporting dart. I like that way of thinking. It feels like this proposal is in the same line. Where polymer seem to have more the philosophy, only use web standards, and if those web standards are not good enough, we should try to push the standards to improve. Some people may prefer that. Not sure if angular2 should try to fish in this water, if there is already a big google ship fishing there. |
Personally I am totally for this. What about even using PascalCase for elements? Here is my reasoning. We already are naming our classes using
Not to mention how nice it would be if one happens to rename their component. Then one could find and |
If we used PascalCase component element names and get rid of the selector don't we lose component directives that are bound to the view as attributes? |
I'm with @ronnross on keeping names consistent and potentially ditching the selector property (keeping it optional in case you want a different name than your class). Directives would probably need to remain lowercase dashed, but if there wasn't a restriction you could technically set your selector to <div MyDirective="stuff"></div> We could make a Component's default selector |
good job! |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Advantages:
inner-html
vsinnerHTML
) Use camelCase instead of dash-case in HTML #4923<name />
for custom elements/cc: @pkozlowski-opensource, @gdi2290, @tbosch
The text was updated successfully, but these errors were encountered: