Visualize Angular Component Dependencies

This challenge focuses on building a visual representation of the dependency graph within an Angular application. Understanding component dependencies is crucial for refactoring, identifying potential performance bottlenecks, and comprehending the overall structure of a large codebase. You will create a service that analyzes Angular component metadata and outputs a graph structure.

Problem Description

Your task is to create an Angular service that can analyze an Angular application's component structure and generate a dependency graph. This graph should represent which components import or declare other components.

What needs to be achieved:

• Create a service that can process Angular component definitions.
• The service should identify direct and indirect dependencies between components.
• The output should be a data structure that can be easily consumed by a visualization library (e.g., a list of nodes and edges).

Key Requirements:

• The service should accept an array of component metadata objects as input. Each object will represent an Angular component and contain information about its dependencies (e.g., imported components, declared components).
• The service should identify direct dependencies (e.g., Component A imports Component B).
• The service should also identify indirect dependencies (e.g., Component A imports Component C, and Component C imports Component B, making Component A indirectly dependent on Component B).
• The output should be a structured object containing two arrays: nodes (representing the components) and edges (representing the dependencies between components).

Expected Behavior:

• Given a set of component metadata, the service should accurately map out the entire dependency tree.
• The nodes array should contain unique identifiers for each component.
• The edges array should contain objects, each with a source and target property, referencing the identifiers of the dependent components.

Important Edge Cases:

• Circular Dependencies: Components that directly or indirectly depend on themselves (e.g., A depends on B, B depends on A). The graph should represent this without causing infinite loops during processing.
• Components with no dependencies: Components that are not imported or do not import other components.
• Multiple dependencies: A single component may depend on several other components.

Examples

Example 1:

Input: [
  { name: 'AppComponent', imports: ['HeaderComponent', 'FooterComponent'] },
  { name: 'HeaderComponent', imports: [] },
  { name: 'FooterComponent', imports: [] },
  { name: 'UserListComponent', imports: ['UserDetailComponent'] },
  { name: 'UserDetailComponent', imports: [] }
]

Output:
{
  nodes: [
    { id: 'AppComponent' },
    { id: 'HeaderComponent' },
    { id: 'FooterComponent' },
    { id: 'UserListComponent' },
    { id: 'UserDetailComponent' }
  ],
  edges: [
    { source: 'AppComponent', target: 'HeaderComponent' },
    { source: 'AppComponent', target: 'FooterComponent' },
    { source: 'UserListComponent', target: 'UserDetailComponent' }
  ]
}

Explanation: AppComponent directly imports HeaderComponent and FooterComponent. UserListComponent directly imports UserDetailComponent. The output clearly shows these relationships as nodes and edges.

Example 2:

Input: [
  { name: 'ParentComponent', imports: ['ChildComponent'] },
  { name: 'ChildComponent', imports: ['GrandchildComponent'] },
  { name: 'GrandchildComponent', imports: [] },
  { name: 'AnotherComponent', imports: ['ParentComponent'] }
]

Output:
{
  nodes: [
    { id: 'ParentComponent' },
    { id: 'ChildComponent' },
    { id: 'GrandchildComponent' },
    { id: 'AnotherComponent' }
  ],
  edges: [
    { source: 'ParentComponent', target: 'ChildComponent' },
    { source: 'ChildComponent', target: 'GrandchildComponent' },
    { source: 'AnotherComponent', target: 'ParentComponent' }
  ]
}

Explanation: This example shows a chain of dependencies. ParentComponent depends on ChildComponent, which depends on GrandchildComponent. AnotherComponent depends on ParentComponent. The graph captures these direct links.

Example 3: (Circular Dependency)

Input: [
  { name: 'AComponent', imports: ['BComponent'] },
  { name: 'BComponent', imports: ['AComponent'] }
]

Output:
{
  nodes: [
    { id: 'AComponent' },
    { id: 'BComponent' }
  ],
  edges: [
    { source: 'AComponent', target: 'BComponent' },
    { source: 'BComponent', target: 'AComponent' }
  ]
}

Explanation: This demonstrates a circular dependency between AComponent and BComponent. The output correctly represents this by having an edge from A to B and an edge from B to A. The algorithm should be robust enough to detect and represent this without infinite looping.

Constraints

• The input will be an array of objects, where each object has a name (string) and an imports (array of strings) property.
• The name property will uniquely identify a component.
• The imports array will contain the names of other components that the current component directly depends on.
• The number of components in the input array will be between 0 and 1000.
• The number of imports per component will be between 0 and 50.
• The solution should be implemented as an Angular service.

Notes

• You will likely need to use a graph traversal algorithm (like Depth-First Search or Breadth-First Search) to identify indirect dependencies.
• Consider how you will handle components that are imported by multiple other components – they should still appear as a single node.
• The focus is on generating the data structure for the graph, not on rendering the graph itself. You can assume that a separate library or component will consume this output for visualization.
• Think about how to efficiently store and retrieve component information during the traversal. A map or a dictionary could be useful.
• Ensure your service is designed to be testable, so consider separating the graph generation logic from any Angular-specific DI if necessary for unit testing.