Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new-log-viewer: Add log query support in StateContextProvider. #80

Merged
merged 29 commits into from
Oct 19, 2024

Conversation

Henry8192
Copy link
Collaborator

@Henry8192 Henry8192 commented Sep 27, 2024

References

new-log-viewer series: #45 #46 #48 #51 #52 #53 #54 #55 #56 #59 #60 #61 #62 #63 #66 #67 #68 #69 #70 #71 #72 #73 #74 #76 #77 #78 #79

Description

Add queryLogs in stateContextProvider.tsx, which posts a worker request code QUERY_LOG.

In MainWorker.ts, QUERY_LOG triggers .startQuery() of LOG_FILE_MANAGER. startQuery then initializes the searchString using regex, and calls #searchChunk.

searchChunk searches logs by SEARCH_CHUNK_SIZE, and sends results with chunkResultsHandler, which posts a worker respond code CHUNK_RESULT.

Validation performed

Click the search button, which triggers a query for keyword "scheduled". Observe the results printed out in console matches with original logs.

Summary by CodeRabbit

Summary by CodeRabbit

  • New Features

    • Introduced a log query functionality in the MenuBar for easier access.
    • Enhanced log management capabilities with new methods for structured log queries.
    • Improved log processing with updated handling for query results.
    • Added new icons and buttons for a more intuitive user interface.
    • Implemented a constant for query chunk size to optimize log queries.
    • Added a utility function to defer execution of callback functions for better asynchronous handling.
  • Bug Fixes

    • Adjusted context management to ensure proper functionality of log queries.
  • Documentation

    • Updated typings to reflect new request and response codes related to log querying.

Copy link

coderabbitai bot commented Sep 27, 2024

Walkthrough

The pull request introduces enhancements to the log management system by adding a startQuery method in the StateContextType interface and modifying the MenuBar component to facilitate log querying. This method allows users to initiate log searches based on parameters like search string and case sensitivity. The MenuBar now includes an IconButton that triggers the querying functionality, thereby improving user interaction with log data.

Changes

File Path Change Summary
new-log-viewer/src/components/MenuBar/index.tsx Added SearchIcon import, updated context destructuring to include startQuery, defined handleQueryClick, and added an IconButton for initiating log queries.
new-log-viewer/src/contexts/StateContextProvider.tsx Introduced startQuery method in StateContextType, added queryResults state variable, and updated handleMainWorkerResp for new response code.
new-log-viewer/src/services/LogFileManager/index.ts Defined QUERY_CHUNK_SIZE, updated constructor to include onQueryResults, and introduced startQuery and #queryChunkAndScheduleNext methods for log searching.
new-log-viewer/src/services/MainWorker.ts Added onQueryResults function for handling query chunk results and a new case for WORKER_REQ_CODE.START_QUERY in the onmessage event handler.
new-log-viewer/src/typings/worker.ts Introduced START_QUERY in WORKER_REQ_CODE, added QueryResults and QueryResultsType, and updated WorkerReqMap and WorkerRespMap accordingly.
new-log-viewer/src/utils/config.ts Added a new constant QUERY_CHUNK_SIZE with a value of 10,000.
new-log-viewer/src/index.tsx Exported QUERY_CHUNK_SIZE from the ./utils/config module.
new-log-viewer/src/utils/time.ts Introduced a new utility function defer for deferring execution of a callback until the call stack is clear.

Possibly related PRs

Suggested reviewers

  • kirkrodrigues

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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@junhaoliao
Copy link
Collaborator

The design was discussed offline. Some key ideas:

  1. Instead of having a giant (time-consuming / blocking) while-loop to collect all results in the service worker, submit query tasks one-by-one (with setTimeout()) which will allow any requests from the render to be handled in between task executions.
  2. The render should aggregate all results on every receipt of chunk results.

Let's get those implemented and we can discuss further. I can help with the UI implementations once #74 is merged.

@Henry8192 Henry8192 marked this pull request as ready for review October 6, 2024 23:03
@Henry8192 Henry8192 changed the title WIP: Support log query new-log-viewer: Add log query feature Oct 6, 2024
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 12

🧹 Outside diff range and nitpick comments (4)
new-log-viewer/src/utils/time.ts (1)

1-4: Improve function documentation

The current documentation is incomplete. Consider enhancing it as follows:

  1. Add a description of the function's purpose and behaviour.
  2. Complete the @param tag with details about the callback parameter.
  3. Include a @returns tag to explicitly state that the function doesn't return a value.

Here's a suggested improvement:

/**
 * Defers the execution of a callback function to the next event loop cycle.
 * 
 * @param callback - The function to be executed in the next event loop cycle.
 * @returns {void}
 */
new-log-viewer/src/components/MenuBar/index.tsx (1)

35-35: LGTM: Search feature added to MenuBar

The changes to add the search feature to the MenuBar component look good:

  1. The queryLogs function is correctly added to the destructured context.
  2. The new search button is logically placed at the end of the menu bar.
  3. The onClick handler for the new button correctly uses the queryLogs function.
  4. The button uses the SmallIconButton component, maintaining consistency with other buttons in the menu bar.

Consider adding an aria-label to the new button to improve accessibility. For example:

 <SmallIconButton
     onClick={queryLogs}
+    aria-label="Search logs"
 >
     <SearchIcon/>
 </SmallIconButton>

Also applies to: 82-86

new-log-viewer/src/typings/worker.ts (1)

76-82: Consider exporting ChunkResultType for external use

While ChunkResults is exported, ChunkResultType might also need to be exported if it's used elsewhere in the application. This ensures that all necessary types are accessible where required.

You can modify the export statement as follows:

 export type {
     BeginLineNumToLogEventNumMap,
     ChunkResults,
+    ChunkResultType,
     CursorType,
     FileSrcType,
     MainWorkerReqMessage,
     MainWorkerRespMessage,
     WorkerReq,
     WorkerResp,
 };
new-log-viewer/src/services/MainWorker.ts (1)

46-48: Ensure non-blocking query processing and result aggregation

To improve responsiveness, consider processing query tasks non-blockingly by submitting them one-by-one using setTimeout() or a similar mechanism. This allows the renderer to handle incoming requests between task executions. Also, ensure that the rendering component aggregates all results upon receiving each chunk to keep the user interface updated.

Would you like assistance in refactoring the query implementation to align with these design recommendations?

Also applies to: 107-116

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between d185624 and 5bf7df1.

📒 Files selected for processing (6)
  • new-log-viewer/src/components/MenuBar/index.tsx (3 hunks)
  • new-log-viewer/src/contexts/StateContextProvider.tsx (6 hunks)
  • new-log-viewer/src/services/LogFileManager.ts (7 hunks)
  • new-log-viewer/src/services/MainWorker.ts (4 hunks)
  • new-log-viewer/src/typings/worker.ts (4 hunks)
  • new-log-viewer/src/utils/time.ts (1 hunks)
🧰 Additional context used
🪛 Biome
new-log-viewer/src/services/LogFileManager.ts

[error] 300-300: Change to an optional chain.

Unsafe fix: Change to an optional chain.

(lint/complexity/useOptionalChain)

🔇 Additional comments (10)
new-log-viewer/src/utils/time.ts (2)

5-7: Implementation looks good

The defer function is well-implemented:

  • It correctly uses setTimeout with a 0ms delay to defer execution.
  • The function name accurately describes its purpose.
  • The type annotation for the callback parameter is correct.

9-9: Export statement is correct

The defer function is properly exported, allowing it to be imported and used in other modules.

new-log-viewer/src/components/MenuBar/index.tsx (2)

15-15: LGTM: New import for SearchIcon

The import for SearchIcon is correctly placed and necessary for the new search feature being added to the MenuBar component.


35-35: Verify implementation of suggested query optimizations

The changes in this file align with the PR objectives by adding the search feature to the MenuBar. However, to ensure full compliance with the suggestions made by junhaoliao in the PR comments, we should verify the implementation of:

  1. The task submission strategy using setTimeout() instead of a blocking while-loop.
  2. The result aggregation in the rendering component.

To verify these implementations, we need to check the queryLogs function and the component that handles the search results. Run the following script to locate these implementations:

Please review the results of this script to ensure that the suggested optimizations have been implemented.

Also applies to: 82-86

new-log-viewer/src/typings/worker.ts (2)

44-44: Proper addition of QUERY_LOG to request codes

The QUERY_LOG entry is correctly added to the WORKER_REQ_CODE enum, maintaining alignment with existing naming conventions and structure.


51-52: Correct inclusion of PAGE_DATA and CHUNK_RESULT in response codes

The new response codes PAGE_DATA and CHUNK_RESULT are appropriately added to the WORKER_RESP_CODE enum, ensuring consistent communication protocols.

new-log-viewer/src/services/MainWorker.ts (2)

46-48: Function chunkResultsHandler is correctly implemented

The chunkResultsHandler function properly posts the chunk results to the renderer. The implementation aligns with the expected behaviour.


81-82: Verify that LogFileManager.create accepts chunkResultsHandler

Ensure that the LogFileManager.create method is updated to accept chunkResultsHandler as the fourth parameter. This is important to avoid runtime errors if the method signature does not match.

Run the following script to confirm the method signature:

new-log-viewer/src/services/LogFileManager.ts (1)

260-279: Efficient implementation of asynchronous log search

Good work implementing startQuery and using asynchronous chunk processing with defer in #searchChunk. This aligns with the task submission strategy suggested to enhance responsiveness and allows the rendering process to handle incoming requests between tasks.

new-log-viewer/src/contexts/StateContextProvider.tsx (1)

365-365: Ensure queryLogs is properly passed to context consumers

Adding queryLogs to the StateContext.Provider value allows context consumers to access this method. Ensure that components consuming this context are updated to utilize the queryLogs function as needed.

new-log-viewer/src/typings/worker.ts Outdated Show resolved Hide resolved
new-log-viewer/src/typings/worker.ts Outdated Show resolved Hide resolved
new-log-viewer/src/services/MainWorker.ts Outdated Show resolved Hide resolved
new-log-viewer/src/services/MainWorker.ts Outdated Show resolved Hide resolved
new-log-viewer/src/services/LogFileManager.ts Outdated Show resolved Hide resolved
new-log-viewer/src/contexts/StateContextProvider.tsx Outdated Show resolved Hide resolved
new-log-viewer/src/contexts/StateContextProvider.tsx Outdated Show resolved Hide resolved
new-log-viewer/src/contexts/StateContextProvider.tsx Outdated Show resolved Hide resolved
new-log-viewer/src/contexts/StateContextProvider.tsx Outdated Show resolved Hide resolved
new-log-viewer/src/contexts/StateContextProvider.tsx Outdated Show resolved Hide resolved
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (1)
new-log-viewer/src/services/LogFileManager.ts (1)

Line range hint 58-88: LGTM: New fields and constructor updates

The new private fields and constructor updates are well-aligned with the new query functionality. However, there's a minor optimization opportunity:

Consider removing the initial value of #numEvents:

- readonly #numEvents: number = 0;
+ readonly #numEvents: number;

This field is set in the constructor, so the initial value of 0 is unnecessary.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 5bf7df1 and 9a3cca9.

📒 Files selected for processing (3)
  • new-log-viewer/src/services/LogFileManager.ts (7 hunks)
  • new-log-viewer/src/services/MainWorker.ts (4 hunks)
  • new-log-viewer/src/typings/worker.ts (4 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • new-log-viewer/src/services/MainWorker.ts
  • new-log-viewer/src/typings/worker.ts
🧰 Additional context used
🔇 Additional comments (4)
new-log-viewer/src/services/LogFileManager.ts (4)

11-19: LGTM: New imports added for query functionality

The new imports for ChunkResults and defer are appropriate for the added query functionality.


115-127: LGTM: Updated create method

The create method has been appropriately updated to include the chunkResultsHandler parameter, maintaining consistency with the constructor changes.


171-173: LGTM: New incrementQueryId method

The incrementQueryId method is a straightforward and effective way to manage query IDs.


252-322: LGTM: New query functionality implementation

The new startQuery and #searchChunk methods effectively implement the log querying functionality as discussed in the PR comments. The use of defer in #searchChunk ensures non-blocking execution, allowing for better responsiveness.

new-log-viewer/src/services/LogFileManager.ts Outdated Show resolved Hide resolved
new-log-viewer/src/services/LogFileManager.ts Outdated Show resolved Hide resolved
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (2)
new-log-viewer/src/components/MenuBar/index.tsx (1)

86-90: Enhance user feedback and accessibility for the search button

The search button is correctly implemented, but could benefit from some enhancements:

  1. Add a tooltip to explain the button's function.
  2. Include an aria-label for better accessibility.
  3. Consider adding visual feedback when a search is in progress.

Here's a suggested improvement:

<SmallIconButton
  onClick={handleSearchButtonClick}
  title="Search Logs"
  aria-label="Search Logs"
  disabled={isLoading}
>
  {isLoading ? <CircularProgress size={24} /> : <SearchIcon />}
</SmallIconButton>

This change adds a tooltip, improves accessibility, and provides visual feedback during the search process.

new-log-viewer/src/contexts/StateContextProvider.tsx (1)

218-222: Simplify object property assignment using shorthand notation

In the queryLogs function, you can use the object property shorthand to make the code more concise since the property names and variables are the same.

Apply this diff to simplify the code:

workerPostReq(mainWorkerRef.current, WORKER_REQ_CODE.QUERY_LOG, {
-    searchString: searchString,
-    isRegex: isRegex,
-    isCaseSensitive: isCaseSensitive,
+    searchString,
+    isRegex,
+    isCaseSensitive,
});
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 9a3cca9 and 8aa0c14.

📒 Files selected for processing (2)
  • new-log-viewer/src/components/MenuBar/index.tsx (3 hunks)
  • new-log-viewer/src/contexts/StateContextProvider.tsx (7 hunks)
🧰 Additional context used
🔇 Additional comments (3)
new-log-viewer/src/components/MenuBar/index.tsx (2)

15-15: LGTM: SearchIcon import added correctly

The import of SearchIcon is properly placed with other icon imports and is used in the component.


Line range hint 1-101: Overall assessment: Good implementation with room for improvement

The changes successfully implement the log query feature as described in the PR objectives. The code is well-structured and consistent with the existing codebase. However, there are opportunities to enhance the user experience and flexibility of the search feature:

  1. Parameterize the search function to allow for more dynamic queries.
  2. Improve error handling and user feedback during the search process.
  3. Enhance accessibility and provide more context for the search button.

These improvements would make the feature more robust and user-friendly.

new-log-viewer/src/contexts/StateContextProvider.tsx (1)

208-223: queryLogs function implementation looks good

The queryLogs function is correctly implemented using useCallback and appropriately sends the request to the worker with the provided parameters.

new-log-viewer/src/components/MenuBar/index.tsx Outdated Show resolved Hide resolved
new-log-viewer/src/contexts/StateContextProvider.tsx Outdated Show resolved Hide resolved
Copy link
Collaborator

@junhaoliao junhaoliao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's one issue with the query id assignment otherwise everything else lgtm with some minor suggestions about docs.

Co-authored-by: Junhao Liao <junhao@junhao.ca>
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (6)
new-log-viewer/src/utils/time.ts (1)

6-8: The implementation looks good. Consider adding a type check for robustness.

The defer function correctly uses setTimeout to defer the execution of the callback function. The implementation is concise and effective.

For added robustness, you might consider adding a type check to ensure callbackFn is a function:

 const defer = (callbackFn: () => void) => {
+    if (typeof callbackFn !== 'function') {
+        throw new TypeError('callbackFn must be a function');
+    }
     setTimeout(callbackFn, 0);
 };

This change would provide clearer error messages if defer is called with an invalid argument.

new-log-viewer/src/services/LogFileManager/index.ts (5)

15-24: LGTM! Good use of imports and constants.

The new imports and constants are well-organized and relevant to the added functionality. Using SEARCH_CHUNK_SIZE from a config file is a good practice for maintainability.

Consider adding a brief comment explaining the purpose of SEARCH_CHUNK_SIZE in the config file for better documentation.


Line range hint 46-125: LGTM! Constructor and create method updated correctly.

The changes to the constructor and create method are well-implemented and consistent with the new query functionality. The use of private fields and the callback pattern for query results is appropriate.

However, there's a minor documentation issue:

Please update the JSDoc for the constructor to include the @param for onQueryResults:

/**
 * Private constructor for LogFileManager. This is not intended to be invoked publicly.
 * Instead, use LogFileManager.create() to create a new instance of the class.
 *
 * @param params
 * @param params.decoder
 * @param params.fileName
 * @param params.onDiskFileSizeInBytes
 * @param params.pageSize Page size for setting up pagination.
 * @param params.onQueryResults Callback function to handle query results.
 */
🧰 Tools
🪛 GitHub Check: lint-check

[warning] 54-54:
Missing JSDoc @param "params.onQueryResults" declaration


[warning] 58-58:
Missing @param "params.onQueryResults"


279-305: LGTM! Well-implemented startQuery method.

The startQuery method is well-structured and handles different cases appropriately. The use of #queryId to manage ongoing searches is a good practice.

For improved readability, consider extracting the regex construction into a separate private method:

private constructSearchRegex(searchString: string, isRegex: boolean, isCaseSensitive: boolean): RegExp {
    const regexPattern = isRegex ?
        searchString :
        searchString.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
    const regexFlags = isCaseSensitive ? "" : "i";
    return new RegExp(regexPattern, regexFlags);
}

Then use it in startQuery:

const searchRegex = this.constructSearchRegex(searchString, isRegex, isCaseSensitive);

This change would make the startQuery method more concise and easier to understand.


307-355: LGTM! Well-implemented chunk-based search, but consider using setTimeout.

The #searchChunkAndScheduleNext method effectively implements chunk-based searching, which is great for handling large log files without blocking the main thread. The use of queryId to manage ongoing searches is a good practice.

However, consider replacing defer with setTimeout for scheduling the next chunk search. setTimeout is more widely supported and its behaviour is more predictable across different JavaScript environments:

if (endSearchIdx < this.#numEvents) {
    setTimeout(() => {
        this.#searchChunkAndScheduleNext(queryId, endSearchIdx, searchRegex);
    }, 0);
}

This change will maintain the same non-blocking behaviour while using a more standard JavaScript function.


54-54: Add missing JSDoc @param for onQueryResults.

To complete the documentation, please add the missing JSDoc @param for params.onQueryResults in the constructor:

/**
 * Private constructor for LogFileManager. This is not intended to be invoked publicly.
 * Instead, use LogFileManager.create() to create a new instance of the class.
 *
 * @param params
 * @param params.decoder
 * @param params.fileName
 * @param params.onDiskFileSizeInBytes
 * @param params.pageSize Page size for setting up pagination.
 * @param params.onQueryResults Callback function to handle query results.
 */

This will ensure that all parameters are properly documented, improving code maintainability.

🧰 Tools
🪛 GitHub Check: lint-check

[warning] 54-54:
Missing JSDoc @param "params.onQueryResults" declaration

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between b732607 and 45e5e61.

📒 Files selected for processing (3)
  • new-log-viewer/src/services/LogFileManager/index.ts (5 hunks)
  • new-log-viewer/src/services/MainWorker.ts (4 hunks)
  • new-log-viewer/src/utils/time.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • new-log-viewer/src/services/MainWorker.ts
🧰 Additional context used
📓 Learnings (1)
new-log-viewer/src/services/LogFileManager/index.ts (2)
Learnt from: Henry8192
PR: y-scope/yscope-log-viewer#80
File: new-log-viewer/src/services/LogFileManager/index.ts:305-321
Timestamp: 2024-10-10T20:26:31.573Z
Learning: When a function like `#searchChunkAndScheduleNext` requires significant improvements, it's preferred to rewrite the entire function rather than making incremental changes.
Learnt from: Henry8192
PR: y-scope/yscope-log-viewer#80
File: new-log-viewer/src/services/LogFileManager.ts:297-313
Timestamp: 2024-10-09T02:08:56.053Z
Learning: In the `#searchChunk` method of `LogFileManager.ts`, checking `typeof match.index === "number"` correctly handles matches at index 0, ensuring matches at the beginning of the string are not skipped.
🪛 GitHub Check: lint-check
new-log-viewer/src/services/LogFileManager/index.ts

[warning] 54-54:
Missing JSDoc @param "params.onQueryResults" declaration


[warning] 58-58:
Missing @param "params.onQueryResults"

🔇 Additional comments (1)
new-log-viewer/src/utils/time.ts (1)

1-5: LGTM! The documentation is clear and concise.

The JSDoc comment effectively describes the purpose of the defer function and its parameter. The parameter name callbackFn is consistent with the function signature, addressing a previous review comment.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (4)
new-log-viewer/src/services/LogFileManager/index.ts (3)

40-50: LGTM! Good additions for query functionality.

The changes to the class properties are well-aligned with the new query functionality. Making #fileName readonly is a good practice for immutability. The new properties #queryId and #onQueryResults are necessary for managing queries.

Consider using a more descriptive name for #queryId, such as #currentQueryId or #latestQueryId, to better convey its purpose.


280-306: LGTM! Well-implemented query initiation logic.

The startQuery method effectively implements the logic for starting a new query. It properly handles empty query strings and the case of no logs. The RegExp construction looks correct and accounts for both regex and non-regex queries.

Consider moving the this.#queryId++ increment to the beginning of the method to ensure it's always incremented, even for empty queries. This would prevent potential issues with query ID management.


308-356: LGTM! Well-implemented chunk querying logic, with room for improvements.

The #queryChunkAndScheduleNext method effectively implements the core logic for querying log chunks. It properly handles query cancellation and chunk size using the QUERY_CHUNK_SIZE constant.

Consider the following improvements:

  1. Add explicit error handling for the decodeRange call to handle potential decoding failures.
  2. Replace defer with setTimeout for better cross-browser compatibility.
  3. Simplify the nested ternary operator in the matchResult check for better readability.

Example for point 3:

if (null !== matchResult && "number" === typeof matchResult.index) {
    // Rest of the code
}
new-log-viewer/src/contexts/StateContextProvider.tsx (1)

303-318: LGTM! Consider clearing existing query results before starting a new query

The implementation of startQuery looks good and correctly handles the case where mainWorkerRef.current is null. However, it might be beneficial to clear any existing query results before starting a new query to ensure a clean slate for each search.

Consider adding the following line at the beginning of the function:

setQueryResults(new Map());

This will reset the query results before initiating a new search, preventing any potential confusion with results from previous queries.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 45e5e61 and 142275e.

📒 Files selected for processing (6)
  • new-log-viewer/src/contexts/StateContextProvider.tsx (6 hunks)
  • new-log-viewer/src/index.tsx (1 hunks)
  • new-log-viewer/src/services/LogFileManager/index.ts (5 hunks)
  • new-log-viewer/src/services/MainWorker.ts (4 hunks)
  • new-log-viewer/src/typings/worker.ts (4 hunks)
  • new-log-viewer/src/utils/config.ts (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
  • new-log-viewer/src/index.tsx
  • new-log-viewer/src/services/MainWorker.ts
  • new-log-viewer/src/typings/worker.ts
  • new-log-viewer/src/utils/config.ts
🧰 Additional context used
📓 Learnings (1)
new-log-viewer/src/services/LogFileManager/index.ts (1)
Learnt from: Henry8192
PR: y-scope/yscope-log-viewer#80
File: new-log-viewer/src/services/LogFileManager/index.ts:305-321
Timestamp: 2024-10-10T20:26:31.573Z
Learning: When a function like `#searchChunkAndScheduleNext` requires significant improvements, it's preferred to rewrite the entire function rather than making incremental changes.
🔇 Additional comments (6)
new-log-viewer/src/services/LogFileManager/index.ts (5)

15-22: LGTM! Good practice for importing configuration constants.

The addition of QueryResults and QUERY_CHUNK_SIZE imports is appropriate for the new query functionality. Importing QUERY_CHUNK_SIZE from a separate config file is a good practice for maintainability.


58-76: LGTM! Constructor updated correctly for query functionality.

The addition of the onQueryResults parameter to the constructor and its assignment to the class property is consistent with the new query functionality. The JSDoc comment is properly updated to include the new parameter.


107-126: LGTM! Create method updated correctly.

The create method has been properly updated to include the new onQueryResults parameter and pass it to the constructor. The JSDoc comment is also updated to reflect this change.


Line range hint 1-391: LGTM! Well-implemented query functionality with minor suggestions for improvement.

The changes introduce a robust query feature to the LogFileManager class while maintaining the existing structure. The implementation is solid overall, with clear separation of concerns and good use of TypeScript features.

Summary of suggestions:

  1. Consider renaming #queryId to #currentQueryId or #latestQueryId for clarity.
  2. Move the this.#queryId++ increment in startQuery to ensure it's always incremented.
  3. Improve error handling in #queryChunkAndScheduleNext for decodeRange.
  4. Replace defer with setTimeout for better cross-browser compatibility.
  5. Simplify the nested ternary operator in the matchResult check.

These minor improvements aside, the pull request looks good and ready to be merged after addressing the integration verification points mentioned earlier.


Line range hint 1-391: Verify integration with UI and other components.

The new query functionality looks well-implemented and self-contained. However, it's important to ensure that it's properly integrated with the rest of the application.

Please verify:

  1. The UI components correctly call the startQuery method with appropriate parameters.
  2. The onQueryResults callback is properly handled in the parent component to update the UI with search results.
  3. The query functionality doesn't negatively impact the performance of other features, especially for large log files.
new-log-viewer/src/contexts/StateContextProvider.tsx (1)

Line range hint 1-487: Overall, the changes implement query functionality well with room for minor improvements

The additions to the StateContextProvider successfully implement new query functionality. The changes are consistent across the interface definition, state initialization, and context provider. The startQuery function and the handling of query results are implemented correctly.

There are a few areas for potential improvement:

  1. The QUERY_RESULT case in handleMainWorkerResp could be refactored for better readability and robustness.
  2. Consider clearing existing query results before starting a new query in the startQuery function.

These minor adjustments would enhance the overall quality and maintainability of the code.

Comment on lines +285 to +296
case WORKER_RESP_CODE.QUERY_RESULT:
setQueryResults((v) => {
args.results.forEach((resultsPerPage, queryPageNum) => {
if (false === v.has(queryPageNum)) {
v.set(queryPageNum, []);
}
v.get(queryPageNum)?.push(...resultsPerPage);
});

return v;
});
break;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Consider refactoring the QUERY_RESULT case for clarity and robustness

The implementation of the QUERY_RESULT case is functional, but there are opportunities for improvement:

  1. Use a more descriptive variable name instead of v for better readability.
  2. Consider simplifying the state update logic using Map methods.
  3. Add error handling for potential type mismatches or unexpected data structures.

Here's a suggested refactor:

case WORKER_RESP_CODE.QUERY_RESULT:
    setQueryResults((prevResults) => {
        const newResults = new Map(prevResults);
        args.results.forEach((resultsPerPage, queryPageNum) => {
            if (typeof queryPageNum !== 'number' || !Array.isArray(resultsPerPage)) {
                console.error(`Invalid data structure for page ${queryPageNum}`);
                return;
            }
            const existingResults = newResults.get(queryPageNum) || [];
            newResults.set(queryPageNum, [...existingResults, ...resultsPerPage]);
        });
        return newResults;
    });
    break;

This refactored version improves readability, simplifies the logic, and adds basic error checking.

Co-authored-by: Junhao Liao <junhao@junhao.ca>
Copy link
Collaborator

@junhaoliao junhaoliao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I verified the behaviour with a simple query button added in the menubar which invokes the startQuery handler provided by the state context provider, and the result look expected.

For the PR title, how about:

new-log-viewer: Add log query support in `StateContextProvider`.

@Henry8192 Henry8192 changed the title new-log-viewer: Add log query feature new-log-viewer: Add log query support in StateContextProvider. Oct 19, 2024
@Henry8192 Henry8192 merged commit 10599f4 into y-scope:main Oct 19, 2024
2 checks passed
@Henry8192 Henry8192 deleted the log-query branch October 21, 2024 20:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants