Add history graph to node specific page #254
Conversation
WalkthroughThe pull request introduces enhancements to the OrcanodeMonitor application, focusing on improving event data handling and visualization. Changes span multiple files including Changes
Sequence DiagramsequenceDiagram
participant User
participant NodeEventsPage
participant EventDataService
participant ChartJS
User->>NodeEventsPage: Select Time Range
NodeEventsPage->>EventDataService: Fetch Events
EventDataService-->>NodeEventsPage: Return Event Data
NodeEventsPage->>ChartJS: Prepare Chart Data
ChartJS->>NodeEventsPage: Render Uptime Graph
Assessment against linked issues
Possibly related PRs
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Signed-off-by: Dave Thaler <[email protected]>
Signed-off-by: Dave Thaler <[email protected]>
Signed-off-by: Dave Thaler <[email protected]>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
OrcanodeMonitor/Pages/SpectralDensity.cshtml.cs (1)
Line range hint
116-117: Consider standardizing the datetime format and caching.A few suggestions for improvement:
- Use a standardized date format to ensure consistency across different system cultures.
- Consider caching the last modified date to avoid repeated HTTP requests.
Here's a suggested implementation:
- DateTime? lastModified = await Fetcher.GetLastModifiedAsync(uri); - LastModified = lastModified?.ToLocalTime().ToString() ?? "Unknown"; + DateTime? lastModified = await Fetcher.GetLastModifiedAsync(uri); + LastModified = lastModified?.ToLocalTime().ToString("yyyy-MM-dd HH:mm:ss") ?? "Unknown";Also, consider adding caching if this page is frequently accessed:
private static readonly MemoryCache _lastModifiedCache = new(new MemoryCacheOptions()); private static readonly TimeSpan _cacheDuration = TimeSpan.FromMinutes(5); // In UpdateEventFrequencyDataAsync: var cacheKey = uri.ToString(); if (!_lastModifiedCache.TryGetValue(cacheKey, out string cachedDate)) { DateTime? lastModified = await Fetcher.GetLastModifiedAsync(uri); cachedDate = lastModified?.ToLocalTime().ToString("yyyy-MM-dd HH:mm:ss") ?? "Unknown"; _lastModifiedCache.Set(cacheKey, cachedDate, _cacheDuration); } LastModified = cachedDate;OrcanodeMonitor/Pages/NodeEvents.cshtml.cs (1)
119-139: Consider refactoring to reduce code duplication in 'FetchEvents'The
FetchEventsmethod processes events for Dataplicity, Hydrophone Stream, and Mezmo in a similar manner. Refactoring this logic into a reusable method or loop could enhance maintainability and reduce repetition.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
OrcanodeMonitor/Models/OrcanodeEvent.cs(1 hunks)OrcanodeMonitor/Pages/NodeEvents.cshtml(5 hunks)OrcanodeMonitor/Pages/NodeEvents.cshtml.cs(4 hunks)OrcanodeMonitor/Pages/SpectralDensity.cshtml.cs(1 hunks)
🔇 Additional comments (16)
OrcanodeMonitor/Pages/SpectralDensity.cshtml.cs (1)
48-48: LGTM! Property initialization is well-placed.The initialization of
LastModifiedfollows the class's established pattern and uses appropriate access modifiers.OrcanodeMonitor/Pages/NodeEvents.cshtml.cs (8)
19-30: New properties and backing fields are well-definedThe addition of
Labels,DataplicityStatus,MezmoStatus, andHydrophoneStreamStatusproperties with their private backing fields is correctly implemented, enhancing the data handling for the charting functionality.
38-47: Ensure all 'timeRange' values are handled in 'GetUptimePercentage'The method initializes
sinceTimetoDateTime.MinValueand sets it for "pastWeek" and "pastMonth". For othertimeRangevalues,sinceTimeremainsDateTime.MinValue, effectively considering all events. Verify that this behavior aligns with the intended functionality for time ranges like "all" or unexpected values.
63-70: Constructor initialization is thorough and consistentInitializing the lists and JSON data properties in the constructor ensures that all collections are ready for use, preventing potential
NullReferenceExceptionoccurrences.
72-86: Status mapping in 'StatusStringToInt' is comprehensiveThe
StatusStringToIntmethod accurately maps status strings to integer values, covering all expected statuses and ensuring consistent data for chart visualization.
88-91: JSON data properties are appropriately declaredThe properties
JsonDataplicityData,JsonMezmoData, andJsonHydrophoneStreamDataare correctly added to store serialized event data for use in the frontend chart.
92-114: 'AddCurrentEvent' method effectively updates event listsThe method correctly appends the current event and inserts an original event if necessary, maintaining the integrity of the event timeline for accurate chart representation.
142-145: Confirm that synchronizing 'OnGet' method does not affect performanceChanging
OnGetAsyncto a synchronousOnGetmethod simplifies the code. Ensure that none of the called methods are inherently asynchronous and that this change does not negatively impact the page's load time or responsiveness.
161-170: Verify time range classification logic in 'GetTimeRangeClass'The method assigns both "pastWeek" and "pastMonth" classes to recent events. Confirm that overlapping classes are intended and that the frontend uses them correctly for filtering and displaying events.
OrcanodeMonitor/Models/OrcanodeEvent.cs (1)
84-91: Renamed parameter enhances clarity in 'OrcanodeEvent' constructorChanging the parameter name from
timestamptotimestampUtcimproves readability and emphasizes that the timestamp should be in UTC. Ensure all constructor calls pass UTC times to prevent potential time zone issues.OrcanodeMonitor/Pages/NodeEvents.cshtml (6)
17-20: Chart.js integration is correctly implementedIncluding Chart.js and its date adapter via CDN links sets up the necessary environment for chart rendering.
21-118: JavaScript code effectively initializes the uptime chartThe chart configuration correctly maps the data, sets up the time-based x-axis and customizes the y-axis labels. This provides a clear visualization of the node's uptime statuses over time.
130-133: Uptime percentages for 'all' time range are properly addedThe new spans for the "all" time range align with the existing uptime display logic, ensuring consistency across different time ranges.
142-142: 'All' time range filter button enhances user optionsAdding the "All" button allows users to view events from the entire available dataset, improving the page's usability.
201-202: Initial filter update ensures correct default displayCalling
updateFilter('default', 'default');on page load sets up the initial state of filters, ensuring the page displays the correct data when first accessed.
245-245: Filter logic accommodates 'all' time range correctlyThe update to the filtering condition in
filterTable()properly handles the new "all" option, ensuring that all events are displayed when selected.
Fixes #248
Summary by CodeRabbit
New Features
Bug Fixes
Refactor