Detecting and Preventing Memory Leaks in Angular Applications

Angular applications, especially complex ones, can be prone to memory leaks if not carefully managed. This challenge focuses on implementing a basic memory leak detection mechanism within an Angular component to identify and potentially mitigate common leak sources like un-subscribed Observables and lingering event listeners. Successfully completing this challenge will improve your understanding of Angular's lifecycle and best practices for memory management.

Problem Description

You are tasked with creating an Angular component that demonstrates a simple memory leak scenario and then implements a mechanism to detect and prevent it. The leak will be simulated by subscribing to an Observable within the component's ngOnInit lifecycle hook and failing to unsubscribe in the ngOnDestroy hook. Your solution should:

1. Simulate a Memory Leak: Create a component that subscribes to a simple Observable (e.g., an Observable emitting numbers every second) in its ngOnInit lifecycle hook. Do not unsubscribe from this Observable in the ngOnDestroy hook.
2. Implement a Leak Detection Mechanism: Introduce a mechanism (e.g., using console.log or a more sophisticated monitoring tool) to detect if the subscription is still active when the component is destroyed. This detection should occur within the ngOnDestroy hook.
3. Prevent the Leak: Modify the component to correctly unsubscribe from the Observable in the ngOnDestroy hook, thereby preventing the memory leak.
4. Provide Clear Output: The component should log messages to the console indicating:
   • When the component is initialized (subscription created).
   • When the component is destroyed (leak detection and, after correction, successful unsubscription).

Examples

Example 1:

Input: A simple Angular component with a leaky Observable subscription.
Output:
- "Component initialized - Subscription created" (on component initialization)
- "Component destroyed - Leak detected!" (on component destruction, before fix)
- "Component destroyed - Subscription unsubscribed" (on component destruction, after fix)
Explanation: The initial component setup creates a subscription that isn't cleaned up, leading to a leak. The leak detection mechanism identifies this.  After implementing the unsubscribe in `ngOnDestroy`, the leak is prevented.

Example 2:

Input: An Angular component with a correctly unsubscribed Observable.
Output:
- "Component initialized - Subscription created" (on component initialization)
- "Component destroyed - Subscription unsubscribed" (on component destruction)
Explanation: This demonstrates the expected behavior when the subscription is properly managed, preventing any leak detection messages.

Constraints

• The solution must be written in TypeScript.
• The Observable used for demonstration can be a simple interval Observable from RxJS.
• The leak detection mechanism should be implemented within the component itself (no external libraries are required for the detection, though you can use RxJS).
• The component should be a functional component.
• The solution should be easily understandable and maintainable.
• The component should not have any other dependencies beyond Angular and RxJS.

Notes

• Consider using takeUntil operator to automatically unsubscribe when the component is destroyed. This is a common and recommended pattern.
• The primary goal is to demonstrate the concept of leak detection and prevention, not to create a production-ready memory leak monitoring system.
• Focus on the lifecycle hooks (ngOnInit, ngOnDestroy) and the importance of unsubscribing from Observables.
• Think about how you can reliably determine if a subscription is still active within the ngOnDestroy hook. The takeUntil operator can simplify this.
• Use console.log statements strategically to provide clear feedback on the component's lifecycle and the status of the subscription.