Repository navigation
Use our own parser for HTML (instead of browser) #4417
Description
Advantages:
- We could use it in WebWorker, Server side, or with native renderers.
- Proper camel casing. (We can get rid of
inner-htmlvsinnerHTML) Use camelCase instead of dash-case in HTML #4923 - Errors have proper line numbers.
- We can rely on attribute order (not sure if it would be relevant)
- We could support self closing tags
<name />for custom elements - No need to ship parser when doing offline compilation.
Activity
vicb commentedon Sep 29, 2015
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.
vicb commentedon Sep 30, 2015
To give more details on why I'm not keen on this idea:
alexpods commentedon Sep 30, 2015
@vicb Angular2 has already deviated from HTML. Please, don't pretend that
[prop]="expr",(event)="expr",*ng-for="#value of values",<div #element>are valid HTML syntax. And it has already frighten some users. The way I see it, the need to remember dash-case/camelCase conversion and its special cases are terrible user experience. It will been frightening users even more.pkozlowski-opensource commentedon Sep 30, 2015
@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"
kasperpeulen commentedon Sep 30, 2015
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
[value],(click)#inputnotation.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.
vicb commentedon Sep 30, 2015
@alexpods
They all are valid HTML syntax.
@pkozlowski-opensource
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:
@kasperpeulen
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.
pkozlowski-opensource commentedon Sep 30, 2015
@vicb IMO there are more benefits that just camel-casing and self-closing tags:
Anyway, to be discussed / measured / decided upon.
martinmcwhorter commentedon Sep 30, 2015
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?
inikulin commentedon Oct 1, 2015
@vicb
Correct. v2.0 will come up with line/col support as well.
kasperpeulen commentedon Oct 1, 2015
@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.
8 remaining items
timkindberg commentedon Nov 6, 2015
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
selector: '[MyDirective]'if you had a preference for it, e.g.:We could make a Component's default selector
'${ComponentClassName}'and a Directive's default selector'[${DirectiveClassName}]'.xgqfrms-GitHub commentedon Jul 21, 2017
good job!
angular-automatic-lock-bot commentedon Sep 12, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.