-
Notifications
You must be signed in to change notification settings - Fork 232
DI: In debug mode, trace a provider failure #434
Comments
…essages. Added a simple test (passes), and a complex test (skipped, does not pass). In dev-mode we will start tracking the chain of failed lookups and give a better error message, i.e. "No provider found for B: A -> B". Work towards #434. PiperOrigin-RevId: 184594151
…essages. Added a simple test (passes), and a complex test (skipped, does not pass). In dev-mode we will start tracking the chain of failed lookups and give a better error message, i.e. "No provider found for B: A -> B". Work towards #434. PiperOrigin-RevId: 184594151
*** Reason for rollback *** Teams are relying on this throwsArgumentError, so I'll have to do this behind a flag... *** Original change description *** feat(Core): Start work on a MissingProviderError, with better error messages. Added a simple test (passes), and a complex test (skipped, does not pass). In dev-mode we will start tracking the chain of failed lookups and give a better error message, i.e. "No provider found for B: A -> B". Work towards #434. *** PiperOrigin-RevId: 184617305
*** Reason for rollback *** Teams are relying on this throwsArgumentError, so I'll have to do this behind a flag... *** Original change description *** feat(Core): Start work on a MissingProviderError, with better error messages. Added a simple test (passes), and a complex test (skipped, does not pass). In dev-mode we will start tracking the chain of failed lookups and give a better error message, i.e. "No provider found for B: A -> B". Work towards #434. *** PiperOrigin-RevId: 184617305
This is a WIP. In early code, it's looking ~OK, but with the following mistakes: When the ViewCompiler generates code like so: build() {
_Foo = new Foo(injectorGet(FooDependency));
} ... it would need to insert trace statements ... build() {
debugInjectorEnter(Foo);
_Foo = new Foo(injectorGet(FooDependency));
debugInjectorExit(Foo);
} ... if we do that, we should get ~100% feature coverage. |
We talked offline. This is probably OK, but we'll validate first that:
|
This flag is *enabled* by default. When enabled, you can expect *some* better error messages, but the better messages are *not* lazy, early testing by key customers don't show any noticeable performance regressions in DDC. See a potentially blocking issue: #434 (comment) ... where we've decided to evaluate code cost before going forward on that one. PiperOrigin-RevId: 184883497
This flag is *enabled* by default. When enabled, you can expect *some* better error messages, but the better messages are *not* lazy, early testing by key customers don't show any noticeable performance regressions in DDC. See a potentially blocking issue: #434 (comment) ... where we've decided to evaluate code cost before going forward on that one. PiperOrigin-RevId: 184883497
The rest of this is very non-trivial. We should review at the weekly about the priority of this. |
I... think either @hterkelsen or @ferhatb was going to help here. |
Finishing this feature has been postponed until after V5/Dart 2. |
Related; this would be much easier with dart-lang/sdk#34141. Otherwise, we'd need to convert current expressions into 3 statements, which is really hard in some places (for example we don't have a great way of creating unique local variables without just using a global counter of some sort). |
Partial work towards #434. It looks like unfortunately completing this fix might be [virtually] infeasible without dart-lang/sdk#34141, though we could potentially use a ternary expression (dart-lang/sdk#34141 (comment)). Closes #1568 PiperOrigin-RevId: 208663946
Partial work towards #434. It looks like unfortunately completing this fix might be [virtually] infeasible without dart-lang/sdk#34141, though we could potentially use a ternary expression (dart-lang/sdk#34141 (comment)). Closes #1568 PiperOrigin-RevId: 208663946
Partially closes #434 (still need factories). Downsides of this implementation is mostly the code it emits now for traceable `new X(...)` is plain ugly, though we wouldn't need the worst part, the ternary expression, if dart-lang/sdk#34141 was addressed. Ideally we would not use this wrapper expression at all, but it is currently NP-hard to refactor what is an expression into a statement due to how the compiler pipeline works (the expression is created before the assignment), so this seems like the least-bad option _if_ we want this fix. Also deleted some unused code. Closes #1573 PiperOrigin-RevId: 209010949
This used to happen in pre-Angular Dart 2.0, but was never added for code generation.
EDIT as of 2018-08-14 - We still need to cover the view-compiler cases to close this:
Child directives with dynamic dependencies:
... should become ...
Child directives in embedded templates (or anything that triggers
parentView.injectorGet
):(i.e. figure out what code-paths invoke
injectFromViewParentInjector
)Queries for services that live on child directives that have dynamic dependencies
Provided services with dynamic dependencies:
... should become ...
Provided services via a
FactoryProvider
The text was updated successfully, but these errors were encountered: