Angular Bundle Analyzer Visualization

This challenge focuses on building a visualizer for Angular application bundle sizes. Understanding your application's bundle size is crucial for optimizing performance, improving load times, and providing a better user experience. You will create a component that analyzes and presents this information in an intuitive way.

Problem Description

Your task is to develop an Angular component that can visualize the size distribution of modules within an Angular application's build output. This component will act as a simplified "bundle analyzer," helping developers understand which parts of their application contribute most to the final bundle size.

Key Requirements:

1. Data Input: The component should accept an array of objects, where each object represents a module and its associated size (e.g., in kilobytes). The structure of these objects will be provided.
2. Visualization: Implement a visual representation of the module sizes. A bar chart or a tree map are good starting points. The visualization should clearly show the relative sizes of different modules.
3. Interactivity (Optional but Recommended): Allow users to hover over a module in the visualization to see its exact size and potentially its name.
4. Sorting/Filtering (Optional): Consider adding options to sort modules by size (descending) or filter out very small modules to declutter the visualization.
5. Error Handling: Gracefully handle cases where no data is provided or the data format is incorrect.

Expected Behavior:

• When provided with valid data, the component should render a clear and understandable visualization of module sizes.
• Larger modules should be visually prominent.
• The visualization should be responsive and adapt to different screen sizes.

Edge Cases:

• Empty input array.
• Input array with modules having zero size.
• Input array with a very large number of modules.

Examples

Example 1:

// Input data structure:
interface ModuleInfo {
  name: string;
  size: number; // size in KB
}

const moduleData: ModuleInfo[] = [
  { name: 'AppComponent', size: 50 },
  { name: 'UserService', size: 20 },
  { name: 'AuthModule', size: 150 },
  { name: 'SharedModule', size: 100 },
  { name: 'NgRx Store', size: 80 },
];

Output: A visual representation (e.g., a bar chart) where 'AuthModule' is the largest bar, followed by 'SharedModule', 'NgRx Store', 'AppComponent', and finally 'UserService'. Hovering over 'AuthModule' should display "AuthModule: 150 KB".

Example 2:

// Input data structure:
interface ModuleInfo {
  name: string;
  size: number; // size in KB
}

const moduleData: ModuleInfo[] = []; // Empty array

Output: The component should display a message like "No bundle data available." or render an empty state.

Example 3:

// Input data structure:
interface ModuleInfo {
  name: string;
  size: number; // size in KB
}

const moduleData: ModuleInfo[] = [
  { name: 'SmallLib1', size: 2 },
  { name: 'SmallLib2', size: 1 },
  { name: 'AppShell', size: 300 },
  { name: 'SmallLib3', size: 3 },
  { name: 'AnotherFeature', size: 120 },
];

Output: A visualization where 'AppShell' dominates, followed by 'AnotherFeature'. The smaller libraries might be grouped or appear as very thin bars, depending on the chosen visualization method. If a filter for modules smaller than 5 KB is applied, 'SmallLib1', 'SmallLib2', and 'SmallLib3' might be hidden.

Constraints

• The input moduleData will be an array of objects conforming to the ModuleInfo interface.
• The size property will be a non-negative number representing kilobytes.
• The component should be implemented using Angular and TypeScript.
• You may use third-party charting libraries (e.g., Chart.js, D3.js, ngx-charts) if you find them helpful, but the core logic for processing and preparing data should be your own.
• Aim for a visually appealing and performant solution, especially when dealing with a large number of modules (e.g., >100).

Notes

• Consider how you will map the module data to visual elements (e.g., bar height, area size).
• Think about the most effective way to display hierarchical data if your bundle analysis tool provides it (e.g., nested modules).
• This challenge is about building the visualizer component itself. You do not need to implement a full-fledged Webpack or Rollup bundle analysis tool. Assume you are receiving the processed data.
• The goal is to make complex bundle size information accessible to developers. Focus on clarity and usability.