You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the lifecycle key exists, we use it as the source of truth:
The lifecycle configuration gets generated by the transformer from the implemented interfaces, that is fine,
For non-transformed code, the lifecycle value has priority over implemented interfaces. It's counter-intuitive and might lead to a different behavior vs transformed code.
In JS:
The lifecycle value has priority over a structural type checking. Once again this could cause unexpected behavior if the lifecycle value is no updated when LC hooks are added or removed.
* Proposal*:
Remove the lifecycle config option from Directive:
In Dart, you would only have to implement the desired interfaces,
In JS, you would have to name methods as LC hooks for them to pass the structural type check,
In TS, the preferred way would be to implement the interfaces as well but the JS way would work equally well.
The only pb I can imagine is related to #2898 where @yjbanov wants to remove interfaces from the generated metadata in Dart. What about having a white list of interfaces we want to include there ?
I don't see a conflict with #2898. We either use interfaces in a runtime check is OnChange (in dev mode) or we discover them in the transformer and generate lifecycle call sites (and let dart2js erase the interfaces later).
Not sure how this would work in TS, as tsc erases all information about interfaces.
As of today, it seems that the compiler calls DirectiveBinding.createFromBinding that in turn check what interfaces are implemented. At some later point we should probably retrieved the metadata generated by the transformer instead. When this is implemented there will be no need for the reflector to have information about implemented interfaces (at least for the LC hooks).
TS (as JS) would use structural type check (implements OnHook is optional but would be documented as the best practice).
Activity
mhevery commentedon Aug 31, 2015
I think this is great, and I would love to see this happen. It is not clear to me if we can do this due to way Dart Transformers work.
yjbanov commentedon Sep 1, 2015
I don't see a conflict with #2898. We either use interfaces in a runtime check
is OnChange(in dev mode) or we discover them in the transformer and generate lifecycle call sites (and letdart2jserase the interfaces later).Not sure how this would work in TS, as
tscerases all information about interfaces.vicb commentedon Sep 1, 2015
As of today, it seems that the compiler calls
DirectiveBinding.createFromBindingthat in turn check what interfaces are implemented. At some later point we should probably retrieved the metadata generated by the transformer instead. When this is implemented there will be no need for the reflector to have information about implemented interfaces (at least for the LC hooks).TS (as JS) would use structural type check (
implements OnHookis optional but would be documented as the best practice).mhevery commentedon Sep 1, 2015
@vicb can this be refactored somehow so that we could drop
LifecycleEvent? I really would like to get this breaking change in ASAP.refactor(LifecycleEvent): remove LifecycleEvent
angular-automatic-lock-bot commentedon Sep 7, 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.