Angular Diagnostic Messaging System

This challenge focuses on building a robust and flexible diagnostic messaging system within an Angular application. Effective diagnostic messaging is crucial for debugging, monitoring application health, and providing informative feedback to developers during development and potentially to users in controlled scenarios. You'll create a service that allows components to log messages with varying severity levels, and a component to display these messages.

Problem Description

You need to create an Angular service called DiagnosticService and a component called DiagnosticDisplayComponent. The DiagnosticService should provide methods for logging diagnostic messages with different severity levels: Info, Warning, Error, and Critical. Each message should include a timestamp and a severity level. The DiagnosticDisplayComponent should subscribe to a stream of diagnostic messages from the DiagnosticService and display them in a user-friendly format.

Key Requirements:

• DiagnosticService:
  • Should have methods for logging messages with each severity level (logInfo, logWarning, logError, logCritical).
  • Each logging method should accept a message string.
  • The service should maintain an internal array (or similar data structure) to store all logged messages.
  • The service should expose an Observable<DiagnosticMessage> that emits all logged messages in real-time.
• DiagnosticDisplayComponent:
  • Should inject the DiagnosticService.
  • Should subscribe to the DiagnosticService's observable.
  • Should display the messages in a list, with each message showing the timestamp, severity level, and message content.
  • The display should update dynamically as new messages are logged.
• DiagnosticMessage Interface: Define an interface DiagnosticMessage with properties for timestamp (Date), severity (string - "Info", "Warning", "Error", "Critical"), and message (string).

Expected Behavior:

When a component calls diagnosticService.logInfo("Application started"), a message with the "Info" severity level, a timestamp, and the message content should be added to the internal store and emitted through the observable. The DiagnosticDisplayComponent should then update its display to show this new message. This should happen for all severity levels.

Edge Cases to Consider:

• What happens if the DiagnosticDisplayComponent is initialized after messages have already been logged? It should display all existing messages.
• Consider how to handle a large number of messages. While not required to implement pagination, be mindful of potential performance implications if the message history grows very large.
• Error handling: What happens if the observable stream encounters an error? (Not required to implement specific error handling, but consider it).

Examples

Example 1:

Input: Component A calls diagnosticService.logInfo("User logged in"); Component B calls diagnosticService.logError("Database connection failed");
Output: DiagnosticDisplayComponent shows two messages: one with timestamp and "Info" severity, and one with timestamp and "Error" severity.
Explanation: The DiagnosticService stores the messages and emits them through the observable, which the DiagnosticDisplayComponent displays.

Example 2:

Input: DiagnosticDisplayComponent is initialized after diagnosticService.logWarning("Low memory") has been called.
Output: DiagnosticDisplayComponent shows a message with timestamp and "Warning" severity.
Explanation: The DiagnosticDisplayComponent subscribes to the observable and receives all existing messages.

Example 3: (Complex Scenario)

Input: Multiple components log messages of different severities concurrently.
Output: DiagnosticDisplayComponent displays all messages in the order they were logged, with accurate timestamps.
Explanation: The observable ensures that messages are emitted and displayed in the correct order, regardless of when they were logged.

Constraints

• The solution must be written in TypeScript and adhere to Angular best practices.
• The DiagnosticService should not store messages indefinitely. Limit the stored message history to a maximum of 100 messages. Older messages should be discarded when the limit is reached.
• The timestamp should be accurate to within 1 second.
• The solution should be reasonably performant, even with a moderate number of messages being logged.

Notes

• Consider using RxJS operators to manage the observable stream (e.g., filter, map, scan).
• Think about how to make the DiagnosticService extensible to support custom severity levels in the future.
• Focus on clear, readable code and proper Angular component structure.
• You don't need to create a full-fledged Angular application; just the DiagnosticService and DiagnosticDisplayComponent are required. You can use a simple template for the display component.