Managing Component Lifecycle: Implementing ngOnDestroy in Angular

Angular components have a lifecycle, and understanding how to manage this lifecycle is crucial for building robust and efficient applications. The ngOnDestroy lifecycle hook is called just before a component is destroyed, providing an opportunity to clean up resources like subscriptions, timers, and event listeners to prevent memory leaks and unexpected behavior. This challenge asks you to implement ngOnDestroy in a simple Angular component to unsubscribe from an observable.

Problem Description

You are tasked with creating a simple Angular component called DataDisplayComponent that subscribes to an observable emitting random numbers. The component displays the latest emitted number. When the component is destroyed (e.g., when navigating away from the page), you need to unsubscribe from the observable within the ngOnDestroy lifecycle hook to prevent memory leaks. Failure to unsubscribe can lead to the observable continuing to emit values even after the component is gone, potentially causing errors or performance issues.

What needs to be achieved:

Create an Angular component (DataDisplayComponent).
The component should subscribe to a predefined observable (randomNumber$) that emits random numbers between 1 and 100.
The component should display the latest emitted number in its template.
Implement the ngOnDestroy lifecycle hook to unsubscribe from the randomNumber$ observable.

Key Requirements:

The component must correctly display the latest random number.
The component must unsubscribe from the observable in ngOnDestroy.
The code should be clean, readable, and follow Angular best practices.

Expected Behavior:

When the component is initialized, it should immediately subscribe to randomNumber$.
The component's template should display the first emitted random number.
As randomNumber$ emits new values, the component's template should update accordingly.
When the component is destroyed, the ngOnDestroy hook should be called, and the subscription to randomNumber$ should be unsubscribed. After destruction, the observable should no longer affect the component.

Edge Cases to Consider:

Ensure the subscription is properly unsubscribed even if the component is destroyed before any values are emitted.
Consider how to handle potential errors during subscription or unsubscription (though error handling is not explicitly required for this challenge).

Examples

Example 1:

Input: Component initialized, randomNumber$ emits 50, then 75, then the component is destroyed.
Output: The component initially displays "50", then updates to "75", and then is destroyed without further updates.
Explanation: The component subscribes, displays the first value, updates with the second, and then unsubscribes upon destruction.

Example 2:

Input: Component initialized and immediately destroyed (e.g., through conditional rendering).
Output: The component is destroyed before any values are emitted from randomNumber$.
Explanation: The component attempts to subscribe, but is destroyed before the subscription completes, and the ngOnDestroy hook is still called to ensure proper cleanup.

Constraints

The randomNumber$ observable is predefined and provided. You should not create it.
The component should be a functional component.
The component should only display the latest emitted number.
The component should not perform any other actions besides displaying the number and unsubscribing.
The component should be written in TypeScript.

Notes

Remember that ngOnDestroy is called after Angular has performed its final destruction tasks.
Use the takeUntil operator on the observable to simplify the unsubscription process. This is a common and recommended pattern in Angular.
Focus on the core requirement of unsubscribing from the observable in ngOnDestroy. Error handling and more complex UI logic are not required for this challenge.
The randomNumber$ observable will be provided as a simple Subject emitting random numbers. You don't need to implement the observable itself.