dart-archive / angular_ast Goto Github PK

See other packages – likely should copy pkg/angular2

Not a trivial process; there are changes made within the angular_ast already to define the new Pipe expression, but implementing it is proving to be troublesome due to circular dependency issue with the analyzer library.

May have to potentially reach out to analyzer team to figure out the best solution.

Potentially look into desugaring/expression parsing pattern with pipes.

Currently using the * sytnax on a <template> element like

<template *ngIf="condition">

produces the error message

Invalid decorator in 'template' element

Providing a link to the * documentation could be more helpful for new users.

Originally filed here: dart-archive/angular_analyzer_plugin#451

Opening a TODO assuming that #60 gets merged.

This PR adds support for <div x:y="z"> and <div [attr.x:y]="z">. However, we may want to either test that <div [x:y]="z"> is allowed, or specifically reject it. The PR likely does the former, but does not add tests if that's what we want.

From #12 (comment):

I think : is allowed more than just here, ie let x of: items.

Also, I think let x of items is equivalent to let x; of items

In general I think the grammar is pretty simple:

Star := '*' name '=' '"' (expr | MicroExprList) '"'
MicroExprList = (LetExpr | BindExpr)+
LetExpr := 'let' id ('=' id)? ';'?
BindExpr := (id ':'?)? expr ';'?

Even simpler when you think of *x="y" as sugar for template="x y"

Template := 'template' '=' '"' MicroExprList '"'

• Support parsing expressions without throwing when a failure occurs
• Include offset data in parseExpression
• Add visitExpression to TemplateAstVisitor
• Add support for accept to BananaAst and StarAst for tooling teams
• Check trailing expressions (see implementation)
• TemplateAstVisitor#visit should delegate to TemplateAst#accept.

Consider also making it into it's own AST.

dart-archive/angular_analyzer_plugin#401

Currently the method signature of TemplateAst.accept is

/*=R*/ accept/*<R, C>*/(TemplateAstVisitor/*<R, C>*/ visitor, [C context]);

Any reason why it's not?

R accept<R, C>(TemplateAstVisitor<R, C> visitor, [C context]);

Not sure which svg tags are allowable as void, but someone reported to me that this was causing problems.

Not sure if we want to go to the length of allowing svg tags only within svg entirely...

Event-bound values are not entirely just Expression type, but List of statements (specifically ExpressionStatement).

Adjust the ast to store these values instead of just "expression" type.

Likely we just want to accept namespaced attributes anywhere.

  <use xlink:href="#path-3">

Be able to detect usage of attriblute-value without quote - then report error.

Related to: dart-lang/code_builder#109

web\packages\angular_ast\src\expression\pipe.dart:103:7:
Duplicate definition of 'operator'.
Try to rename or remove this definition.
  set operator(Token token) {
      ^^^^^^^^

If you think that supporting dart2js is or can be a goal, I can possibly provide a PR to resolve this (late this weekend).

This is a pretty significant change in terms of architecture and wanted to discuss this before submitting a PR on it.

Is there a strong reason to keep the Lexer and Parser as const factories? I would like to change it to just regular constructor.

TL;DR reason: Current parser, upon seeing a parse error, gives up and throws a single error. I want to recover from predictable parse errors and continue parsing the document while also throwing further parse errors it sees.

I want the NgScanner to store all propagated errors in a list, which can be accessed by the NgLexer. Since NgLexer is a const and holds no real value (unless static - but that's a bad idea), I can't propagate errors into NgLexer. Similar issue with the NgParser.

Example: [style.width.%]="100"

Raised in: dart-archive/angular_analyzer_plugin#281

PR #37

We are not published yet, so this shouldn't be an issue.

If you can also add @MichaelRFairhurst and @mk13 as contributors here.

After Pipe expression is implemented, it would be a good point to refactor some of the code to make it cleaner.

Potentially add a PipeExpression type so a visitPipe can be added for tooling.

@MichaelRFairhurst on #11:

Hmm, I think the only thing about that to me is that the resulting AST has a semantic meaning, just one that existing tools won't like.

I think it'd be best to transform the semantic meaning into a valid one (ie, actually expose $$ng.pipe to users and everything), or create an extension to the AST so that existing tools know that they need to be extended with visitPipe etc before they can work.

• Remove // TODO: Support pipe arguments.
• Ensure that the parser only accepts identifiers for pipe names
• Use PrefixedIdentifier instead of SimpleIdentifier

Support parsing expressions without throwing when a failure occurs
Include offset data in parseExpression

• Remove the hacky /test.dart
• Import the analyzer Expression class prefixed

Remove C from /*<R, C>*/ on TemplateAst#accept methods

Also see #15, and #17

PR #345 in analyzer; once added remove the error from plugin to avoid redundant.