mirror of
https://github.com/angular/angular
synced 2026-05-24 09:28:37 +00:00
75f2cb8f56
This creates a new `angular:di-graph` in-page tool which returns the entire dependency injection graph for the application. We use the following rough algorithm for discovering all element injectors: 1. Find all root `LView` objects by querying for `[ng-version]`. 2. Walk all the transitive `LView` descendants of the roots. 3. Filter these `LView` objects to just directives. 4. Find the injector for a given directive and walk up its ancestors to find all element injectors. Discovering environment injectors works mostly the same way, just following the environment injector graph instead. This approach has a few known limitations which are out of scope for the moment: 1. Any given component typically has both an element injector *and* an environment injector. The relationship of "component -> environment injector" is not expressed in the result as of now, meaning the AI doesn't really have any insight into _which_ environment injector is being used for a particular component, though the injector will be one of the returned values. 2. The implementation does not support MFE use cases of multiple applications on the page at the same time. 3. The performance is not ideal, as we walk `LView` descendants twice and walk up the injector tree for every directive, repeatedly covering the same scope (ideally we'd just walk up every *leaf* directive, which would cover the same result for less effort). However for a debug tool, this is likely fine for now and we can optimize later if/when it becomes necessary. I did consider reusing more of the existing implementation in `global_utils` which exists to support Angular DevTools (we are already using some of it), however the existing support in `@angular/core` is actually fairly limited, returning very primitive data structures and relying on Angular DevTools to do the heavier lifting of collapsing the code into a usable graph representation. There's a potential path in the future to converge these implementations and potentially have `global_utils` use some of this code instead, but I will leave that for a future cleanup effort. |
||
|---|---|---|
| .. | ||
| acceptance | ||
| animation | ||
| animation_utils | ||
| authoring | ||
| bundling | ||
| change_detection | ||
| compiler | ||
| debug | ||
| di | ||
| dom | ||
| hydration | ||
| i18n | ||
| legacy_animation | ||
| linker | ||
| metadata | ||
| reflection | ||
| render3 | ||
| resource | ||
| sanitization | ||
| signals | ||
| strict_types | ||
| testability | ||
| util | ||
| zone | ||
| application_config_spec.ts | ||
| application_init_spec.ts | ||
| application_module_spec.ts | ||
| application_ref_integration_spec.ts | ||
| application_ref_spec.ts | ||
| BUILD.bazel | ||
| change_detection_scheduler_spec.ts | ||
| component_fixture_spec.ts | ||
| defer_fixture_spec.ts | ||
| dev_mode_spec.ts | ||
| directive_lifecycle_integration_spec.ts | ||
| error_handler_spec.ts | ||
| event_emitter_spec.ts | ||
| fake_async_spec.ts | ||
| forward_ref_integration_spec.ts | ||
| runtime_error_spec.ts | ||
| test_bed_effect_spec.ts | ||
| test_bed_spec.ts | ||
| transfer_state_spec.ts | ||