-
Notifications
You must be signed in to change notification settings - Fork 231
@deferred silently does nothing if host also has structural directive #1538
Comments
We already have an error if there are two structural directives on the same element. I think it's reasonable to treat |
Agree with @alorenzen, though it is confusing because it is an |
We agreed making this a static error is acceptable, and not strictly speaking a breaking change. |
@leonsenft @alorenzen I guess that we'd have to do this in if (astNode.annotations.isNotEmpty) {
final i = astNode.annotations.indexWhere((ast) => ast.name == 'deferred');
if (i != -1) {
final deferredAst = astNode.annotations.removeAt(i);
final origin = _toolFriendlyAstOrigin ? deferredAst : null;
return EmbeddedTemplateAst.from(
origin,
childNodes: [astNode],
hasDeferredComponent: true,
);
}
} ... right? |
Yeah, I think so. |
It looks like this is less than straightforward, because:
Thoughts? |
Why not check the annotations before de-sugaring |
That solves the |
Oh sorry I think I misunderstood your second point. You're concerned about <template @deferred>
...
</template> right?
Why not add the check for |
I could, it just seemed messy. But reading this discussion, it probably is not. Thanks! |
Closes #1538. PiperOrigin-RevId: 207997994
Closes #1538. PiperOrigin-RevId: 207997994
Closes #1538. PiperOrigin-RevId: 207997994
Closes #1538. PiperOrigin-RevId: 207997994
Closes #1538. PiperOrigin-RevId: 207997994
Fixed in 703fbda. |
The following pattern silently drops the
@deferred
:A correct solution is to move the structural directive to a parent element:
Given this restriction, the compiler should warn or error if
@deferred
and a structural directive are placed on the same element.The text was updated successfully, but these errors were encountered: