chore: added kakfa analytics

[SagarRajput-7]

Summary

MQ Kafka: Partition Latency view	opened and if data rendered
MQ Kafka: Partition Latency - details	active tab(producer or consumer ), data rendered, config (topic and partition)
MQ Kafka: Producer Latency view	opened and if data rendered, active tab (producer or consumer)
MQ Kafka: Producer Latency - details	source- (producer or consumer parent table), active tab(producer or consumer ), data rendered, config (topic and service)
MQ Kafka: Drop Rate view	opened and if data rendered
MQ Kafka: Drop Rate - traceid navigation	traceid, filters used to navigate
MQ Kafka: Metric view	visited and graphs rendered

Related Issues / PR's

Screenshots

NA

Affected Areas and Manually Tested Areas

---

Important

Add Kafka analytics logging for data rendering and navigation in messaging queue details and metric pages.

• Logging:
  • Add logEvent calls in DropRateView.tsx for trace ID navigation and data rendering.
  • Add logEvent calls in MQTables.tsx for data rendering in both overview and detail views.
  • Add logEvent in MetricPage.tsx to log when the first graph is rendered.
• Components:
  • Update MetricPageGridGraph to accept checkIfDataExists prop for logging data availability.
  • Update MetricColumnGraphs and CollapsibleMetricSection to pass checkIfDataExists to child components.
• Misc:
  • Add option prop to MessagingQueueOverview.tsx and MQTables.tsx for producer latency options.

^{This description was created by for 92eaa59. It will automatically update as commits are pushed.}

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 92eaa59 in 2 minutes and 41 seconds

More details

• Looked at 324 lines of code in 6 files
• Skipped 0 files when reviewing.
• Skipped posting 7 drafted comments based on config settings.

1. frontend/src/pages/MessagingQueues/MQDetails/DropRateView/DropRateView.tsx:236

• Draft comment:
  Avoid JSON.stringify(tableData) in useEffect dependency. This may impact performance if the table data is large.
• Reason this comment was not posted:
  Marked as duplicate.

2. frontend/src/pages/MessagingQueues/MQDetails/MQTables/MQTables.tsx:271

• Draft comment:
  Using JSON.stringify(tableData) as a dependency may cause unnecessary re-renders. Consider a more efficient comparison if possible.
• Reason this comment was not posted:
  Marked as duplicate.

3. frontend/src/pages/MessagingQueues/MQDetails/MQTables/MQTables.tsx:285

• Draft comment:
  Same as before: avoid using JSON.stringify(tableData) in dependency arrays to prevent redundant effect triggers.
• Reason this comment was not posted:
  Marked as duplicate.

4. frontend/src/pages/MessagingQueues/MQDetails/DropRateView/DropRateView.tsx:237

• Draft comment:
  Consider memoizing the JSON.stringify output of tableData (used here and in the dependency array) to avoid repeated computation on every render. This is especially useful if tableData grows large.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

5. frontend/src/pages/MessagingQueues/MQDetails/DropRateView/DropRateView.tsx:95

• Draft comment:
  For security, consider adding 'noopener noreferrer' when using window.open to mitigate reverse tabnabbing risks.
• Reason this comment was not posted:
  Comment was on unchanged code.

6. frontend/src/pages/MessagingQueues/MQDetails/MQTables/MQTables.tsx:271

• Draft comment:
  Consider memoizing the JSON.stringify(tableData) result used in the dependency arrays of the useEffect hooks to reduce unnecessary recalculations, especially with larger datasets.
• Reason this comment was not posted:
  Marked as duplicate.

7. frontend/src/pages/MessagingQueues/MQDetails/MetricPage/MetricPage.tsx:128

• Draft comment:
  In the checkIfDataExists callback, ensure that the state update (renderedGraphCount) and the logEvent trigger handle potential concurrent renders safely. Consider using a functional state update if simultaneous graph renders are possible.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
  While technically correct that functional updates are safer for concurrent updates, in this case it's not critical because: 1) The count is only used for logging the first render 2) We have hasLoggedRef as a safety net 3) Even if we miss counting some graphs due to race conditions, it doesn't affect functionality 4) The graphs likely don't render so quickly that race conditions would be an issue
  I might be underestimating the possibility of many graphs rendering simultaneously. Also, using non-functional updates is generally considered a React anti-pattern.
  Even if many graphs render simultaneously, the worst case is we might log slightly later than the first actual render, which is not a critical issue. The current code is simple and works for its purpose.
  The comment, while technically correct, suggests an optimization that isn't critical for this use case. The current implementation is good enough for its purpose.

Workflow ID: wflow_g83i9rkpZKkutN5N

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.