fix(Traces Explorer): prevent duplicate API calls to query_range in traces explorer

[ahmadshaheer]

Summary

• Memoize the query key to ensure that we don't have multiple query keys.
• Make API call only when the time range state is not loading (while the time range state is being updated).
• Added a check in the Filter component to avoid redundant redirection when the current query matches the prepared query.
• set location.pathname as the initial value for currentPathnameRef, absense of this causes stagedQuery && location.pathname !== currentPathnameRef.current to be truthy (since currentPathnameRef.current is null), and therefore causes duplicate triggering of initQueryBuilderData(compositeQueryParam); in the useEffect of line ~784

  if (!isValid) {
      redirectWithQueryBuilderData(validData);
  } else {
      initQueryBuilderData(compositeQueryParam);
  }

Related Issues / PR's

close #6308

Previous PR: #6640

Screenshots

Before:

2024-12-16.09-15-35.mov

After:

2024-12-16.09-19-47.mov

Affected Areas and Manually Tested Areas

---

Important

Prevent duplicate API calls in Traces Explorer by memoizing query keys and adding conditional checks in index.tsx, Filter.tsx, and QueryBuilder.tsx.

• Behavior:
  • Memoize queryKey in index.tsx to prevent duplicate API calls in Traces Explorer.
  • API call in useGetQueryRange in index.tsx is now conditional on !timeRangeUpdateLoading.
  • In Filter.tsx, added check to prevent redundant redirection if currentQuery matches preparedQuery.
• State Management:
  • Initialize currentPathnameRef in QueryBuilder.tsx to prevent duplicate initQueryBuilderData calls.
• Misc:
  • Minor refactoring in index.tsx and QueryBuilder.tsx for better readability and performance.

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

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 9e1aa02 in 1 minute and 22 seconds

More details

• Looked at 181 lines of code in 3 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. frontend/src/container/TracesExplorer/ListView/index.tsx:80

• Draft comment:
  The useMemo hook has a redundant second array of dependencies. Remove the second array to avoid confusion and potential errors.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The comment is incorrect. In useMemo, the first array is the value being memoized, and the second array is the dependencies that determine when to recompute that value. This is the standard and correct way to use useMemo. Removing the second array would break the memoization functionality.
  Could there be a performance optimization opportunity by reordering the dependencies to match the order of usage? Could there be unnecessary dependencies?
  While the order of dependencies could potentially be cleaned up, the current implementation is functionally correct and follows React's useMemo pattern. The dependencies listed are all necessary as they are used in the memoized value.
  The comment should be deleted as it is incorrect - the second array is a required part of useMemo's API and is being used correctly here.

2. frontend/src/providers/QueryBuilder.tsx:836

• Draft comment:
  The useEffect hook is missing 'currentQuery' as a dependency. Add it to ensure the effect runs correctly when 'currentQuery' changes.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The effect only uses location.pathname to track navigation changes and reset some state when navigation occurs. currentQuery is not referenced in the effect body at all, so adding it as a dependency would be incorrect and could cause unnecessary re-runs of the effect. The current dependency array correctly lists only the values used in the effect.
  Could I be missing some subtle reason why currentQuery should be tracked? Perhaps there's some edge case where currentQuery changes would need to trigger this navigation reset logic?
  No - this effect's sole purpose is to track navigation changes via pathname and reset state when navigation occurs. currentQuery changes should not trigger this navigation-specific logic. The current dependencies are correct.
  The comment suggesting to add currentQuery as a dependency is incorrect and should be deleted. The current dependency array correctly includes only location.pathname which is the only value used in the effect.

Workflow ID: wflow_yRJjx5FIKCBR4uKM

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[vikrantgupta25]

Remove the debuggers, rest looks good !

[ellipsis-dev]

👍 Looks good to me! Incremental review on 753824b in 25 seconds

More details

• Looked at 38 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. frontend/src/providers/QueryBuilder.tsx:99

• Draft comment:
  Good use of useRef to track currentPathnameRef and prevent unnecessary re-renders and duplicate API calls.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The use of useRef for currentPathnameRef is appropriate for tracking the pathname without causing re-renders. The initialization with location.pathname is crucial to prevent unnecessary re-renders and duplicate API calls, as described in the PR.

2. frontend/src/providers/QueryBuilder.tsx:95

• Draft comment:
  Avoid using the component/index.tsx file structure approach, as it makes it difficult to debug and find components using global search tools like VS Code.
• Reason this comment was not posted:
  Comment was on unchanged code.

Workflow ID: wflow_Fltwb9UNaRRWpkOr

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.